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