Dominance in pattern matching for switch: Spec and Javac inconsistency

[Jesper Steen Møller]

Hi

If I understand correctly, a guarded switch label effectively can't dominate any other labels, since the spec doesn't go into trying to statically analyse whether or not the guard could ever be false.
I guess the spec could mention that (but it would be a comment, since it follows from the other rules).

-Jesper


> On 3 Sep 2021, at 09.29, Remi Forax <forax at univ-mlv.fr> wrote:
> 
> 
> 
> From: "Ilyas Selimov" <ilyas.selimov at jetbrains.com>
> To: "compiler-dev" <compiler-dev at openjdk.java.net>
> Sent: Vendredi 3 Septembre 2021 07:27:42
> Subject: Dominance in pattern matching for switch: Spec and Javac inconsistency
> Hello!
> 
> The next code compiles correctly, but it seems to contradict the dominance rules:
> 
> void test(Integer i) {
>   switch (i) {
>     case Integer in && in != null:
>       break;
>     case 1:
>       break;
>     case default:
>       break;  
>   }
> }
> 
> > A switch label that has a pattern case label element p dominates another switch label that has a constant case label element c if either of the following is true:
> > - the type of c is a primitive type and its wrapper class (5.1.7) is a subtype of the erasure of the type of p.
> 
> Maybe the type of p should also be total for the type of selector expression like in the rules for pattern-over-null dominance?
> 
> For me, the problem comes from the guard, if you write the same code without the guard, the compiler correctly emits an error
> void test(Integer i) {
>   switch (i) {
>     case Integer in:
>       break;
>     case 1:
>       break;
>     case default:
>       break;  
>   }
> }
> 
> for me, this rule should apply even if p is a guard, the type of p when p is a guard is the type of the type part (the left part) of a guard.
> 
> So it's more a bug in the implementation than a spec issue.
> But given that Eclipse has the same issue, the spec should be clarified.
> 
> 
> 
> Thanks,
> Ilyas
> 
> regards,
> Rémi

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20210903/eed94518/attachment.htm>