Bug 160132 - [1.5][compiler] Compiler fails with indirect reference error message
Summary: [1.5][compiler] Compiler fails with indirect reference error message
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.3   Edit
Hardware: PC Windows 2000
: P3 major (vote)
Target Milestone: 3.2.2   Edit
Assignee: Philipe Mulet CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-10-07 15:08 EDT by Ed Merks CLA
Modified: 2007-01-15 12:59 EST (History)
2 users (show)

See Also:

Attachments
Two projects that demonstrate the problem. (4.29 KB, application/zip)
2006-10-07 15:15 EDT, Ed Merks CLA 		no flags Details
Proposed patch (2.17 KB, patch)
2006-10-09 07:16 EDT, Philipe Mulet CLA 		no flags Details | Diff
View All 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 Ed Merks CLA 2006-10-07 15:08:35 EDT 
I'll attached a test case that represents a simplified version of the problem that I'm having in the org.eclipse.emf.ecore plugin. This problem is a show stopper for me.  I.e., I cannot get a downstream class to compile because of this.
Comment 1 Ed Merks CLA 2006-10-07 15:15:29 EDT 
Created attachment 51602 [details]
Two projects that demonstrate the problem.

Often the problem shows up just in B class of project a. I.e., this error appears:

The type org.example.a.A$Entry.Internal cannot be resolved. It is indirectly referenced from required .class files	a/src/org/example/a	B.java	line 0	1160248111755	1939091

If I modify B (add space and remove) and save it, the error goes away, and if I do it again, the error comes back.  The same error occurs in project b, and in this case there is nothing I can do to make the error go away.

This same type of problem occurs when I templatize org.eclipse.emf.ecore.util.FeatureMap and then try to use FeatureMap.Entry.Internal in the org.eclipse.emf.ecore.change model, so I'm very anxious to get this working...
Comment 2 Philipe Mulet CLA 2006-10-08 10:13:46 EDT 
Smells like a buildpath issue.
Comment 3 Maxime Daniel CLA 2006-10-09 02:47:16 EDT 
Reproduced with HEAD and I20061003-0800. Released (simpler) test case BuildpathTests test0100 (inactive for now).
Comment 4 Philipe Mulet CLA 2006-10-09 04:55:04 EDT 
Also added GenericTypeTest#test1046-48.
If removing generic type parameters from X, no more problem is detected. Problem rather lies in decoding of generic signatures from binaries.
Comment 5 Philipe Mulet CLA 2006-10-09 04:57:34 EDT 
Added InnerEmulationTest#test129 with non generic scenario.
Comment 6 Philipe Mulet CLA 2006-10-09 05:00:46 EDT 
Maxime - watch GenericTypeTest#test1048. Interestingly it works fine when using static classes instead of interfaces.
Comment 7 Philipe Mulet CLA 2006-10-09 05:15:59 EDT 
Problem comes from misgeneration of the generic signature for Internal#createEntry().

We issue a generic signature attribute (slightly corrupted) where none is required.

Should be:
  // Method descriptor #8 ()LX$Entry$Internal;
  public abstract X.Entry.Internal createEntry();

But we issue:
  // Method descriptor #8 ()LX$Entry$Internal;
  // Signature: ()LX$Entry.Internal;
  public abstract X.Entry.Internal createEntry();
Comment 8 Philipe Mulet CLA 2006-10-09 07:16:32 EDT 
Created attachment 51634 [details]
Proposed patch
Comment 9 Philipe Mulet CLA 2006-10-09 07:20:58 EDT 
Released for 3.3M3 (HEAD)
Backporting to 3.2.2
Comment 10 Philipe Mulet CLA 2006-10-09 07:36:13 EDT 
Added GenericTypeSignatureTest#test020.
Released for 3.2.2

Fixed
Comment 11 David Audel CLA 2006-10-30 10:58:00 EST 
Verified for 3.3 M3 using build I20061030-0010
Comment 12 Eric Jodet CLA 2007-01-15 07:27:34 EST 
verified for 3.2.2 using build M20070112-1200