Loosen type rules for transitive closure

[eclipse-viatra-bot]

| --- | --- | | Bugzilla Link | 559522 | | Status | NEW | | Importance | P3 normal | | Reported | Jan 24, 2020 11:39 EDT | | Modified | Nov 23, 2020 08:30 EDT | | Version | 2.3.0 | | Reporter | Zoltan Ujhelyi |

Description

Given the current type rules for transitive closure (both variables should be compatible with each other), in the following pattern the type of the variable mainReq cannot be calculated:

pattern unsatisfiedRequirementsUnderPackage(root : Package, req : Class){\ PackageableElement.owningPackage+(mainReq, root);\ Class.nestedClassifier*(mainReq, req);\ }

The detailed evaluation goes as follows:

1. In the first transitive closure (owningPackage) the inferrer states mainReq should be compatible with both PackageableElement and Package, saying the result should be a Package.
2. In the second transitive closure (nestedClassifier) the inferrer states mainReq should be compatible with both Class and Classifier, resulting in a type of Class.
3. Combining the first two points, it expects the variable mainReq should be both Class and Package which is impossible.

This result is clearly unexpected, as saying mainReq is a Classifier should fulfil all real constraints. The type rules should be loosened to handle this case correctly (while not breaking anything else).

Given it is easy to do a mistake in type rules resulting in subtly broken parse errors, this issue should not be triggered to a bugfix release but only to a new feature release.

[eclipse-viatra-bot]

By Zoltan Ujhelyi on Feb 13, 2020 15:21

The exact situation is even worse than expected: because of a mistaken condition no type rules are considered for inline transitive closures by the type inferrer. The issue shoul include fixing both that and loosening the rules to make sure the problematic pattern parses and compiles correctly.

[eclipse-viatra-bot]

By Zoltan Ujhelyi on May 18, 2020 13:04

Postponing issues that will not be solved for version 2.5.

[eclipse-viatra-bot]

By Zoltan Ujhelyi on Nov 23, 2020 08:30

Mass postponing of issues to the 2.6 timeframe.