RFR 8199910: Compiler crashes with -g option and variables of intersection type inferred by `var`
Jonathan Gibbons
jonathan.gibbons at oracle.com
Wed Mar 21 05:06:42 UTC 2018
Looks good. I'll let others comment on the fix itself.
-- Jon
On 3/20/18 10:04 PM, ShinyaYoshida wrote:
> 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
> <http://cr.openjdk.java.net/%7Eshinyafox/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 <mailto: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 <mailto: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/
>>> <http://cr.openjdk.java.net/%7Eshinyafox/8199910/webrev.01/>
>>>
>>> Regards,
>>> shinyafox(Shinya Yoshida)
>>>
>>> 2018-03-21 13:31 GMT+09:00 Jonathan Gibbons
>>> <jonathan.gibbons at oracle.com
>>> <mailto: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
>>>> <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/20180320/7cae3fa4/attachment-0001.html>
More information about the compiler-dev
mailing list