Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 368263 - [xbase][types] AssertionError
Summary: [xbase][types] AssertionError
Status: CLOSED FIXED
Alias: None
Product: TMF
Classification: Modeling
Component: Xtext (show other bugs)
Version: 2.2.1   Edit
Hardware: PC Mac OS X - Carbon (unsup.)
: P3 major (vote)
Target Milestone: M5   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-01-10 10:36 EST by Sebastian Zarnekow CLA
Modified: 2017-09-19 17:04 EDT (History)
1 user (show)

See Also:
sebastian.zarnekow: juno+

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Sebastian Zarnekow CLA 2012-01-10 10:36:50 EST 
Will try to find a minimal repro for this one. However, the problem is obvious: You shall not directly call XAbstractFeatureCall#getFeature in the type provider.

java.lang.AssertionError: there is already another assumption about the given proxy. Please make sure that you don't use AbstractFeatureCall#getFeature in the type inference orin your scoping implementation but AbstractTypeProvider#getFeature instead.
	at org.eclipse.xtext.xbase.resource.XbaseResource.assumeLinked(XbaseResource.java:130)
	at org.eclipse.xtext.xbase.resource.LinkingAssumptions.assumeLinkedAndRun(LinkingAssumptions.java:86)
	at org.eclipse.xtext.xbase.linking.FeatureCallChecker.doCheck(FeatureCallChecker.java:240)
	at org.eclipse.xtext.xbase.linking.FeatureCallChecker.checkTypesWithoutGenerics(FeatureCallChecker.java:213)
	at org.eclipse.xtext.xbase.linking.BestMatchingJvmFeatureScope.getBestMatch(BestMatchingJvmFeatureScope.java:137)
	at org.eclipse.xtext.xbase.linking.BestMatchingJvmFeatureScope.getBestMatch(BestMatchingJvmFeatureScope.java:122)
	at org.eclipse.xtext.xbase.linking.BestMatchingJvmFeatureScope.getSingleElement(BestMatchingJvmFeatureScope.java:78)
	at org.eclipse.xtext.linking.impl.DefaultLinkingService.getLinkedObjects(DefaultLinkingService.java:121)
	at org.eclipse.xtext.linking.lazy.LazyLinkingResource.getEObject(LazyLinkingResource.java:175)
	at org.eclipse.xtext.xbase.resource.XbaseResource.access$0(XbaseResource.java:1)
	at org.eclipse.xtext.xbase.resource.XbaseResource$2.exec(XbaseResource.java:227)
	at org.eclipse.xtext.xbase.resource.XbaseResource$2.exec(XbaseResource.java:1)
	at org.eclipse.xtext.util.OnChangeEvictingCache.execWithoutCacheClear(OnChangeEvictingCache.java:121)
	at org.eclipse.xtext.xbase.resource.XbaseResource.getEObject(XbaseResource.java:225)
	at org.eclipse.xtext.xtend2.resource.Xtend2Resource.getEObject(Xtend2Resource.java:88)
	at org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getEObject(ResourceSetImpl.java:219)
	at org.eclipse.emf.ecore.util.EcoreUtil.resolve(EcoreUtil.java:203)
	at org.eclipse.emf.ecore.util.EcoreUtil.resolve(EcoreUtil.java:263)
	at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eResolveProxy(BasicEObjectImpl.java:1483)
	at org.eclipse.xtext.xbase.impl.XAbstractFeatureCallImpl.getFeature(XAbstractFeatureCallImpl.java:161)
	at org.eclipse.xtext.xbase.typing.XbaseTypeProvider.findTypeGuardedXCasePartContainer(XbaseTypeProvider.java:1009)
Comment 1 Sebastian Zarnekow CLA 2012-01-10 10:59:39 EST 
Pushed to master.
Comment 2 Knut Wannheden CLA 2012-01-10 14:52:18 EST 
FWIW this problem seems to occur for instance when combining a switch expression with a contained closure calling a static method. E.g.

 def foo(EObject context) {
   switch (context) {
     EClass:
         context.EAllReferences.map(r|EObjectDescription::create('foo', r))
   }
 }

A workaround is to rewrite the switch using dispatch methods:

 def dispatch foo(EClass context) {
    context.EAllReferences.map(r|EObjectDescription::create('foo', r))
 }
Comment 3 Karsten Thoms CLA 2017-09-19 16:53:38 EDT 
Closing all bugs that were set to RESOLVED before Neon.0
Comment 4 Karsten Thoms CLA 2017-09-19 17:04:28 EDT 
Closing all bugs that were set to RESOLVED before Neon.0