Bug 362663

Comment 1 Oliver L 2011-11-02 09:03:30 EDT

Created attachment 206322 [details]
Xtend error

Comment 2 Sebastian Zarnekow 2011-11-02 09:15:38 EDT

Please try to do an explicit refresh (F5) on the project. A restart may help, too (JDT caches or plugin dependencies seem to be outdated or something like that).

Comment 3 Oliver L 2011-11-02 09:54:34 EDT

(In reply to comment #2)
> Please try to do an explicit refresh (F5) on the project. A restart may help,
> too (JDT caches or plugin dependencies seem to be outdated or something like
> that).

Hi Sebastian,

refreshed, cleaned, restarted, closed/opened... it all didn't work.

I just created a little project in order to reproduce the error, but it doesn't occur there. And I can not provide the whole project, because it's a customer project.

Comment 4 Benjamin Schwertfeger 2011-11-02 17:29:17 EDT

I've seen a similar problem with a property from a super class. I'd no time to analyse yet, but perhaps you can see some parallels. I have four classes in different project where the last extends them like this

A extends B extends C extends Named
A and B are in project pAB
C is in project pC
Named is in project pNamed
pGen contains the Xtend file

pAB depends on pC and reexport it
pC depends on pNamed and reexport it
pGEn depends on pAB

The property from Named (lets call it name) can't be accessed without cast:

a.name //<fails
(a as Named).name //<works for me

Comment 5 Oliver L 2011-11-02 17:43:12 EDT

(In reply to comment #4)
> I've seen a similar problem with a property from a super class. I'd no time to
> analyse yet, but perhaps you can see some parallels. I have four classes in
> different project where the last extends them like this
> 
> A extends B extends C extends Named
> A and B are in project pAB
> C is in project pC
> Named is in project pNamed
> pGen contains the Xtend file
> 
> pAB depends on pC and reexport it
> pC depends on pNamed and reexport it
> pGEn depends on pAB
> 
> The property from Named (lets call it name) can't be accessed without cast:
> 
> a.name //<fails
> (a as Named).name //<works for me

That might be related as the comments getter is defined in a superinterface, too. I'm going to try the cast workaround tomorrow.

Comment 6 Oliver L 2011-11-03 04:15:38 EDT

(In reply to comment #5)
> (In reply to comment #4)
> > I've seen a similar problem with a property from a super class. I'd no time to
> > analyse yet, but perhaps you can see some parallels. I have four classes in
> > different project where the last extends them like this
> > 
> > A extends B extends C extends Named
> > A and B are in project pAB
> > C is in project pC
> > Named is in project pNamed
> > pGen contains the Xtend file
> > 
> > pAB depends on pC and reexport it
> > pC depends on pNamed and reexport it
> > pGEn depends on pAB
> > 
> > The property from Named (lets call it name) can't be accessed without cast:
> > 
> > a.name //<fails
> > (a as Named).name //<works for me
> 
> That might be related as the comments getter is defined in a superinterface,
> too. I'm going to try the cast workaround tomorrow.

The cast workaround works for me... In my example the hierachy (all interfaces are defined in the same plugin) is:

Block extends Member
Member extends NamedElement
NamedElement extends Commentable

In Commentable getComments() is defined.

Scenario 1: 
def test(Block block) {
block.comments // works
}

Scenario 2: 
def test(Member member) {
member.comments // doesn't work
}

Scenario 3: 
def test(NamedElement namedElement) {
namedElement.comments // works
}

Scenario 4: 
def test(Commentable commentable) {
commentable.comments // works
}

Only having a Member type doesn't work. I can cast as NamedElement or Commentable and it works... but I don't have a clue, what's special about the Method interface.

Comment 7 Benjamin Schwertfeger 2011-11-04 11:24:18 EDT

Created attachment 206468 [details]
Example project for similar situation to the one mentioned above

Example project where I see the same behavior, but in a different situation.

Steps:
1. Import Project
2. open both gen.xtend and Block.java 
3. remove the '2' from 'Block extends Dummy2, Member' in Block.java
4. The gen.xtend get an error marker because comment can't be reslved
5. explicit cast in gen.xtend solves the problem:
  (b as Commentable).comment

This example is only valid until saving, but behaviar looks the same.

Comment 8 Benjamin Schwertfeger 2011-11-11 11:42:57 EST

Created attachment 206863 [details]
Patch of JvmDeclaredTypeImplCustom

The calculation in internalGetAllFeaturesMap skips superTypes if they appear twice in different parents, but caches the results. Patch for calculating every parent once.

P.S.: Yesterday the xtend-generator used a get-method (getName) inside the Xtend-file instead of the attribute name of a local variable. 
class A{
  def a(NamedElement n){n.name}
  def getName(NamedElement n){"FooBar"}
}
leads once to a java file where getName(n) is called.

Comment 9 Benjamin Schwertfeger 2011-11-14 03:25:16 EST

Created attachment 206922 [details]
Reworked patch for corrected cycle detection

I've reworked the patch to correct the cycle detection in class hierarchy. Now it works without instance variable and less complex code. Tomorrow I can test it against the wrong error message in the editor.

Comment 10 Sven Efftinge 2011-11-14 03:28:20 EST

Cool, thank you!

Comment 11 Benjamin Schwertfeger 2011-11-15 10:44:38 EST

Works also for the root problem in the editor here. No problem in compiler seen since update.

Comment 12 Sebastian Zarnekow 2011-11-17 09:16:43 EST

Thanks for the patch. Works like a charm.

See repro in bug 363621

Comment 13 Karsten Thoms 2017-09-19 17:03:31 EDT

Closing all bugs that were set to RESOLVED before Neon.0

Comment 14 Karsten Thoms 2017-09-19 17:15:06 EDT

Closing all bugs that were set to RESOLVED before Neon.0