[CG] LookupCodeGenerator generates erroneous code

[eclipse-ocl-bot]

| --- | --- | | Bugzilla Link | 466712 | | Status | RESOLVED FIXED | | Importance | P3 normal | | Reported | May 07, 2015 07:02 EDT | | Modified | May 08, 2015 09:25 EDT | | Reporter | Adolfo Sanchez-Barbudo Herrera |

Description

LookupCodeGenerator might generate erroneous code, with valid lookup descriptions, under certain circumstances:

Particularly, when generating the lookupVisitor for QVTo I've found problems when we access a property in the lookupDescription with the same name of any of the visitor fields, in this case one property access called "context". Attachment (coming next) shows the faulty generated code in which the local java variable for the "context" property access, hides the protected field "context" of the visitor.

The original lookup description is [1]. To invoke the visitor generator execute [2].

The configuration of OCL/QVTo branches comes next, once I've got the bugzilla number.

I've also got a workaround in branch (OCL/QVTo) asanchez/397429, in which the context is hold/copied in a field of the generated lookup visitor, but with a different/specific name reducing the chances of name clashing. asanchez/397429 is a workaround, so it obviously doesn't solves the generator bug.

[1] org.eclipse.qvto.examples.pivot.qvtoperational\model\QVTOperationalNameResolution.ocl\ [2] org.eclipse.qvto.examples.build\src\org\eclipse\qvto\examples\build\GenerateQVToAutoASModels.mwe2

[eclipse-ocl-bot]

By Adolfo Sanchez-Barbudo Herrera on May 07, 2015 07:06

Created attachment 253283 SS with the erroneous code

OCL&QVTo asanchez/466712 branches pushed

Capture.PNG

[eclipse-ocl-bot]

By Adolfo Sanchez-Barbudo Herrera on May 07, 2015 07:17

BTW,

I've just realized that "master" has included my workaround[1] to overcome the issue for the particular generation of the LookupVisitor for the QVTo.NameResolution.ocl lookup description. We have to bear in mind that when resolving this bugzilla

[1] commit 95c0f069826fc5a499db92957e731f459a035096

[eclipse-ocl-bot]

By Ed Willink on May 07, 2015 11:30

I'm confused.

Please clarify which commits demonstrate the problem without the confusion of workarounds.

[eclipse-ocl-bot]

By Adolfo Sanchez-Barbudo Herrera on May 07, 2015 11:55

Hi Ed,

(In reply to comment #3)

I'm confused.

Please clarify which commits demonstrate the problem without the confusion of workarounds.

OCL: commit bd2df0d6d4f883e54b8c4aae489698780195b309\ QVTo: commit ffc30d5b18081cf5d17db3dbe40de152c10753a9

Just checkout to OCL&QVTo asanchez/466712 branches

[eclipse-ocl-bot]

By Ed Willink on May 08, 2015 06:55

(In reply to Adolfo Sanchez-Barbudo Herrera from comment #2)

I've just realized that "master" has included my workaround[1] to overcome

Your workaround looks pretty close. The context is indeed a Java Property not a variable, so introducing a 'variableEnv' that magically clones 'context' is close. Better to make 'context' a useable property in its own right, which I think just requires an ability to indicate that it is an inherited rather than locally generated property.

[eclipse-ocl-bot]

By Ed Willink on May 08, 2015 09:25

(In reply to Ed Willink from comment #5)

The context is indeed a Java Property not a variable

But you need a Variable for a to access "context" in "context." using a VariableExp rather than a PropertyCallExp.

The fix pushed to master creates a CGVariable reserves its name in the GlobalContext so that it doesn't get repeatedly disambiguated.

commit f314fad68fe65633339001663eee2f3ded6ad008

Pushed to master for RC1.