From Peter.Runge at acma.gov.au on compiler-dev
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?