Community
Participate
Working Groups
I've got a library with helpers/queries and configuration properties. library Library; configuration property aaa : Integer; helper xxx() : String { return 'asd' + aaa.repr(); } Attempt to use it, like: var lll : Library := new Library(); lll.aaa = 5; log (lll.xxx()); leads to NPE: java.lang.NullPointerException at org.eclipse.m2m.internal.qvt.oml.ast.env.QvtOperationalEvaluationEnv.createInstance(QvtOperationalEvaluationEnv.java:407) at org.eclipse.m2m.internal.qvt.oml.evaluator.QvtOperationalEvaluationVisitorImpl.createInstance(QvtOperationalEvaluationVisitorImpl.java:2013) at org.eclipse.m2m.internal.qvt.oml.evaluator.QvtOperationalEvaluationVisitorImpl.visitInstantiationExp(QvtOperationalEvaluationVisitorImpl.java:809) at org.eclipse.m2m.internal.qvt.oml.evaluator.QvtGenericEvaluationVisitor.visitInstantiationExp(QvtGenericEvaluationVisitor.java:383) at org.eclipse.m2m.qvt.oml.ecore.ImperativeOCL.impl.InstantiationExpImpl.accept(InstantiationExpImpl.java:291) at org.eclipse.m2m.internal.qvt.oml.evaluator.QvtOperationalEvaluationVisitorImpl.visitVariableInitExp(QvtOperationalEvaluationVisitorImpl.java:979) at org.eclipse.m2m.internal.qvt.oml.evaluator.QvtGenericEvaluationVisitor.visitVariableInitExp(QvtGenericEvaluationVisitor.java:407) at org.eclipse.m2m.qvt.oml.ecore.ImperativeOCL.impl.VariableInitExpImpl.accept(VariableInitExpImpl.java:262) at org.eclipse.m2m.internal.qvt.oml.evaluator.QvtOperationalEvaluationVisitorImpl.visitOperationBody(QvtOperationalEvaluationVisitorImpl.java:956) at org.eclipse.m2m.internal.qvt.oml.evaluator.QvtOperationalEvaluationVisitorImpl.visitEntryOperation(QvtOperationalEvaluationVisitorImpl.java:455) at org.eclipse.m2m.internal.qvt.oml.evaluator.QvtGenericEvaluationVisitor.visitEntryOperation(QvtGenericEvaluationVisitor.java:443) at org.eclipse.m2m.internal.qvt.oml.expressions.impl.EntryOperationImpl.accept(EntryOperationImpl.java:67) at org.eclipse.m2m.internal.qvt.oml.evaluator.QvtOperationalEvaluationVisitorImpl.executeImperativeOperation(QvtOperationalEvaluationVisitorImpl.java:1575) at org.eclipse.m2m.internal.qvt.oml.evaluator.QvtOperationalEvaluationVisitorImpl.runMainEntry(QvtOperationalEvaluationVisitorImpl.java:2082) at org.eclipse.m2m.internal.qvt.oml.evaluator.QvtOperationalEvaluationVisitorImpl$1.invoke(QvtOperationalEvaluationVisitorImpl.java:895) at org.eclipse.m2m.internal.qvt.oml.evaluator.QvtOperationalEvaluationVisitorImpl.doVisitTransformation(QvtOperationalEvaluationVisitorImpl.java:870) at org.eclipse.m2m.internal.qvt.oml.evaluator.QvtOperationalEvaluationVisitorImpl.visitModule(QvtOperationalEvaluationVisitorImpl.java:724) at org.eclipse.m2m.internal.qvt.oml.evaluator.QvtGenericEvaluationVisitor.visitModule(QvtGenericEvaluationVisitor.java:371) at org.eclipse.m2m.internal.qvt.oml.expressions.impl.ModuleImpl.accept(ModuleImpl.java:622) at org.eclipse.m2m.internal.qvt.oml.runtime.project.QvtInterpretedTransformation.evaluate(QvtInterpretedTransformation.java:170) at org.eclipse.m2m.internal.qvt.oml.runtime.project.QvtInterpretedTransformation.run(QvtInterpretedTransformation.java:118) at org.eclipse.m2m.internal.qvt.oml.runtime.launch.QvtLaunchConfigurationDelegateBase.doLaunch(QvtLaunchConfigurationDelegateBase.java:182) at org.eclipse.m2m.internal.qvt.oml.runtime.launch.QvtLaunchConfigurationDelegateBase.doLaunch(QvtLaunchConfigurationDelegateBase.java:137) at org.eclipse.m2m.internal.qvt.oml.runtime.launch.QvtLaunchConfigurationDelegate$1.run(QvtLaunchConfigurationDelegate.java:65) at org.eclipse.m2m.internal.qvt.oml.common.launch.SafeRunner$SameThreadRunner.run(SafeRunner.java:33) at org.eclipse.m2m.internal.qvt.oml.common.launch.SafeRunner$1.run(SafeRunner.java:26) at org.eclipse.m2m.internal.qvt.oml.common.launch.ShallowProcess.run(ShallowProcess.java:41) at org.eclipse.m2m.internal.qvt.oml.common.launch.ShallowProcess.run(ShallowProcess.java:32) at org.eclipse.m2m.internal.qvt.oml.runtime.launch.QvtLaunchConfigurationDelegate$3.run(QvtLaunchConfigurationDelegate.java:98) at java.lang.Thread.run(Thread.java:595) Perhaps, bug #259376 and bug #256673 might be related, as there's definitely a mechanism to instantiate a module, which fails in this scenario.
That's rather result of bug #250628 implementation. It looks like explicit instantiation of libraries is not permitted. Specification "8.2.1.2 Library": [spec] However, in contrast with operational transformations there is no main operation to execute and the instantiation of the class is always implicit. When a library is imported with access semantics, an implicit instance is created and used to access the properties and operations of the library. When a library is imported with extension semantics, normal class inheritance applies as for operational transformations. [/spec] So the bug is that explicit instantiation of library not prohibited by semantic analyzer (validation).
Created attachment 233727 [details] The patch reports an error for cases where a library name is used a type name
Created attachment 233728 [details] A unit test for the patch
Isn't this a little bit too restrictive? I sometimes like to prefix contextless mapping calls with the parent module's name: var x : EClass = map MyLibrary::createEClass(); Would this be prohibited by the patch?
No, it won't be prohibited. The sample code you provided compiles OK with the patch.
Comment on attachment 233727 [details] The patch reports an error for cases where a library name is used a type name The patch is correct. Junit test verifies all cases where library is meant to be used as a type.
Test cases was extended to verify that fully qualified access to library's features is not prohibited. Pushed to master. Commit ID: bea746fa16c728a37018230f44489f8bf72d194e
The following code does not compile anymore: mapping m1() : EObject inherits MyLibrary::m0 {...} I have other cases in mind where it might be reasonable to use a library as a type, try to think of a transformation variable typed over a library that the transformation extends. var x : MyLibary = new MyTransformation(...); Yes, it's useless since a library instance has no interface to invoke, but I think it should still be valid code.
Created attachment 233827 [details] The patch reports an error for cases where a library name is used a type name The new patch includes additional fix for handling <LibName::MapName> scoped names.
I hope my second example above clearly demonstrates that there could be much circulating user code relying on libraries as types. Why not addressing the original bug directly, forbidding libraries only in constructors, object expressions and mappings?
