Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 345423

Summary: [serializer][generator] ambiguous type references in AbstractXyzSemanticSerializer
Product: [Modeling] TMF Reporter: Knut Wannheden <knut.wannheden>
Component: XtextAssignee: Project Inbox <tmf.xtext-inbox>
Status: CLOSED FIXED QA Contact:
Severity: normal    
Priority: P3 CC: moritz.eysholdt, sebastian.zarnekow
Version: 2.0.0Flags: moritz.eysholdt: indigo+
Target Milestone: RC2   
Hardware: All   
OS: All   
Whiteboard:
Attachments:
Description Flags
simple patch none

Description Knut Wannheden CLA 2011-05-11 09:42:21 EDT 
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.
Comment 1 Knut Wannheden CLA 2011-05-11 16:08:32 EDT 
Created attachment 195421 [details]
simple patch

Simple patch solving the problem by using qualified names everywhere except for the Ecore package interfaces.
Comment 2 Sebastian Zarnekow CLA 2011-05-12 01:51:22 EDT 
Reproducable with org.eclipse.xtext.generator.ecore.SubTestLanguage and org.eclipse.xtext.parsetree.reconstr.SimpleReconstrTestLanguage
Comment 3 Moritz Eysholdt CLA 2011-05-16 07:32:46 EDT 
pushed to master. All types are now imported explicitly.
Comment 4 Knut Wannheden CLA 2011-05-16 07:53:45 EDT 
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.
Comment 5 Moritz Eysholdt CLA 2011-05-16 09:07:12 EDT 
(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).
Comment 6 Knut Wannheden CLA 2011-05-17 02:05:56 EDT 
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';
Comment 7 Moritz Eysholdt CLA 2011-05-17 08:06:12 EDT 
fixed, once again. hopefully I didn't miss anything this time.
Comment 8 Karsten Thoms CLA 2017-09-19 17:27:12 EDT 
Closing all bugs that were set to RESOLVED before Neon.0
Comment 9 Karsten Thoms CLA 2017-09-19 17:38:27 EDT 
Closing all bugs that were set to RESOLVED before Neon.0