RFR 8199910: Compiler crashes with -g option and variables of intersection type inferred by `var`
ShinyaYoshida
bitterfoxc at gmail.com
Wed Mar 21 04:56:54 UTC 2018
Oops,
I've copied from lvti/T8191959.java and it has such header...
I'll fix my test header in same webrev URL.
I'm not sure we should fix some other tests that have the wrong header
like lvti/T8191959.java
in this patch.
Regards,
shinyafox(Shinya Yoshida)
2018-03-21 13:51 GMT+09:00 Jonathan Gibbons <jonathan.gibbons at oracle.com>:
> Sorry to be picky, but you appear to have copied the legal header from a
> source file (in the src/ directory) and not from a nearby test (in the
> test/ directory). The difference is that source files are designated as
> subject to the "Classpath exception". Test files are not.
>
> Generally, the rules are ...
>
> - New source files, in the src/ directory, use GPLv2 + Classpath
> Exception.
> - New tests, in the test/ directory, use GPLv2 .... except for files
> using @compile/fail/ref=
> - New tests, in the test/ directory, use /* nodynamiccopyright */ if
> the test uses golden files containing line numbers
>
> Generally, I recommend copying exactly the text from a nearby file,
> assuming the text looks "normal". The only edit should be to initialize
> the year in the copyright line. I do not recommend editing anything else;
> we do occasionally run scripts to "audit the legal headers" and every so
> often, that turns up anomalies!
>
> -- Jon
>
> On 3/20/18 9:39 PM, ShinyaYoshida wrote:
>
> Hi Jonathan,
> Thank you for the review.
>
> I was not sure the meaning of nodynamiccopyright in tests.
> Thank you for the pointing that.
>
> I've updated the webrev:
> http://cr.openjdk.java.net/~shinyafox/8199910/webrev.01/
>
> Regards,
> shinyafox(Shinya Yoshida)
>
> 2018-03-21 13:31 GMT+09:00 Jonathan Gibbons <jonathan.gibbons at oracle.com>:
>
>> Shinya,
>>
>> Tests like the one you provided should normally have the full legal
>> header, including the standard GPL license text.
>>
>> We only use the "/nodynamiccopyright/" version when the test is a
>> negative test with a golden file that contains line numbers, such as a test
>> using "@compile/fail/ref=file.out ....". This is to prevent the test from
>> undergoing any automated processing should the license text ever change.
>>
>> -- Jon
>>
>> On 3/20/18 7:53 PM, 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(C
>>> lassWriter.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(J
>>> avaCompiler.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(J
>>> avaCompiler.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/9b4d8d9e/attachment.html>
More information about the compiler-dev
mailing list