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

ShinyaYoshida bitterfoxc at gmail.com
Wed Mar 21 05:04:53 UTC 2018


Thank you for the direction, Jonathan.
I've fixed my header:
http://cr.openjdk.java.net/~shinyafox/8199910/webrev.01/test/langtools/tools/javac/T8199910.java.html

Regards,
shinyafox(Shinya Yoshida)

2018-03-21 14:01 GMT+09:00 Jonathan Gibbons <jonathan.gibbons at oracle.com>:

> Shinya,
>
> Thanks for pointing out the problem in that other test. This is why we
> sometimes run scripts to check these headers!
>
> I recommend you fix your new test, and we'll separately check if there are
> any other tests using the Classpath Exception header.
>
> -- Jon
>
> On 3/20/18 9:56 PM, ShinyaYoshida wrote:
>
> 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/488eb68e/attachment-0001.html>


More information about the compiler-dev mailing list