Problem with when type annotation positions are determined

[Werner Dietl]

Jon,

thanks for your comments!

This changeset should fix this issue:

http://hg.openjdk.java.net/type-annotations/type-annotations/langtools/rev/8fdf095581b0

I performed a big refactoring of when type annotations are positioned in:

http://hg.openjdk.java.net/type-annotations/type-annotations/langtools/rev/a43c94235366

which now allows this cleaner solution.

I still have to perform more tests, in particular with the Checker Framework.


> At least conceptually, the for-loop calling
> completeTypeAnnotationsInSignatures should logically be done inside
> annotate.enterDone, not after it.  Code in enterDone will be analyzing
> annotations, including repeated annotations, and will presumably trip up
> over type annotations.

In enterDone we do not have the AST for the whole class declaration,
which is necessary to determine the type annotation position.
I now perform a call in attribClassBody, where I have that information.
So far this seems to work.


> Separately, very minor, it looks like TypeAnnotations should be an instance
> obtained from a Context -- that would save you having to pass in a Names.

I recently changed away from having an instance, because that object
didn't have any behavior.
After today's refactoring there is just one method and an inner class
and that method is called once.

Let me know what you think!

Thanks,
cu, WMD.


> On 12/01/2012 03:23 PM, Werner Dietl wrote:
>>
>> Joel, Jon, all,
>>
>> the trunk version of type-annotations passes the jtreg tests and also
>> the Checker Framework tests.
>> However, some uses of the compiler failed and I finally managed to
>> produce a minimal test case.
>> This problem is caused by the changes I made to when the type
>> annotation positions for different annotations is determined, i.e.
>> where we call
>> com.sun.tools.javac.code.TypeAnnotations.completeTypeAnnotationsInSignatures
>> in Enter/MemberEnter/Attr.
>> Previous versions (e.g. the code that is still in jsr308-langtools)
>> did not have this problem.
>>
>> To reproduce:
>>
>> 1. tar -xvzf annobug.tar.gz
>> 2. cd annobug
>> 3. type-annotations-build-dir/bin/javac -cp . Main.java
>>
>> For me, this results in a stack trace that begins with:
>>
>> java.lang.NullPointerException
>>          at
>> com.sun.tools.javac.code.TypeAnnotations$TypeAnnotationPositions.setTypeAnnotationPos(TypeAnnotations.java:789)
>>          at
>> com.sun.tools.javac.code.TypeAnnotations$TypeAnnotationPositions.findPosition(TypeAnnotations.java:862)
>>          at
>> com.sun.tools.javac.code.TypeAnnotations$TypeAnnotationPositions.visitAnnotatedType(TypeAnnotations.java:839)
>>          at
>> com.sun.tools.javac.tree.JCTree$JCAnnotatedType.accept(JCTree.java:2304)
>>          at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49)
>>          at
>> com.sun.tools.javac.code.TypeAnnotations$TypeAnnotationPositions.scan(TypeAnnotations.java:450)
>>          at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:57)
>>          at
>> com.sun.tools.javac.tree.TreeScanner.visitClassDef(TreeScanner.java:80)
>>          at
>> com.sun.tools.javac.tree.JCTree$JCClassDecl.accept(JCTree.java:648)
>>          at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49)
>>          at
>> com.sun.tools.javac.code.TypeAnnotations$TypeAnnotationPositions.scan(TypeAnnotations.java:450)
>>          at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:57)
>>          at
>> com.sun.tools.javac.tree.TreeScanner.visitTopLevel(TreeScanner.java:68)
>>          at
>> com.sun.tools.javac.tree.JCTree$JCCompilationUnit.accept(JCTree.java:517)
>>          at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49)
>>          at
>> com.sun.tools.javac.code.TypeAnnotations$TypeAnnotationPositions.scan(TypeAnnotations.java:450)
>>          at
>> com.sun.tools.javac.code.TypeAnnotations.completeTypeAnnotationsInSignatures(TypeAnnotations.java:87)
>>          at com.sun.tools.javac.comp.Enter.complete(Enter.java:514)
>>          at
>> com.sun.tools.javac.main.JavaCompiler.complete(JavaCompiler.java:791)
>>          at
>> com.sun.tools.javac.jvm.ClassReader.fillIn(ClassReader.java:2425)
>>          at
>> com.sun.tools.javac.jvm.ClassReader.complete(ClassReader.java:2332)
>>          at com.sun.tools.javac.code.Symbol.complete(Symbol.java:426)
>>          at
>> com.sun.tools.javac.code.Symbol$ClassSymbol.complete(Symbol.java:834)
>>          at
>> com.sun.tools.javac.jvm.ClassReader.loadClass(ClassReader.java:2513)
>>
>>
>> Note that if the classes are compiled together, no problem arises, i.e.
>>
>> javac *.java
>>
>> works as expected. Also, compiling the classes in the right sequence
>> works:
>>
>> javac -cp . Anno.java
>> javac -cp . Dep.java
>> javac -cp . Main.java
>>
>> In the invocation that gives an exception we're trying to determine
>> the position for an annotation that doesn't have its TypeCompound set
>> yet.
>> I failed at tracking down why the TypeCompound is set when invoked
>> with all classes, but not when invoked with just one.
>>
>> Ideas?
>>
>> Thanks,
>> cu, WMD.
>>
>



-- 
http://www.google.com/profiles/wdietl