Community
Participate
Working Groups
3.10.M4a Given a loop such as [for (precedence : Precedence | pkg.ownedPrecedence)] [emitPrecedence(precedence)/] [/for] in which emitPrecedence is in a separate module, changing "Precedence" to "Precedence1" introduces an Invalid Type error, and an "Illegal Operation Signature" error; not unreasonable. However changing "Precedence1" back to "Precedence" corrects only the "Invalid Type". Saving the file does not remove the markers. Only an edit of the separate module removes the errors.
M6a: I think this has got worse. With two files sharing a common file, it is now necessary to start an edit on all importing files, then edit and save the imported file, before saving the importing files in order to clear the errors.
I have been tracking this bug for a very long time and I didn't knew where it was coming from. This bug is the same bug as https://bugs.eclipse.org/bugs/show_bug.cgi?id=337567 and several other bugs. It is all about incremental compilation and the loss of templates/queries from imported/extended modules. Today, I have found where this was coming from: The method "org.eclipse.ocl.AbstractTypeResolver#findShadowClass(C type)" assumes that two shadow classes must be referencing exactly the same instance: "if (getShadowedClassifier(next) == type) {...}" Which is true during a full build, but with an incremental build we can have multiple instances of our types (one instance of of each type per module imported). So if you have: Module 1 - template1 (a: MyClass) Module 2 - template2 (a: MyClass) - template3 (a: MyClass) And if the module 1 is importing the module 2, then during the incremental build of the module 1 you would have two shadow classes since each module will have an instanceof of the MyClass type: MyClass_Class defining the operation: template1 MyClass_Class defining the operation: template2 and template3 When OCL would look for the operation of MyClass available, it would look for the first shadow object matching the type MyClass. Since we are compiling the module 1, the first object would be: "MyClass_Class defining the operation: template1" All the operations from the current module would be found but the templates/queries imported from other modules are not found. Thus all call from the module 1 to template 2 or template 3 would result in a "Cannot find operation "template 2/3" for the type "MyClass". The fix will create an AcceleoTypeResolver that will just change this: "if (getShadowedClassifier(next) == type) {...}" To prevent the creation of multiple shadow classes for different instances of the same type. If you look at the emtl file for your module, you should see an "additions" package containing several times the same shadow class, one time per imported/extended module and each of those shadow class should contain the imported templates/queries from one specific imported/extended module. It work when compiling the imported module because it forces the compilation of the importing module. If I'm right you would have the same behavior as with a full build, everything is in memory so we have only one instance of each type so we don't have any problem with the type resolver. It will require several tests to ensure that we don't have any regressions and to be sure that it covers all cases but with my examples, it seems to work pretty well :) I'll close this bug and the similar bugs after proper testing.
*** Bug 337567 has been marked as a duplicate of this bug. ***
*** Bug 295598 has been marked as a duplicate of this bug. ***
