Bug 155115

Summary: UnresolvedReferenceBindings surfacing through DOM AST
Product: [Eclipse Project] JDT Reporter: Walter Harley <eclipse>
Component: CoreAssignee: Maxime Daniel <maxime_daniel>
Status: VERIFIED FIXED QA Contact:
Severity: normal    
Priority: P3 CC: jgarms, kent_johnson, philippe_mulet
Version: 3.2   
Target Milestone: 3.2.2   
Hardware: PC   
OS: Windows XP   
Whiteboard:
Bug Depends on:    
Bug Blocks: 527462    
Attachments:
Description Flags
jar file with binary types and anno def
none
processor plug-in project
none
debug target project
none
Tentative patch
none
Reduced fix for the 3.2 maintenance branch, plus test cases. none

Description Walter Harley CLA 2006-08-24 16:55:40 EDT
Types which appear as values in annotation elements within binary types are surfacing as unresolved bindings, even after they have otherwise been resolved.

That is, if an annotation like @Anno(IFoo.class) shows up on a type in a jar file, when APT tries to read the annotation value it gets a TypeBinding that is internally represented with an UnresolvedReferenceBinding and therefore gives wrong answers to questions like isInterface() or getQualifiedName().

The attached repro case consists of the following:

  1. annoval-binary.jar contains an interface definition, an annotation definition with an element of type Class, and some base classes A and B which are annotated with the annotation.

  2. anno-val.zip, which is a plug-in project that creates an annotation processor.

  3. anno-val-target.zip, which is a Java project that declares a class C that extends B and that is annotated.  This project needs annoval-binary.jar to be on  its classpath.

To reproduce the problem, import the anno-val project into a host workspace.  Then debug the resulting plug-in as an Eclipse application.  In the debug Eclipse instance, import the anno-val-target project and ensure that annoval-binary is on its classpath (may require editing the path).

Watch the console output in the host workspace, as the target workspace is built.  You will see output like this:

source.C.f(): val = intf.IFoo.IBar
binary.B.f(): val = intf.IFoo$IBar
binary.A.f(): val = intf.IFoo$IBar

Note that the output for classes B and A shows the IBar interface delimited with a '$' rather than a '.'; this is because the getQualifiedName() API returned the wrong thing, which is one sign of the unresolved reference.  But note also that the value was resolved correctly for class C, which got evaluated first.

If there's something that APT is doing wrong under the covers in getting these declarations, please let me know.  The creation of the parser is done in BaseProcessorEnv.createASTs(), with the following code:

		ASTParser p = ASTParser.newParser( AST.JLS3 );
		p.setResolveBindings( true );
		p.setProject( javaProject );
		p.setKind( ASTParser.K_COMPILATION_UNIT );
		p.createASTs( parseUnits, keys,  requestor, null);
Comment 1 Walter Harley CLA 2006-08-24 16:56:34 EDT
Created attachment 48644 [details]
jar file with binary types and anno def
Comment 2 Walter Harley CLA 2006-08-24 16:56:53 EDT
Created attachment 48645 [details]
processor plug-in project
Comment 3 Walter Harley CLA 2006-08-24 16:57:11 EDT
Created attachment 48646 [details]
debug target project
Comment 4 Olivier Thomann CLA 2006-08-28 14:11:26 EDT
Added regression test org.eclipse.jdt.core.tests.dom.ASTConverter15Test#test0227 in HEAD.
The test is disabled for now.
Comment 5 Olivier Thomann CLA 2006-08-29 10:11:45 EDT
Maxime,

Please give it a try? Kent can help you in case of problems.
Comment 6 Maxime Daniel CLA 2006-09-05 11:34:06 EDT
Created attachment 49405 [details]
Tentative patch
Comment 7 Maxime Daniel CLA 2006-09-06 01:22:32 EDT
Released for 3.3 M2

(May have minimized the changes, but I really wanted to clarify the situation around createUnresolvedAnnotation.)

Verifier please use the original test case, or else ASTConverter15Test#test0227.
Comment 8 Walter Harley CLA 2006-09-06 11:02:43 EDT
Thanks!  Much appreciated.  I'm traveling today, won't be able to verify until this Friday but will do it then.

Am I correct that this fix would also work for 3.2?  We'd like to get it applied there as well, at least for 3.2.2 if it is too late for 3.2.1.
Comment 9 Philipe Mulet CLA 2006-09-06 11:10:58 EDT
This isn't planned for 3.2.1 (too late and too risky).
We can consider backporting it post 3.2.1, and posting a patch.
Then maybe it makes it into 3.2.2
Comment 10 Walter Harley CLA 2006-09-08 18:42:58 EDT
I'm still seeing the behavior in I20060906-1200.  But maybe it didn't make it in time for that build?  I'm downloading N20060908-0010 right now, will try it there.
Comment 11 Walter Harley CLA 2006-09-09 02:57:30 EDT
Verified in v3.3 N20060908-0010.  Thanks, Maxime!

I would appreciate it if we could include this in 3.2.2, as well.
Comment 12 Maxime Daniel CLA 2006-09-11 03:10:54 EDT
(In reply to comment #11)
> Verified in v3.3 N20060908-0010.  Thanks, Maxime!
You're welcome.
> I would appreciate it if we could include this in 3.2.2, as well.
Philippe's call. I'll wait until 3.2.1 is declared anyway.

Comment 13 Philipe Mulet CLA 2006-09-11 03:24:57 EDT
+1 for 3.2.2, BUT we may want a reduced fix for 3.2.2 (i.e. just the one change to address the bug, vs. the bigger change made for 3.3 stream). Need to interact with Kent to narrow the change to reasonable subset.
Comment 14 Philipe Mulet CLA 2006-10-04 07:01:24 EDT
Reopening for 3.2.2
Comment 15 Maxime Daniel CLA 2006-10-11 09:12:02 EDT
Created attachment 51753 [details]
Reduced fix for the 3.2 maintenance branch, plus test cases.

I believe this fix is narrowly focused on the problem at hand. Kent please let me know if you disagree.
Comment 16 Maxime Daniel CLA 2006-10-11 09:35:08 EDT
Released for 3.2.2.
Comment 17 David Audel CLA 2007-01-16 06:34:57 EST
Verified for 3.2.2 using build M20070112-1200