[jdk17] RFR: 8268871: Adjust javac to updated exhaustiveness specification

[Vicente Romero]

On Wed, 16 Jun 2021 12:47:22 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> The current updates spec for pattern matching in switch:
> http://cr.openjdk.java.net/~gbierman/jep406/jep406-20210608/specs/patterns-switch-jls.html
> 
> tweaks the definition of exhaustive switches so that it include handling special types, like intersection types, sealed subclasses of sealed types, like:
> 
> sealed abstract class A permits B, C {}
> final class B extends A {}
> sealed abstract class C extends A permits D, E {}
> final class D extends C {}
> final class E extends C {}
> 
> public class Test {
>   public static void main(String[] args) {
>      A a = new D();
>      System.out.println(
>         switch (a) {
>            case B x -> "B";
>            case D x -> "D";
>            case E x -> "E";
>         });
>   }
> }
> 
> 
> etc. This patch attempts to tweak javac to work according to this specification. It builds covered types based on what types are covered, i.e. if all subtypes of a sealed type are covered, the sealed type itself is covered, and this is done transitively, so that in the example above, `D` and `E` will mark `C` as covered, and then `B` and `C` will mark `A` as covered, and as the type if `a` is `A`, it means the switch is exhaustive.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 773:

> 771: 
> 772:                         case TYP -> {
> 773:                             for (Type sup : types.directSupertypes(sym.type)) {

just an observation, once a symbol has been processed, there is no need to process it again so you could keep a set of visited symbols to avoid visiting them again. Not a big deal performance wise unless we are switching on a sealed hierarchy with a lot of members I guess > 50 but we know what automatic code generators are capable of :)

-------------

PR: https://git.openjdk.java.net/jdk17/pull/78