6512707: "incompatible types" after (unrelated) annotation processing [SEC=UNCLASSIFIED]

[Peter Runge]

Hi everyone,
 
I ran into this bug regarding annotation processing a couple of days ago
and have attempted a fix.
 
I have signed and sent off the SCA by e-mail.  Do I need to wait for a
response before posting patches/fixes?
 
Anyway, I believe the root of the problem is that
com.sun.tools.javac.tree.TreeScanner does not scan for default values
for methods (which are only used for annotation and enum default
values).  This causes an issue because cleanTrees() in
com.sun.tools.javac.processing.JavacProcessingEnvironment, which I think
cleans up symbols from all elements in the source tree, is missing out
on cleaning up symbols for default values which is causing the error as
described in the bug (e.g. 'TestEnum' incompatible type with
'TestEnum').
 
What led me to this conclusion was through debugging the compiler, I
found that multiple Type objects that had the same name for Enums (but
were not equal) were existing when running an annotation processor first
- this didn't happen when running the compiler by itself (the same Type
object was used throughout the compiler run).  
 
For example, at the start of checkType() in
com.sun.tools.javac.comp.Check, when the names (used toString()) of the
found and required types were the same, found == req for a 'good'
compile run without an annotation processor running first but found !=
req when an annotation processor ran first for enumeration types with
default values.  toString() for com.sun.tools.javac.code.Type uses the
symbol to find the name.  This is what led me to believe that symbols
were not properly cleaned up after an annotation processor run.
 
Adding a line in TreeScanner's visitMethodDef() to
scan(tree.defaultValue) seems to squash the bug.  Can anyone think of
any issues with this fix?
 
Regards,
 
Peter

If you have received this email in error, please notify the sender immediately and erase all copies of the email and any attachments to it. The information contained in this email and any attachments may be private, confidential and legally privileged or the subject of copyright. If you are not the addressee it may be illegal to review, disclose, use, forward, or distribute this email and/or its contents.
 
Unless otherwise specified, the information in the email and any attachments is intended as a guide only and should not be relied upon as legal or technical advice or regarded as a substitute for legal or technical advice in individual cases. Opinions contained in this email or any of its attachments do not necessarily reflect the opinions of ACMA.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20081222/a933be5a/attachment.html