javac throws an AssertionError while compiling a switch on types

[forax at univ-mlv.fr]

promoted to amber-spec-experts because we are talking about the spec more than the implementation. 

> De: "Brian Goetz" <brian.goetz at oracle.com>
> À: "jan lahoda" <jan.lahoda at oracle.com>, "Remi Forax" <forax at univ-mlv.fr>
> Cc: "compiler-dev" <compiler-dev at openjdk.java.net>
> Envoyé: Lundi 7 Juin 2021 21:14:40
> Objet: Re: javac throws an AssertionError while compiling a switch on types

> The specification (and design) does allow this.

> We talked about revising the positioning rules regarding `default`, but in the
> end decided not to do anything about this. So putting `default` ahead of
> `String s` is allowed. The interpretation of `default` is "anything not handled
> by some other case, except null."

> In point of fact, what this means is that we have to test all the patterns
> before concluding something goes in the default bucket, not just the patterns
> that precede the default case. So Strings fall into the `case String s` bucket,
> and everything else (except null) falls into the default bucket. This is weird
> enough behavior we might consider issuing a warning.
I'm not a big fan of warning if it can be an error. 
I'm old enough to remember when Java was touted as a clean language because it has no warnings (Go is now the new kid on the block on that front). 
I'm Ok with warnings because of backward compatibility, otherwise, i prefer errors, especially in this case because it helps to convey the semantics. 

I like the fact that the total pattern has to be the last case. Default is as you say the total pattern minus null, so it seems logical to require it to be the last case too, to convey that the total pattern and default are semantically cousins. 

As you said, it goes against the fact that you can put default everywhere which is nice in term of code sharing, that's why we have decided to not do anything about it the last time we talk about default. 

I think i better understand the tradeoff around default that the last time we talk about, so i think we should revisit the spec (for Java 18) to require default to be at the end. 
But i may have miss a part of the picture ? 

Rémi 

> On 6/7/2021 10:17 AM, Jan Lahoda wrote:

>> Thanks for the report, Remi.

>> I believe the specification currently allows this (default does not have to be
>> last, and does not dominate anything), so javac should be able to handle this
>> code. I've filled:

>> [ https://bugs.openjdk.java.net/browse/JDK-8268333 |
>> https://bugs.openjdk.java.net/browse/JDK-8268333 ]

>> Jan

>> On 07. 06. 21 11:54, Remi Forax wrote:

>>> Hi all,
>>> javac does like this code, there is a check missing because javac should not
>>> reach Gen with a code like this.

>>> Object o = null;
>>> var value = switch(o) {
>>> default -> 0;
>>> case String s -> 0;
>>> };
>>> System.out.println(value);

>>> An exception has occurred in the compiler (17-internal). Please file a bug
>>> against the Java compiler via the Java bug reporting page ( [
>>> http://bugreport.java.com/ | http://bugreport.java.com ] ) after checking the
>>> Bug Database ( [ http://bugs.java.com/ | http://bugs.java.com ] ) for
>>> duplicates. Include your program, the following diagnostic, and the parameters
>>> passed to the Java compiler in your report. Thank you.
>>> java.lang.AssertionError
>>> at jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:155)
>>> at jdk.compiler/com.sun.tools.javac.util.Assert.check(Assert.java:46)
>>> at jdk.compiler/com.sun.tools.javac.jvm.Gen.handleSwitch(Gen.java:1310)
>>> at
>>> jdk.compiler/com.sun.tools.javac.jvm.Gen.doHandleSwitchExpression(Gen.java:1238)
>>> at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitSwitchExpression(Gen.java:1202)
>>> at
>>> jdk.compiler/com.sun.tools.javac.tree.JCTree$JCSwitchExpression.accept(JCTree.java:1381)
>>> at jdk.compiler/com.sun.tools.javac.jvm.Gen.genExpr(Gen.java:877)
>>> at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitLetExpr(Gen.java:2376)
>>> at jdk.compiler/com.sun.tools.javac.tree.JCTree$LetExpr.accept(JCTree.java:3288)
>>> at jdk.compiler/com.sun.tools.javac.jvm.Gen.genExpr(Gen.java:877)
>>> at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitVarDef(Gen.java:1081)
>>> at
>>> jdk.compiler/com.sun.tools.javac.tree.JCTree$JCVariableDecl.accept(JCTree.java:1028)
>>> at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:610)
>>> at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:645)
>>> at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:631)
>>> at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStats(Gen.java:682)
>>> at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitBlock(Gen.java:1097)
>>> at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:1092)
>>> at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:610)
>>> at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:645)
>>> at jdk.compiler/com.sun.tools.javac.jvm.Gen.genMethod(Gen.java:967)
>>> at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitMethodDef(Gen.java:930)
>>> at
>>> jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:922)
>>> at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:610)
>>> at jdk.compiler/com.sun.tools.javac.jvm.Gen.genClass(Gen.java:2415)
>>> at
>>> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.genCode(JavaCompiler.java:737)
>>> at
>>> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1617)
>>> at
>>> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1585)
>>> at
>>> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:946)
>>> at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:317)
>>> at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:176)
>>> at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:64)
>>> at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:50)

>>> regards,
>>> Rémi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20210607/ce77d620/attachment-0001.htm>