Community
Participate
Working Groups
The generated AbstractXyzSemanticSerializer classes contain a lot of type casts. As these type casts are generated using unqualified type references and there are wildcard imports for potentially multiple EMF generated Java packages, it is possible to end up with ambiguous type references. Also these type references can be ambiguous if the type also exists in java.lang (as e.g. is the case with "Package"). I suppose the simplest solution is to always generate qualified type references, which IMHO is OK.
Created attachment 195421 [details] simple patch Simple patch solving the problem by using qualified names everywhere except for the Ecore package interfaces.
Reproducable with org.eclipse.xtext.generator.ecore.SubTestLanguage and org.eclipse.xtext.parsetree.reconstr.SimpleReconstrTestLanguage
pushed to master. All types are now imported explicitly.
Excellent! Just to make sure: Does this really also solve the corner case where an EClass name conflicts with a Java class from package java.lang? E.g. "Package" as mentioned or "Override". If we want to keep simple names I suggest we integrate with the EMF code generation utilities for this. See CodeGenUtil#isJavaDefaultType() and GenPackage#getJavaLangConflicts() et al.
(In reply to comment #4) > Excellent! > > Just to make sure: Does this really also solve the corner case where an EClass > name conflicts with a Java class from package java.lang? E.g. "Package" as > mentioned or "Override". > > If we want to keep simple names I suggest we integrate with the EMF code > generation utilities for this. See CodeGenUtil#isJavaDefaultType() and > GenPackage#getJavaLangConflicts() et al. good point, I wasn't aware of CodeGenUtil#isJavaDefaultType(). I've improved the generator to always use a type's qualified name if (CodeGenUtil#isJavaDefaultType(simpleName) == true).
The imports and sequence_* methods are now correctly generated but the corresponding type casts must also be qualified in the cases as the unqualified type reference will otherwise refer to the wrong type. The same of course applies when the conflicting type is a type of package java.lang. Example grammar to reproduce both these problems: grammar org.xtext.example.mydsl.MyDsl with org.eclipse.xtext.common.Terminals import "platform:/resource/org.eclipse.xtext.xbase/model/Xbase.ecore" as xbase generate myDsl "http://www.xtext.org/example/mydsl/MyDsl" Model returns XExpression: greetings+=Greeting* overrides+=Override; Greeting returns xbase::XExpression : {xbase::XExpression} 'Hello'; Override : {Override} 'Bye';
fixed, once again. hopefully I didn't miss anything this time.
Closing all bugs that were set to RESOLVED before Neon.0
