[qvtr] Domain analysis needed for awkward variables

[eclipse-qvtd-bot]

| --- | --- | | Bugzilla Link | 517038 | | Status | NEW | | Importance | P3 normal | | Reported | May 22, 2017 01:37 EDT | | Modified | Jun 10, 2017 08:39 EDT | | Depends on | 517524 | | Blocks | 517072 | | See also | 459984, 512683 | | Reporter | Ed Willink |

Description

The current example hstm2fstm fails with

java.lang.IllegalStateException: Failed to determine other pattern for leafToStates : Set(HierarchicalStateMachine::State) = hierarchicalToState.oclAsSet()->closure(1 : HierarchicalStateMachine::State[1] | 1.nestedStates)->select(1 : HierarchicalStateMachine::State[?] | 1.nestedStates->isEmpty()) PREDICATE:hier\ at org.eclipse.qvtd.compiler.internal.qvtr2qvtc.RelationVariableAnalysis.getOtherDomain(RelationVariableAnalysis.java:361)\ at org.eclipse.qvtd.compiler.internal.qvtr2qvtc.RelationVariableAnalysis.synthesize(RelationVariableAnalysis.java:494)

because in:

top relation HierachicalTransition2FlatTransition\
{\
    leafFromStates : Set(hierMM::State) = hierarchicalFromState->closure(nestedStates)->select(nestedStates->isEmpty());\
    leafToStates : Set(hierMM::State) = hierarchicalToState->closure(nestedStates)->select(nestedStates->isEmpty());

the eliminated domain analysis is needed to identify the domain of leafFromStates.

Workaround: use the current test version:

when { ...\ this.getLeafStates(hierarchicalFromState)->includes(leafFromState);\ this.getLeafStates(hierarchicalToState)->includes(leafToState);\ }

that pushes it into a query and so has no problematic variable.

Fix: re-introduce the domain analysis or allow and require non-primitive variables to be declared within their domains.

[eclipse-qvtd-bot]

By Ed Willink on May 22, 2017 09:07

(In reply to Ed Willink from comment #0)

The current example hstm2fstm fails with

Bug 517072 deals with the failure to detect the regression in a JUnit test.

[eclipse-qvtd-bot]

By Ed Willink on May 23, 2017 11:47

For RC1, the problem example has been changed to use a query avoiding the challenging variable, Bug 517072 requires reversion.

This bug requires an analysis that allows the reversion.

[eclipse-qvtd-bot]

By Ed Willink on May 31, 2017 06:33

(In reply to Ed Willink from comment #0)

Fix: re-introduce the domain analysis

There never was a QVTrDomainUsageAnalysis.

The 'working' Neon example relied on:

variableAnalysis.setPredicate(ClassUtil.nonNullState(corePattern.getArea()));\ // FIXME need QVTrDomainAnalayis

in the AbstractEnforceableRelationDomain2CoreMapping constructor.

and unfortunately the 'predicate' support got lost as VariableAnalysis evolved.

[eclipse-qvtd-bot]

By Ed Willink on May 31, 2017 07:51

Bug 517524 motivates an AS change so that the domain of shared variables is unambiguous in the AS and so unambiguous for QVTr2QVTc.

The QVTr CS is however ambiguous. Bug 517524 suggests that a QVTo-like @model might disambiguate.

But this should not be necessary. A shared variable can be declared with an explicitly qualified type. For the troublesome case of an endogenous transformation, the multiply-used metamodel may be imported twice with two distinct aliases so that the shared variable qualification uses the appropriate alias. Fine in principle, but not losing the alias during Xtext parsing, and forcing the alias during Xtext serialization may be tricky.

[eclipse-qvtd-bot]

By Ed Willink on Jun 10, 2017 08:31

(In reply to Ed Willink from comment #3)

There never was a QVTrDomainUsageAnalysis.

So we add one to support use of the prevailing ambiguities during CS2AS.