Problem with when type annotation positions are determined

Werner Dietl wdietl at gmail.com
Sat Dec 1 15:23:00 PST 2012


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: annobug.tar.gz
Type: application/x-gzip
Size: 337 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/type-annotations-dev/attachments/20121201/dde2c4ee/annobug.tar.gz 


More information about the type-annotations-dev mailing list