Community
Participate
Working Groups
Hi, I noticed a difference between the compiler and the runtime evaluation of a script. Here is an example that shows the issue: [module workflow('http://www.eclipse.org/emf/2002/Ecore')/] [template public main(a : EClass)] [let idFeature : EAttribute = eIDAttribute] [sub()/] [/let] [/template] [template public sub(a : EStructuralFeature)] Feature [name/] [/template] The compiler never complains but the runtime never goes into sub() template! I have to modify the call into the sub() to [idFeature.sub()/] It seems that idFeature is pushed as the new 'self' in the compiler while it is not in the runtime evaluation. I don't have any clue about who is rightful but it should coherent ;) (or at least the runtime should throw an exception instead of silently doing nothing) Best regards, Mikael
The accurate behavior here is the engine's : neither "if" nor "let" change the context of an evaluation. We have to provide a compilation error for such uses.
>> I don't have any clue about who is rightful but it should coherent >> The accurate behavior here is the engine's I don't know who's right here between the parser and the engine but since we just have to pick one and since, if the engine is right, I just have to remove four lines of code in the parser, let's say the engine is right, it's easier that way :D "Let" and "For" blocks will not change the context anymore in the parser. Unit tests have also been added to ensure the non regression. The fix has been contributed on HEAD. It will be available in Acceleo 3.1.0M7.
I am reopening this issue since, after careful evaluation, the previous solution is not an option for several reasons: 1- this problem does not appear all the time since most of the time the parser will transform the template/query call with an implicit variable to a template/query call with the "current" self as an explicit variable and the engine will not complain. With the previous patch, all those call are now treated as error and we will create a situation in which valid module in Acceleo 3.0.x would have dozens of errors starting with Acceleo 3.1.0M7 (see the EEF project 130+ errors with this fix). 2- even if there are no errors, the previous fix can change the behavior of the generator: [template public a(myClass : EClass)] [for (myOperation : EOperation | myClass.eAllOperations)] [b()/] [/for] [/template] [template public b(myNamedElement : ENamedElement)] [myNamedElement.name/] [/template] This would previously generate the name of all the operations of the given class, now it would generate the name of the class. It does not seem very clear/logical while reading the template "a" (one could reasonably argue that implicit call are never very clear in the first place). This produce very complex error in existing generators (again, see the EEF project). The bug raised by Mikael appears only in minor cases since (as stated in "1") most of the time the engine does not now that the call is using an implicit variable. The behavior of the parser will be restored right now, the unit tests that have been contributed will be adapted and the engine will have to adapt even if it shouldn't even know about the existence of an implicit call. The parser should resolve the variables of those calls in the first place.
Closing this one again. The new behavior is: -> template/queries/for are creating a new context -> if/let are not creating a new context
