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:01:59 UTC 2018
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/99471c2f/attachment-0001.html>
More information about the compiler-dev
mailing list