ST6RI-894 Inconsistent name resolution for qualified name as target of redefinition

[seidewitz]

This PR fixes a bug that could case inconsistent name resolution for a qualified name used as the target of a nested redefinition.

Background

Consider the following SysML model:

item def A {
    item x { 
        attribute y;
    }
}

item def B :> A {
	item x :>> x {
		attribute :>> x::y;
	}
}

When a file with this model is initially opened in the Eclipse Xtext editor, and the attribute usage nested in B::x (commented) is viewed in the outline, the target x::y of the redefinition is shown as resolving to the attribute usage itself (that is B::x::y). Previously, however, if a space was typed so that the model was re-parsed and validated, the outline then showed that the target of the redefinition had resolved instead to the attribute usage A::x::y. On the other hand, if the model is entered in Jupyter, the attribute usage in question generates the error “Featuring types of redefining feature and redefined feature cannot be the same”, indicating that x::y has resolved to B::x::y, making the redefinition invalid.

Cause

• When the model is opened in the Xtext editor, no validation is done initially. To be viewed in the outline, however, the qualified name x::y has to be resolved as the target of a redefinition.
  • The name resolution algorithm initially resolves x::y to A::x::y, which determines that the effective name of the redefining attribute is y.
  • But this means that, in the scope of B (the parent of B::x), x::y then resolves to B::x::y, and the resolution is updated to this element (i.e., the redefining attribute usage itself).
  • This is also what happens in the Jupyter deployment, but, in the environment, validation is also carried out, resulting in the error message.
• In the Xtext editor (but not in Jupyter), after a change to the model text, the text is re-parsed, and then Xtext performs reconcilation and resolves all cross-reference proxies.
  • In the case of a Redefinition relationship, it checks the general Relationship::target value before the Redefinition::redefinedFeature value.
  • The source and target for any kind of Specialization are lists containing the single values of the specific and general properties of the Specialization, respectively. The getSource and getTarget methods in SpecializationImpl implement this by creating a list and then inserting the specific or general values into the list.
  • In the generated code for these methods, the getSpecific and getGeneral methods are used, which will resolve proxies if necessary, so the returned lists never contain (resolvable) proxies. However, Previously, these calls had been replaced by calls to basicGetSpecific and basicGetGeneral, which do not do proxy resolution.
  • So, when the target of the Redefinition was found to be a proxy, Xtext resolved the proxy and then updated the target list with the resolved element. However, since the list was created in the getTarget method, this did not result in the redefinedFeature property value actually being updated for the Redefinition, so the value was left as the earlier resolution to A::x::y.

Changes

1. SpecializationImpl.java – Replaced the non-generated versions of getSource and getTarget with the generated versions. This resolves the bug, so, in the example model above, x::y always resolves to B::x::y. (A comment in the code indicated that the changes had been made to these methods to prevent circular name resolution. However, testing indicated that the generated version without the changes no longer caused circular resolution errors.)
2. ConstructorExpressionAdapter.java – Revised the adding of the implied result type to the result parameter of a constructor expression so that it is added immediately when the result parameter is added. Otherwise, the above change resulting named arguments of constructor expressions having spurious validation errors.
3. Redefinition_Scoping.kerml.xt – Added a KerML Xpect test using a KerML version of the above example model, to check that the nested redefinition causes the expected error (i.e., that the redefining feature redefines itself).
4. Library and example models – The following models contained cases of nested redefinitions that caused validation errors once the change to SpecializationImpl was made. These were corrected by adding further qualification to the redefinition target names.
   • Domain Libraries/Geometry/ShapeItems.sysml
   • kerml/src/examples/KerML Spec Annex A Examples/A-3-8-ChangingFeatureValues.kerml

Note

This PR corrects the bug in the implementation that caused name resolution to be inconsistent in the specific case of cross-reference link resolution after a text change in the Xtext editor. See KERML12-140 on the wider issue of what the proper resolution should be according to the specification. Depending on the ultimate resolution of KERML12-140, the implementation may be updated again in this area in the future.

[seidewitz]

Closed in preference for PR #717.