Future of 'type-annotations/type-annotations' forest

[Jonathan Gibbons]

Aha, I think the code may be triggered by saveParameterNames.

Thanks for the stack trace.

-- Jon


On 05/09/2014 06:26 PM, Werner Dietl wrote:
> The stack trace that caused me to look at this, with code from
> February 7, 2014, is below.
> When I changed the reordering code back to the way it is in
> type-annotations now, this exception went away.
> The Checker Framework isn't doing funny things with the class files
> and it isn't on this stack trace.
> So to me it seems like that code is used, as it had direct impact on
> this exception.
>
> java.lang.ClassCastException:
> com.sun.tools.javac.code.Symbol$MethodSymbol cannot be cast to
> com.sun.tools.javac.util.Name
> at com.sun.tools.javac.jvm.ClassReader.readName(ClassReader.java:565)
> at com.sun.tools.javac.jvm.ClassReader.readCompoundAnnotation(ClassReader.java:1458)
> at com.sun.tools.javac.jvm.ClassReader.readTypeAnnotation(ClassReader.java:1467)
> at com.sun.tools.javac.jvm.ClassReader.attachTypeAnnotations(ClassReader.java:1415)
> at com.sun.tools.javac.jvm.ClassReader$23.read(ClassReader.java:1180)
> at com.sun.tools.javac.jvm.ClassReader.readAttrs(ClassReader.java:1330)
> at com.sun.tools.javac.jvm.ClassReader.readMemberAttrs(ClassReader.java:1320)
> at com.sun.tools.javac.jvm.ClassReader.readCode(ClassReader.java:1357)
> at com.sun.tools.javac.jvm.ClassReader$3.read(ClassReader.java:954)
> at com.sun.tools.javac.jvm.ClassReader.readAttrs(ClassReader.java:1330)
> at com.sun.tools.javac.jvm.ClassReader.readMemberAttrs(ClassReader.java:1320)
> at com.sun.tools.javac.jvm.ClassReader.readMethod(ClassReader.java:2088)
> at com.sun.tools.javac.jvm.ClassReader.readClass(ClassReader.java:2296)
> at com.sun.tools.javac.jvm.ClassReader.readClassFile(ClassReader.java:2368)
> at com.sun.tools.javac.jvm.ClassReader.fillIn(ClassReader.java:2484)
> at com.sun.tools.javac.jvm.ClassReader.complete(ClassReader.java:2415)
> at com.sun.tools.javac.jvm.ClassReader.access$000(ClassReader.java:76)
> at com.sun.tools.javac.jvm.ClassReader$1.complete(ClassReader.java:234)
> at com.sun.tools.javac.code.Symbol.complete(Symbol.java:560)
> at com.sun.tools.javac.code.Symbol$ClassSymbol.complete(Symbol.java:1024)
> at com.sun.tools.javac.jvm.ClassReader.loadClass(ClassReader.java:2597)
> at com.sun.tools.javac.comp.Resolve.loadClass(Resolve.java:1862)
> at com.sun.tools.javac.comp.Resolve.findIdentInPackage(Resolve.java:2101)
> at com.sun.tools.javac.comp.Attr.selectSym(Attr.java:3366)
> at com.sun.tools.javac.comp.Attr.visitSelect(Attr.java:3265)
> at com.sun.tools.javac.tree.JCTree$JCFieldAccess.accept(JCTree.java:1891)
> at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:595)
> at com.sun.tools.javac.comp.Attr.attribType(Attr.java:657)
> at com.sun.tools.javac.comp.Attr.attribType(Attr.java:650)
> at com.sun.tools.javac.comp.MemberEnter.attribImportType(MemberEnter.java:835)
> at com.sun.tools.javac.comp.MemberEnter.visitImport(MemberEnter.java:555)
> at com.sun.tools.javac.tree.JCTree$JCImport.accept(JCTree.java:571)
> at com.sun.tools.javac.comp.MemberEnter.memberEnter(MemberEnter.java:434)
> at com.sun.tools.javac.comp.MemberEnter.memberEnter(MemberEnter.java:446)
> at com.sun.tools.javac.comp.MemberEnter.visitTopLevel(MemberEnter.java:525)
> at com.sun.tools.javac.tree.JCTree$JCCompilationUnit.accept(JCTree.java:518)
> at com.sun.tools.javac.comp.MemberEnter.memberEnter(MemberEnter.java:434)
> at com.sun.tools.javac.comp.MemberEnter.complete(MemberEnter.java:1035)
> at com.sun.tools.javac.code.Symbol.complete(Symbol.java:560)
> at com.sun.tools.javac.code.Symbol$ClassSymbol.complete(Symbol.java:1024)
> at com.sun.tools.javac.comp.Enter.complete(Enter.java:495)
> at com.sun.tools.javac.comp.Enter.main(Enter.java:473)
> at com.sun.tools.javac.main.JavaCompiler.enterTrees(JavaCompiler.java:981)
> at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:856)
> at com.sun.tools.javac.main.Main.compile(Main.java:521)
> at com.sun.tools.javac.main.Main.compile(Main.java:381)
> at com.sun.tools.javac.main.Main.compile(Main.java:370)
> at com.sun.tools.javac.main.Main.compile(Main.java:361)
> at com.sun.tools.javac.Main.compile(Main.java:56)
> at com.sun.tools.javac.Main.main(Main.java:42)
>
> cu, WMD.
>
>
> On Fri, May 9, 2014 at 9:18 PM, Jonathan Gibbons
> <jonathan.gibbons at oracle.com> wrote:
>> Werner,
>>
>> Potentially, yes. We're investigating.
>>
>> -- Jon
>>
>>
>> On 05/09/2014 06:15 PM, Werner Dietl wrote:
>>> Eric,
>>>
>>> are you saying that that part of ClassReader is dead code that will
>>> never run? Shouldn't it be removed then?
>>>
>>> cu, WMD.
>>>
>>> On Fri, May 9, 2014 at 8:42 PM, Eric McCorkle <eric.mccorkle at oracle.com>
>>> wrote:
>>>> On 05/08/14 16:57, Eric McCorkle wrote:
>>>>
>>>>> I am aware of the fix that was pushed into the type annotations forest.
>>>>>    As we discussed when you developed the fix, I cannot push it into
>>>>> jdk9-dev as-is, because the development practices of the langtools team
>>>>> require that any changeset that introduces behavioral changes be
>>>>> accompanied by a test.
>>>>>
>>>>> I will take care of the test this time, so that you can run checkers on
>>>>> the contents of jdk9.  However, in the future, we ask that patches
>>>>> submitted against jdk9 conform to the langtools group's development
>>>>> practices.
>>>> I looked into this more.  I'm not at all certain how you even get this
>>>> problem to show up.  The only type annotations with local variable info
>>>> are LOCAL_VARIABLE or RESOURCE_VARIABLE type annotations, both of which
>>>> javac only ever generates on code attributes.  Also, javac never *reads*
>>>> annotations on code attributes.  Therefore, it is not really possible to
>>>> write a test.  It also suggests you're running into funny class files in
>>>> checkers somehow.
>>>>
>>>> On the other hand, all this means we can give the bug the noreg-hard
>>>> tag, and send it through the review process.  So it should be in jdk9
>>>> soon.
>>>
>>>
>
>