RFR 8199910: Compiler crashes with -g option and variables of intersection type inferred by `var`
Maurizio Cimadamore
maurizio.cimadamore at oracle.com
Wed Mar 21 21:04:33 UTC 2018
Hi,
I think extending the format of the signature attribute is something
that *could* be done - but I would only consider it if there was a
significant payoff (e.g. in the context of type specialization, etc.).
We already have variable types today whose type is not represented in
the LocalVariableTypeTable attribute due to denotability issues - of
course 'var' is going to make that more frequent, but it doesn't change
the substance.
Also, take into account that changing sig attribute is not a small task
- you also need to enhance the java.lang.reflect.Type API that goes with
it - if the signature is more expressive, you might want to need
additional Type subclasses to reflect over intersection types.
On a related note, the only place where these weird types can pop up is
in local variables - e.g. inside method bodies; this information in no
way affects what can happen in other compilation units etc. - this is
good (e.g. scope is limited - you might even get away w/o reflection
changes) but begs the question as to whether is worth changing the
grammar of the attribute for such a narrow case.
Maurizio
On 21/03/18 17:39, ShinyaYoshida wrote:
> Hi Maurizio,
> Here is another question.
>
> Is there a possibility of supporting the representation of an
> intersection or union type in a signature format for debugging use or
> something?
> Recently, we see intersection type or union type in Java code often
> than before.
> We may see it more often because we can represent intersection types
> as a type of variables using var feature after JDK 10.
> So may it help debugging with var or something like that if it present?
>
> Regards,
> shinyafox(Shinya Yoshida)
>
> 2018-03-22 2:08 GMT+09:00 ShinyaYoshida <bitterfoxc at gmail.com
> <mailto:bitterfoxc at gmail.com>>:
>
> 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
> <mailto: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-6999635>
>>
>> https://bugs.openjdk.java.net/browse/JDK-7005371
>> <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
>>> <https://bugs.openjdk.java.net/browse/JDK-8199910>
>>> Webrev:
>>> http://cr.openjdk.java.net/~shinyafox/8199910/webrev/
>>> <http://cr.openjdk.java.net/%7Eshinyafox/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 <mailto: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
>>> <http://java.io>.Serializable&java.lang.Comparable<?
>>> extends java.lang.Object&java.io
>>> <http://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
>>>
>>>
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20180321/a06e14d9/attachment-0001.html>
More information about the compiler-dev
mailing list