RFR 8199910: Compiler crashes with -g option and variables of intersection type inferred by `var`

B. Blaser bsrbnd at gmail.com
Fri Mar 23 15:19:45 UTC 2018


On 23 March 2018 at 13:51, B. Blaser <bsrbnd at gmail.com> wrote:
> On 23 March 2018 at 13:11, B. Blaser <bsrbnd at gmail.com> wrote:
>> On 23 March 2018 at 11:57, Maurizio Cimadamore
>> <maurizio.cimadamore at oracle.com> wrote:
>>> Ping :-)
>>
>> Hello Maurizio,
>>
>> You'll still need another review but this looks good to me,
>> Bernard
>
> And I now see the "interest" (even if dangerous) of having
> intersection types involving final classes [1]. So, I suggest to close
> https://bugs.openjdk.java.net/browse/JDK-8189684

I maybe went too fast, you previously wrote 'Foo<A & B>' probably
referring to the intersection type 'Object & Serializable &
Comparable' present in the stack trace which was induced by the 'lub'
of the union type 'List<String | Integer>' from our example 'var s =
java.util.List.of("a", 1)' ? In such a case, final classes are not
dangerous;-)

Bernard


> What do you think?
>
> Thanks,
> Bernard
>
> [1] http://mail.openjdk.java.net/pipermail/compiler-dev/2017-November/011299.html
>
>
>>> Maurizio
>>>
>>>
>>> On 21/03/18 20:56, Maurizio Cimadamore wrote:
>>>
>>> Here's an updated webrev - passes all tests.
>>>
>>> In addition to the tests already provided, I also tweaked the LVTI test
>>> harness to also use -g and report crashes (I verified that in this mode the
>>> harness crashes w/o the patch).
>>>
>>> Webrev here:
>>>
>>> http://cr.openjdk.java.net/~mcimadamore/8199910-v3/
>>>
>>> Cheers
>>> Maurizio
>>>
>>>
>>> On 21/03/18 17:08, ShinyaYoshida wrote:
>>>
>>> Hi Maurizio,
>>> Thank you for the pointing that.
>>>
>>> I've read the logic around your fix. It seems to me it's reasonable.
>>> We don't need to handle intersection type in enterInner because inner
>>> classes are handled triggered by a symbol of another part.
>>>
>>> I could confirm the test passes.
>>> Please go ahead!
>>>
>>> Thank you for the opportunity to learn the logic around that.
>>>
>>> Regards,
>>> shinyafox(Shinya Yoshida)
>>>
>>> 2018-03-22 1:26 GMT+09:00 Maurizio Cimadamore
>>> <maurizio.cimadamore at oracle.com>:
>>>>
>>>> Attached is my take on the problem.
>>>>
>>>> As I said, we added some logic to handle this with multi-catch, but
>>>> unfortunately the current logic only handle cases where you have a type like
>>>> A & B and not cases where you have Foo<A & B>.
>>>>
>>>> I've enhanced the check to do a proper non-denotable visit on the type of
>>>> the local variable, rather than just doing a simple check as before.
>>>>
>>>> Let me know what you think - and also if you'd like me to go ahead with
>>>> it, or if you still want to take this.
>>>>
>>>> Cheers
>>>> Maurizio
>>>>
>>>>
>>>> On 21/03/18 16:09, Maurizio Cimadamore wrote:
>>>>
>>>> Hi Shinya,
>>>> thanks for the fix; unfortunately, I believe it is not correct. An
>>>> intersection type should be erased by the time we get here; we had a similar
>>>> issue in the past with multicatch:
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-6999635
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-7005371
>>>>
>>>> I will take a closer look as to find out exactly what's going on; the fix
>>>> for multicatch should have taken care for this one too...
>>>>
>>>> Maurizio
>>>>
>>>>
>>>> On 21/03/18 02:53, ShinyaYoshida wrote:
>>>>
>>>> Hi all and Kishida,
>>>>
>>>> Thank you for reporting the issue.
>>>>
>>>> I've filed and created a patch:
>>>> Bugs: https://bugs.openjdk.java.net/browse/JDK-8199910
>>>> Webrev: http://cr.openjdk.java.net/~shinyafox/8199910/webrev/
>>>>
>>>> Could someone review this?
>>>>
>>>> If it's fine, I'll commit to jdk repo and I'd like to backport to jdk10
>>>> after backport approval.
>>>>
>>>> Regards,
>>>> shinyafox(Shinya Yoshida)
>>>>
>>>> 2018-03-21 10:54 GMT+09:00 kishida naoki <naokikishida at gmail.com>:
>>>>>
>>>>> Hi all!
>>>>>
>>>>> I'm glad that JDK 10 is released.
>>>>> But I've faced a compiler bug with `var`.
>>>>> I'm using the build 46.
>>>>>
>>>>> This code crashes the compiler with `-g` option.
>>>>> ```
>>>>> public class Main {
>>>>>     void m() {
>>>>>         var s = java.util.List.of("a", 1);
>>>>>     }
>>>>> }
>>>>> ```
>>>>>
>>>>> $ javac Main.java -g
>>>>> C:\src>javac Main.java -g
>>>>> java.lang.AssertionError: Unexpected intersection type:
>>>>> java.lang.Object&java.io.Serializable&java.lang.Comparable<? extends
>>>>> java.lang.Object&java.io.Serializable&java.lang.Comparable<?>>
>>>>>         at
>>>>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.enterInner(ClassWriter.java:1043)
>>>>>         at
>>>>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter$CWSignatureGenerator.classReference(ClassWriter.java:312)
>>>>>         at
>>>>> jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerator.assembleClassSig(Types.java:5182)
>>>>>         at
>>>>> jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerator.assembleSig(Types.java:5114)
>>>>>         at
>>>>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter$CWSignatureGenerator.assembleSig(ClassWriter.java:291)
>>>>>         at
>>>>> jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerator.assembleSig(Types.java:5225)
>>>>>         at
>>>>> jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerator.assembleClassSig(Types.java:5201)
>>>>>         at
>>>>> jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerator.assembleSig(Types.java:5114)
>>>>>         at
>>>>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter$CWSignatureGenerator.assembleSig(ClassWriter.java:291)
>>>>>         at
>>>>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.typeSig(ClassWriter.java:334)
>>>>>         at
>>>>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeCode(ClassWriter.java:1271)
>>>>>         at
>>>>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeMethod(ClassWriter.java:1158)
>>>>>         at
>>>>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeMethods(ClassWriter.java:1653)
>>>>>         at
>>>>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeClassFile(ClassWriter.java:1761)
>>>>>         at
>>>>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeClass(ClassWriter.java:1679)
>>>>>         at
>>>>> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.genCode(JavaCompiler.java:749)
>>>>>         at
>>>>> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1627)
>>>>>         at
>>>>> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1595)
>>>>>         at
>>>>> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:965)
>>>>>         at
>>>>> jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:306)
>>>>>         at
>>>>> jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:165)
>>>>>         at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:57)
>>>>>         at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:43)
>>>>>
>>>>> The cause is about intersection. The variable type that is infered
>>>>> becomes as a type with intersection, and will crash the compiler when
>>>>> generating a debug info.
>>>>> These are no problem.
>>>>>   var s=List.of("a");
>>>>>   var s=List.of("a", 1, Optional.empty());
>>>>>   var s=List.of("a", 1, List.of());
>>>>>
>>>>> Best regards.
>>>>>
>>>>> --
>>>>> Naoki Kishida
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>


More information about the compiler-dev mailing list