[patterns-record-deconstruction3] RFR: Fix NPE and exhaustivity bug in record patterns with nested primitive type patterns [v2]

Aggelos Biboudis duke at openjdk.java.net
Wed Apr 27 13:27:20 UTC 2022


> The following attempts to address two problems:
> 
> a) the crash should not happen (shown below)
> b) the switch should be considered exhaustive (as in the equivalent with Integer)
> 
> 
> public record R(int x) {}
> 
> public int test2(R r) {
>     return switch (r) {
>         case R(int x) -> 1; // crash while type-checking this in Flow
>         // error: the switch expression does not cover all possible input values
>     };
> }
> 
> 
> <details>
> <summary>Stack trace</summary>
> 
> 
> java.lang.NullPointerException: Cannot invoke "com.sun.tools.javac.code.Type.isPrimitive()" because "t" is null
>         at jdk.compiler/com.sun.tools.javac.code.Types.eraseNotNeeded(Types.java:2394)
>         at jdk.compiler/com.sun.tools.javac.code.Types.erasure(Types.java:2387)
>         at jdk.compiler/com.sun.tools.javac.code.Symbol$ClassSymbol.erasure(Symbol.java:1354)
>         at jdk.compiler/com.sun.tools.javac.comp.Flow$AliveAnalyzer.coversDeconstructionStartingFromComponent(Flow.java:812)
>         at jdk.compiler/com.sun.tools.javac.comp.Flow$AliveAnalyzer.coveredSymbols(Flow.java:776)
>         at jdk.compiler/com.sun.tools.javac.comp.Flow$AliveAnalyzer.coveredSymbolsForCases(Flow.java:745)
>         at jdk.compiler/com.sun.tools.javac.comp.Flow$AliveAnalyzer.visitSwitchExpression(Flow.java:728)
>         at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCSwitchExpression.accept(JCTree.java:1385)
>         at jdk.compiler/com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49)
>         at jdk.compiler/com.sun.tools.javac.comp.Flow$BaseAnalyzer.scan(Flow.java:447)
>         at jdk.compiler/com.sun.tools.javac.comp.Flow$AliveAnalyzer.visitReturn(Flow.java:977)
>         at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCReturn.accept(JCTree.java:1714)
>         at jdk.compiler/com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49)
>         at jdk.compiler/com.sun.tools.javac.comp.Flow$BaseAnalyzer.scan(Flow.java:447)
>         at jdk.compiler/com.sun.tools.javac.comp.Flow$AliveAnalyzer.scanStat(Flow.java:507)
>         at jdk.compiler/com.sun.tools.javac.comp.Flow$AliveAnalyzer.scanStats(Flow.java:515)
>         at jdk.compiler/com.sun.tools.javac.comp.Flow$AliveAnalyzer.visitBlock(Flow.java:607)
>         at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:1092)
>         at jdk.compiler/com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49)
>         at jdk.compiler/com.sun.tools.javac.comp.Flow$BaseAnalyzer.scan(Flow.java:447)
>         at jdk.compiler/com.sun.tools.javac.comp.Flow$AliveAnalyzer.scanStat(Flow.java:507)
>         at jdk.compiler/com.sun.tools.javac.comp.Flow$AliveAnalyzer.visitMethodDef(Flow.java:571)
>         at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:922)
>         at jdk.compiler/com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49)
>         at jdk.compiler/com.sun.tools.javac.comp.Flow$BaseAnalyzer.scan(Flow.java:447)
>         at jdk.compiler/com.sun.tools.javac.comp.Flow$AliveAnalyzer.visitClassDef(Flow.java:551)
>         at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCClassDecl.accept(JCTree.java:820)
>         at jdk.compiler/com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49)
>         at jdk.compiler/com.sun.tools.javac.comp.Flow$BaseAnalyzer.scan(Flow.java:447)
>         at jdk.compiler/com.sun.tools.javac.comp.Flow$AliveAnalyzer.analyzeTree(Flow.java:1039)
>         at jdk.compiler/com.sun.tools.javac.comp.Flow$AliveAnalyzer.analyzeTree(Flow.java:1031)
>         at jdk.compiler/com.sun.tools.javac.comp.Flow.analyzeTree(Flow.java:223)
>         at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.flow(JavaCompiler.java:1377)
>         at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.flow(JavaCompiler.java:1351)
>         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)
> 
> 
> </details>

Aggelos Biboudis has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:

  Fix NPE and exhaustivity bug in record patterns with nested primitive type patterns

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

Changes: https://git.openjdk.java.net/amber/pull/82/files
 Webrev: https://webrevs.openjdk.java.net/?repo=amber&pr=82&range=01
  Stats: 69 lines in 2 files changed: 67 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/amber/pull/82.diff
  Fetch: git fetch https://git.openjdk.java.net/amber pull/82/head:pull/82

PR: https://git.openjdk.java.net/amber/pull/82


More information about the amber-dev mailing list