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

[ShinyaYoshida]

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$CWSignature
>> Generator.classReference(ClassWriter.java:312)
>>         at jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerat
>> or.assembleClassSig(Types.java:5182)
>>         at jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerat
>> or.assembleSig(Types.java:5114)
>>         at jdk.compiler/com.sun.tools.javac.jvm.ClassWriter$CWSignature
>> Generator.assembleSig(ClassWriter.java:291)
>>         at jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerat
>> or.assembleSig(Types.java:5225)
>>         at jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerat
>> or.assembleClassSig(Types.java:5201)
>>         at jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerat
>> or.assembleSig(Types.java:5114)
>>         at jdk.compiler/com.sun.tools.javac.jvm.ClassWriter$CWSignature
>> Generator.assembleSig(ClassWriter.java:291)
>>         at jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.typeSig(Cla
>> ssWriter.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.writeMethod
>> s(ClassWriter.java:1653)
>>         at jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeClassF
>> ile(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
>>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20180322/92c42890/attachment-0001.html>