Community
Participate
Working Groups
Build Identifier: Helios, Xtext 1.0.2 A grammar ConcreteDSL extends grammar AbstractDSL. Both grammars use an external model. Grammar AbstractDSL defines Rule Model, grammar ConcreteDSL redefines Model with different structure. When calling AbstractDSLGrammarAccess.getRuleModel(), it throws a ClassCastException. Reproducible: Always Steps to Reproduce: I will attach an example.
Created attachment 196562 [details] Eclipse projects with example to reproduce the CCE
This would case the CCE: AbstractDSL: Model returns abstractDSL::Model: greetings+=Greeting*; ConcreteDSL: Model returns abstractDSL::Model: greetings+=Greeting* text=STRING; Hint: Can easily be avoided by using a different name within the subgrammar. AbstractDSL: Model returns abstractDSL::Model: greetings+=Greeting*; ConcreteDSL: ConcreteModel returns abstractDSL::Model: greetings+=Greeting* text=STRING;
(In reply to Bug 347171 comment #1) > Most likely related to bug 347171 Yes this looks very like a duplicate. (In reply to comment #2) > Hint: > Can easily be avoided by using a different name within the subgrammar. Except when the redefine is a deliberate design for re-use.
Not 2.1
*** Bug 366786 has been marked as a duplicate of this bug. ***
Note that bug 366786 describes a much more common use case - the adaption of Xbase, which is likely to happen very often in the future as many DSLs make use of Xbase. This might shift the priority of this issue.
Is there any chance that this bug will be ever addressed? Or is it simply not wished that existing grammar rules are overridden by subgrammars (especially in the case of Xbase)?
(In reply to comment #7) > Is there any chance that this bug will be ever addressed? > Or is it simply not wished that existing grammar rules are overridden by > subgrammars (especially in the case of Xbase)? Will likely be fixed for Juno. Unlikely before M6.
(In reply to comment #8) > Will likely be fixed for Juno. Unlikely before M6. Ping. M6 is done. It would be really good to see a fix for this since when using the new Serializer, there is a significant regression in useable behaviour for Complete OCL.
Pong! We have an internal project on hold because of / waiting for this... (bug 366786). Would love to see progress - will help testing.
Preliminary scheduled for M7. Not sure if it'll make it, though.
pushed to master. GrammarAccess now always use the grammar they were generated for.
I am afraid I have to ask to reopen this issue. The class cast exception is gone, but I am now getting java.lang.RuntimeException: The context 'XMemberFeatureCall_XMemberFeatureCall_1_1_0_0_0' is not valid for type 'XNumberLiteral' Recommended contexts for type 'XNumberLiteral': XMemberFeatureCall_XMemberFeatureCall_1_1_0_0_0 I assume the problem is within the class Abstract[supergrammar]SemanticSequencer here as it compares the context with object identity (==) instead of object equals. To reproduce the problem, please see the junit test that I have provided at https://bugs.eclipse.org/bugs/show_bug.cgi?id=366786#c0, which is available on Github (https://github.com/openhab/xtext-tests).
The equality comparison is unlikely causing the issue. Reopened for further investigation.
(In reply to comment #13) > I am afraid I have to ask to reopen this issue. > > The class cast exception is gone, but I am now getting > > java.lang.RuntimeException: The context > 'XMemberFeatureCall_XMemberFeatureCall_1_1_0_0_0' is not valid for type > 'XNumberLiteral' > Recommended contexts for type 'XNumberLiteral': > XMemberFeatureCall_XMemberFeatureCall_1_1_0_0_0 > > I assume the problem is within the class > Abstract[supergrammar]SemanticSequencer here as it compares the context with > object identity (==) instead of object equals. > > To reproduce the problem, please see the junit test that I have provided at > https://bugs.eclipse.org/bugs/show_bug.cgi?id=366786#c0, which is available on > Github (https://github.com/openhab/xtext-tests). I've opened a separate ticket for this. See bug #378325
Requested via bug 522520. -M.
