Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 332634 - CCE in LazyLinkingResource#resolveLazyCrossReferences(...)
Summary: CCE in LazyLinkingResource#resolveLazyCrossReferences(...)
Status: CLOSED FIXED
Alias: None
Product: TMF
Classification: Modeling
Component: Xtext (show other bugs)
Version: 2.0.0   Edit
Hardware: All All
: P3 normal (vote)
Target Milestone: M5   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-12-15 09:26 EST by Sebastian Benz CLA
Modified: 2017-09-19 17:14 EDT (History)
3 users (show)

See Also:
sebastian.zarnekow: indigo+


Attachments
Bug fix & tests (4.77 KB, application/octet-stream)
2010-12-15 10:08 EST, Sebastian Benz CLA
no flags Details
Updated bug fix & test (5.58 KB, application/zip)
2010-12-15 11:16 EST, Sebastian Benz CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Sebastian Benz CLA 2010-12-15 09:26:38 EST
Subclasses of XAbstractFeatureCallImpl return in getArguments() a BasicEList instead of an EObjectResolvingEList. Derived features should use the corresponding EList implementations. This causes a CCE in LazyLinkingResource#resolveLazyCrossReference(...) where feature lists are cast to InternalEList. I attached a patch for the XExpression classes with corresponding tests.
Comment 1 Sebastian Benz CLA 2010-12-15 09:35:59 EST
I accidentally added an empty test case (XBinaryOperationTest) to the patch, which can be safely ignored.
Comment 2 Sebastian Benz CLA 2010-12-15 10:08:55 EST
Created attachment 185228 [details]
Bug fix & tests
Comment 3 Sebastian Benz CLA 2010-12-15 11:16:33 EST
Created attachment 185237 [details]
Updated bug fix & test
Comment 4 Sebastian Zarnekow CLA 2011-01-04 04:49:38 EST
Patch has been applied. Thanks.
Comment 5 Sven Efftinge CLA 2011-01-19 12:35:16 EST
getArguments is now called getAllArguments and is no longer an EReference but an EOperation.

I wonder whether we should exclude 'derived' and 'transient' cross references in 
LazyLinkingResource.resolveLazyCrossReference(InternalEObject, EStructuralFeature)

An comments?
Comment 6 Sebastian Zarnekow CLA 2011-01-19 12:42:34 EST
(In reply to comment #5)
> I wonder whether we should exclude 'derived' and 'transient' cross references
> in 
> LazyLinkingResource.resolveLazyCrossReference(InternalEObject,
> EStructuralFeature)
> 
> An comments?

I think it should behave like the EObjectValidator when it tries to detect unresolved proxies.
Comment 7 Knut Wannheden CLA 2011-01-19 13:55:08 EST
(In reply to comment #6)
> (In reply to comment #5)
> > I wonder whether we should exclude 'derived' and 'transient' cross references
> > in 
> > LazyLinkingResource.resolveLazyCrossReference(InternalEObject,
> > EStructuralFeature)
> > 
> > An comments?
> 
> I think it should behave like the EObjectValidator when it tries to detect
> unresolved proxies.

I agree. In our projects we've used both transient and derived references which we normally want to be checked by the validation.
Comment 8 Sven Efftinge CLA 2011-01-20 00:17:36 EST
> 
> I agree. In our projects we've used both transient and derived references which
> we normally want to be checked by the validation.

But derived or transient features do not contain lazy proxies, do they?
Comment 9 Knut Wannheden CLA 2011-01-20 01:04:23 EST
(In reply to comment #8)
> > 
> > I agree. In our projects we've used both transient and derived references which
> > we normally want to be checked by the validation.
> 
> But derived or transient features do not contain lazy proxies, do they?

In our case they actually sometimes do. In these cases the linker will in afterModelLinked() have installed a lazy proxy based on the node model for another EAttribute. We then dub this a "derived attribute based reference".

One use case for this is languages like Ada with separate package specification and body files, where the package body name should also be an implicit reference to its package specification. Parsing this as a cross reference in the first place is not so good as this may cause problems for the builder when computing the corresponding EObjectDescription's name (or would alternatively require extracting the name from the node model). 

Of course subsequent (i.e. post parse) changes to the EAttribute must be tracked by an EAdapter, at which point the EReference no longer has a lazy proxy.
Comment 10 Karsten Thoms CLA 2017-09-19 17:02:57 EDT
Closing all bugs that were set to RESOLVED before Neon.0
Comment 11 Karsten Thoms CLA 2017-09-19 17:14:30 EDT
Closing all bugs that were set to RESOLVED before Neon.0