tag
Message-ID: 

Please review a simple fix for an NPE in doclint, in JDK 17.

The NPE is caused by checking if an unknown tag is self-closing. The fix is to move the check into the arm of the preceding `if` statement that ensures that the tags is not null.   Effectively, we do not valid whether unknown tags may be self-closing.

The potential for the NPE has been there a long time. The check that triggers the NPE became more likely when we removed support for HTML4.

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

Commit messages:
 - JDK-8264843: Javac crashes with NullPointerException when finding unencoded XML in  tag

Changes: https://git.openjdk.java.net/jdk17/pull/86/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=86&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8264843
  Stats: 32 lines in 3 files changed: 28 ins; 1 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/86.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/86/head:pull/86

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

From hannesw at openjdk.java.net  Thu Jun 17 09:55:14 2021
From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Thu, 17 Jun 2021 09:55:14 GMT
Subject: [jdk17] RFR: JDK-8264843: Javac crashes with NullPointerException
 when finding unencoded XML in  tag
In-Reply-To: 
References: 
Message-ID: 

On Wed, 16 Jun 2021 23:29:38 GMT, Jonathan Gibbons  wrote:

> Please review a simple fix for an NPE in doclint, in JDK 17.
> 
> The NPE is caused by checking if an unknown tag is self-closing. The fix is to move the check into the arm of the preceding `if` statement that ensures that the tags is not null.   Effectively, we do not valid whether unknown tags may be self-closing.
> 
> The potential for the NPE has been there a long time. The check that triggers the NPE became more likely when we removed support for HTML4.

Looks good!

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

Marked as reviewed by hannesw (Reviewer).

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

From jlahoda at openjdk.java.net  Thu Jun 17 13:43:20 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Thu, 17 Jun 2021 13:43:20 GMT
Subject: [jdk17] RFR: 8266631: StandardJavaFileManager:
 getJavaFileObjects() impl violates the spec [v2]
In-Reply-To: 
References: 
Message-ID: 

> [a copy of https://github.com/openjdk/jdk/pull/4360 for openjdk/jdk17]
> 
> This improves javadoc/specification of several StandardJavaFileManager methods, as requested in these bugs:
> https://bugs.openjdk.java.net/browse/JDK-8266631
> https://bugs.openjdk.java.net/browse/JDK-8266596
> https://bugs.openjdk.java.net/browse/JDK-8266591
> https://bugs.openjdk.java.net/browse/JDK-8266590
> 
> The CSR is here:
> https://bugs.openjdk.java.net/browse/JDK-8268260

Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:

 - Using @code instead of @linkplain, as suggested.
 - Merge branch 'master' into JDK-8266631
 - Improving javadoc as suggested on the review.
 - 8266631: StandardJavaFileManager: getJavaFileObjects() impl violates the spec

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

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/56/files
  - new: https://git.openjdk.java.net/jdk17/pull/56/files/3136b328..3f22cb02

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=56&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=56&range=00-01

  Stats: 48465 lines in 882 files changed: 37419 ins; 6396 del; 4650 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/56.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/56/head:pull/56

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

From jjg at openjdk.java.net  Thu Jun 17 15:22:34 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Thu, 17 Jun 2021 15:22:34 GMT
Subject: [jdk17] RFR: 8266631: StandardJavaFileManager:
 getJavaFileObjects() impl violates the spec [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 17 Jun 2021 13:43:20 GMT, Jan Lahoda  wrote:

>> [a copy of https://github.com/openjdk/jdk/pull/4360 for openjdk/jdk17]
>> 
>> This improves javadoc/specification of several StandardJavaFileManager methods, as requested in these bugs:
>> https://bugs.openjdk.java.net/browse/JDK-8266631
>> https://bugs.openjdk.java.net/browse/JDK-8266596
>> https://bugs.openjdk.java.net/browse/JDK-8266591
>> https://bugs.openjdk.java.net/browse/JDK-8266590
>> 
>> The CSR is here:
>> https://bugs.openjdk.java.net/browse/JDK-8268260
>
> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Using @code instead of @linkplain, as suggested.
>  - Merge branch 'master' into JDK-8266631
>  - Improving javadoc as suggested on the review.
>  - 8266631: StandardJavaFileManager: getJavaFileObjects() impl violates the spec

Marked as reviewed by jjg (Reviewer).

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

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

From gli at openjdk.java.net  Thu Jun 17 15:50:53 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Thu, 17 Jun 2021 15:50:53 GMT
Subject: RFR: 8263926: JavacFileManager.hasExplicitLocation fails with NPE
 while compiling
Message-ID: <5lGnGva_JNpEQKrBYfoDWHS7i05vv4Hiovw824Xm8EI=.60465cbf-59a9-4c05-9693-592fadb5c297@github.com>

Hi all,

The compiler fails with NullPointerException while building the maven project provided by the user in [JDK-8263926](https://bugs.openjdk.java.net/browse/JDK-8263926).

Actually, the patch is simple. We only need to add a `null` check before using the `msym.sourceLocation`.


-            if (fileManager.contains(msym.sourceLocation, fo)) 
+            if (msym.sourceLocation != null && fileManager.contains(msym.sourceLocation, fo)) 


But we can't verify whether the problem is solved because the code provided by the user is complex so that we have no way to wtite a regression test.

Recently, I deeply researched the relationship of the source code provided by the user 
and construct a minimal test case to verify the patch. 
The minimal test was attached to the JBS just now.
The attached test reproduces the bug by using the shell script instead of maven.
And the test case `SourceLocationNotExist.java` at this patch is another way to reproduce the bug. 
The steps in `SourceLocationNotExist.java` is the same as the shell script mentioned above.

Given that the bug is hard to be reproduced, I give some comments here.

1. We need to construct a jar file which has both `*.java` files and `*.class` files and has no named module.
    First, I compile the file `test/TestUnnamedModule.java` into `test/TestUnnamedModule.class`.
    Then  I use the `jar` tool to construct the jar file `test.jar`, which contains both `test/TestUnnamedModule.java` and `test/TestUnnamedModule.class`.
    Commands are like: 
    `javac test/TestUnnamedModule.java` and 
    `jar -c -f test.jar test/TestUnnamedModule.class test/TestUnnamedModule.java`

2. The last modified time of the `*.java` files should be newer than that of the `*.class` files. 
    Because the compiler implicitly choose the last modified file if both source files and class files are present.
    We need the compiler the choose the `*.java` files to reproduce the bug.
    So before using the `jar` command, we need to update the modified time of the `*.java` files to let it newer than `*.class` files.
    Command is like: `touch test/TestUnnamedModule.java`.

3. We need to use the class of the `test.jar` in a named module.
    I construct a module named `use`, which has a module file `module-info.java` and a source file `TestUse.java`.
    You can see the `TestUse.java` has a statement `import test.TestUnnamedModule;` to use the `test.jar`.

4. The `module-info.java` of the module `use` can't have the directive `requires test`. Because the name `test` is the automatic module name of the jar file `test.jar`.

5. When compiling the module `use` mentioned above, we must use the option `-sourcepath` and the `test.jar` is not  the argument of the `-sourcepath` and `--module-path`.
    Command is like: `javac -classpath test.jar -d use -sourcepath use use/module-info.java use/TestUse.java`

We can see that these five requirements are difficult to meet.
- Generally, our jar files shouldn't have the `*.java` files and only have the `*.class` files. But some libs that the user uses have these `*.java`files unexpectedly .
- And the class files are always compiled from the source files so that it is almost impossible that the last modified time of the `*.java` files is newer than `*.class` files.
- Generally, if we use the module system to construct our source code, we should compile the source code by using option `--module-path` instead of `-classpath`.
Command is like: javac **--module-path** test.jar -d use -sourcepath use use/module-info.java use/TestUse.java
instead of: javac **-classpath** test.jar -d use -sourcepath use use/module-info.java use/TestUse.java
However, the option `-classpath` is used by the maven at this situation (which no `requires` directive is in the `module-info.java`).

It is a combination of the java compiler(has no null check), the maven building tools(use `-classpath`), 
the extra libraries(have `*.java` files in the jar file) and the user's moduled project codes(have no corresponding module directive).

Anyway, we actually meet it now which is provided by the user.
Hope you are not confused by these descriptions.

Thanks for taking the time to review.

Best Regards,
-- Guoxiong

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

Commit messages:
 - 8263926: JavacFileManager.hasExplicitLocation fails with NPE while compiling

Changes: https://git.openjdk.java.net/jdk/pull/4523/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4523&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8263926
  Stats: 167 lines in 2 files changed: 166 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4523.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4523/head:pull/4523

PR: https://git.openjdk.java.net/jdk/pull/4523

From jjg at openjdk.java.net  Thu Jun 17 16:41:31 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Thu, 17 Jun 2021 16:41:31 GMT
Subject: [jdk17] Integrated: JDK-8264843: Javac crashes with
 NullPointerException when finding unencoded XML in  tag
In-Reply-To: 
References: 
Message-ID: 

On Wed, 16 Jun 2021 23:29:38 GMT, Jonathan Gibbons  wrote:

> Please review a simple fix for an NPE in doclint, in JDK 17.
> 
> The NPE is caused by checking if an unknown tag is self-closing. The fix is to move the check into the arm of the preceding `if` statement that ensures that the tags is not null.   Effectively, we do not valid whether unknown tags may be self-closing.
> 
> The potential for the NPE has been there a long time. The check that triggers the NPE became more likely when we removed support for HTML4.

This pull request has now been integrated.

Changeset: 0011b52e
Author:    Jonathan Gibbons 
URL:       https://git.openjdk.java.net/jdk17/commit/0011b52ee81d88b023f771432abc079c64266578
Stats:     32 lines in 3 files changed: 28 ins; 1 del; 3 mod

8264843: Javac crashes with NullPointerException when finding unencoded XML in  tag

Reviewed-by: hannesw

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

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

From vromero at openjdk.java.net  Thu Jun 17 16:41:47 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Thu, 17 Jun 2021 16:41:47 GMT
Subject: [jdk17] RFR: 8254571: Erroneous generic type inference in a
 lambda expression with a checked exception
In-Reply-To: 
References: 
Message-ID: <8eVy-1W0VFM_yOUn8hTnurzkKPvGO7-SyCWVVsWSMPs=.5ad283d9-bcfc-48a4-b5e0-b1aefaa2f03f@github.com>

On Thu, 17 Jun 2021 16:33:11 GMT, Vicente Romero  wrote:

> Hi,
> 
> The compiler is issuing an error for code like:
> 
> 
> class JDK8254571 {
>     public static void test() {
>         outer(nested(x -> mightThrow()));
>     }
>     
>     static  void outer(Object o) {}
> 
>     static  B nested(Fun fun) {
>         return null;
>     }
> 
>     interface Fun {
>         void m(X t) throws Y;
>     }
> 
>     static void mightThrow() throws Exception {}
> } 
> 
> 
> there are several things at play here:
> 
> 1) for performance reasons we decided to minimize the number of inference variables popped up when inferring nested generic method invocations, see Infer::roots
> 2) when an expression is stuck (like in this case this implicit lambda) we decide which inference variables should be present in the related inference context and thrown variables were not part of the equation
> 
> So there are three hypothesis here:
> 1) there is a bug in the code that determines which variables are passed up to the nested inference context, meaning that it is passing less variables than the bare minimum needed
> 2) there is a bug in determining which inference variables should be extracted from stuck expressions
> 3) both are buggy
> 
> The root cause of this bug is that some types escape from Attr with non instantiated type variables in them. I modified the test case to double check if the issue was not related to lambdas, but then the test passed so in the example above I added:
> 
> 
>      static  Fun mightThrow2() throws Y { return null; }
> 
> 
> which simulates the lambda and the compiler has no issues compiling this invocation:
> 
> 
>     outer(nested(mightThrow2()));
> 
> 
> so summing up, after double checking the logic of the code that minimized the inference context I realized that the issue is not there. The code is sound and its output only depend on its input, so the issue should be on determining the input. So IMO the issue is in what inference variables we extract from stuck expressions, which is one of the inputs to Infer::roots. Looking for what variables we extract from stuck expressions, I realized that the code currently ignores type variables in the throws clause and this is why my proposed fix is addressing this issue.
> 
> Comments?

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java line 1242:

> 1240:                 stuckVars.addAll(freeArgVars);
> 1241:                 depVars.addAll(inferenceContext.freeVarsIn(descType.getReturnType()));
> 1242:                 depVars.addAll(inferenceContext.freeVarsIn(descType.getThrownTypes()));

did the same for method references for completion but I couldn't find a test case that reproduced the issue with a method reference

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

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

From vromero at openjdk.java.net  Thu Jun 17 16:41:46 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Thu, 17 Jun 2021 16:41:46 GMT
Subject: [jdk17] RFR: 8254571: Erroneous generic type inference in a lambda
 expression with a checked exception
Message-ID: 

Hi,

The compiler is issuing an error for code like:


class JDK8254571 {
    public static void test() {
        outer(nested(x -> mightThrow()));
    }
    
    static  void outer(Object o) {}

    static  B nested(Fun fun) {
        return null;
    }

    interface Fun {
        void m(X t) throws Y;
    }

    static void mightThrow() throws Exception {}
} 


there are several things at play here:

1) for performance reasons we decided to minimize the number of inference variables popped up when inferring nested generic method invocations, see Infer::roots
2) when an expression is stuck (like in this case this implicit lambda) we decide which inference variables should be present in the related inference context and thrown variables were not part of the equation

So there are three hypothesis here:
1) there is a bug in the code that determines which variables are passed up to the nested inference context, meaning that it is passing less variables than the bare minimum needed
2) there is a bug in determining which inference variables should be extracted from stuck expressions
3) both are buggy

The root cause of this bug is that some types escape from Attr with non instantiated type variables in them. I modified the test case to double check if the issue was not related to lambdas, but then the test passed so in the example above I added:


     static  Fun mightThrow2() throws Y { return null; }


which simulates the lambda and the compiler has no issues compiling this invocation:


    outer(nested(mightThrow2()));


so summing up, after double checking the logic of the code that minimized the inference context I realized that the issue is not there. The code is sound and its output only depend on its input, so the issue should be on determining the input. So IMO the issue is in what inference variables we extract from stuck expressions, which is one of the inputs to Infer::roots. Looking for what variables we extract from stuck expressions, I realized that the code currently ignores type variables in the throws clause and this is why my proposed fix is addressing this issue.

Comments?

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

Commit messages:
 - 8254571: Erroneous generic type inference in a lambda expression with a checked exception

Changes: https://git.openjdk.java.net/jdk17/pull/91/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=91&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8254571
  Stats: 50 lines in 2 files changed: 50 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/91.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/91/head:pull/91

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

From gli at openjdk.java.net  Thu Jun 17 16:56:55 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Thu, 17 Jun 2021 16:56:55 GMT
Subject: RFR: 8263926: JavacFileManager.hasExplicitLocation fails with NPE
 while compiling [v2]
In-Reply-To: <5lGnGva_JNpEQKrBYfoDWHS7i05vv4Hiovw824Xm8EI=.60465cbf-59a9-4c05-9693-592fadb5c297@github.com>
References: <5lGnGva_JNpEQKrBYfoDWHS7i05vv4Hiovw824Xm8EI=.60465cbf-59a9-4c05-9693-592fadb5c297@github.com>
Message-ID: 

> Hi all,
> 
> The compiler fails with NullPointerException while building the maven project provided by the user in [JDK-8263926](https://bugs.openjdk.java.net/browse/JDK-8263926).
> 
> Actually, the patch is simple. We only need to add a `null` check before using the `msym.sourceLocation`.
> 
> 
> -            if (fileManager.contains(msym.sourceLocation, fo)) 
> +            if (msym.sourceLocation != null && fileManager.contains(msym.sourceLocation, fo)) 
> 
> 
> But we can't verify whether the problem is solved because the code provided by the user is complex so that we have no way to wtite a regression test.
> 
> Recently, I deeply researched the relationship of the source code provided by the user 
> and construct a minimal test case to verify the patch. 
> The minimal test was attached to the JBS just now.
> The attached test reproduces the bug by using the shell script instead of maven.
> And the test case `SourceLocationNotExist.java` at this patch is another way to reproduce the bug. 
> The steps in `SourceLocationNotExist.java` is the same as the shell script mentioned above.
> 
> Given that the bug is hard to be reproduced, I give some comments here.
> 
> 1. We need to construct a jar file which has both `*.java` files and `*.class` files and has no named module.
>     First, I compile the file `test/TestUnnamedModule.java` into `test/TestUnnamedModule.class`.
>     Then  I use the `jar` tool to construct the jar file `test.jar`, which contains both `test/TestUnnamedModule.java` and `test/TestUnnamedModule.class`.
>     Commands are like: 
>     `javac test/TestUnnamedModule.java` and 
>     `jar -c -f test.jar test/TestUnnamedModule.class test/TestUnnamedModule.java`
> 
> 2. The last modified time of the `*.java` files should be newer than that of the `*.class` files. 
>     Because the compiler implicitly choose the last modified file if both source files and class files are present.
>     We need the compiler the choose the `*.java` files to reproduce the bug.
>     So before using the `jar` command, we need to update the modified time of the `*.java` files to let it newer than `*.class` files.
>     Command is like: `touch test/TestUnnamedModule.java`.
> 
> 3. We need to use the class of the `test.jar` in a named module.
>     I construct a module named `use`, which has a module file `module-info.java` and a source file `TestUse.java`.
>     You can see the `TestUse.java` has a statement `import test.TestUnnamedModule;` to use the `test.jar`.
> 
> 4. The `module-info.java` of the module `use` can't have the directive `requires test`. Because the name `test` is the automatic module name of the jar file `test.jar`.
> 
> 5. When compiling the module `use` mentioned above, we must use the option `-sourcepath` and the `test.jar` is not  the argument of the `-sourcepath` and `--module-path`.
>     Command is like: `javac -classpath test.jar -d use -sourcepath use use/module-info.java use/TestUse.java`
> 
> We can see that these five requirements are difficult to meet.
> - Generally, our jar files shouldn't have the `*.java` files and only have the `*.class` files. But some libs that the user uses have these `*.java`files unexpectedly .
> - And the class files are always compiled from the source files so that it is almost impossible that the last modified time of the `*.java` files is newer than `*.class` files.
> - Generally, if we use the module system to construct our source code, we should compile the source code by using option `--module-path` instead of `-classpath`.
> Command is like: javac **--module-path** test.jar -d use -sourcepath use use/module-info.java use/TestUse.java
> instead of: javac **-classpath** test.jar -d use -sourcepath use use/module-info.java use/TestUse.java
> However, the option `-classpath` is used by the maven at this situation (which no `requires` directive is in the `module-info.java`).
> 
> It is a combination of the java compiler(has no null check), the maven building tools(use `-classpath`), 
> the extra libraries(have `*.java` files in the jar file) and the user's moduled project codes(have no corresponding module directive).
> 
> Anyway, we actually meet it now which is provided by the user.
> Hope you are not confused by these descriptions.
> 
> Thanks for taking the time to review.
> 
> Best Regards,
> -- Guoxiong

Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:

  Adjust the comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4523/files
  - new: https://git.openjdk.java.net/jdk/pull/4523/files/30b06d0c..d98b4e46

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4523&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4523&range=00-01

  Stats: 12 lines in 1 file changed: 0 ins; 0 del; 12 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4523.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4523/head:pull/4523

PR: https://git.openjdk.java.net/jdk/pull/4523

From prappo at openjdk.java.net  Thu Jun 17 17:45:29 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Thu, 17 Jun 2021 17:45:29 GMT
Subject: RFR: JDK-8268420: new Reporter method to report a diagnostic
 within a DocTree node [v2]
In-Reply-To: 
References: <_rKwE0lZFYFSnBNwLQRcaRiJnoAr6ZVXwyJSaXPnNQs=.d47a5ae3-c6fb-4a5b-aa32-9359d91eb912@github.com>
 
Message-ID: 

On Wed, 16 Jun 2021 17:18:31 GMT, Jonathan Gibbons  wrote:

>> Please review an update to add a new method in Reporter to report a diagnostic within a DocTree node for those DocTree nodes that wrap a string.
>> 
>> This is the last of the current round of updates to improve the diagnostics that can be generated by javadoc.
>> 
>> The general fix, in JavadocLog and Reporter, is pretty simple, given all the improvements in recent related changes.
>> 
>> There are some cosmetic cleanups that were made while exploring the current solution.
>> 
>> The test is "reasonably thorough" and uses a custom taglet to generate diagnostics for selected nodes in doc comment trees. The test then "algorithmically validates" (i.e. no golden files or text blocks) the diagnostics that are either passed to a DiagnosticListener or written to the console stream.
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review feedback

Re-synchronize with the CSR.

src/jdk.javadoc/share/classes/jdk/javadoc/doclet/Reporter.java line 97:

> 95:      * The positions should satisfy the relation {@code start <= pos <= end}.
> 96:      *
> 97:      * @implNote

Should be `@implSpec` instead; please make sure the CSR is updated as well since it also uses `@implNote`.

src/jdk.javadoc/share/classes/jdk/javadoc/doclet/Reporter.java line 99:

> 97:      * @implNote
> 98:      * This implementation ignores the {@code (start, pos, end)} values and simply calls
> 99:      * {@link #print(Diagnostic.Kind, DocTreePath,String) print(kind, path, message)};

Add a single space character after `,` in the reference.

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

Changes requested by prappo (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4489

From jlahoda at openjdk.java.net  Thu Jun 17 18:33:56 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Thu, 17 Jun 2021 18:33:56 GMT
Subject: [jdk17] RFR: 8268766: Desugaring of pattern matching enum switch
 should be improved [v2]
In-Reply-To: <3xKa946t0s_eRqnj0vfgjkfurBvZqKGe1QkYk-0lNO0=.518519f5-a2cb-44ed-946c-09e517e7c5d2@github.com>
References: <3xKa946t0s_eRqnj0vfgjkfurBvZqKGe1QkYk-0lNO0=.518519f5-a2cb-44ed-946c-09e517e7c5d2@github.com>
Message-ID: 

> Currently, an enum switch with patterns is desugared in a very non-standard, and potentially slow, way. It would be better to use the standard `typeSwitch` bootstrap to classify the enum constants. The bootstrap needs to accept enum constants as labels in order to allow this. A complication is that if an enum constant is missing, that is not an incompatible change for the switch, and the switch should simply work as if the case for the missing constant didn't exist. So, the proposed solution is to have a new bootstrap `enumConstant` that converts the enum constant name to the enum constant, returning `null`, if the constant does not exist. It delegates to `ConstantBootstraps.enumConstant` to do the actual conversion. And `typeSwitch` accepts `null`s as padding.
> 
> How does this look?

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Creating a new bootstrap method for (pattern matching) enum switches, as suggested.

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

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/81/files
  - new: https://git.openjdk.java.net/jdk17/pull/81/files/053c4895..4e1977a7

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=81&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=81&range=00-01

  Stats: 227 lines in 6 files changed: 144 ins; 44 del; 39 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/81.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/81/head:pull/81

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

From jjg at openjdk.java.net  Thu Jun 17 18:50:28 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Thu, 17 Jun 2021 18:50:28 GMT
Subject: RFR: 8263926: JavacFileManager.hasExplicitLocation fails with NPE
 while compiling [v2]
In-Reply-To: 
References: <5lGnGva_JNpEQKrBYfoDWHS7i05vv4Hiovw824Xm8EI=.60465cbf-59a9-4c05-9693-592fadb5c297@github.com>
 
Message-ID: 

On Thu, 17 Jun 2021 16:56:55 GMT, Guoxiong Li  wrote:

>> Hi all,
>> 
>> The compiler fails with NullPointerException while building the maven project provided by the user in [JDK-8263926](https://bugs.openjdk.java.net/browse/JDK-8263926).
>> 
>> Actually, the patch is simple. We only need to add a `null` check before using the `msym.sourceLocation`.
>> 
>> 
>> -            if (fileManager.contains(msym.sourceLocation, fo)) 
>> +            if (msym.sourceLocation != null && fileManager.contains(msym.sourceLocation, fo)) 
>> 
>> 
>> But we can't verify whether the problem is solved because the code provided by the user is complex so that we have no way to wtite a regression test.
>> 
>> Recently, I deeply researched the relationship of the source code provided by the user 
>> and construct a minimal test case to verify the patch. 
>> The minimal test was attached to the JBS just now.
>> The attached test reproduces the bug by using the shell script instead of maven.
>> And the test case `SourceLocationNotExist.java` at this patch is another way to reproduce the bug. 
>> The steps in `SourceLocationNotExist.java` is the same as the shell script mentioned above.
>> 
>> Given that the bug is hard to be reproduced, I give some comments here.
>> 
>> 1. We need to construct a jar file which has both `*.java` files and `*.class` files and has no named module.
>>     First, I compile the file `test/TestUnnamedModule.java` into `test/TestUnnamedModule.class`.
>>     Then  I use the `jar` tool to construct the jar file `test.jar`, which contains both `test/TestUnnamedModule.java` and `test/TestUnnamedModule.class`.
>>     Commands are like: 
>>     `javac test/TestUnnamedModule.java` and 
>>     `jar -c -f test.jar test/TestUnnamedModule.class test/TestUnnamedModule.java`
>> 
>> 2. The last modified time of the `*.java` files should be newer than that of the `*.class` files. 
>>     Because the compiler implicitly choose the last modified file if both source files and class files are present.
>>     We need the compiler the choose the `*.java` files to reproduce the bug.
>>     So before using the `jar` command, we need to update the modified time of the `*.java` files to let it newer than `*.class` files.
>>     Command is like: `touch test/TestUnnamedModule.java`.
>> 
>> 3. We need to use the class of the `test.jar` in a named module.
>>     I construct a module named `use`, which has a module file `module-info.java` and a source file `TestUse.java`.
>>     You can see the `TestUse.java` has a statement `import test.TestUnnamedModule;` to use the `test.jar`.
>> 
>> 4. The `module-info.java` of the module `use` can't have the directive `requires test`. Because the name `test` is the automatic module name of the jar file `test.jar`.
>> 
>> 5. When compiling the module `use` mentioned above, we must use the option `-sourcepath` and the `test.jar` is not  the argument of the `-sourcepath` and `--module-path`.
>>     Command is like: `javac -classpath test.jar -d use -sourcepath use use/module-info.java use/TestUse.java`
>> 
>> We can see that these five requirements are difficult to meet.
>> - Generally, our jar files shouldn't have the `*.java` files and only have the `*.class` files. But some libs that the user uses have these `*.java`files unexpectedly .
>> - And the class files are always compiled from the source files so that it is almost impossible that the last modified time of the `*.java` files is newer than `*.class` files.
>> - Generally, if we use the module system to construct our source code, we should compile the source code by using option `--module-path` instead of `-classpath`.
>> Command is like: javac **--module-path** test.jar -d use -sourcepath use use/module-info.java use/TestUse.java
>> instead of: javac **-classpath** test.jar -d use -sourcepath use use/module-info.java use/TestUse.java
>> However, the option `-classpath` is used by the maven at this situation (which no `requires` directive is in the `module-info.java`).
>> 
>> It is a combination of the java compiler(has no null check), the maven building tools(use `-classpath`), 
>> the extra libraries(have `*.java` files in the jar file) and the user's moduled project codes(have no corresponding module directive).
>> 
>> Anyway, we actually meet it now which is provided by the user.
>> Hope you are not confused by these descriptions.
>> 
>> Thanks for taking the time to review.
>> 
>> Best Regards,
>> -- Guoxiong
>
> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust the comments

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Modules.java line 539:

> 537:         try {
> 538:             JavaFileObject fo = tree.sourcefile;
> 539:             if (msym.sourceLocation != null && fileManager.contains(msym.sourceLocation, fo)) {

What is the module for which the `sourceLocation` is `null` ... in other words, it is reasonable for this method to be called with a module with no source location, or is this check just hiding some other bug elsewhere?

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

PR: https://git.openjdk.java.net/jdk/pull/4523

From mcimadamore at openjdk.java.net  Thu Jun 17 21:24:39 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 17 Jun 2021 21:24:39 GMT
Subject: [jdk17] RFR: 8268766: Desugaring of pattern matching enum switch
 should be improved [v2]
In-Reply-To: 
References: <3xKa946t0s_eRqnj0vfgjkfurBvZqKGe1QkYk-0lNO0=.518519f5-a2cb-44ed-946c-09e517e7c5d2@github.com>
 
Message-ID: <2h5cKY6Dcez1aTsH9d9NoJ-4vMBYTrCoPCKz-JkcV8o=.ecfd36ec-afef-4484-9cb9-e54cffc6881e@github.com>

On Thu, 17 Jun 2021 18:33:56 GMT, Jan Lahoda  wrote:

>> Currently, an enum switch with patterns is desugared in a very non-standard, and potentially slow, way. It would be better to use the standard `typeSwitch` bootstrap to classify the enum constants. The bootstrap needs to accept enum constants as labels in order to allow this. A complication is that if an enum constant is missing, that is not an incompatible change for the switch, and the switch should simply work as if the case for the missing constant didn't exist. So, the proposed solution is to have a new bootstrap `enumConstant` that converts the enum constant name to the enum constant, returning `null`, if the constant does not exist. It delegates to `ConstantBootstraps.enumConstant` to do the actual conversion. And `typeSwitch` accepts `null`s as padding.
>> 
>> How does this look?
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Creating a new bootstrap method for (pattern matching) enum switches, as suggested.

Very good piece of work. I like all the code that can be removed because of this.

I assume that the new code only kicks in if there's at least a pattern in the switch, otherwise we fallback to legacy translation (meaning that compiling with source < 17 is still ok), right?

I left some comments to help and clarify the javadoc text of the enum BSM.

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 173:

> 171: 
> 172:     /**
> 173:      * Bootstrap method for linking an {@code invokedynamic} call site that

This should be made clearer - e.g. the first argument is of type `Class` and represents the enum we want to switch on. The remaining constants should be of type `String`, the names of the various constants.

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 178:

> 176:      * {@code String} (representing enum constants) or {@code Class}.
> 177:      * 
> 178:      * The type of the returned {@code CallSite}'s method handle will have

Suggestion:

     * The returned {@code CallSite}'s method handle will have

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 179:

> 177:      * 

> 178:      * The type of the returned {@code CallSite}'s method handle will have
> 179:      * a return type of {@code int}.   It has two parameters: the first argument

Suggestion:

     * a return type of {@code int}.   It has two parameters: the first argument

Suggestion:

     * a return type of {@code int} and accepts two parameters: the first argument

test/langtools/tools/javac/patterns/EnumTypeChanges.java line 80:

> 78:     A,
> 79:     B;
> 80: }

missing newline here

test/langtools/tools/javac/patterns/EnumTypeChanges2.java line 27:

> 25:     A,
> 26:     C;
> 27: }

missing newline here

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

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

From forax at openjdk.java.net  Thu Jun 17 21:59:31 2021
From: forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Thu, 17 Jun 2021 21:59:31 GMT
Subject: [jdk17] RFR: 8268766: Desugaring of pattern matching enum switch
 should be improved [v2]
In-Reply-To: 
References: <3xKa946t0s_eRqnj0vfgjkfurBvZqKGe1QkYk-0lNO0=.518519f5-a2cb-44ed-946c-09e517e7c5d2@github.com>
 
Message-ID: 

On Thu, 17 Jun 2021 18:33:56 GMT, Jan Lahoda  wrote:

>> Currently, an enum switch with patterns is desugared in a very non-standard, and potentially slow, way. It would be better to use the standard `typeSwitch` bootstrap to classify the enum constants. The bootstrap needs to accept enum constants as labels in order to allow this. A complication is that if an enum constant is missing, that is not an incompatible change for the switch, and the switch should simply work as if the case for the missing constant didn't exist. So, the proposed solution is to have a new bootstrap `enumConstant` that converts the enum constant name to the enum constant, returning `null`, if the constant does not exist. It delegates to `ConstantBootstraps.enumConstant` to do the actual conversion. And `typeSwitch` accepts `null`s as padding.
>> 
>> How does this look?
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Creating a new bootstrap method for (pattern matching) enum switches, as suggested.

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 222:

> 220:                                       String invocationName,
> 221:                                       MethodType invocationType,
> 222:                                       Object... labels) throws Throwable {

Is it not better to take a Class and a String... as separated parameters instead of taking Object... and doing the conversion to a Class and an array of String later in Java

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 238:

> 236:         MethodHandle target =
> 237:                 MethodHandles.insertArguments(DO_ENUM_SWITCH, 2, (Object) labels);
> 238:         target = MethodHandles.explicitCastArguments(target, invocationType);

why explicitCast is used here instead of the classical cast asType() ?

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

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

From jwilhelm at openjdk.java.net  Thu Jun 17 23:34:36 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Thu, 17 Jun 2021 23:34:36 GMT
Subject: RFR: Merge jdk17
Message-ID: 

Forwardport JDK 17 -> JDK 18

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

Commit messages:
 - Merge
 - 8268371: C2: assert(_gvn.type(obj)->higher_equal(tjp)) failed: cast_up is no longer needed
 - 8268676: assert(!ik->is_interface() && !ik->has_subklass()) failed: inconsistent klass hierarchy
 - 8268265: MutableSpaceUsedHelper::take_sample() hits assert(left >= right) failed: avoid overflow
 - 8268971: ProblemList tools/jpackage/windows/WinInstallerIconTest.java on win-x64
 - 8264843: Javac crashes with NullPointerException when finding unencoded XML in  tag
 - 8265297: javax/net/ssl/SSLSession/TestEnabledProtocols.java failed with "RuntimeException: java.net.SocketException: Connection reset"
 - 8268353: Test libsvml.so is and is not present in jdk image
 - 8249899: jdk/javadoc/tool/InlineTagsWithBraces.java uses @ignore w/o bug-id
 - 8268776: Test `ADatagramSocket.java` missing /othervm from @run tag
 - ... and 3 more: https://git.openjdk.java.net/jdk/compare/bb24fa65...a3951c44

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.java.net/jdk/pull/4525/files
  Stats: 845 lines in 26 files changed: 408 ins; 384 del; 53 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4525.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4525/head:pull/4525

PR: https://git.openjdk.java.net/jdk/pull/4525

From jwilhelm at openjdk.java.net  Fri Jun 18 00:56:32 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Fri, 18 Jun 2021 00:56:32 GMT
Subject: Integrated: Merge jdk17
In-Reply-To: 
References: 
Message-ID: 

On Thu, 17 Jun 2021 23:26:26 GMT, Jesper Wilhelmsson  wrote:

> Forwardport JDK 17 -> JDK 18

This pull request has now been integrated.

Changeset: a051e735
Author:    Jesper Wilhelmsson 
URL:       https://git.openjdk.java.net/jdk/commit/a051e735cda0d5ee5cb6ce0738aa549a7319a28c
Stats:     845 lines in 26 files changed: 408 ins; 384 del; 53 mod

Merge

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

PR: https://git.openjdk.java.net/jdk/pull/4525

From jlahoda at openjdk.java.net  Fri Jun 18 09:03:30 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Fri, 18 Jun 2021 09:03:30 GMT
Subject: [jdk17] RFR: 8268766: Desugaring of pattern matching enum switch
 should be improved [v2]
In-Reply-To: <2h5cKY6Dcez1aTsH9d9NoJ-4vMBYTrCoPCKz-JkcV8o=.ecfd36ec-afef-4484-9cb9-e54cffc6881e@github.com>
References: <3xKa946t0s_eRqnj0vfgjkfurBvZqKGe1QkYk-0lNO0=.518519f5-a2cb-44ed-946c-09e517e7c5d2@github.com>
 
 <2h5cKY6Dcez1aTsH9d9NoJ-4vMBYTrCoPCKz-JkcV8o=.ecfd36ec-afef-4484-9cb9-e54cffc6881e@github.com>
Message-ID: 

On Thu, 17 Jun 2021 21:03:58 GMT, Maurizio Cimadamore  wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Creating a new bootstrap method for (pattern matching) enum switches, as suggested.
>
> src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 173:
> 
>> 171: 
>> 172:     /**
>> 173:      * Bootstrap method for linking an {@code invokedynamic} call site that
> 
> This should be made clearer - e.g. the first argument is of type `Class` and represents the enum we want to switch on. The remaining constants should be of type `String`, the names of the various constants.

That is not quite what the labels represent. The target Enum type is inferred from the bootstrap method's invocation MethodType. (Alternatively, we can add a new Class parameter to the bootstrap method.)

For the labels, please consider this switch:

         E sel = null;
         switch (sel) {
             case A -> {}
             case E e && "B".equals(e.name()) -> {}
             case C -> {}
             case E e -> {}
         }


The patterns and the constants are mixed, and the order needs to be represented somehow in the labels array, so that the switch will classify the input correctly. The method in this proposal will use `{"A", E.class, "C", E.class}` as the labels array (which is mostly consistent with the `typeSwitch` method), but we could use different encodings if needed.

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

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

From jlahoda at openjdk.java.net  Fri Jun 18 09:11:26 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Fri, 18 Jun 2021 09:11:26 GMT
Subject: [jdk17] RFR: 8268766: Desugaring of pattern matching enum switch
 should be improved [v2]
In-Reply-To: 
References: <3xKa946t0s_eRqnj0vfgjkfurBvZqKGe1QkYk-0lNO0=.518519f5-a2cb-44ed-946c-09e517e7c5d2@github.com>
 
 
Message-ID: 

On Thu, 17 Jun 2021 21:56:21 GMT, R?mi Forax  wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Creating a new bootstrap method for (pattern matching) enum switches, as suggested.
>
> src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 222:
> 
>> 220:                                       String invocationName,
>> 221:                                       MethodType invocationType,
>> 222:                                       Object... labels) throws Throwable {
> 
> Is it not better to take a Class and a String... as separated parameters instead of taking Object... and doing the conversion to a Class and an array of String later in Java

This is to represent cases like:

         E sel = null;
         switch (sel) {
             case A -> {}
             case E e && "B".equals(e.name()) -> {}
             case C -> {}
             case E e -> {}
         }


The method needs to know which cases represent constants and which represent patterns (even though the primary type of all the patterns will be the enum type), so we cannot easily put the `Class` first (or elide it), and then a `String...`, unless we represent the patterns in the `String...` array somehow.

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

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

From jlahoda at openjdk.java.net  Fri Jun 18 09:14:31 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Fri, 18 Jun 2021 09:14:31 GMT
Subject: [jdk17] RFR: 8268766: Desugaring of pattern matching enum switch
 should be improved [v2]
In-Reply-To: <2h5cKY6Dcez1aTsH9d9NoJ-4vMBYTrCoPCKz-JkcV8o=.ecfd36ec-afef-4484-9cb9-e54cffc6881e@github.com>
References: <3xKa946t0s_eRqnj0vfgjkfurBvZqKGe1QkYk-0lNO0=.518519f5-a2cb-44ed-946c-09e517e7c5d2@github.com>
 
 <2h5cKY6Dcez1aTsH9d9NoJ-4vMBYTrCoPCKz-JkcV8o=.ecfd36ec-afef-4484-9cb9-e54cffc6881e@github.com>
Message-ID: 

On Thu, 17 Jun 2021 21:21:14 GMT, Maurizio Cimadamore  wrote:

> Very good piece of work. I like all the code that can be removed because of this.

Thanks!

> 
> I assume that the new code only kicks in if there's at least a pattern in the switch, otherwise we fallback to legacy translation (meaning that compiling with source < 17 is still ok), right?

Yes, it is only for pattern matching switches. Traditional switches are still desugared in the way they were.

> 
> I left some comments to help and clarify the javadoc text of the enum BSM.

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

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

From forax at openjdk.java.net  Fri Jun 18 09:50:28 2021
From: forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Fri, 18 Jun 2021 09:50:28 GMT
Subject: [jdk17] RFR: 8268766: Desugaring of pattern matching enum switch
 should be improved [v2]
In-Reply-To: 
References: <3xKa946t0s_eRqnj0vfgjkfurBvZqKGe1QkYk-0lNO0=.518519f5-a2cb-44ed-946c-09e517e7c5d2@github.com>
 
 
 
Message-ID: 

On Fri, 18 Jun 2021 09:08:04 GMT, Jan Lahoda  wrote:

>> src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 222:
>> 
>>> 220:                                       String invocationName,
>>> 221:                                       MethodType invocationType,
>>> 222:                                       Object... labels) throws Throwable {
>> 
>> Is it not better to take a Class and a String... as separated parameters instead of taking Object... and doing the conversion to a Class and an array of String later in Java
>
> This is to represent cases like:
> 
>          E sel = null;
>          switch (sel) {
>              case A -> {}
>              case E e && "B".equals(e.name()) -> {}
>              case C -> {}
>              case E e -> {}
>          }
> 
> 
> The method needs to know which cases represent constants and which represent patterns (even though the primary type of all the patterns will be the enum type), so we cannot easily put the `Class` first (or elide it), and then a `String...`, unless we represent the patterns in the `String...` array somehow.

Ok got it,
At some point, we will have to represent patterns either as String and parse them or as Condy of condy if we want a more structured recursive way.

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

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

From jlahoda at openjdk.java.net  Fri Jun 18 13:23:57 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Fri, 18 Jun 2021 13:23:57 GMT
Subject: [jdk17] RFR: 8268766: Desugaring of pattern matching enum switch
 should be improved [v3]
In-Reply-To: <3xKa946t0s_eRqnj0vfgjkfurBvZqKGe1QkYk-0lNO0=.518519f5-a2cb-44ed-946c-09e517e7c5d2@github.com>
References: <3xKa946t0s_eRqnj0vfgjkfurBvZqKGe1QkYk-0lNO0=.518519f5-a2cb-44ed-946c-09e517e7c5d2@github.com>
Message-ID: 

> Currently, an enum switch with patterns is desugared in a very non-standard, and potentially slow, way. It would be better to use the standard `typeSwitch` bootstrap to classify the enum constants. The bootstrap needs to accept enum constants as labels in order to allow this. A complication is that if an enum constant is missing, that is not an incompatible change for the switch, and the switch should simply work as if the case for the missing constant didn't exist. So, the proposed solution is to have a new bootstrap `enumConstant` that converts the enum constant name to the enum constant, returning `null`, if the constant does not exist. It delegates to `ConstantBootstraps.enumConstant` to do the actual conversion. And `typeSwitch` accepts `null`s as padding.
> 
> How does this look?

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Updating javadoc, code and tests as suggested.

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

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/81/files
  - new: https://git.openjdk.java.net/jdk17/pull/81/files/4e1977a7..06a1bebf

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=81&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=81&range=01-02

  Stats: 5 lines in 3 files changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/81.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/81/head:pull/81

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

From mcimadamore at openjdk.java.net  Fri Jun 18 14:29:31 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 18 Jun 2021 14:29:31 GMT
Subject: [jdk17] RFR: 8268766: Desugaring of pattern matching enum switch
 should be improved [v2]
In-Reply-To: 
References: <3xKa946t0s_eRqnj0vfgjkfurBvZqKGe1QkYk-0lNO0=.518519f5-a2cb-44ed-946c-09e517e7c5d2@github.com>
 
 
 
 
Message-ID: 

On Fri, 18 Jun 2021 09:47:29 GMT, R?mi Forax  wrote:

>> This is to represent cases like:
>> 
>>          E sel = null;
>>          switch (sel) {
>>              case A -> {}
>>              case E e && "B".equals(e.name()) -> {}
>>              case C -> {}
>>              case E e -> {}
>>          }
>> 
>> 
>> The method needs to know which cases represent constants and which represent patterns (even though the primary type of all the patterns will be the enum type), so we cannot easily put the `Class` first (or elide it), and then a `String...`, unless we represent the patterns in the `String...` array somehow.
>
> Ok got it,
> At some point, we will have to represent patterns either as String and parse them or as Condy of condy if we want a more structured recursive way.

Of course - I missed it! Thanks for the explanation.

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

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

From mcimadamore at openjdk.java.net  Fri Jun 18 14:40:38 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 18 Jun 2021 14:40:38 GMT
Subject: [jdk17] RFR: 8268766: Desugaring of pattern matching enum switch
 should be improved [v3]
In-Reply-To: 
References: <3xKa946t0s_eRqnj0vfgjkfurBvZqKGe1QkYk-0lNO0=.518519f5-a2cb-44ed-946c-09e517e7c5d2@github.com>
 
Message-ID: 

On Fri, 18 Jun 2021 13:23:57 GMT, Jan Lahoda  wrote:

>> Currently, an enum switch with patterns is desugared in a very non-standard, and potentially slow, way. It would be better to use the standard `typeSwitch` bootstrap to classify the enum constants. The bootstrap needs to accept enum constants as labels in order to allow this. A complication is that if an enum constant is missing, that is not an incompatible change for the switch, and the switch should simply work as if the case for the missing constant didn't exist. So, the proposed solution is to have a new bootstrap `enumConstant` that converts the enum constant name to the enum constant, returning `null`, if the constant does not exist. It delegates to `ConstantBootstraps.enumConstant` to do the actual conversion. And `typeSwitch` accepts `null`s as padding.
>> 
>> How does this look?
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updating javadoc, code and tests as suggested.

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 175:

> 173:      * Bootstrap method for linking an {@code invokedynamic} call site that
> 174:      * implements a {@code switch} on a target of an enum type.  The static
> 175:      * arguments are an array of case labels which must be non-null and of type

This sentence can still be improved and made cleared. Example:

> The static arguments are used to encode the case labels associated to the `switch` construct, where each label can be encoded as a `String` (e.g. to represent an enum constant), or, alternatively, as a `Class` (e.g. to represent a type test pattern whose type is an enum type).

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 179:

> 177:      * 
> 178:      * The returned {@code CallSite}'s method handle will have
> 179:      * a return type of {@code int} and accepts two parameters: the first argument

By writing the javadoc text above, it came to mind that, perhaps, some validation is in order for the static arguments. For instance:

* the enum type of a Class parameter doesn't match that of the BSM
* the static arguments contain more than one Class parameter (I think even if they are all of the same "correct" type, that's bogus, right?)

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

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

From gli at openjdk.java.net  Fri Jun 18 16:13:04 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Fri, 18 Jun 2021 16:13:04 GMT
Subject: RFR: 8263926: JavacFileManager.hasExplicitLocation fails with NPE
 while compiling [v3]
In-Reply-To: <5lGnGva_JNpEQKrBYfoDWHS7i05vv4Hiovw824Xm8EI=.60465cbf-59a9-4c05-9693-592fadb5c297@github.com>
References: <5lGnGva_JNpEQKrBYfoDWHS7i05vv4Hiovw824Xm8EI=.60465cbf-59a9-4c05-9693-592fadb5c297@github.com>
Message-ID: <78FllLSXin1pf4XJXj_y1hzMzfyqGdhB4u_TGyFKsqM=.38939f19-85b4-4d4d-8bf9-64565233378e@github.com>

> Hi all,
> 
> The compiler fails with NullPointerException while building the maven project provided by the user in [JDK-8263926](https://bugs.openjdk.java.net/browse/JDK-8263926).
> 
> Actually, the patch is simple. We only need to add a `null` check before using the `msym.sourceLocation`.
> 
> 
> -            if (fileManager.contains(msym.sourceLocation, fo)) 
> +            if (msym.sourceLocation != null && fileManager.contains(msym.sourceLocation, fo)) 
> 
> 
> But we can't verify whether the problem is solved because the code provided by the user is complex so that we have no way to wtite a regression test.
> 
> Recently, I deeply researched the relationship of the source code provided by the user 
> and construct a minimal test case to verify the patch. 
> The minimal test was attached to the JBS just now.
> The attached test reproduces the bug by using the shell script instead of maven.
> And the test case `SourceLocationNotExist.java` at this patch is another way to reproduce the bug. 
> The steps in `SourceLocationNotExist.java` is the same as the shell script mentioned above.
> 
> Given that the bug is hard to be reproduced, I give some comments here.
> 
> 1. We need to construct a jar file which has both `*.java` files and `*.class` files and has no named module.
>     First, I compile the file `test/TestUnnamedModule.java` into `test/TestUnnamedModule.class`.
>     Then  I use the `jar` tool to construct the jar file `test.jar`, which contains both `test/TestUnnamedModule.java` and `test/TestUnnamedModule.class`.
>     Commands are like: 
>     `javac test/TestUnnamedModule.java` and 
>     `jar -c -f test.jar test/TestUnnamedModule.class test/TestUnnamedModule.java`
> 
> 2. The last modified time of the `*.java` files should be newer than that of the `*.class` files. 
>     Because the compiler implicitly choose the last modified file if both source files and class files are present.
>     We need the compiler the choose the `*.java` files to reproduce the bug.
>     So before using the `jar` command, we need to update the modified time of the `*.java` files to let it newer than `*.class` files.
>     Command is like: `touch test/TestUnnamedModule.java`.
> 
> 3. We need to use the class of the `test.jar` in a named module.
>     I construct a module named `use`, which has a module file `module-info.java` and a source file `TestUse.java`.
>     You can see the `TestUse.java` has a statement `import test.TestUnnamedModule;` to use the `test.jar`.
> 
> 4. The `module-info.java` of the module `use` can't have the directive `requires test`. Because the name `test` is the automatic module name of the jar file `test.jar`.
> 
> 5. When compiling the module `use` mentioned above, we must use the option `-sourcepath` and the `test.jar` is not  the argument of the `-sourcepath` and `--module-path`.
>     Command is like: `javac -classpath test.jar -d use -sourcepath use use/module-info.java use/TestUse.java`
> 
> We can see that these five requirements are difficult to meet.
> - Generally, our jar files shouldn't have the `*.java` files and only have the `*.class` files. But some libs that the user uses have these `*.java`files unexpectedly .
> - And the class files are always compiled from the source files so that it is almost impossible that the last modified time of the `*.java` files is newer than `*.class` files.
> - Generally, if we use the module system to construct our source code, we should compile the source code by using option `--module-path` instead of `-classpath`.
> Command is like: javac **--module-path** test.jar -d use -sourcepath use use/module-info.java use/TestUse.java
> instead of: javac **-classpath** test.jar -d use -sourcepath use use/module-info.java use/TestUse.java
> However, the option `-classpath` is used by the maven at this situation (which no `requires` directive is in the `module-info.java`).
> 
> It is a combination of the java compiler(has no null check), the maven building tools(use `-classpath`), 
> the extra libraries(have `*.java` files in the jar file) and the user's moduled project codes(have no corresponding module directive).
> 
> Anyway, we actually meet it now which is provided by the user.
> Hope you are not confused by these descriptions.
> 
> Thanks for taking the time to review.
> 
> Best Regards,
> -- Guoxiong

Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:

  Revise the method ClassFinder#scanUserPaths. Address the situation when the haveSourcePath is true and the includeSourcePath is false

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4523/files
  - new: https://git.openjdk.java.net/jdk/pull/4523/files/d98b4e46..fd4be911

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4523&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4523&range=01-02

  Stats: 33 lines in 2 files changed: 23 ins; 0 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4523.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4523/head:pull/4523

PR: https://git.openjdk.java.net/jdk/pull/4523

From gli at openjdk.java.net  Fri Jun 18 16:25:30 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Fri, 18 Jun 2021 16:25:30 GMT
Subject: RFR: 8263926: JavacFileManager.hasExplicitLocation fails with NPE
 while compiling [v2]
In-Reply-To: 
References: <5lGnGva_JNpEQKrBYfoDWHS7i05vv4Hiovw824Xm8EI=.60465cbf-59a9-4c05-9693-592fadb5c297@github.com>
 
 
Message-ID: 

On Thu, 17 Jun 2021 18:47:12 GMT, Jonathan Gibbons  wrote:

>> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adjust the comments
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Modules.java line 539:
> 
>> 537:         try {
>> 538:             JavaFileObject fo = tree.sourcefile;
>> 539:             if (msym.sourceLocation != null && fileManager.contains(msym.sourceLocation, fo)) {
> 
> What is the module for which the `sourceLocation` is `null` ... in other words, it is reasonable for this method to be called with a module with no source location, or is this check just hiding some other bug elsewhere?

@jonathan-gibbons Thanks for the comment. Your worry is right. I do more investigation in the source code today.

The logic of the method `ClassFinder#scanUserPaths` seems wrong. 
When the `fileManager.hasLocation(SOURCE_PATH)` (means `haveSourcePath` in my updated code) is true and the `includeSourcePath` is false, the compiler shouldn't search any source path and source files.

I seperated the situations and revised the code and test. What do you think about the updated code?
I worry that this change may cause some regressions. Currently, the `tools/javac` passed locally.
I am still waiting for the `Pre-submit tests` to finish.

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

PR: https://git.openjdk.java.net/jdk/pull/4523

From gli at openjdk.java.net  Fri Jun 18 16:29:38 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Fri, 18 Jun 2021 16:29:38 GMT
Subject: RFR: 8263926: JavacFileManager.hasExplicitLocation fails with NPE
 while compiling [v2]
In-Reply-To: 
References: <5lGnGva_JNpEQKrBYfoDWHS7i05vv4Hiovw824Xm8EI=.60465cbf-59a9-4c05-9693-592fadb5c297@github.com>
 
 
 
Message-ID: 

On Fri, 18 Jun 2021 16:22:26 GMT, Guoxiong Li  wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Modules.java line 539:
>> 
>>> 537:         try {
>>> 538:             JavaFileObject fo = tree.sourcefile;
>>> 539:             if (msym.sourceLocation != null && fileManager.contains(msym.sourceLocation, fo)) {
>> 
>> What is the module for which the `sourceLocation` is `null` ... in other words, it is reasonable for this method to be called with a module with no source location, or is this check just hiding some other bug elsewhere?
>
> @jonathan-gibbons Thanks for the comment. Your worry is right. I do more investigation in the source code today.
> 
> The logic of the method `ClassFinder#scanUserPaths` seems wrong. 
> When the `fileManager.hasLocation(SOURCE_PATH)` (means `haveSourcePath` in my updated code) is true and the `includeSourcePath` is false, the compiler shouldn't search any source path and source files.
> 
> I seperated the situations and revised the code and test. What do you think about the updated code?
> I worry that this change may cause some regressions. Currently, the `tools/javac` passed locally.
> I am still waiting for the `Pre-submit tests` to finish.

And about the null check, I want to keep it so that the compiler won't crash when meeting the situation like this bug.

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

PR: https://git.openjdk.java.net/jdk/pull/4523

From jjg at openjdk.java.net  Fri Jun 18 21:08:37 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Fri, 18 Jun 2021 21:08:37 GMT
Subject: RFR: 8263926: JavacFileManager.hasExplicitLocation fails with NPE
 while compiling [v2]
In-Reply-To: 
References: <5lGnGva_JNpEQKrBYfoDWHS7i05vv4Hiovw824Xm8EI=.60465cbf-59a9-4c05-9693-592fadb5c297@github.com>
 
 
 
 
Message-ID: <6ktugZwAsJmG8RpAatIdKo84YoiPcFceuyA6MoISYVs=.6430fa1a-d48e-4398-809d-5e086ed77189@github.com>

On Fri, 18 Jun 2021 16:26:57 GMT, Guoxiong Li  wrote:

> And about the null check, I want to keep it so that the compiler won't crash when meeting the situation like this bug.

If we believe that the null should not occur, it would be covering up a bug to provide the null check.

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

PR: https://git.openjdk.java.net/jdk/pull/4523

From forax at univ-mlv.fr  Fri Jun 18 22:01:35 2021
From: forax at univ-mlv.fr (Remi Forax)
Date: Sat, 19 Jun 2021 00:01:35 +0200 (CEST)
Subject: javac allows to catch a checked exception if hidden inside an
 intersection type
Message-ID: <1753700900.1260524.1624053695654.JavaMail.zimbra@u-pem.fr>

Hi all,
this code has two bugs.

  public static void execute(Runnable runnable) throws IOException {
    try {
      runnable.run();
    } catch(RuntimeException | IOException e) {   // oops 1
      var cause = e instanceof UncheckedIOException unchecked ? unchecked.getCause(): e;
      throw cause;  // oops 2
    }
  }

The catch (oops 1) should be rejected because the try block doesn't throw IOException, but javac accepts it.

Intellij does not see any bugs, like javac it does not see "oops 1". It also types "cause" as a RuntimeException | IOException instead of Exception,
the common super type because ?: does not support precise exceptions like a catch/throw does so it should compute the lowest upper bound).

Eclipse correctly reports the two issues.

regards,
R?mi

From forax at univ-mlv.fr  Fri Jun 18 22:13:09 2021
From: forax at univ-mlv.fr (Remi Forax)
Date: Sat, 19 Jun 2021 00:13:09 +0200 (CEST)
Subject: javac allows to catch a checked exception if hidden inside an
 intersection type
In-Reply-To: <1753700900.1260524.1624053695654.JavaMail.zimbra@u-pem.fr>
References: <1753700900.1260524.1624053695654.JavaMail.zimbra@u-pem.fr>
Message-ID: <1421719015.1262097.1624054389009.JavaMail.zimbra@u-pem.fr>

false alarm :(
correction,
i'm now not able to reproduce "oops 1" with javac anymore.

so it's just a bug (oops 2) in IntelliJ.

public static void execute(Runnable runnable) throws IOException {
   try {
     runnable.run();
     throw new IOException();
   } catch(RuntimeException | IOException e) {
     var cause = e instanceof UncheckedIOException unchecked ? unchecked.getCause():
     throw cause;  // oops 2
   }
}

R?mi

----- Mail original -----
> De: "Remi Forax" 
> ?: "compiler-dev" 
> Envoy?: Samedi 19 Juin 2021 00:01:35
> Objet: javac allows to catch a checked exception if hidden inside an intersection type

> Hi all,
> this code has two bugs.
> 
>  public static void execute(Runnable runnable) throws IOException {
>    try {
>      runnable.run();
>    } catch(RuntimeException | IOException e) {   // oops 1
>      var cause = e instanceof UncheckedIOException unchecked ? unchecked.getCause():
>      e;
>      throw cause;  // oops 2
>    }
>  }
> 
> The catch (oops 1) should be rejected because the try block doesn't throw
> IOException, but javac accepts it.
> 
> Intellij does not see any bugs, like javac it does not see "oops 1". It also
> types "cause" as a RuntimeException | IOException instead of Exception,
> the common super type because ?: does not support precise exceptions like a
> catch/throw does so it should compute the lowest upper bound).
> 
> Eclipse correctly reports the two issues.
> 
> regards,
> R?mi

From gli at openjdk.java.net  Sat Jun 19 09:19:56 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Sat, 19 Jun 2021 09:19:56 GMT
Subject: RFR: 8263926: JavacFileManager.hasExplicitLocation fails with NPE
 while compiling [v4]
In-Reply-To: <5lGnGva_JNpEQKrBYfoDWHS7i05vv4Hiovw824Xm8EI=.60465cbf-59a9-4c05-9693-592fadb5c297@github.com>
References: <5lGnGva_JNpEQKrBYfoDWHS7i05vv4Hiovw824Xm8EI=.60465cbf-59a9-4c05-9693-592fadb5c297@github.com>
Message-ID: 

> Hi all,
> 
> The compiler fails with NullPointerException while building the maven project provided by the user in [JDK-8263926](https://bugs.openjdk.java.net/browse/JDK-8263926).
> 
> Actually, the patch is simple. We only need to add a `null` check before using the `msym.sourceLocation`.
> 
> 
> -            if (fileManager.contains(msym.sourceLocation, fo)) 
> +            if (msym.sourceLocation != null && fileManager.contains(msym.sourceLocation, fo)) 
> 
> 
> But we can't verify whether the problem is solved because the code provided by the user is complex so that we have no way to wtite a regression test.
> 
> Recently, I deeply researched the relationship of the source code provided by the user 
> and construct a minimal test case to verify the patch. 
> The minimal test was attached to the JBS just now.
> The attached test reproduces the bug by using the shell script instead of maven.
> And the test case `SourceLocationNotExist.java` at this patch is another way to reproduce the bug. 
> The steps in `SourceLocationNotExist.java` is the same as the shell script mentioned above.
> 
> Given that the bug is hard to be reproduced, I give some comments here.
> 
> 1. We need to construct a jar file which has both `*.java` files and `*.class` files and has no named module.
>     First, I compile the file `test/TestUnnamedModule.java` into `test/TestUnnamedModule.class`.
>     Then  I use the `jar` tool to construct the jar file `test.jar`, which contains both `test/TestUnnamedModule.java` and `test/TestUnnamedModule.class`.
>     Commands are like: 
>     `javac test/TestUnnamedModule.java` and 
>     `jar -c -f test.jar test/TestUnnamedModule.class test/TestUnnamedModule.java`
> 
> 2. The last modified time of the `*.java` files should be newer than that of the `*.class` files. 
>     Because the compiler implicitly choose the last modified file if both source files and class files are present.
>     We need the compiler the choose the `*.java` files to reproduce the bug.
>     So before using the `jar` command, we need to update the modified time of the `*.java` files to let it newer than `*.class` files.
>     Command is like: `touch test/TestUnnamedModule.java`.
> 
> 3. We need to use the class of the `test.jar` in a named module.
>     I construct a module named `use`, which has a module file `module-info.java` and a source file `TestUse.java`.
>     You can see the `TestUse.java` has a statement `import test.TestUnnamedModule;` to use the `test.jar`.
> 
> 4. The `module-info.java` of the module `use` can't have the directive `requires test`. Because the name `test` is the automatic module name of the jar file `test.jar`.
> 
> 5. When compiling the module `use` mentioned above, we must use the option `-sourcepath` and the `test.jar` is not  the argument of the `-sourcepath` and `--module-path`.
>     Command is like: `javac -classpath test.jar -d use -sourcepath use use/module-info.java use/TestUse.java`
> 
> We can see that these five requirements are difficult to meet.
> - Generally, our jar files shouldn't have the `*.java` files and only have the `*.class` files. But some libs that the user uses have these `*.java`files unexpectedly .
> - And the class files are always compiled from the source files so that it is almost impossible that the last modified time of the `*.java` files is newer than `*.class` files.
> - Generally, if we use the module system to construct our source code, we should compile the source code by using option `--module-path` instead of `-classpath`.
> Command is like: javac **--module-path** test.jar -d use -sourcepath use use/module-info.java use/TestUse.java
> instead of: javac **-classpath** test.jar -d use -sourcepath use use/module-info.java use/TestUse.java
> However, the option `-classpath` is used by the maven at this situation (which no `requires` directive is in the `module-info.java`).
> 
> It is a combination of the java compiler(has no null check), the maven building tools(use `-classpath`), 
> the extra libraries(have `*.java` files in the jar file) and the user's moduled project codes(have no corresponding module directive).
> 
> Anyway, we actually meet it now which is provided by the user.
> Hope you are not confused by these descriptions.
> 
> Thanks for taking the time to review.
> 
> Best Regards,
> -- Guoxiong

Guoxiong Li has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:

 - Merge branch 'master' into JDK-8263926
 - Remove null check
 - Revise the method ClassFinder#scanUserPaths. Address the situation when the haveSourcePath is true and the includeSourcePath is false
 - Adjust the comments
 - 8263926: JavacFileManager.hasExplicitLocation fails with NPE while compiling

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4523/files
  - new: https://git.openjdk.java.net/jdk/pull/4523/files/fd4be911..a4eca801

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4523&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4523&range=02-03

  Stats: 15260 lines in 209 files changed: 8794 ins; 5935 del; 531 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4523.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4523/head:pull/4523

PR: https://git.openjdk.java.net/jdk/pull/4523

From gli at openjdk.java.net  Sat Jun 19 09:19:57 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Sat, 19 Jun 2021 09:19:57 GMT
Subject: RFR: 8263926: JavacFileManager.hasExplicitLocation fails with NPE
 while compiling [v2]
In-Reply-To: <6ktugZwAsJmG8RpAatIdKo84YoiPcFceuyA6MoISYVs=.6430fa1a-d48e-4398-809d-5e086ed77189@github.com>
References: <5lGnGva_JNpEQKrBYfoDWHS7i05vv4Hiovw824Xm8EI=.60465cbf-59a9-4c05-9693-592fadb5c297@github.com>
 
 
 
 
 <6ktugZwAsJmG8RpAatIdKo84YoiPcFceuyA6MoISYVs=.6430fa1a-d48e-4398-809d-5e086ed77189@github.com>
Message-ID: 

On Fri, 18 Jun 2021 21:05:24 GMT, Jonathan Gibbons  wrote:

>> And about the null check, I want to keep it so that the compiler won't crash when meeting the situation like this bug.
>
>> And about the null check, I want to keep it so that the compiler won't crash when meeting the situation like this bug.
> 
> If we believe that the null should not occur, it would be covering up a bug to provide the null check.

Got it. I can't find a situation now that the null occurs. So I removed the null check just now.

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

PR: https://git.openjdk.java.net/jdk/pull/4523

From michael.mirwaldt at gmx.de  Sun Jun 20 21:48:50 2021
From: michael.mirwaldt at gmx.de (Michael Mirwaldt)
Date: Sun, 20 Jun 2021 23:48:50 +0200
Subject: Type inference bug with method references in OpenJDK 16+ discovered
Message-ID: 

Hi,
I wanted to report a bug in the type inference with references in
OpenJDK 16 and 17-ea.
I have created a sample project on
https://github.com/mmirwaldt/TypeInferenceBugOfMethodReferences/

to reproduce the bug. Just run Main and notice the exception.
However, a friend told me that the bug only occurs with compiling
directly by javac but not by maven compile.
We don't know why. Moreover, it seems to be dependent on the operating
system:
I haven't been able to reproduce the bug on linux (CentOS 7, OpenJDK
16.0.1) yet. Windows 10 and Mac show that bug, though.
Can you please have a look on it, try it out and help me creating a bug
ticket if you can confirm it's a bug?
I mean it must be a bug if the type inference somehow infers the wrong
type of a method reference which leads to an exception at runtime,
doesn't it?
Type inference should either infer the right type or cause a compiler
error if it cannot infer the type or isn't sure about it in order to ask
the developer for an explicit declaration. Is that right?
I am sorry I cannot help you finding the bug in the code of the compiler
which infers types. I would if I could.
All the best,
Michael Mirwaldt


From jfranck at openjdk.java.net  Mon Jun 21 08:43:32 2021
From: jfranck at openjdk.java.net (Joel =?UTF-8?B?Qm9yZ2dyw6luLUZyYW5jaw==?=)
Date: Mon, 21 Jun 2021 08:43:32 GMT
Subject: Integrated: 8266082: AssertionError in Annotate.fromAnnotations with
 -Xdoclint
In-Reply-To: 
References: 
Message-ID: 

On Mon, 14 Jun 2021 13:35:35 GMT, Joel Borggr?n-Franck  wrote:

> Javac crashes in Annotate when a javadoc reference contains an annotated type, since attribType expects type annotations to have been attributed.
> 
> This proposed fix checks references at parse time to disallow annotated types instead of crashing later on.
> 
> Since the exact type of error is known I opted for a new error message to make it easier for the developer to see what is wrong.
> 
> Since this affects javac at least as far back as jdk 11 and we are past RDP1 I targeted this for 18.

This pull request has now been integrated.

Changeset: 0b8a0e2b
Author:    Joel Borggr?n-Franck 
URL:       https://git.openjdk.java.net/jdk/commit/0b8a0e2b58dbdd5c9553e502212d32c033a5efb5
Stats:     96 lines in 5 files changed: 95 ins; 0 del; 1 mod

8266082: AssertionError in Annotate.fromAnnotations with -Xdoclint

Reviewed-by: vromero

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

PR: https://git.openjdk.java.net/jdk/pull/4483

From cushon at google.com  Mon Jun 21 21:28:00 2021
From: cushon at google.com (Liam Miller-Cushon)
Date: Mon, 21 Jun 2021 14:28:00 -0700
Subject: JDK-8254073, unicode escape preprocessing, and \u005C
Message-ID: 

class T {
  public static void main(String[] args) {
    System.err.println("\u005C\\u005D");
  }
}

Before JDK-8254073, this prints `\]`.

After JDK-8254073, unicode escape processing results in `\\\u005D`, which
results in an 'invalid escape' error for `\u`. Was that deliberate?

JLS 3.3 says

> for each raw input character that is a backslash \, input processing must
consider how many other \ characters contiguously precede it, separating it
from a non-\ character or the start of the input stream. If this number is
even, then the \ is eligible to begin a Unicode escape; if the number is
odd, then the \ is not eligible to begin a Unicode escape.

The difference is in whether `\u005C` (the unicode escape for `\`) counts
as one of the `\` preceding a valid unicode escape.

Does "how many other \ characters contiguously precede it" refer to
preceding raw input characters, or does it refer to preceding characters
after unicode escape processing is performed on them?

JLS 3.3 also mentions that a "character produced by a Unicode escape does
not participate in further Unicode escapes", but I'm not sure if that
applies here, since in the pre-JDK-8254073 interpretation the
unicode-escaped backslash isn't really 'participating' in the second
unicode escape.

Thanks,
Liam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From james.laskey at oracle.com  Mon Jun 21 21:56:11 2021
From: james.laskey at oracle.com (Jim Laskey)
Date: Mon, 21 Jun 2021 21:56:11 +0000
Subject: JDK-8254073, unicode escape preprocessing, and \u005C
In-Reply-To: 
References: 
Message-ID: <86DC9BD0-1DDB-40D8-A46D-43A9C72EBFA9@oracle.com>

"\u005C? should have been treated as a backslash. Will check into it. 

Cheers,

? Jim

??

> On Jun 21, 2021, at 6:28 PM, Liam Miller-Cushon  wrote:
> 
> ?
> class T {
>   public static void main(String[] args) {
>     System.err.println("\u005C\\u005D");
>   }
> }
> 
> Before JDK-8254073, this prints `\]`.
> 
> After JDK-8254073, unicode escape processing results in `\\\u005D`, which results in an 'invalid escape' error for `\u`. Was that deliberate?
> 
> JLS 3.3 says
> 
> > for each raw input character that is a backslash \, input processing must consider how many other \ characters contiguously precede it, separating it from a non-\ character or the start of the input stream. If this number is even, then the \ is eligible to begin a Unicode escape; if the number is odd, then the \ is not eligible to begin a Unicode escape.
> 
> The difference is in whether `\u005C` (the unicode escape for `\`) counts as one of the `\` preceding a valid unicode escape.
> 
> Does "how many other \ characters contiguously precede it" refer to preceding raw input characters, or does it refer to preceding characters after unicode escape processing is performed on them?
> 
> JLS 3.3 also mentions that a "character produced by a Unicode escape does not participate in further Unicode escapes", but I'm not sure if that applies here, since in the pre-JDK-8254073 interpretation the unicode-escaped backslash isn't really 'participating' in the second unicode escape.
> 
> Thanks,
> Liam

From alex.buckley at oracle.com  Mon Jun 21 23:41:41 2021
From: alex.buckley at oracle.com (Alex Buckley)
Date: Mon, 21 Jun 2021 16:41:41 -0700
Subject: JDK-8254073, unicode escape preprocessing, and \u005C
In-Reply-To: <86DC9BD0-1DDB-40D8-A46D-43A9C72EBFA9@oracle.com>
References: 
 <86DC9BD0-1DDB-40D8-A46D-43A9C72EBFA9@oracle.com>
Message-ID: <86520066-93a7-d24e-c86e-e9dda6b9bc9b@oracle.com>

There's no question that the first six raw input characters \ u 0 0 5 c 
are identified as a Unicode escape \u005c and translated to a backslash.

The question is whether that backslash is then treated as:

1. a raw input character \ that is followed by seven more raw input 
characters \ \ u 0 0 5 d   For these *eight* raw input characters, there 
are three raw input character \'s in a row. Due to contiguous-\ 
counting, the third raw input character \ is eligible to begin a Unicode 
escape; the first and second pass through and you get \ \ ] which 
further translates within a string literal as \]

or

2. something which is independent of the subsequent seven raw input 
characters \ \ u 0 0 5 d   For those *seven* subsequent raw input 
characters, there are two raw input character \'s in a row. Due to 
contiguous-\ counting, the second raw input character \ is not eligible 
to begin a Unicode escape, so all seven raw input characters pass 
through. You get (including the first "independent" backslash) \ \ \ u 0 
0 5 d


The contiguous-\ counting is due to the fact that \\ is the escape 
sequence for backslash in a string literal, so we don't want too many 
raw \ input character to "disappear" into Unicode escapes.


The JDK 15 behavior was #1. That looks correct to me. \ u 0 0 5 c 
becomes a raw input character \ that cannot serve as the opening 
backslash for an *immediate* Unicode escape (the classic JLS 3.3 
scenario of \u005cu005a) but that can serve as a raw input character for 
the purpose of skipping over \\ pairs (the purpose of contiguous-\ 
counting) in order for a *later* Unicode escape to be recognized (\u005d).

> Does "how many other \ characters contiguously precede it" refer to
> preceding raw input characters, or does it refer to preceding
> characters after unicode escape processing is performed on them?

Where JLS 3.3 says "translating the ASCII characters \u followed by four 
hexadecimal digits to the UTF-16 code unit (?3.1) for the indicated 
hexadecimal value", it really means "translating the ASCII characters \u 
followed by four hexadecimal digits to *a raw input character which 
denotes* the UTF-16 code unit (?3.1) for the indicated hexadecimal value".

Thus, the later clause "for each raw input character that is a backslash 
\, input processing must consider how many other [raw input] \ 
characters contiguously precede it" can be seen more easily to include 
characters that result from Unicode escape processing.

Alex

On 6/21/2021 2:56 PM, Jim Laskey wrote:
> "\u005C? should have been treated as a backslash. Will check into it.
> 
> Cheers,
> 
> ? Jim
> 
> ??
> 
>> On Jun 21, 2021, at 6:28 PM, Liam Miller-Cushon  wrote:
>>
>> ?
>> class T {
>>    public static void main(String[] args) {
>>      System.err.println("\u005C\\u005D");
>>    }
>> }
>>
>> Before JDK-8254073, this prints `\]`.
>>
>> After JDK-8254073, unicode escape processing results in `\\\u005D`, which results in an 'invalid escape' error for `\u`. Was that deliberate?
>>
>> JLS 3.3 says
>>
>>> for each raw input character that is a backslash \, input processing must consider how many other \ characters contiguously precede it, separating it from a non-\ character or the start of the input stream. If this number is even, then the \ is eligible to begin a Unicode escape; if the number is odd, then the \ is not eligible to begin a Unicode escape.
>>
>> The difference is in whether `\u005C` (the unicode escape for `\`) counts as one of the `\` preceding a valid unicode escape.
>>
>> Does "how many other \ characters contiguously precede it" refer to preceding raw input characters, or does it refer to preceding characters after unicode escape processing is performed on them?
>>
>> JLS 3.3 also mentions that a "character produced by a Unicode escape does not participate in further Unicode escapes", but I'm not sure if that applies here, since in the pre-JDK-8254073 interpretation the unicode-escaped backslash isn't really 'participating' in the second unicode escape.
>>
>> Thanks,
>> Liam

From jlahoda at openjdk.java.net  Tue Jun 22 07:37:38 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 22 Jun 2021 07:37:38 GMT
Subject: [jdk17] Integrated: 8266631: StandardJavaFileManager:
 getJavaFileObjects() impl violates the spec
In-Reply-To: 
References: 
Message-ID: 

On Tue, 15 Jun 2021 14:26:46 GMT, Jan Lahoda  wrote:

> [a copy of https://github.com/openjdk/jdk/pull/4360 for openjdk/jdk17]
> 
> This improves javadoc/specification of several StandardJavaFileManager methods, as requested in these bugs:
> https://bugs.openjdk.java.net/browse/JDK-8266631
> https://bugs.openjdk.java.net/browse/JDK-8266596
> https://bugs.openjdk.java.net/browse/JDK-8266591
> https://bugs.openjdk.java.net/browse/JDK-8266590
> 
> The CSR is here:
> https://bugs.openjdk.java.net/browse/JDK-8268260

This pull request has now been integrated.

Changeset: 01f12fba
Author:    Jan Lahoda 
URL:       https://git.openjdk.java.net/jdk17/commit/01f12fba648b8c0cb64870b00e6f0f3a7f0ba4c9
Stats:     21 lines in 1 file changed: 6 ins; 0 del; 15 mod

8266631: StandardJavaFileManager: getJavaFileObjects() impl violates the spec
8266596: StandardJavaFileManager: default impls of setLocationFromPaths(), getJavaFileObjectsFromPaths() methods don't throw IllegalArgumentException as specified
8266591: StandardJavaFileManager::getJavaFileObjectsFromPaths() methods contain a typo in their spec
8266590: StandardJavaFileManager::setLocationFromPaths() spec contains an error

Reviewed-by: vromero, jjg

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

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

From ilyas.selimov at jetbrains.com  Tue Jun 22 08:37:36 2021
From: ilyas.selimov at jetbrains.com (Ilyas Selimov)
Date: Tue, 22 Jun 2021 15:37:36 +0700
Subject: Switch statement containing pattern case label element gets in the
 loop during execution
Message-ID: 

Hello!

I tried to execute the code using OpenJDK 17 (build 17-ea+27-2476):

    public static void main(String[] args) {
        test(1);
    }

    static void test(Integer i) {
        switch (i) {
            case Integer o && o != null:
                System.out.println("s1");
            default:
                System.out.println("def");
        }
    }

and got the next output:
s1
def
s1
def
...

As a result the switch statement gets in the loop.
Looking at the bytecode of the method It seems the issue is related to the
latest goto instruction:

 static void test(java.lang.Integer);
    Code:
       0: aload_0
       1: dup
       2: invokestatic  #19                 // Method
java/util/Objects.requireNonNull:
       5: pop
       6: astore_1
       7: iconst_0
       8: istore_2
       9: aload_1
      10: iload_2
      11: invokedynamic #25,  0             // InvokeDynamic
#0:typeSwitch:(Ljava/lang/Object;I)I
      16: lookupswitch  { // 1
                     0: 36
               default: 55
          }
      36: aload_1
      37: astore_3
      38: aload_3
      39: ifnonnull     47
      42: iconst_1
      43: istore_2
      44: goto          9
      47: getstatic     #29                 // Field
java/lang/System.out:Ljava/io/PrintStream;
      50: ldc           #35                 // String s1
      52: invokevirtual #37                 // Method
java/io/PrintStream.println:(Ljava/lang/String;)V
      55: getstatic     #29                 // Field
java/lang/System.out:Ljava/io/PrintStream;
      58: ldc           #43                 // String def
      60: invokevirtual #37                 // Method
java/io/PrintStream.println:(Ljava/lang/String;)V
      63: goto          9

Could somebody take a look?

Thanks,
Ilyas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From forax at univ-mlv.fr  Tue Jun 22 09:10:50 2021
From: forax at univ-mlv.fr (Remi Forax)
Date: Tue, 22 Jun 2021 11:10:50 +0200 (CEST)
Subject: Switch statement containing pattern case label element gets in
 the loop during execution
In-Reply-To: 
References: 
Message-ID: <1498503876.796691.1624353050034.JavaMail.zimbra@u-pem.fr>

> De: "Ilyas Selimov" 
> ?: "compiler-dev" 
> Envoy?: Mardi 22 Juin 2021 10:37:36
> Objet: Switch statement containing pattern case label element gets in the loop
> during execution

> Hello!
> I tried to execute the code using OpenJDK 17 (build 17-ea+27-2476):

> public static void main(String[] args) {
> test(1);
> }

> static void test(Integer i) {
> switch (i) {
> case Integer o && o != null:
> System.out.println("s1");
> default:
> System.out.println("def");
> }
> }

> and got the next output:
> s1
> def
> s1
> def
> ...

> As a result the switch statement gets in the loop.
> Looking at the bytecode of the method It seems the issue is related to the
> latest goto instruction:

> static void test(java.lang.Integer);
> Code:
> 0: aload_0
> 1: dup
> 2: invokestatic #19 // Method java/util/Objects.requireNonNull:
> 5: pop
> 6: astore_1
> 7: iconst_0
> 8: istore_2
> 9: aload_1
> 10: iload_2
> 11: invokedynamic #25, 0 // InvokeDynamic #0:typeSwitch:(Ljava/lang/Object;I)I
> 16: lookupswitch { // 1
> 0: 36
> default: 55
> }
> 36: aload_1
> 37: astore_3
> 38: aload_3
> 39: ifnonnull 47
> 42: iconst_1
> 43: istore_2
> 44: goto 9
> 47: getstatic #29 // Field java/lang/System.out:Ljava/io/PrintStream;
> 50: ldc #35 // String s1
> 52: invokevirtual #37 // Method
> java/io/PrintStream.println:(Ljava/lang/String;)V
> 55: getstatic #29 // Field java/lang/System.out:Ljava/io/PrintStream;
> 58: ldc #43 // String def
> 60: invokevirtual #37 // Method
> java/io/PrintStream.println:(Ljava/lang/String;)V
> 63: goto 9

> Could somebody take a look?

I agree with your analysis, the last goto should not be there. 

> Thanks,
> Ilyas

R?mi 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From lgxbslgx at gmail.com  Tue Jun 22 10:04:41 2021
From: lgxbslgx at gmail.com (Guoxiong Li)
Date: Tue, 22 Jun 2021 18:04:41 +0800
Subject: Type inference bug with method references in OpenJDK 16+
 discovered
In-Reply-To: 
References: 
Message-ID: 

Hi Michael,

Thanks for reporting this bug.

I reproduced this bug on linux by using the following commands
and the error messages are similar to yours.

```
java -m jdk.compiler/com.sun.tools.javac.Main $(find src/main/java -name
"*.java")
java -classpath src/main/java net.mirwaldt.bug.Main
```

And I also reproduced it by using the maven to compile.(also on linux)

```
mvn clean compile
java -classpath target/classes/ net.mirwaldt.bug.Main
```

It seems that you misuse some commands.

Anyway, it is a reproduced bug.
Filed https://bugs.openjdk.java.net/browse/JDK-8269121 in the JBS.

Best Regards,
-- Guoxiong


On Mon, Jun 21, 2021 at 5:49 AM Michael Mirwaldt 
wrote:

> Hi,
> I wanted to report a bug in the type inference with references in
> OpenJDK 16 and 17-ea.
> I have created a sample project on
> https://github.com/mmirwaldt/TypeInferenceBugOfMethodReferences/
> 
> to reproduce the bug. Just run Main and notice the exception.
> However, a friend told me that the bug only occurs with compiling
> directly by javac but not by maven compile.
> We don't know why. Moreover, it seems to be dependent on the operating
> system:
> I haven't been able to reproduce the bug on linux (CentOS 7, OpenJDK
> 16.0.1) yet. Windows 10 and Mac show that bug, though.
> Can you please have a look on it, try it out and help me creating a bug
> ticket if you can confirm it's a bug?
> I mean it must be a bug if the type inference somehow infers the wrong
> type of a method reference which leads to an exception at runtime,
> doesn't it?
> Type inference should either infer the right type or cause a compiler
> error if it cannot infer the type or isn't sure about it in order to ask
> the developer for an explicit declaration. Is that right?
> I am sorry I cannot help you finding the bug in the code of the compiler
> which infers types. I would if I could.
> All the best,
> Michael Mirwaldt
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From gli at openjdk.java.net  Tue Jun 22 10:50:26 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Tue, 22 Jun 2021 10:50:26 GMT
Subject: [jdk17] RFR: 8267610: NPE at at
 jdk.compiler/com.sun.tools.javac.jvm.Code.emitop
In-Reply-To: 
References: 
Message-ID: 

On Tue, 15 Jun 2021 15:05:40 GMT, Guoxiong Li  wrote:

> Hi all,
> 
> Currently, the class TransPatterns sometimes doesn't transform the `pattern variables` and `pattern symbols` to the normal variables and symbols, especially the places where the pattern variables are used.
> The following phases, such as LambdaToMethod, Lower and Gen, may crash or generate some wrong results.
> 
> The known issues are [JDK-8267610](https://bugs.openjdk.java.net/browse/JDK-8267610) and [JDK-8268748](https://bugs.openjdk.java.net/browse/JDK-8268748).
> 
> **JDK-8267610 is an issue that pattern symbol causes the compiler to crash.**
> 
> During transforming the InstanceOfTree (JCInstanceOf) , the `BindingSymbol`  instead of the `VarSymbol` is used to make the new `JCIdent` and `JCBinary` trees. At the phase LambdaToMethod, the compiler can't capture this variable so that the lambda method has uncorrect parameters. So at the phase Gen, the compiler crashes because of NPE.
> 
> **JDK-8268748 is an issue that pattern symbol causes that the compiler generates wrong bytecodes.**
> 
> When transforming the BindingPatternTree (JCBindingPattern), the `BindingSymbol` is also handled uncorrectly and used to make the new `JCIdent` and `JCAssign` trees. At the phase Gen, the compiler find the wrong variables, so that the wrong bytecodes are generated.
> 
> These two issues are similar and influence each other. So I solve them at one patch.
> The lines 208-212 are to solve JDK-8267610 with the test `LambdaCannotCapturePatternVariables`. 
> The lines 233-239 are to solve JDK-8268748 with the test `NestedPatternVariablesBytecode`.
> 
> If lines 208-212 are not included, the test  `NestedPatternVariablesBytecode` can't pass. 
> If lines 233-239 are not included, the test `LambdaCannotCapturePatternVariables` can't pass. 
> So I put them together.
> 
> Thanks for taking the time to review.
> 
> Best Regards,
> -- Guoxiong.

Ping for review.

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

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

From ilyas.selimov at jetbrains.com  Tue Jun 22 11:38:21 2021
From: ilyas.selimov at jetbrains.com (Ilyas Selimov)
Date: Tue, 22 Jun 2021 18:38:21 +0700
Subject: Pattern matching for switch: Spec and Javac inconsistency
Message-ID: 

Hello!

I found several differences between some rules in the spec draft (
http://cr.openjdk.java.net/~gbierman/jep406/jep406-20210527/specs/patterns-switch-jls.html#jls-14.11.1
)
and its javac implementation (OpenJDK 17 build 17-ea+27-2476).
Maybe ones are intentional or I missed something during the past
discussions.

1)
Spec:
If a switch label has a constant case label element then if the switch
label also has other case element labels they must be either a constant
case label element, the default case label element, or the null case label
element.

The next code is compiled fine despite the existence of both constant and
pattern case label elements:
void testInt(Integer i) {
  switch (i) {
    case Integer o && o != null, 1:
      System.out.println("s1");
    default:
      System.out.println("def");
  }
}

while the similar code isn't compiled:

enum Day { MONDAY, TUESDAY, WEDNESDAY }
void testEnum(Day d) {
  switch (d) {
    case Day day && day != null, TUESDAY: // illegal fall-through to a
pattern
      System.out.println("day");
    default:
      System.out.println("def");
  }
}

2)
Spec:
If a switch label has a null case label element then if the switch label
also has any pattern case element labels, they must be type patterns
(14.30.1).

Does "must be be type patterns" mean here that I can't declare guarded
patterns together with
'null' label element like in the code below:
void testInt(Integer i) {
  switch (i) {
    case null, Integer o && o != null:
      System.out.println("s1");
    default:
      System.out.println("def");
  }
}

3)
Spec:
A switch label that has a pattern case label element p that is total for
the type of the selector expression of the enclosing switch statement or
switch expression dominates a switch label that has a 'null' label element.

Here are two similar code samples:
void testInt1(Integer i) {
  switch (i) {
    case Object o, null:
      System.out.println("s1");
  }
}

void testInt2(Integer i) {
  switch (i) {
    case Object o:
      System.out.println("s1");
    case null: // this case label is dominated by a preceding case label
      System.out.println("null");
  }
}

The first one compiles fine, while the second one is not.
The spec says only about dominance between label elements within separate
switch labels. Anyway, what is the main reason that allows the first sample
to be compiled?
'Object o' is a total for the type of the selector expression and it
dominates 'null',
so the 'null' label element looks redundant.

Thanks,
Ilyas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jlahoda at openjdk.java.net  Tue Jun 22 13:10:13 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 22 Jun 2021 13:10:13 GMT
Subject: [jdk17] RFR: 8268961: Parenthesized pattern with guards does not work
Message-ID: 

This PR fixes a couple of problems related to parenthesized patterns:
a) as noted in https://bugs.openjdk.java.net/browse/JDK-8268961, javac does not accept guards after parenthesized patterns (e.g. `(String s) && s.isEmpty()`, although it should.
b) related to that, the disambiguation determining whether a case label is a pattern or an expression is not working well for cases like `a >> b`, which will be interpreted as a pattern (while it may be a valid expression)
c) related to that, handling of parenthesized patterns in Attr should also be better - the raw type warning should be reported for all type patterns, even those inside a guarded pattern
d) the source level check was missing on one place for parenthesized patterns, as noted in https://bugs.openjdk.java.net/browse/JDK-8268896

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

Commit messages:
 - Improving handling of parenthesized and guarded pattern types.
 - 8268961: Parenthesized pattern with guards does not work
 - 8268896: Parenthesized pattern is not guarded by source level check

Changes: https://git.openjdk.java.net/jdk17/pull/116/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=116&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8268961
  Stats: 274 lines in 8 files changed: 244 ins; 19 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/116.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/116/head:pull/116

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

From michael.mirwaldt at gmx.de  Tue Jun 22 14:34:21 2021
From: michael.mirwaldt at gmx.de (Michael Mirwaldt)
Date: Tue, 22 Jun 2021 16:34:21 +0200
Subject: Type inference bug with method references in OpenJDK 16+
 discovered
In-Reply-To: 
References: 
 
Message-ID: 

Hi Guoxiong,
thanks for trying out my example project, reproducing the bug even under
linux and creating a bug ticket for that.
I hope, my example project helps you to find out what goes wrong with
type inference here and fix that bug.
Best regards,
Michael Mirwaldt

Am 22.06.2021 um 12:04 schrieb Guoxiong Li:
> Hi?Michael,
>
> Thanks for reporting this bug.
>
> I reproduced this bug on linux by using the following commands
> and the error messages are similar to yours.
>
> ```
> java -m jdk.compiler/com.sun.tools.javac.Main $(find src/main/java
> -name "*.java")
> java -classpath src/main/java net.mirwaldt.bug.Main
> ```
>
> And I also reproduced it by using the maven to compile.(also on linux)
>
> ```
> mvn clean compile
> java -classpath target/classes/ net.mirwaldt.bug.Main
> ```
>
> It seems that you misuse some commands.
>
> Anyway, it is a reproduced bug.
> Filed https://bugs.openjdk.java.net/browse/JDK-8269121
>  in the JBS.
>
> Best Regards,
> -- Guoxiong
>
>
> On Mon, Jun 21, 2021 at 5:49 AM Michael Mirwaldt
> > wrote:
>
>     Hi,
>     I wanted to report a bug in the type inference with references in
>     OpenJDK 16 and 17-ea.
>     I have created a sample project on
>     https://github.com/mmirwaldt/TypeInferenceBugOfMethodReferences/
>     
>          >
>     to reproduce the bug. Just run Main and notice the exception.
>     However, a friend told me that the bug only occurs with compiling
>     directly by javac but not by maven compile.
>     We don't know why. Moreover, it seems to be dependent on the operating
>     system:
>     I haven't been able to reproduce the bug on linux (CentOS 7, OpenJDK
>     16.0.1) yet. Windows 10 and Mac show that bug, though.
>     Can you please have a look on it, try it out and help me creating
>     a bug
>     ticket if you can confirm it's a bug?
>     I mean it must be a bug if the type inference somehow infers the wrong
>     type of a method reference which leads to an exception at runtime,
>     doesn't it?
>     Type inference should either infer the right type or cause a compiler
>     error if it cannot infer the type or isn't sure about it in order
>     to ask
>     the developer for an explicit declaration. Is that right?
>     I am sorry I cannot help you finding the bug in the code of the
>     compiler
>     which infers types. I would if I could.
>     All the best,
>     Michael Mirwaldt
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From vromero at openjdk.java.net  Tue Jun 22 15:24:31 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Tue, 22 Jun 2021 15:24:31 GMT
Subject: [jdk17] RFR: 8254571: Erroneous generic type inference in a
 lambda expression with a checked exception
In-Reply-To: 
References: 
Message-ID: 

On Thu, 17 Jun 2021 16:33:11 GMT, Vicente Romero  wrote:

> Hi,
> 
> The compiler is issuing an error for code like:
> 
> 
> class JDK8254571 {
>     public static void test() {
>         outer(nested(x -> mightThrow()));
>     }
>     
>     static  void outer(Object o) {}
> 
>     static  B nested(Fun fun) {
>         return null;
>     }
> 
>     interface Fun {
>         void m(X t) throws Y;
>     }
> 
>     static void mightThrow() throws Exception {}
> } 
> 
> 
> there are several things at play here:
> 
> 1) for performance reasons we decided to minimize the number of inference variables popped up when inferring nested generic method invocations, see Infer::roots
> 2) when an expression is stuck (like in this case this implicit lambda) we decide which inference variables should be present in the related inference context and thrown variables were not part of the equation
> 
> So there are three hypothesis here:
> 1) there is a bug in the code that determines which variables are passed up to the nested inference context, meaning that it is passing less variables than the bare minimum needed
> 2) there is a bug in determining which inference variables should be extracted from stuck expressions
> 3) both are buggy
> 
> The root cause of this bug is that some types escape from Attr with non instantiated type variables in them. I modified the test case to double check if the issue was not related to lambdas, but then the test passed so in the example above I added:
> 
> 
>      static  Fun mightThrow2() throws Y { return null; }
> 
> 
> which simulates the lambda and the compiler has no issues compiling this invocation:
> 
> 
>     outer(nested(mightThrow2()));
> 
> 
> so summing up, after double checking the logic of the code that minimized the inference context I realized that the issue is not there. The code is sound and its output only depend on its input, so the issue should be on determining the input. So IMO the issue is in what inference variables we extract from stuck expressions, which is one of the inputs to Infer::roots. Looking for what variables we extract from stuck expressions, I realized that the code currently ignores type variables in the throws clause and this is why my proposed fix is addressing this issue.
> 
> Comments?

ping

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

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

From alex.buckley at oracle.com  Tue Jun 22 17:38:08 2021
From: alex.buckley at oracle.com (Alex Buckley)
Date: Tue, 22 Jun 2021 10:38:08 -0700
Subject: JDK-8254073, unicode escape preprocessing, and \u005C
In-Reply-To: <86520066-93a7-d24e-c86e-e9dda6b9bc9b@oracle.com>
References: 
 <86DC9BD0-1DDB-40D8-A46D-43A9C72EBFA9@oracle.com>
 <86520066-93a7-d24e-c86e-e9dda6b9bc9b@oracle.com>
Message-ID: <2feaea08-2217-a094-93ef-fc519cab793e@oracle.com>

I am minded to extend the final note in JLS 3.3 to help people 
understand the multi-level escape story in play when they experiment 
with Unicode escapes. Perhaps it will also improve some javac error 
messages or test cases. Let me know what you think of this:

-----
For example, the input stream \u005cu005a results in the six characters 
\ u 0 0 5 a, because 005c is the Unicode value for \. It does not result 
in the character Z, which is Unicode character 005a, because the \ that 
resulted from the \u005c is not interpreted as the start of a further 
Unicode escape.

Note that \u005cu005a cannot be written in a string literal to denote 
the six characters \ u 0 0 5 a. This is because the first two characters 
resulting from translation, \ and u, are interpreted in a string literal 
as an illegal escape sequence (3.10.7).

Fortunately, the rule about contiguous \ characters helps programmers to 
craft input streams that denote Unicode escapes in a string literal. 
Denoting the six characters \ u 0 0 5 a in a string literal simply 
requires another \ to be written adjacent to the existing \, such as in 
"Z is \\u005a". This works because the second \ in the input stream 
\\u005a is not eligible, so the first \ and second \ are preserved as 
raw input characters; they are subsequently interpreted in a string 
literal as the escape sequence for a backslash, resulting in the desired 
six characters \ u 0 0 5 a. Without the rule, the input stream \\u005a 
would be translated as the raw input character \ followed by the Unicode 
escape \u005a (Z), but \Z is an illegal escape sequence in a string literal.

The rule also allows programmers to craft input streams that denote 
escape sequences in a string literal. For example, the input stream 
\\\u006e results in the three characters \ \ n because the third \ is 
eligible and thus \u006e is translated to n, while the first \ and 
second \ are preserved as raw input characters. The three characters \ \ 
n are subsequently interpreted in a string literal as \ n which denotes 
the escape sequence for a linefeed. (The input stream \\\u006e may also 
be written as \u005c\u005c\u006e.)
-----

Alex

On 6/21/2021 4:41 PM, Alex Buckley wrote:
> There's no question that the first six raw input characters \ u 0 0 5 c 
> are identified as a Unicode escape \u005c and translated to a backslash.
> 
> The question is whether that backslash is then treated as:
> 
> 1. a raw input character \ that is followed by seven more raw input 
> characters \ \ u 0 0 5 d?? For these *eight* raw input characters, there 
> are three raw input character \'s in a row. Due to contiguous-\ 
> counting, the third raw input character \ is eligible to begin a Unicode 
> escape; the first and second pass through and you get \ \ ] which 
> further translates within a string literal as \]
> 
> or
> 
> 2. something which is independent of the subsequent seven raw input 
> characters \ \ u 0 0 5 d?? For those *seven* subsequent raw input 
> characters, there are two raw input character \'s in a row. Due to 
> contiguous-\ counting, the second raw input character \ is not eligible 
> to begin a Unicode escape, so all seven raw input characters pass 
> through. You get (including the first "independent" backslash) \ \ \ u 0 
> 0 5 d
> 
> 
> The contiguous-\ counting is due to the fact that \\ is the escape 
> sequence for backslash in a string literal, so we don't want too many 
> raw \ input character to "disappear" into Unicode escapes.
> 
> 
> The JDK 15 behavior was #1. That looks correct to me. \ u 0 0 5 c 
> becomes a raw input character \ that cannot serve as the opening 
> backslash for an *immediate* Unicode escape (the classic JLS 3.3 
> scenario of \u005cu005a) but that can serve as a raw input character for 
> the purpose of skipping over \\ pairs (the purpose of contiguous-\ 
> counting) in order for a *later* Unicode escape to be recognized (\u005d).
> 
>> Does "how many other \ characters contiguously precede it" refer to
>> preceding raw input characters, or does it refer to preceding
>> characters after unicode escape processing is performed on them?
> 
> Where JLS 3.3 says "translating the ASCII characters \u followed by four 
> hexadecimal digits to the UTF-16 code unit (?3.1) for the indicated 
> hexadecimal value", it really means "translating the ASCII characters \u 
> followed by four hexadecimal digits to *a raw input character which 
> denotes* the UTF-16 code unit (?3.1) for the indicated hexadecimal value".
> 
> Thus, the later clause "for each raw input character that is a backslash 
> \, input processing must consider how many other [raw input] \ 
> characters contiguously precede it" can be seen more easily to include 
> characters that result from Unicode escape processing.
> 
> Alex
> 
> On 6/21/2021 2:56 PM, Jim Laskey wrote:
>> "\u005C? should have been treated as a backslash. Will check into it.
>>
>> Cheers,
>>
>> ? Jim
>>
>> ??
>>
>>> On Jun 21, 2021, at 6:28 PM, Liam Miller-Cushon  
>>> wrote:
>>>
>>> ?
>>> class T {
>>> ?? public static void main(String[] args) {
>>> ???? System.err.println("\u005C\\u005D");
>>> ?? }
>>> }
>>>
>>> Before JDK-8254073, this prints `\]`.
>>>
>>> After JDK-8254073, unicode escape processing results in `\\\u005D`, 
>>> which results in an 'invalid escape' error for `\u`. Was that 
>>> deliberate?
>>>
>>> JLS 3.3 says
>>>
>>>> for each raw input character that is a backslash \, input processing 
>>>> must consider how many other \ characters contiguously precede it, 
>>>> separating it from a non-\ character or the start of the input 
>>>> stream. If this number is even, then the \ is eligible to begin a 
>>>> Unicode escape; if the number is odd, then the \ is not eligible to 
>>>> begin a Unicode escape.
>>>
>>> The difference is in whether `\u005C` (the unicode escape for `\`) 
>>> counts as one of the `\` preceding a valid unicode escape.
>>>
>>> Does "how many other \ characters contiguously precede it" refer to 
>>> preceding raw input characters, or does it refer to preceding 
>>> characters after unicode escape processing is performed on them?
>>>
>>> JLS 3.3 also mentions that a "character produced by a Unicode escape 
>>> does not participate in further Unicode escapes", but I'm not sure if 
>>> that applies here, since in the pre-JDK-8254073 interpretation the 
>>> unicode-escaped backslash isn't really 'participating' in the second 
>>> unicode escape.
>>>
>>> Thanks,
>>> Liam

From james.laskey at oracle.com  Tue Jun 22 17:48:54 2021
From: james.laskey at oracle.com (Jim Laskey)
Date: Tue, 22 Jun 2021 17:48:54 +0000
Subject: JDK-8254073, unicode escape preprocessing, and \u005C
In-Reply-To: 
References: 
Message-ID:

diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/UnicodeReader.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/UnicodeReader.java
index c51be0fdf07..9603fa0da7b 100644
--- a/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/UnicodeReader.java
+++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/UnicodeReader.java
@@ -169,7 +169,7 @@ public class UnicodeReader {
             // May be an unicode escape.
             switch (unicodeEscape()) {
                 case BACKSLASH -> wasBackslash = true;
-                case VALID_ESCAPE -> wasBackslash = false;
+                case VALID_ESCAPE -> wasBackslash = character == '\\';
                 case BROKEN_ESCAPE -> nextUnicodeInputCharacter(); //skip broken unicode escapes
             }
         }


Running tests now.

On Jun 21, 2021, at 6:28 PM, Liam Miller-Cushon > wrote:

class T {
  public static void main(String[] args) {
    System.err.println("\u005C\\u005D");
  }
}

Before JDK-8254073, this prints `\]`.

After JDK-8254073, unicode escape processing results in `\\\u005D`, which results in an 'invalid escape' error for `\u`. Was that deliberate?

JLS 3.3 says

> for each raw input character that is a backslash \, input processing must consider how many other \ characters contiguously precede it, separating it from a non-\ character or the start of the input stream. If this number is even, then the \ is eligible to begin a Unicode escape; if the number is odd, then the \ is not eligible to begin a Unicode escape.

The difference is in whether `\u005C` (the unicode escape for `\`) counts as one of the `\` preceding a valid unicode escape.

Does "how many other \ characters contiguously precede it" refer to preceding raw input characters, or does it refer to preceding characters after unicode escape processing is performed on them?

JLS 3.3 also mentions that a "character produced by a Unicode escape does not participate in further Unicode escapes", but I'm not sure if that applies here, since in the pre-JDK-8254073 interpretation the unicode-escaped backslash isn't really 'participating' in the second unicode escape.

Thanks,
Liam

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From lgxbslgx at gmail.com  Tue Jun 22 18:09:29 2021
From: lgxbslgx at gmail.com (Guoxiong Li)
Date: Wed, 23 Jun 2021 02:09:29 +0800
Subject: Type inference bug with method references in OpenJDK 16+
 discovered
In-Reply-To: 
References: 
 
 
Message-ID: 

Hi Michael,

I find that this bug depends on the order of the `StringLiteral.java` and
`Variable.java`.
When I put the `Variable.java` in front of `StringLiteral.java`, the error
is gone and the program runs well,
which is the same as your local linux environment.

A file named `files.txt` is attached in this email. Could you use the
following commands in your linux environment to verify it?

```
// move the `files.txt` to the project path. Enter(`cd`) the project path
and run the following commands.
java -m jdk.compiler/com.sun.tools.javac.Main @files.txt
java -classpath src/main/java net.mirwaldt.bug.Main
```

If you can reproduce this bug in your linux environment, it means that this
bug is not related to the OS.
And the maven may compile the source files in different order, so we get
different results locally.

You can verify my idea in your own compile way and only note the order of
the `StringLiteral.java` and `Variable.java`.

Looking forward to your feedback.

Best Regards,
-- Guoxiong
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
-------------- next part --------------
src/main/java/net/mirwaldt/bug/StringVariable.java
src/main/java/net/mirwaldt/bug/Query.java
src/main/java/net/mirwaldt/bug/Main.java
src/main/java/net/mirwaldt/bug/IntVariable.java
src/main/java/net/mirwaldt/bug/Interpreter.java
src/main/java/net/mirwaldt/bug/DummyInterpreter.java
src/main/java/net/mirwaldt/bug/TwoVariablesQuery.java
src/main/java/net/mirwaldt/bug/Literal.java
src/main/java/net/mirwaldt/bug/MyFact.java
src/main/java/net/mirwaldt/bug/OneVariableQuery.java
src/main/java/net/mirwaldt/bug/IntLiteral.java

src/main/java/net/mirwaldt/bug/StringLiteral.java
src/main/java/net/mirwaldt/bug/Variable.java

From vromero at openjdk.java.net  Tue Jun 22 18:59:27 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Tue, 22 Jun 2021 18:59:27 GMT
Subject: [jdk17] RFR: 8268961: Parenthesized pattern with guards does not
 work
In-Reply-To: 
References: 
Message-ID: 

On Tue, 22 Jun 2021 13:02:40 GMT, Jan Lahoda  wrote:

> This PR fixes a couple of problems related to parenthesized patterns:
> a) as noted in https://bugs.openjdk.java.net/browse/JDK-8268961, javac does not accept guards after parenthesized patterns (e.g. `(String s) && s.isEmpty()`, although it should.
> b) related to that, the disambiguation determining whether a case label is a pattern or an expression is not working well for cases like `a >> b`, which will be interpreted as a pattern (while it may be a valid expression)
> c) related to that, handling of parenthesized patterns in Attr should also be better - the raw type warning should be reported for all type patterns, even those inside a guarded pattern
> d) the source level check was missing on one place for parenthesized patterns, as noted in https://bugs.openjdk.java.net/browse/JDK-8268896

looks sensible

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

Marked as reviewed by vromero (Reviewer).

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

From jlahoda at openjdk.java.net  Tue Jun 22 19:41:55 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 22 Jun 2021 19:41:55 GMT
Subject: [jdk17] RFR: 8268766: Desugaring of pattern matching enum switch
 should be improved [v4]
In-Reply-To: <3xKa946t0s_eRqnj0vfgjkfurBvZqKGe1QkYk-0lNO0=.518519f5-a2cb-44ed-946c-09e517e7c5d2@github.com>
References: <3xKa946t0s_eRqnj0vfgjkfurBvZqKGe1QkYk-0lNO0=.518519f5-a2cb-44ed-946c-09e517e7c5d2@github.com>
Message-ID: 

> Currently, an enum switch with patterns is desugared in a very non-standard, and potentially slow, way. It would be better to use the standard `typeSwitch` bootstrap to classify the enum constants. The bootstrap needs to accept enum constants as labels in order to allow this. A complication is that if an enum constant is missing, that is not an incompatible change for the switch, and the switch should simply work as if the case for the missing constant didn't exist. So, the proposed solution is to have a new bootstrap `enumConstant` that converts the enum constant name to the enum constant, returning `null`, if the constant does not exist. It delegates to `ConstantBootstraps.enumConstant` to do the actual conversion. And `typeSwitch` accepts `null`s as padding.
> 
> How does this look?

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Updating javadoc, as suggested.

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

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/81/files
  - new: https://git.openjdk.java.net/jdk17/pull/81/files/06a1bebf..196e106f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=81&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=81&range=02-03

  Stats: 21 lines in 2 files changed: 17 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/81.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/81/head:pull/81

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

From jlahoda at openjdk.java.net  Tue Jun 22 19:41:56 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 22 Jun 2021 19:41:56 GMT
Subject: [jdk17] RFR: 8268766: Desugaring of pattern matching enum switch
 should be improved [v3]
In-Reply-To: 
References: <3xKa946t0s_eRqnj0vfgjkfurBvZqKGe1QkYk-0lNO0=.518519f5-a2cb-44ed-946c-09e517e7c5d2@github.com>
 
 
Message-ID: 

On Fri, 18 Jun 2021 14:35:42 GMT, Maurizio Cimadamore  wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updating javadoc, code and tests as suggested.
>
> src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 175:
> 
>> 173:      * Bootstrap method for linking an {@code invokedynamic} call site that
>> 174:      * implements a {@code switch} on a target of an enum type.  The static
>> 175:      * arguments are an array of case labels which must be non-null and of type
> 
> This sentence can still be improved and made cleared. Example:
> 
>> The static arguments are used to encode the case labels associated to the `switch` construct, where each label can be encoded as a `String` (e.g. to represent an enum constant), or, alternatively, as a `Class` (e.g. to represent a type test pattern whose type is an enum type).

Thanks. I've updated the javadoc and improved the validation a little, checking the `Class` objects provided.

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

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

From mcimadamore at openjdk.java.net  Tue Jun 22 20:48:28 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 22 Jun 2021 20:48:28 GMT
Subject: [jdk17] RFR: 8268766: Desugaring of pattern matching enum switch
 should be improved [v4]
In-Reply-To: 
References: <3xKa946t0s_eRqnj0vfgjkfurBvZqKGe1QkYk-0lNO0=.518519f5-a2cb-44ed-946c-09e517e7c5d2@github.com>
 
Message-ID: 

On Tue, 22 Jun 2021 19:41:55 GMT, Jan Lahoda  wrote:

>> Currently, an enum switch with patterns is desugared in a very non-standard, and potentially slow, way. It would be better to use the standard `typeSwitch` bootstrap to classify the enum constants. The bootstrap needs to accept enum constants as labels in order to allow this. A complication is that if an enum constant is missing, that is not an incompatible change for the switch, and the switch should simply work as if the case for the missing constant didn't exist. So, the proposed solution is to have a new bootstrap `enumConstant` that converts the enum constant name to the enum constant, returning `null`, if the constant does not exist. It delegates to `ConstantBootstraps.enumConstant` to do the actual conversion. And `typeSwitch` accepts `null`s as padding.
>> 
>> How does this look?
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updating javadoc, as suggested.

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 175:

> 173:      * Bootstrap method for linking an {@code invokedynamic} call site that
> 174:      * implements a {@code switch} on a target of an enum type. The static
> 175:      * arguments are used to encode the case labels associated to the switch

`String` and `Class` should appear in code blocks perhaps, or link tags? Also, I think this text could be improved by splitting the sentence by using a bullet list:


The static arguments are used to encode the case labels associated to the switch
construct, where each label can be encoded in two ways:
* as a String value, which represents the name of the enum constant associated with the label
* as a Class value, which represents the enum type associated with a type test pattern

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 218:

> 216:      * {@code Class} of the target enum type.
> 217:      * @throws Throwable if there is any error linking the call site
> 218:      * @jvms 4.4.6 The CONSTANT_NameAndType_info Structure

Not sure what we do for other bootstraps, but I wonder if the throws clause here should be more specific - for instance the LambdaMetafactory tells when an exception is gonna be triggered. Here it seems like there are a couple of cases which can be called out, where we know that linkage is going to fail.

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

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

From gavin.bierman at oracle.com  Tue Jun 22 22:23:01 2021
From: gavin.bierman at oracle.com (Gavin Bierman)
Date: Tue, 22 Jun 2021 22:23:01 +0000
Subject: Pattern matching for switch: Spec and Javac inconsistency
In-Reply-To: 
References: 
Message-ID: 

Hi Ilyas

On 22 Jun 2021, at 12:38, Ilyas Selimov > wrote:

Hello!

I found several differences between some rules in the spec draft (http://cr.openjdk.java.net/~gbierman/jep406/jep406-20210527/specs/patterns-switch-jls.html#jls-14.11.1)
and its javac implementation (OpenJDK 17 build 17-ea+27-2476).
Maybe ones are intentional or I missed something during the past discussions.

1)
Spec:
If a switch label has a constant case label element then if the switch label also has other case element labels they must be either a constant case label element, the default case label element, or the null case label element.

The next code is compiled fine despite the existence of both constant and pattern case label elements:
void testInt(Integer i) {
  switch (i) {
    case Integer o && o != null, 1:
      System.out.println("s1");
    default:
      System.out.println("def");
  }
}

while the similar code isn't compiled:

enum Day { MONDAY, TUESDAY, WEDNESDAY }
void testEnum(Day d) {
  switch (d) {
    case Day day && day != null, TUESDAY: // illegal fall-through to a pattern
      System.out.println("day");
    default:
      System.out.println("def");
  }
}

Hmm? that looks like a bug.


2)
Spec:
If a switch label has a null case label element then if the switch label also has any pattern case element labels, they must be type patterns (14.30.1).

Does "must be be type patterns" mean here that I can't declare guarded patterns together with
'null' label element like in the code below:
void testInt(Integer i) {
  switch (i) {
    case null, Integer o && o != null:
      System.out.println("s1");
    default:
      System.out.println("def");
  }
}


This is the feature that we discussed. The idea is that you can append a null case to a type pattern. So if you see a label such as `case null, T t` then if the label matches it is the case that `t` is either null or is an object whose type is convertible to T. We could have instead added some sort of T? t pattern, but this felt more readable.

The problem with what you suggest is, I think, readability. The guarded pattern suggests to the casual reader that `o` is never null. Except that by prepending with null, it could be.

We are being conservative in this first preview. The idea is that if restrictions like this actually bite, then we can look at loosening it up. Let us know how it goes.


3)
Spec:
A switch label that has a pattern case label element p that is total for the type of the selector expression of the enclosing switch statement or switch expression dominates a switch label that has a 'null' label element.

Here are two similar code samples:
void testInt1(Integer i) {
  switch (i) {
    case Object o, null:
      System.out.println("s1");
  }
}

void testInt2(Integer i) {
  switch (i) {
    case Object o:
      System.out.println("s1");
    case null: // this case label is dominated by a preceding case label
      System.out.println("null");
  }
}

The first one compiles fine, while the second one is not.
The spec says only about dominance between label elements within separate switch labels. Anyway, what is the main reason that allows the first sample to be compiled?

Yes, I considered this. But it felt like it would be too tough on the user, and it seemed okay to allow them to add a redundant null label element. (Of course, compilers and IDEs could add warnings here to suggest to the programmer that they can remove the null.) We can look again at this for the second preview version of course.

Thanks,
Gavin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jwilhelm at openjdk.java.net  Wed Jun 23 00:31:30 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Wed, 23 Jun 2021 00:31:30 GMT
Subject: RFR: Merge jdk17
Message-ID: 

Forwardport JDK 17 -> JDK 18

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

Commit messages:
 - Merge
 - 8268404: [TESTBUG] tools/jpackage/windows/WinInstallerIconTest.java failed "AssertionError: Failed: Check icon"
 - 8267652: c2 loop unrolling by 8 results in reading memory past array
 - 8267399: C2: java/text/Normalizer/ConformanceTest.java test failed with assertion
 - 8268888: Upstream 8268230: Foreign Linker API & Windows user32/kernel32: String conversion seems broken
 - 8268524: nmethod::post_compiled_method_load_event racingly called on zombie
 - 8266631: StandardJavaFileManager: getJavaFileObjects() impl violates the spec
 - 8267421: j.l.constant.DirectMethodHandleDesc.Kind.valueOf(int) implementation doesn't conform to the spec regarding REF_invokeInterface handling
 - 8268349: Provide clear run-time warnings about Security Manager deprecation
 - 8268293: VectorAPI cast operation on mask and shuffle is broken
 - ... and 1 more: https://git.openjdk.java.net/jdk/compare/0c693e2f...7bf4b35f

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.java.net/jdk/pull/4562/files
  Stats: 1931 lines in 60 files changed: 653 ins; 1061 del; 217 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4562.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4562/head:pull/4562

PR: https://git.openjdk.java.net/jdk/pull/4562

From jwilhelm at openjdk.java.net  Wed Jun 23 01:09:32 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Wed, 23 Jun 2021 01:09:32 GMT
Subject: RFR: Merge jdk17 [v2]
In-Reply-To: 
References: 
Message-ID: 

> Forwardport JDK 17 -> JDK 18

Jesper Wilhelmsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 59 commits:

 - Merge
 - 8268290: Improve LockFreeQueue<> utility
   
   Reviewed-by: iwalulya, tschatzl
 - 8264941: Remove CodeCache::mark_for_evol_deoptimization() method
   
   Reviewed-by: kvn, vlivanov, sspitsyn
 - 8269031: linux x86_64 check for binutils 2.25 or higher after 8265783
   
   Reviewed-by: ihse, erikj
 - 8267657: Add missing PrintC1Statistics before incrementing counters
   
   Reviewed-by: iveresov
 - 8268857: Merge VM_PrintJNI and VM_PrintThreads and remove the unused field 'is_deadlock' of DeadlockCycle
   
   Reviewed-by: dholmes
 - 8269077: TestSystemGC uses "require vm.gc.G1" for large pages subtest
   
   Reviewed-by: tschatzl, kbarrett
 - Merge
 - 8268458: Add verification type for evacuation failures
   
   Reviewed-by: kbarrett, iwalulya
 - 8268952: Automatically update heap sizes in G1MonitoringScope
   
   Reviewed-by: kbarrett, iwalulya
 - ... and 49 more: https://git.openjdk.java.net/jdk/compare/35e4c272...7bf4b35f

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

Changes: https://git.openjdk.java.net/jdk/pull/4562/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4562&range=01
  Stats: 16267 lines in 261 files changed: 13210 ins; 2433 del; 624 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4562.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4562/head:pull/4562

PR: https://git.openjdk.java.net/jdk/pull/4562

From jwilhelm at openjdk.java.net  Wed Jun 23 01:09:33 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Wed, 23 Jun 2021 01:09:33 GMT
Subject: Integrated: Merge jdk17
In-Reply-To: 
References: 
Message-ID: <_z9pXnmkit5l3vbQ1LT3mAP67fTQ2wh8P8g7ScaZVGw=.91f3374b-1abd-416d-a80b-d0a540f6889e@github.com>

On Wed, 23 Jun 2021 00:21:57 GMT, Jesper Wilhelmsson  wrote:

> Forwardport JDK 17 -> JDK 18

This pull request has now been integrated.

Changeset: b6cfca8a
Author:    Jesper Wilhelmsson 
URL:       https://git.openjdk.java.net/jdk/commit/b6cfca8a89810c7ed63ebc34ed9855b66ebcb5d9
Stats:     1931 lines in 60 files changed: 653 ins; 1061 del; 217 mod

Merge

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

PR: https://git.openjdk.java.net/jdk/pull/4562

From john.r.rose at oracle.com  Wed Jun 23 02:33:33 2021
From: john.r.rose at oracle.com (John Rose)
Date: Wed, 23 Jun 2021 02:33:33 +0000
Subject: JDK-8254073, unicode escape preprocessing, and \u005C
In-Reply-To: <86DC9BD0-1DDB-40D8-A46D-43A9C72EBFA9@oracle.com>
References: 
 <86DC9BD0-1DDB-40D8-A46D-43A9C72EBFA9@oracle.com>
Message-ID: 

It would be good if javac gave a warning when fed
highly questionable puzzlers like the sequence of
code points \ u 0 0 5 C.  There?s no excuse for using
it, and although the JLS tolerates it, it is almost
certainly a mark of someone confusing themselves,
or trying to confuse others.

The deepest problems are with the unicode escape
for the character (005C) which introduces the
unicode escape.  But I would also welcome a wider
warning, which would report any use of a unicode
escape which decodes to a legitimate token constituent
in the basic ASCII set.

For safety?s sake, I would want to warn on any printable
(non-control) code point between 0020 and 007E inclusive,
plus line terminators 000A and 000D.

Such warnings would help train users away from
writing obfuscated code, even if they thought they
had a reason to do so, and it would also help users
detect maliciously obfuscated code.

Supposedly it?s useful to (once in a blue moon)
re-encode everything in Java source file using
unicode escapes (maybe for blank-free URLs?)
but in such cases the warnings can be disabled
and disregarded.  Apart from blue moons,
nobody ever, ever wants to get confused by
unicode escapes which make a program less
readable.

? John

> On Jun 21, 2021, at 2:56 PM, Jim Laskey  wrote:
> 
> "\u005C? should have been treated as a backslash. Will check into it. 
> 
> Cheers,
> 
> ? Jim
> 
> ??
> 
>> On Jun 21, 2021, at 6:28 PM, Liam Miller-Cushon  wrote:
>> 
>> ?
>> class T {
>>  public static void main(String[] args) {
>>    System.err.println("\u005C\\u005D");
>>  }
>> }
>> 
>> Before JDK-8254073, this prints `\]`.
>> 
>> After JDK-8254073, unicode escape processing results in `\\\u005D`, which results in an 'invalid escape' error for `\u`. Was that deliberate?
>> 
>> JLS 3.3 says
>> 
>>> for each raw input character that is a backslash \, input processing must consider how many other \ characters contiguously precede it, separating it from a non-\ character or the start of the input stream. If this number is even, then the \ is eligible to begin a Unicode escape; if the number is odd, then the \ is not eligible to begin a Unicode escape.
>> 
>> The difference is in whether `\u005C` (the unicode escape for `\`) counts as one of the `\` preceding a valid unicode escape.
>> 
>> Does "how many other \ characters contiguously precede it" refer to preceding raw input characters, or does it refer to preceding characters after unicode escape processing is performed on them?
>> 
>> JLS 3.3 also mentions that a "character produced by a Unicode escape does not participate in further Unicode escapes", but I'm not sure if that applies here, since in the pre-JDK-8254073 interpretation the unicode-escaped backslash isn't really 'participating' in the second unicode escape.
>> 
>> Thanks,
>> Liam


From jlahoda at openjdk.java.net  Wed Jun 23 07:44:28 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Wed, 23 Jun 2021 07:44:28 GMT
Subject: [jdk17] RFR: 8254571: Erroneous generic type inference in a
 lambda expression with a checked exception
In-Reply-To: 
References: 
Message-ID: 

On Thu, 17 Jun 2021 16:33:11 GMT, Vicente Romero  wrote:

> Hi,
> 
> The compiler is issuing an error for code like:
> 
> 
> class JDK8254571 {
>     public static void test() {
>         outer(nested(x -> mightThrow()));
>     }
>     
>     static  void outer(Object o) {}
> 
>     static  B nested(Fun fun) {
>         return null;
>     }
> 
>     interface Fun {
>         void m(X t) throws Y;
>     }
> 
>     static void mightThrow() throws Exception {}
> } 
> 
> 
> there are several things at play here:
> 
> 1) for performance reasons we decided to minimize the number of inference variables popped up when inferring nested generic method invocations, see Infer::roots
> 2) when an expression is stuck (like in this case this implicit lambda) we decide which inference variables should be present in the related inference context and thrown variables were not part of the equation
> 
> So there are three hypothesis here:
> 1) there is a bug in the code that determines which variables are passed up to the nested inference context, meaning that it is passing less variables than the bare minimum needed
> 2) there is a bug in determining which inference variables should be extracted from stuck expressions
> 3) both are buggy
> 
> The root cause of this bug is that some types escape from Attr with non instantiated type variables in them. I modified the test case to double check if the issue was not related to lambdas, but then the test passed so in the example above I added:
> 
> 
>      static  Fun mightThrow2() throws Y { return null; }
> 
> 
> which simulates the lambda and the compiler has no issues compiling this invocation:
> 
> 
>     outer(nested(mightThrow2()));
> 
> 
> so summing up, after double checking the logic of the code that minimized the inference context I realized that the issue is not there. The code is sound and its output only depend on its input, so the issue should be on determining the input. So IMO the issue is in what inference variables we extract from stuck expressions, which is one of the inputs to Infer::roots. Looking for what variables we extract from stuck expressions, I realized that the code currently ignores type variables in the throws clause and this is why my proposed fix is addressing this issue.
> 
> Comments?

Looks reasonable to me. Not sure if I can foresee the consequences, though.

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

Marked as reviewed by jlahoda (Reviewer).

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

From jlahoda at openjdk.java.net  Wed Jun 23 07:44:28 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Wed, 23 Jun 2021 07:44:28 GMT
Subject: [jdk17] RFR: 8254571: Erroneous generic type inference in a
 lambda expression with a checked exception
In-Reply-To: <8eVy-1W0VFM_yOUn8hTnurzkKPvGO7-SyCWVVsWSMPs=.5ad283d9-bcfc-48a4-b5e0-b1aefaa2f03f@github.com>
References: 
 <8eVy-1W0VFM_yOUn8hTnurzkKPvGO7-SyCWVVsWSMPs=.5ad283d9-bcfc-48a4-b5e0-b1aefaa2f03f@github.com>
Message-ID: 

On Thu, 17 Jun 2021 16:35:45 GMT, Vicente Romero  wrote:

>> Hi,
>> 
>> The compiler is issuing an error for code like:
>> 
>> 
>> class JDK8254571 {
>>     public static void test() {
>>         outer(nested(x -> mightThrow()));
>>     }
>>     
>>     static  void outer(Object o) {}
>> 
>>     static  B nested(Fun fun) {
>>         return null;
>>     }
>> 
>>     interface Fun {
>>         void m(X t) throws Y;
>>     }
>> 
>>     static void mightThrow() throws Exception {}
>> } 
>> 
>> 
>> there are several things at play here:
>> 
>> 1) for performance reasons we decided to minimize the number of inference variables popped up when inferring nested generic method invocations, see Infer::roots
>> 2) when an expression is stuck (like in this case this implicit lambda) we decide which inference variables should be present in the related inference context and thrown variables were not part of the equation
>> 
>> So there are three hypothesis here:
>> 1) there is a bug in the code that determines which variables are passed up to the nested inference context, meaning that it is passing less variables than the bare minimum needed
>> 2) there is a bug in determining which inference variables should be extracted from stuck expressions
>> 3) both are buggy
>> 
>> The root cause of this bug is that some types escape from Attr with non instantiated type variables in them. I modified the test case to double check if the issue was not related to lambdas, but then the test passed so in the example above I added:
>> 
>> 
>>      static  Fun mightThrow2() throws Y { return null; }
>> 
>> 
>> which simulates the lambda and the compiler has no issues compiling this invocation:
>> 
>> 
>>     outer(nested(mightThrow2()));
>> 
>> 
>> so summing up, after double checking the logic of the code that minimized the inference context I realized that the issue is not there. The code is sound and its output only depend on its input, so the issue should be on determining the input. So IMO the issue is in what inference variables we extract from stuck expressions, which is one of the inputs to Infer::roots. Looking for what variables we extract from stuck expressions, I realized that the code currently ignores type variables in the throws clause and this is why my proposed fix is addressing this issue.
>> 
>> Comments?
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java line 1242:
> 
>> 1240:                 stuckVars.addAll(freeArgVars);
>> 1241:                 depVars.addAll(inferenceContext.freeVarsIn(descType.getReturnType()));
>> 1242:                 depVars.addAll(inferenceContext.freeVarsIn(descType.getThrownTypes()));
> 
> did the same for method references given the similarities between both but I couldn't find a test case that reproduced the issue with a method reference

How about:

outer(nested(ConsiderExceptionTVarsInStuckExprs::mightThrow2));
...
static  void mightThrow2(C c) throws Exception {}

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

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

From mcimadamore at openjdk.java.net  Wed Jun 23 09:53:28 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 23 Jun 2021 09:53:28 GMT
Subject: [jdk17] RFR: 8254571: Erroneous generic type inference in a
 lambda expression with a checked exception
In-Reply-To: 
References: 
Message-ID: <3a-fcwO7Od2woUCzPdv1BWRfG3UUyofk6qEal8e6AGs=.a81b5e36-d32d-4f10-affb-21ddbb35442f@github.com>

On Thu, 17 Jun 2021 16:33:11 GMT, Vicente Romero  wrote:

> Hi,
> 
> The compiler is issuing an error for code like:
> 
> 
> class JDK8254571 {
>     public static void test() {
>         outer(nested(x -> mightThrow()));
>     }
>     
>     static  void outer(Object o) {}
> 
>     static  B nested(Fun fun) {
>         return null;
>     }
> 
>     interface Fun {
>         void m(X t) throws Y;
>     }
> 
>     static void mightThrow() throws Exception {}
> } 
> 
> 
> there are several things at play here:
> 
> 1) for performance reasons we decided to minimize the number of inference variables popped up when inferring nested generic method invocations, see Infer::roots
> 2) when an expression is stuck (like in this case this implicit lambda) we decide which inference variables should be present in the related inference context and thrown variables were not part of the equation
> 
> So there are three hypothesis here:
> 1) there is a bug in the code that determines which variables are passed up to the nested inference context, meaning that it is passing less variables than the bare minimum needed
> 2) there is a bug in determining which inference variables should be extracted from stuck expressions
> 3) both are buggy
> 
> The root cause of this bug is that some types escape from Attr with non instantiated type variables in them. I modified the test case to double check if the issue was not related to lambdas, but then the test passed so in the example above I added:
> 
> 
>      static  Fun mightThrow2() throws Y { return null; }
> 
> 
> which simulates the lambda and the compiler has no issues compiling this invocation:
> 
> 
>     outer(nested(mightThrow2()));
> 
> 
> so summing up, after double checking the logic of the code that minimized the inference context I realized that the issue is not there. The code is sound and its output only depend on its input, so the issue should be on determining the input. So IMO the issue is in what inference variables we extract from stuck expressions, which is one of the inputs to Infer::roots. Looking for what variables we extract from stuck expressions, I realized that the code currently ignores type variables in the throws clause and this is why my proposed fix is addressing this issue.
> 
> Comments?

I believe the fix is good. We probably overlooked free type variables in the thrown clause (as they are relatively rare) when doing stuck expression computation. These variables are part of the bound set used by JLS chapter 18, so dropping them on the floor (as current code does) is not a good option. This patch rectifies that.

To test with method references, you would need the method reference to be "non-exact": only in that case will the method reference be considered stuck in the same way the implicit lambda is, I believe.

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

Marked as reviewed by mcimadamore (Reviewer).

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

From jlahoda at openjdk.java.net  Wed Jun 23 10:20:43 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Wed, 23 Jun 2021 10:20:43 GMT
Subject: [jdk17] Integrated: 8268961: Parenthesized pattern with guards does
 not work
In-Reply-To: 
References: 
Message-ID: 

On Tue, 22 Jun 2021 13:02:40 GMT, Jan Lahoda  wrote:

> This PR fixes a couple of problems related to parenthesized patterns:
> a) as noted in https://bugs.openjdk.java.net/browse/JDK-8268961, javac does not accept guards after parenthesized patterns (e.g. `(String s) && s.isEmpty()`, although it should.
> b) related to that, the disambiguation determining whether a case label is a pattern or an expression is not working well for cases like `a >> b`, which will be interpreted as a pattern (while it may be a valid expression)
> c) related to that, handling of parenthesized patterns in Attr should also be better - the raw type warning should be reported for all type patterns, even those inside a guarded pattern
> d) the source level check was missing on one place for parenthesized patterns, as noted in https://bugs.openjdk.java.net/browse/JDK-8268896

This pull request has now been integrated.

Changeset: bf706207
Author:    Jan Lahoda 
URL:       https://git.openjdk.java.net/jdk17/commit/bf706207454d8aea57049189befdf2a08e6d1291
Stats:     274 lines in 8 files changed: 244 ins; 19 del; 11 mod

8268961: Parenthesized pattern with guards does not work
8268896: Parenthesized pattern is not guarded by source level check

Reviewed-by: vromero

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

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

From jlahoda at openjdk.java.net  Wed Jun 23 11:58:10 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Wed, 23 Jun 2021 11:58:10 GMT
Subject: [jdk17] RFR: 8268766: Desugaring of pattern matching enum switch
 should be improved [v4]
In-Reply-To: 
References: <3xKa946t0s_eRqnj0vfgjkfurBvZqKGe1QkYk-0lNO0=.518519f5-a2cb-44ed-946c-09e517e7c5d2@github.com>
 
 
Message-ID: 

On Tue, 22 Jun 2021 20:43:03 GMT, Maurizio Cimadamore  wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updating javadoc, as suggested.
>
> src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 175:
> 
>> 173:      * Bootstrap method for linking an {@code invokedynamic} call site that
>> 174:      * implements a {@code switch} on a target of an enum type. The static
>> 175:      * arguments are used to encode the case labels associated to the switch
> 
> `String` and `Class` should appear in code blocks perhaps, or link tags? Also, I think this text could be improved by splitting the sentence by using a bullet list:
> 
> 
> The static arguments are used to encode the case labels associated to the switch
> construct, where each label can be encoded in two ways:
> * as a String value, which represents the name of the enum constant associated with the label
> * as a Class value, which represents the enum type associated with a type test pattern

Thanks! I've (tried to) updated the javadoc as suggested.

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

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

From jlahoda at openjdk.java.net  Wed Jun 23 11:58:06 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Wed, 23 Jun 2021 11:58:06 GMT
Subject: [jdk17] RFR: 8268766: Desugaring of pattern matching enum switch
 should be improved [v5]
In-Reply-To: <3xKa946t0s_eRqnj0vfgjkfurBvZqKGe1QkYk-0lNO0=.518519f5-a2cb-44ed-946c-09e517e7c5d2@github.com>
References: <3xKa946t0s_eRqnj0vfgjkfurBvZqKGe1QkYk-0lNO0=.518519f5-a2cb-44ed-946c-09e517e7c5d2@github.com>
Message-ID: 

> Currently, an enum switch with patterns is desugared in a very non-standard, and potentially slow, way. It would be better to use the standard `typeSwitch` bootstrap to classify the enum constants. The bootstrap needs to accept enum constants as labels in order to allow this. A complication is that if an enum constant is missing, that is not an incompatible change for the switch, and the switch should simply work as if the case for the missing constant didn't exist. So, the proposed solution is to have a new bootstrap `enumConstant` that converts the enum constant name to the enum constant, returning `null`, if the constant does not exist. It delegates to `ConstantBootstraps.enumConstant` to do the actual conversion. And `typeSwitch` accepts `null`s as padding.
> 
> How does this look?

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Improving javadoc.

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

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/81/files
  - new: https://git.openjdk.java.net/jdk17/pull/81/files/196e106f..0c371364

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=81&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=81&range=03-04

  Stats: 13 lines in 1 file changed: 6 ins; 2 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/81.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/81/head:pull/81

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

From jlahoda at openjdk.java.net  Wed Jun 23 14:44:34 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Wed, 23 Jun 2021 14:44:34 GMT
Subject: [jdk17] RFR: 8267610: NPE at at
 jdk.compiler/com.sun.tools.javac.jvm.Code.emitop
In-Reply-To: 
References: 
Message-ID: 

On Tue, 15 Jun 2021 15:05:40 GMT, Guoxiong Li  wrote:

> Hi all,
> 
> Currently, the class TransPatterns sometimes doesn't transform the `pattern variables` and `pattern symbols` to the normal variables and symbols, especially the places where the pattern variables are used.
> The following phases, such as LambdaToMethod, Lower and Gen, may crash or generate some wrong results.
> 
> The known issues are [JDK-8267610](https://bugs.openjdk.java.net/browse/JDK-8267610) and [JDK-8268748](https://bugs.openjdk.java.net/browse/JDK-8268748).
> 
> **JDK-8267610 is an issue that pattern symbol causes the compiler to crash.**
> 
> During transforming the InstanceOfTree (JCInstanceOf) , the `BindingSymbol`  instead of the `VarSymbol` is used to make the new `JCIdent` and `JCBinary` trees. At the phase LambdaToMethod, the compiler can't capture this variable so that the lambda method has uncorrect parameters. So at the phase Gen, the compiler crashes because of NPE.
> 
> **JDK-8268748 is an issue that pattern symbol causes that the compiler generates wrong bytecodes.**
> 
> When transforming the BindingPatternTree (JCBindingPattern), the `BindingSymbol` is also handled uncorrectly and used to make the new `JCIdent` and `JCAssign` trees. At the phase Gen, the compiler find the wrong variables, so that the wrong bytecodes are generated.
> 
> These two issues are similar and influence each other. So I solve them at one patch.
> The lines 208-212 are to solve JDK-8267610 with the test `LambdaCannotCapturePatternVariables`. 
> The lines 233-239 are to solve JDK-8268748 with the test `NestedPatternVariablesBytecode`.
> 
> If lines 208-212 are not included, the test  `NestedPatternVariablesBytecode` can't pass. 
> If lines 233-239 are not included, the test `LambdaCannotCapturePatternVariables` can't pass. 
> So I put them together.
> 
> Thanks for taking the time to review.
> 
> Best Regards,
> -- Guoxiong.

Thanks for looking into this and sorry for trouble. Looking at the implementation, would it make sense to set the currentValue only after the expression is translated? E.g. something like:

diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java
index 4c077968ff5..c57294bf4ab 100644
--- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java
+++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java
@@ -189,12 +189,14 @@ public class TransPatterns extends TreeTranslator {
             //=>
             //(let T' N$temp = E; N$temp instanceof typeof($pattern) && )
             //note the pattern desugaring performs binding variable assignments
-            Symbol exprSym = TreeInfo.symbol(tree.expr);
             Type tempType = tree.expr.type.hasTag(BOT) ?
                     syms.objectType
                     : tree.expr.type;
             VarSymbol prevCurrentValue = currentValue;
             try {
+                JCExpression translatedExpr = translate(tree.expr);
+                Symbol exprSym = TreeInfo.symbol(translatedExpr);
+
                 if (exprSym != null &&
                     exprSym.kind == Kind.VAR &&
                     exprSym.owner.kind.matches(Kinds.KindSelector.VAL_MTH)) {
@@ -206,7 +208,6 @@ public class TransPatterns extends TreeTranslator {
                             currentMethodSym);
                 }
 
-                JCExpression translatedExpr = translate(tree.expr);
                 Type principalType = principalType((JCPattern) tree.pattern);
                 result = makeBinary(Tag.AND,
                                     makeTypeTest(make.Ident(currentValue), make.Type(principalType)),


I think the `currentValue` is needed only when the pattern is being processed, not when the expression is being processed, unless I am mistaken.

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

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

From gli at openjdk.java.net  Wed Jun 23 15:08:31 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Wed, 23 Jun 2021 15:08:31 GMT
Subject: [jdk17] RFR: 8267610: NPE at at
 jdk.compiler/com.sun.tools.javac.jvm.Code.emitop
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 23 Jun 2021 14:41:02 GMT, Jan Lahoda  wrote:

>> Hi all,
>> 
>> Currently, the class TransPatterns sometimes doesn't transform the `pattern variables` and `pattern symbols` to the normal variables and symbols, especially the places where the pattern variables are used.
>> The following phases, such as LambdaToMethod, Lower and Gen, may crash or generate some wrong results.
>> 
>> The known issues are [JDK-8267610](https://bugs.openjdk.java.net/browse/JDK-8267610) and [JDK-8268748](https://bugs.openjdk.java.net/browse/JDK-8268748).
>> 
>> **JDK-8267610 is an issue that pattern symbol causes the compiler to crash.**
>> 
>> During transforming the InstanceOfTree (JCInstanceOf) , the `BindingSymbol`  instead of the `VarSymbol` is used to make the new `JCIdent` and `JCBinary` trees. At the phase LambdaToMethod, the compiler can't capture this variable so that the lambda method has uncorrect parameters. So at the phase Gen, the compiler crashes because of NPE.
>> 
>> **JDK-8268748 is an issue that pattern symbol causes that the compiler generates wrong bytecodes.**
>> 
>> When transforming the BindingPatternTree (JCBindingPattern), the `BindingSymbol` is also handled uncorrectly and used to make the new `JCIdent` and `JCAssign` trees. At the phase Gen, the compiler find the wrong variables, so that the wrong bytecodes are generated.
>> 
>> These two issues are similar and influence each other. So I solve them at one patch.
>> The lines 208-212 are to solve JDK-8267610 with the test `LambdaCannotCapturePatternVariables`. 
>> The lines 233-239 are to solve JDK-8268748 with the test `NestedPatternVariablesBytecode`.
>> 
>> If lines 208-212 are not included, the test  `NestedPatternVariablesBytecode` can't pass. 
>> If lines 233-239 are not included, the test `LambdaCannotCapturePatternVariables` can't pass. 
>> So I put them together.
>> 
>> Thanks for taking the time to review.
>> 
>> Best Regards,
>> -- Guoxiong.
>
> Thanks for looking into this and sorry for trouble. Looking at the implementation, would it make sense to set the currentValue only after the expression is translated? E.g. something like:
> 
> diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java
> index 4c077968ff5..c57294bf4ab 100644
> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java
> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java
> @@ -189,12 +189,14 @@ public class TransPatterns extends TreeTranslator {
>              //=>
>              //(let T' N$temp = E; N$temp instanceof typeof($pattern) && )
>              //note the pattern desugaring performs binding variable assignments
> -            Symbol exprSym = TreeInfo.symbol(tree.expr);
>              Type tempType = tree.expr.type.hasTag(BOT) ?
>                      syms.objectType
>                      : tree.expr.type;
>              VarSymbol prevCurrentValue = currentValue;
>              try {
> +                JCExpression translatedExpr = translate(tree.expr);
> +                Symbol exprSym = TreeInfo.symbol(translatedExpr);
> +
>                  if (exprSym != null &&
>                      exprSym.kind == Kind.VAR &&
>                      exprSym.owner.kind.matches(Kinds.KindSelector.VAL_MTH)) {
> @@ -206,7 +208,6 @@ public class TransPatterns extends TreeTranslator {
>                              currentMethodSym);
>                  }
>  
> -                JCExpression translatedExpr = translate(tree.expr);
>                  Type principalType = principalType((JCPattern) tree.pattern);
>                  result = makeBinary(Tag.AND,
>                                      makeTypeTest(make.Ident(currentValue), make.Type(principalType)),
> 
> 
> I think the `currentValue` is needed only when the pattern is being processed, not when the expression is being processed, unless I am mistaken.

@lahodaj thanks for your comment.

I have tried your way before submitting this PR. But the compiler didn't work as expected.
It is because the following translations need the right `currentValue` to complete the translation.
If we don't set the `currentValue` before these translations, the result may be wrong.


                JCExpression translatedExpr = translate(tree.expr);
                Type principalType = principalType((JCPattern) tree.pattern);


So I revised the code like this patch which seems to use unnecessary variable `actualVar`.
Actually, this redundant step is necessary to avoid the regression.

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

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

From jonathan.gibbons at oracle.com  Wed Jun 23 15:10:34 2021
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 23 Jun 2021 08:10:34 -0700
Subject: JDK-8254073, unicode escape preprocessing, and \u005C
In-Reply-To: 
References: 
 <86DC9BD0-1DDB-40D8-A46D-43A9C72EBFA9@oracle.com>
 
Message-ID: <6ff1f145-e491-2be4-ff4a-c3196e67d6a6@oracle.com>

How about -Xlint:unicode ... default on.

-- Jon

On 6/22/21 7:33 PM, John Rose wrote:
> It would be good if javac gave a warning when fed
> highly questionable puzzlers like the sequence of
> code points \ u 0 0 5 C.  There?s no excuse for using
> it, and although the JLS tolerates it, it is almost
> certainly a mark of someone confusing themselves,
> or trying to confuse others.
>
> The deepest problems are with the unicode escape
> for the character (005C) which introduces the
> unicode escape.  But I would also welcome a wider
> warning, which would report any use of a unicode
> escape which decodes to a legitimate token constituent
> in the basic ASCII set.
>
> For safety?s sake, I would want to warn on any printable
> (non-control) code point between 0020 and 007E inclusive,
> plus line terminators 000A and 000D.
>
> Such warnings would help train users away from
> writing obfuscated code, even if they thought they
> had a reason to do so, and it would also help users
> detect maliciously obfuscated code.
>
> Supposedly it?s useful to (once in a blue moon)
> re-encode everything in Java source file using
> unicode escapes (maybe for blank-free URLs?)
> but in such cases the warnings can be disabled
> and disregarded.  Apart from blue moons,
> nobody ever, ever wants to get confused by
> unicode escapes which make a program less
> readable.
>
> ? John
>
>> On Jun 21, 2021, at 2:56 PM, Jim Laskey  wrote:
>>
>> "\u005C? should have been treated as a backslash. Will check into it.
>>
>> Cheers,
>>
>> ? Jim
>>
>> ??
>>
>>> On Jun 21, 2021, at 6:28 PM, Liam Miller-Cushon  wrote:
>>>
>>> ?
>>> class T {
>>>   public static void main(String[] args) {
>>>     System.err.println("\u005C\\u005D");
>>>   }
>>> }
>>>
>>> Before JDK-8254073, this prints `\]`.
>>>
>>> After JDK-8254073, unicode escape processing results in `\\\u005D`, which results in an 'invalid escape' error for `\u`. Was that deliberate?
>>>
>>> JLS 3.3 says
>>>
>>>> for each raw input character that is a backslash \, input processing must consider how many other \ characters contiguously precede it, separating it from a non-\ character or the start of the input stream. If this number is even, then the \ is eligible to begin a Unicode escape; if the number is odd, then the \ is not eligible to begin a Unicode escape.
>>> The difference is in whether `\u005C` (the unicode escape for `\`) counts as one of the `\` preceding a valid unicode escape.
>>>
>>> Does "how many other \ characters contiguously precede it" refer to preceding raw input characters, or does it refer to preceding characters after unicode escape processing is performed on them?
>>>
>>> JLS 3.3 also mentions that a "character produced by a Unicode escape does not participate in further Unicode escapes", but I'm not sure if that applies here, since in the pre-JDK-8254073 interpretation the unicode-escaped backslash isn't really 'participating' in the second unicode escape.
>>>
>>> Thanks,
>>> Liam

From james.laskey at oracle.com  Wed Jun 23 15:13:24 2021
From: james.laskey at oracle.com (Jim Laskey)
Date: Wed, 23 Jun 2021 15:13:24 +0000
Subject: JDK-8254073, unicode escape preprocessing, and \u005C
In-Reply-To: <6ff1f145-e491-2be4-ff4a-c3196e67d6a6@oracle.com>
References: 
 <86DC9BD0-1DDB-40D8-A46D-43A9C72EBFA9@oracle.com>
 
 <6ff1f145-e491-2be4-ff4a-c3196e67d6a6@oracle.com>
Message-ID: <7F9C25F0-F34E-4DF3-AB91-5C032687D7CB@oracle.com>

I assume y'all are suggesting this for 18. I want to make sure the main fix makes it into LTS 17.

> On Jun 23, 2021, at 12:10 PM, Jonathan Gibbons  wrote:
> 
> How about -Xlint:unicode ... default on.
> 
> -- Jon
> 
> On 6/22/21 7:33 PM, John Rose wrote:
>> It would be good if javac gave a warning when fed
>> highly questionable puzzlers like the sequence of
>> code points \ u 0 0 5 C.  There?s no excuse for using
>> it, and although the JLS tolerates it, it is almost
>> certainly a mark of someone confusing themselves,
>> or trying to confuse others.
>> 
>> The deepest problems are with the unicode escape
>> for the character (005C) which introduces the
>> unicode escape.  But I would also welcome a wider
>> warning, which would report any use of a unicode
>> escape which decodes to a legitimate token constituent
>> in the basic ASCII set.
>> 
>> For safety?s sake, I would want to warn on any printable
>> (non-control) code point between 0020 and 007E inclusive,
>> plus line terminators 000A and 000D.
>> 
>> Such warnings would help train users away from
>> writing obfuscated code, even if they thought they
>> had a reason to do so, and it would also help users
>> detect maliciously obfuscated code.
>> 
>> Supposedly it?s useful to (once in a blue moon)
>> re-encode everything in Java source file using
>> unicode escapes (maybe for blank-free URLs?)
>> but in such cases the warnings can be disabled
>> and disregarded.  Apart from blue moons,
>> nobody ever, ever wants to get confused by
>> unicode escapes which make a program less
>> readable.
>> 
>> ? John
>> 
>>> On Jun 21, 2021, at 2:56 PM, Jim Laskey  wrote:
>>> 
>>> "\u005C? should have been treated as a backslash. Will check into it.
>>> 
>>> Cheers,
>>> 
>>> ? Jim
>>> 
>>> ??
>>> 
>>>> On Jun 21, 2021, at 6:28 PM, Liam Miller-Cushon  wrote:
>>>> 
>>>> ?
>>>> class T {
>>>>  public static void main(String[] args) {
>>>>    System.err.println("\u005C\\u005D");
>>>>  }
>>>> }
>>>> 
>>>> Before JDK-8254073, this prints `\]`.
>>>> 
>>>> After JDK-8254073, unicode escape processing results in `\\\u005D`, which results in an 'invalid escape' error for `\u`. Was that deliberate?
>>>> 
>>>> JLS 3.3 says
>>>> 
>>>>> for each raw input character that is a backslash \, input processing must consider how many other \ characters contiguously precede it, separating it from a non-\ character or the start of the input stream. If this number is even, then the \ is eligible to begin a Unicode escape; if the number is odd, then the \ is not eligible to begin a Unicode escape.
>>>> The difference is in whether `\u005C` (the unicode escape for `\`) counts as one of the `\` preceding a valid unicode escape.
>>>> 
>>>> Does "how many other \ characters contiguously precede it" refer to preceding raw input characters, or does it refer to preceding characters after unicode escape processing is performed on them?
>>>> 
>>>> JLS 3.3 also mentions that a "character produced by a Unicode escape does not participate in further Unicode escapes", but I'm not sure if that applies here, since in the pre-JDK-8254073 interpretation the unicode-escaped backslash isn't really 'participating' in the second unicode escape.
>>>> 
>>>> Thanks,
>>>> Liam


From jlaskey at openjdk.java.net  Wed Jun 23 15:37:49 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Wed, 23 Jun 2021 15:37:49 GMT
Subject: [jdk17] RFR: JDK-8269150 Unicode \u005C not treated as an escaping
 backslash
Message-ID: 

\u005C Unicode escape sequence not being treated as a backslash for general escape sequences.

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

Commit messages:
 - Correct unicode escape handling in UnicodeReader, added test

Changes: https://git.openjdk.java.net/jdk17/pull/126/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=126&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8269150
  Stats: 37 lines in 2 files changed: 36 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/126.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/126/head:pull/126

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

From jlahoda at openjdk.java.net  Wed Jun 23 15:50:34 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Wed, 23 Jun 2021 15:50:34 GMT
Subject: [jdk17] RFR: 8267610: NPE at at
 jdk.compiler/com.sun.tools.javac.jvm.Code.emitop
In-Reply-To: 
References: 
Message-ID: 

On Tue, 15 Jun 2021 15:05:40 GMT, Guoxiong Li  wrote:

> Hi all,
> 
> Currently, the class TransPatterns sometimes doesn't transform the `pattern variables` and `pattern symbols` to the normal variables and symbols, especially the places where the pattern variables are used.
> The following phases, such as LambdaToMethod, Lower and Gen, may crash or generate some wrong results.
> 
> The known issues are [JDK-8267610](https://bugs.openjdk.java.net/browse/JDK-8267610) and [JDK-8268748](https://bugs.openjdk.java.net/browse/JDK-8268748).
> 
> **JDK-8267610 is an issue that pattern symbol causes the compiler to crash.**
> 
> During transforming the InstanceOfTree (JCInstanceOf) , the `BindingSymbol`  instead of the `VarSymbol` is used to make the new `JCIdent` and `JCBinary` trees. At the phase LambdaToMethod, the compiler can't capture this variable so that the lambda method has uncorrect parameters. So at the phase Gen, the compiler crashes because of NPE.
> 
> **JDK-8268748 is an issue that pattern symbol causes that the compiler generates wrong bytecodes.**
> 
> When transforming the BindingPatternTree (JCBindingPattern), the `BindingSymbol` is also handled uncorrectly and used to make the new `JCIdent` and `JCAssign` trees. At the phase Gen, the compiler find the wrong variables, so that the wrong bytecodes are generated.
> 
> These two issues are similar and influence each other. So I solve them at one patch.
> The lines 208-212 are to solve JDK-8267610 with the test `LambdaCannotCapturePatternVariables`. 
> The lines 233-239 are to solve JDK-8268748 with the test `NestedPatternVariablesBytecode`.
> 
> If lines 208-212 are not included, the test  `NestedPatternVariablesBytecode` can't pass. 
> If lines 233-239 are not included, the test `LambdaCannotCapturePatternVariables` can't pass. 
> So I put them together.
> 
> Thanks for taking the time to review.
> 
> Best Regards,
> -- Guoxiong.

Do you have details on what goes wrong when the `currentValue` is set after translating the expression? Looking into the code, I am not sure what that should break, and I ran existing tests and none seem to fail. So I wonder where it fails. Thanks!

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

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

From jjg at openjdk.java.net  Wed Jun 23 15:56:25 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 23 Jun 2021 15:56:25 GMT
Subject: [jdk17] RFR: JDK-8269150 Unicode \u005C not treated as an
 escaping backslash
In-Reply-To: 
References: 
Message-ID: 

On Wed, 23 Jun 2021 15:30:25 GMT, Jim Laskey  wrote:

> \u005C Unicode escape sequence not being treated as a backslash for general escape sequences.

Changes requested by jjg (Reviewer).

test/langtools/tools/javac/T8269150/T8269150.java line 33:

> 31: public class T8269150 {
> 32:     public static void main(String... args) {
> 33:         System.err.println("\u005C\\u005D");

This seems to be a very weak "don't crash" test.
Shouldn't it check what is printed as well?

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

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

From jlaskey at openjdk.java.net  Wed Jun 23 15:56:26 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Wed, 23 Jun 2021 15:56:26 GMT
Subject: [jdk17] RFR: JDK-8269150 Unicode \u005C not treated as an
 escaping backslash
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 23 Jun 2021 15:50:40 GMT, Jonathan Gibbons  wrote:

>> \u005C Unicode escape sequence not being treated as a backslash for general escape sequences.
>
> test/langtools/tools/javac/T8269150/T8269150.java line 33:
> 
>> 31: public class T8269150 {
>> 32:     public static void main(String... args) {
>> 33:         System.err.println("\u005C\\u005D");
> 
> This seems to be a very weak "don't crash" test.
> Shouldn't it check what is printed as well?

Sure

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

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

From vromero at openjdk.java.net  Wed Jun 23 17:10:29 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Wed, 23 Jun 2021 17:10:29 GMT
Subject: [jdk17] RFR: 8254571: Erroneous generic type inference in a
 lambda expression with a checked exception
In-Reply-To: 
References: 
 <8eVy-1W0VFM_yOUn8hTnurzkKPvGO7-SyCWVVsWSMPs=.5ad283d9-bcfc-48a4-b5e0-b1aefaa2f03f@github.com>
 
Message-ID: 

On Wed, 23 Jun 2021 07:36:58 GMT, Jan Lahoda  wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java line 1242:
>> 
>>> 1240:                 stuckVars.addAll(freeArgVars);
>>> 1241:                 depVars.addAll(inferenceContext.freeVarsIn(descType.getReturnType()));
>>> 1242:                 depVars.addAll(inferenceContext.freeVarsIn(descType.getThrownTypes()));
>> 
>> did the same for method references given the similarities between both but I couldn't find a test case that reproduced the issue with a method reference
>
> How about:
> 
> outer(nested(ConsiderExceptionTVarsInStuckExprs::mightThrow2));
> ...
> static  void mightThrow2(C c) throws Exception {}

yep that one makes the trick, thanks

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

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

From vromero at openjdk.java.net  Wed Jun 23 17:17:03 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Wed, 23 Jun 2021 17:17:03 GMT
Subject: [jdk17] RFR: 8254571: Erroneous generic type inference in a
 lambda expression with a checked exception [v2]
In-Reply-To: 
References: 
Message-ID: 

> Hi,
> 
> The compiler is issuing an error for code like:
> 
> 
> class JDK8254571 {
>     public static void test() {
>         outer(nested(x -> mightThrow()));
>     }
>     
>     static  void outer(Object o) {}
> 
>     static  B nested(Fun fun) {
>         return null;
>     }
> 
>     interface Fun {
>         void m(X t) throws Y;
>     }
> 
>     static void mightThrow() throws Exception {}
> } 
> 
> 
> there are several things at play here:
> 
> 1) for performance reasons we decided to minimize the number of inference variables popped up when inferring nested generic method invocations, see Infer::roots
> 2) when an expression is stuck (like in this case this implicit lambda) we decide which inference variables should be present in the related inference context and thrown variables were not part of the equation
> 
> So there are three hypothesis here:
> 1) there is a bug in the code that determines which variables are passed up to the nested inference context, meaning that it is passing less variables than the bare minimum needed
> 2) there is a bug in determining which inference variables should be extracted from stuck expressions
> 3) both are buggy
> 
> The root cause of this bug is that some types escape from Attr with non instantiated type variables in them. I modified the test case to double check if the issue was not related to lambdas, but then the test passed so in the example above I added:
> 
> 
>      static  Fun mightThrow2() throws Y { return null; }
> 
> 
> which simulates the lambda and the compiler has no issues compiling this invocation:
> 
> 
>     outer(nested(mightThrow2()));
> 
> 
> so summing up, after double checking the logic of the code that minimized the inference context I realized that the issue is not there. The code is sound and its output only depend on its input, so the issue should be on determining the input. So IMO the issue is in what inference variables we extract from stuck expressions, which is one of the inputs to Infer::roots. Looking for what variables we extract from stuck expressions, I realized that the code currently ignores type variables in the throws clause and this is why my proposed fix is addressing this issue.
> 
> Comments?

Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:

  adding a case for method references to the test

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

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/91/files
  - new: https://git.openjdk.java.net/jdk17/pull/91/files/343943b9..7cd83011

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=91&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=91&range=00-01

  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/91.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/91/head:pull/91

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

From vromero at openjdk.java.net  Wed Jun 23 17:17:04 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Wed, 23 Jun 2021 17:17:04 GMT
Subject: [jdk17] RFR: 8254571: Erroneous generic type inference in a
 lambda expression with a checked exception
In-Reply-To: 
References: 
Message-ID: <2AVylMHqGOHN46poMdyqGamX76d_uQvYoB0w9k3v0ak=.243ccd16-70b8-4b17-b4b9-31e1ac796106@github.com>

On Thu, 17 Jun 2021 16:33:11 GMT, Vicente Romero  wrote:

> Hi,
> 
> The compiler is issuing an error for code like:
> 
> 
> class JDK8254571 {
>     public static void test() {
>         outer(nested(x -> mightThrow()));
>     }
>     
>     static  void outer(Object o) {}
> 
>     static  B nested(Fun fun) {
>         return null;
>     }
> 
>     interface Fun {
>         void m(X t) throws Y;
>     }
> 
>     static void mightThrow() throws Exception {}
> } 
> 
> 
> there are several things at play here:
> 
> 1) for performance reasons we decided to minimize the number of inference variables popped up when inferring nested generic method invocations, see Infer::roots
> 2) when an expression is stuck (like in this case this implicit lambda) we decide which inference variables should be present in the related inference context and thrown variables were not part of the equation
> 
> So there are three hypothesis here:
> 1) there is a bug in the code that determines which variables are passed up to the nested inference context, meaning that it is passing less variables than the bare minimum needed
> 2) there is a bug in determining which inference variables should be extracted from stuck expressions
> 3) both are buggy
> 
> The root cause of this bug is that some types escape from Attr with non instantiated type variables in them. I modified the test case to double check if the issue was not related to lambdas, but then the test passed so in the example above I added:
> 
> 
>      static  Fun mightThrow2() throws Y { return null; }
> 
> 
> which simulates the lambda and the compiler has no issues compiling this invocation:
> 
> 
>     outer(nested(mightThrow2()));
> 
> 
> so summing up, after double checking the logic of the code that minimized the inference context I realized that the issue is not there. The code is sound and its output only depend on its input, so the issue should be on determining the input. So IMO the issue is in what inference variables we extract from stuck expressions, which is one of the inputs to Infer::roots. Looking for what variables we extract from stuck expressions, I realized that the code currently ignores type variables in the throws clause and this is why my proposed fix is addressing this issue.
> 
> Comments?

thanks guys for the review

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

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

From vromero at openjdk.java.net  Wed Jun 23 17:17:08 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Wed, 23 Jun 2021 17:17:08 GMT
Subject: [jdk17] Integrated: 8254571: Erroneous generic type inference in a
 lambda expression with a checked exception
In-Reply-To: 
References: 
Message-ID: 

On Thu, 17 Jun 2021 16:33:11 GMT, Vicente Romero  wrote:

> Hi,
> 
> The compiler is issuing an error for code like:
> 
> 
> class JDK8254571 {
>     public static void test() {
>         outer(nested(x -> mightThrow()));
>     }
>     
>     static  void outer(Object o) {}
> 
>     static  B nested(Fun fun) {
>         return null;
>     }
> 
>     interface Fun {
>         void m(X t) throws Y;
>     }
> 
>     static void mightThrow() throws Exception {}
> } 
> 
> 
> there are several things at play here:
> 
> 1) for performance reasons we decided to minimize the number of inference variables popped up when inferring nested generic method invocations, see Infer::roots
> 2) when an expression is stuck (like in this case this implicit lambda) we decide which inference variables should be present in the related inference context and thrown variables were not part of the equation
> 
> So there are three hypothesis here:
> 1) there is a bug in the code that determines which variables are passed up to the nested inference context, meaning that it is passing less variables than the bare minimum needed
> 2) there is a bug in determining which inference variables should be extracted from stuck expressions
> 3) both are buggy
> 
> The root cause of this bug is that some types escape from Attr with non instantiated type variables in them. I modified the test case to double check if the issue was not related to lambdas, but then the test passed so in the example above I added:
> 
> 
>      static  Fun mightThrow2() throws Y { return null; }
> 
> 
> which simulates the lambda and the compiler has no issues compiling this invocation:
> 
> 
>     outer(nested(mightThrow2()));
> 
> 
> so summing up, after double checking the logic of the code that minimized the inference context I realized that the issue is not there. The code is sound and its output only depend on its input, so the issue should be on determining the input. So IMO the issue is in what inference variables we extract from stuck expressions, which is one of the inputs to Infer::roots. Looking for what variables we extract from stuck expressions, I realized that the code currently ignores type variables in the throws clause and this is why my proposed fix is addressing this issue.
> 
> Comments?

This pull request has now been integrated.

Changeset: 7e96318a
Author:    Vicente Romero 
URL:       https://git.openjdk.java.net/jdk17/commit/7e96318a1fb083d1c037c2c8d5a26f68fddf7a04
Stats:     52 lines in 2 files changed: 52 ins; 0 del; 0 mod

8254571: Erroneous generic type inference in a lambda expression with a checked exception

Reviewed-by: jlahoda, mcimadamore

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

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

From gli at openjdk.java.net  Wed Jun 23 17:23:33 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Wed, 23 Jun 2021 17:23:33 GMT
Subject: [jdk17] RFR: 8267610: NPE at at
 jdk.compiler/com.sun.tools.javac.jvm.Code.emitop
In-Reply-To: 
References: 
Message-ID: 

On Tue, 15 Jun 2021 15:05:40 GMT, Guoxiong Li  wrote:

> Hi all,
> 
> Currently, the class TransPatterns sometimes doesn't transform the `pattern variables` and `pattern symbols` to the normal variables and symbols, especially the places where the pattern variables are used.
> The following phases, such as LambdaToMethod, Lower and Gen, may crash or generate some wrong results.
> 
> The known issues are [JDK-8267610](https://bugs.openjdk.java.net/browse/JDK-8267610) and [JDK-8268748](https://bugs.openjdk.java.net/browse/JDK-8268748).
> 
> **JDK-8267610 is an issue that pattern symbol causes the compiler to crash.**
> 
> During transforming the InstanceOfTree (JCInstanceOf) , the `BindingSymbol`  instead of the `VarSymbol` is used to make the new `JCIdent` and `JCBinary` trees. At the phase LambdaToMethod, the compiler can't capture this variable so that the lambda method has uncorrect parameters. So at the phase Gen, the compiler crashes because of NPE.
> 
> **JDK-8268748 is an issue that pattern symbol causes that the compiler generates wrong bytecodes.**
> 
> When transforming the BindingPatternTree (JCBindingPattern), the `BindingSymbol` is also handled uncorrectly and used to make the new `JCIdent` and `JCAssign` trees. At the phase Gen, the compiler find the wrong variables, so that the wrong bytecodes are generated.
> 
> These two issues are similar and influence each other. So I solve them at one patch.
> The lines 208-212 are to solve JDK-8267610 with the test `LambdaCannotCapturePatternVariables`. 
> The lines 233-239 are to solve JDK-8268748 with the test `NestedPatternVariablesBytecode`.
> 
> If lines 208-212 are not included, the test  `NestedPatternVariablesBytecode` can't pass. 
> If lines 233-239 are not included, the test `LambdaCannotCapturePatternVariables` can't pass. 
> So I put them together.
> 
> Thanks for taking the time to review.
> 
> Best Regards,
> -- Guoxiong.

In short:

I re-read the code and my current patch seems wrong. I would like to adopt your advice and your patch. Thanks for the clarification.

---
In detailed:

I can't find the original change locally now. I try my best to recall the process. The following steps lead me to the wrong direction.

First, I might use the following patch. As you can see, I didn't get the new `Symbol` after `translate(tree.expr)` by using the statement `Symbol exprSym = TreeInfo.symbol(translatedExpr);` so that some tests didn't pass.


diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java
index 16c2fdbf2a5..9be88ac6de1 100644
--- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java
+++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java
@@ -192,6 +192,8 @@ public class TransPatterns extends TreeTranslator {
                     : tree.expr.type;
             VarSymbol prevCurrentValue = currentValue;
             try {
+                JCExpression translatedExpr = translate(tree.expr);
+
                 if (exprSym != null &&
                     exprSym.kind == Kind.VAR &&
                     exprSym.owner.kind.matches(Kinds.KindSelector.VAL_MTH)) {
@@ -203,7 +205,6 @@ public class TransPatterns extends TreeTranslator {
                             currentMethodSym);
                 }
 
-                JCExpression translatedExpr = translate(tree.expr);
                 Type principalType = principalType((JCPattern) tree.pattern);
                 result = makeBinary(Tag.AND,
                                     makeTypeTest(make.Ident(currentValue), make.Type(principalType)),



Then, I look into the failed tests and found that the method `visitBindingPattern` need to be adjusted, too. And I tried the following patch. It caused some tests failed, too.


diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java
index 16c2fdbf2a5..8c8a1935e38 100644
--- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java
+++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java
@@ -186,12 +186,14 @@ public class TransPatterns extends TreeTranslator {
             //=>
             //(let T' N$temp = E; N$temp instanceof typeof($pattern) && )
             //note the pattern desugaring performs binding variable assignments
-            Symbol exprSym = TreeInfo.symbol(tree.expr);
             Type tempType = tree.expr.type.hasTag(BOT) ?
                     syms.objectType
                     : tree.expr.type;
             VarSymbol prevCurrentValue = currentValue;
             try {
+                JCExpression translatedExpr = translate(tree.expr);
+                Symbol exprSym = TreeInfo.symbol(translatedExpr);
+
                 if (exprSym != null &&
                     exprSym.kind == Kind.VAR &&
                     exprSym.owner.kind.matches(Kinds.KindSelector.VAL_MTH)) {
@@ -203,7 +205,6 @@ public class TransPatterns extends TreeTranslator {
                             currentMethodSym);
                 }
 
-                JCExpression translatedExpr = translate(tree.expr);
                 Type principalType = principalType((JCPattern) tree.pattern);
                 result = makeBinary(Tag.AND,
                                     makeTypeTest(make.Ident(currentValue), make.Type(principalType)),
@@ -227,10 +228,13 @@ public class TransPatterns extends TreeTranslator {
         BindingSymbol binding = (BindingSymbol) tree.var.sym;
         Type castTargetType = principalType(tree);
         VarSymbol bindingVar = bindingContext.bindingDeclared(binding);
+        VarSymbol actualVar = (currentValue.flags() & Flags.MATCH_BINDING) != 0
+                ? bindingContext.getBindingFor((BindingSymbol) currentValue)
+                : currentValue;
 
         if (bindingVar != null) {
             JCAssign fakeInit = (JCAssign)make.at(TreeInfo.getStartPos(tree)).Assign(
-                    make.Ident(bindingVar), convert(make.Ident(currentValue), castTargetType)).setType(bindingVar.erasure(types));
+                    make.Ident(bindingVar), convert(make.Ident(actualVar), castTargetType)).setType(bindingVar.erasure(types));
             LetExpr nestedLE = make.LetExpr(List.of(make.Exec(fakeInit)),
                                             make.Literal(true));
             nestedLE.needsCond = true;



At this time, I mistakenly confirmed that both `visitBindingPattern` and `visitTypeTest` need to be revised because they are all about the BindingPattern. So finally, I try the code like this patch, which uses the `actualVal` after translation instead of `currentValue` to make the new tree. Actually, the `visitBindingPattern` don't need to be revised if `visitTypeTest` already set the `currentValue` correctly.

My patch seems good to solve the bug, but actually the `currentValue` in the method `visitTypeTest` should be set after `translate(tree.expr)` by using the statement `Symbol exprSym = TreeInfo.symbol(translatedExpr);` so that the following code, such as `visitBindingPattern`, could use this actual right `currentValue`.

After these analysis, I think my current patch may cause some new regresion because the `currentValue` is not set correctly. And all the tests of `tools/javac` passed locally by using your patch just now. So I would like to adopt your advice and your patch. Thanks for your clarification. I learn more in this bug.

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

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

From gli at openjdk.java.net  Wed Jun 23 18:34:58 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Wed, 23 Jun 2021 18:34:58 GMT
Subject: [jdk17] RFR: 8267610: NPE at at
 jdk.compiler/com.sun.tools.javac.jvm.Code.emitop [v2]
In-Reply-To: 
References: 
Message-ID: <-yacICsemaeKfUoBDbmg0hZV5ZwjnlZNXlzk2pws0bw=.2ad3f4fa-fe7c-4305-839f-30fbc0cfcf29@github.com>

> Hi all,
> 
> Currently, the class TransPatterns sometimes doesn't transform the `pattern variables` and `pattern symbols` to the normal variables and symbols, especially the places where the pattern variables are used.
> The following phases, such as LambdaToMethod, Lower and Gen, may crash or generate some wrong results.
> 
> The known issues are [JDK-8267610](https://bugs.openjdk.java.net/browse/JDK-8267610) and [JDK-8268748](https://bugs.openjdk.java.net/browse/JDK-8268748).
> 
> **JDK-8267610 is an issue that pattern symbol causes the compiler to crash.**
> 
> During transforming the InstanceOfTree (JCInstanceOf) , the `BindingSymbol`  instead of the `VarSymbol` is used to make the new `JCIdent` and `JCBinary` trees. At the phase LambdaToMethod, the compiler can't capture this variable so that the lambda method has uncorrect parameters. So at the phase Gen, the compiler crashes because of NPE.
> 
> **JDK-8268748 is an issue that pattern symbol causes that the compiler generates wrong bytecodes.**
> 
> When transforming the BindingPatternTree (JCBindingPattern), the `BindingSymbol` is also handled uncorrectly and used to make the new `JCIdent` and `JCAssign` trees. At the phase Gen, the compiler find the wrong variables, so that the wrong bytecodes are generated.
> 
> These two issues are similar and influence each other. So I solve them at one patch.
> The lines 208-212 are to solve JDK-8267610 with the test `LambdaCannotCapturePatternVariables`. 
> The lines 233-239 are to solve JDK-8268748 with the test `NestedPatternVariablesBytecode`.
> 
> If lines 208-212 are not included, the test  `NestedPatternVariablesBytecode` can't pass. 
> If lines 233-239 are not included, the test `LambdaCannotCapturePatternVariables` can't pass. 
> So I put them together.
> 
> Thanks for taking the time to review.
> 
> Best Regards,
> -- Guoxiong.

Guoxiong Li has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - Merge remote-tracking branch 'origin/master' into JDK-8267610
 - Set currentValue after translating tree.expr
 - JDK-8267610 and JDK-8268748

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

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/59/files
  - new: https://git.openjdk.java.net/jdk17/pull/59/files/3c303236..2ce9bcb6

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=59&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=59&range=00-01

  Stats: 18076 lines in 301 files changed: 10232 ins; 7037 del; 807 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/59.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/59/head:pull/59

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

From jlaskey at openjdk.java.net  Wed Jun 23 18:42:10 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Wed, 23 Jun 2021 18:42:10 GMT
Subject: [jdk17] RFR: JDK-8269150 Unicode \u005C not treated as an
 escaping backslash [v2]
In-Reply-To: 
References: 
Message-ID: 

> \u005C Unicode escape sequence not being treated as a backslash for general escape sequences.

Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:

 - Merge branch 'master' into 8269150
 - Correct unicode escape handling in UnicodeReader, added test

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

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/126/files
  - new: https://git.openjdk.java.net/jdk17/pull/126/files/3faf4092..8293b8c5

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=126&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=126&range=00-01

  Stats: 63 lines in 3 files changed: 58 ins; 4 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/126.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/126/head:pull/126

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

From jlaskey at openjdk.java.net  Wed Jun 23 18:58:37 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Wed, 23 Jun 2021 18:58:37 GMT
Subject: [jdk17] RFR: JDK-8269150 Unicode \u005C not treated as an
 escaping backslash [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 23 Jun 2021 18:42:10 GMT, Jim Laskey  wrote:

>> \u005C Unicode escape sequence not being treated as a backslash for general escape sequences.
>
> Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'master' into 8269150
>  - Correct unicode escape handling in UnicodeReader, added test

I'll rework the fix to be consistent with jdk 15.

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

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

From gli at openjdk.java.net  Wed Jun 23 19:48:28 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Wed, 23 Jun 2021 19:48:28 GMT
Subject: [jdk17] RFR: 8267610: NPE at at
 jdk.compiler/com.sun.tools.javac.jvm.Code.emitop
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 23 Jun 2021 15:48:04 GMT, Jan Lahoda  wrote:

>> Hi all,
>> 
>> Currently, the class TransPatterns sometimes doesn't transform the `pattern variables` and `pattern symbols` to the normal variables and symbols, especially the places where the pattern variables are used.
>> The following phases, such as LambdaToMethod, Lower and Gen, may crash or generate some wrong results.
>> 
>> The known issues are [JDK-8267610](https://bugs.openjdk.java.net/browse/JDK-8267610) and [JDK-8268748](https://bugs.openjdk.java.net/browse/JDK-8268748).
>> 
>> **JDK-8267610 is an issue that pattern symbol causes the compiler to crash.**
>> 
>> During transforming the InstanceOfTree (JCInstanceOf) , the `BindingSymbol`  instead of the `VarSymbol` is used to make the new `JCIdent` and `JCBinary` trees. At the phase LambdaToMethod, the compiler can't capture this variable so that the lambda method has uncorrect parameters. So at the phase Gen, the compiler crashes because of NPE.
>> 
>> **JDK-8268748 is an issue that pattern symbol causes that the compiler generates wrong bytecodes.**
>> 
>> When transforming the BindingPatternTree (JCBindingPattern), the `BindingSymbol` is also handled uncorrectly and used to make the new `JCIdent` and `JCAssign` trees. At the phase Gen, the compiler find the wrong variables, so that the wrong bytecodes are generated.
>> 
>> These two issues are similar and influence each other. So I solve them at one patch.
>> The lines 208-212 are to solve JDK-8267610 with the test `LambdaCannotCapturePatternVariables`. 
>> The lines 233-239 are to solve JDK-8268748 with the test `NestedPatternVariablesBytecode`.
>> 
>> If lines 208-212 are not included, the test  `NestedPatternVariablesBytecode` can't pass. 
>> If lines 233-239 are not included, the test `LambdaCannotCapturePatternVariables` can't pass. 
>> So I put them together.
>> 
>> Thanks for taking the time to review.
>> 
>> Best Regards,
>> -- Guoxiong.
>
> Do you have details on what goes wrong when the `currentValue` is set after translating the expression? Looking into the code, I am not sure what that should break, and I ran existing tests and none seem to fail. So I wonder where it fails. Thanks!

@lahodaj I updated the code by adopting your advice. Considering that I can't accurately recall the potential regression situation, I suggest it should be more than one reviewer to approve this patch before integrating.

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

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

From john.r.rose at oracle.com  Wed Jun 23 20:59:59 2021
From: john.r.rose at oracle.com (John Rose)
Date: Wed, 23 Jun 2021 20:59:59 +0000
Subject: JDK-8254073, unicode escape preprocessing, and \u005C
In-Reply-To: <7F9C25F0-F34E-4DF3-AB91-5C032687D7CB@oracle.com>
References: 
 <86DC9BD0-1DDB-40D8-A46D-43A9C72EBFA9@oracle.com>
 
 <6ff1f145-e491-2be4-ff4a-c3196e67d6a6@oracle.com>
 <7F9C25F0-F34E-4DF3-AB91-5C032687D7CB@oracle.com>
Message-ID: <19115305-D28F-4937-BDE4-0426994D6E2B@oracle.com>

Yup, no urgency!

And, yes "-Xlint:unicode ... default on? would do the trick.

(?Assuming that -Xlint:unicode would not give false
positives, for non-ASCII encodings.  The most legitimate
uses of \uXXYY are when XX > 01.  Those uses allow
Java source code to be written in 7-bit ASCII.)


> On Jun 23, 2021, at 8:13 AM, Jim Laskey  wrote:
> 
> I assume y'all are suggesting this for 18. I want to make sure the main fix makes it into LTS 17.
> 
>> On Jun 23, 2021, at 12:10 PM, Jonathan Gibbons  wrote:
>> 
>> How about -Xlint:unicode ... default on.
>> 
>> -- Jon
>> 
>> On 6/22/21 7:33 PM, John Rose wrote:
>>> It would be good if javac gave a warning when fed
>>> highly questionable puzzlers like the sequence of
>>> code points \ u 0 0 5 C.  There?s no excuse for using
>>> it, and although the JLS tolerates it, it is almost
>>> certainly a mark of someone confusing themselves,
>>> or trying to confuse others.
>>> 
>>> The deepest problems are with the unicode escape
>>> for the character (005C) which introduces the
>>> unicode escape.  But I would also welcome a wider
>>> warning, which would report any use of a unicode
>>> escape which decodes to a legitimate token constituent
>>> in the basic ASCII set.
>>> 
>>> For safety?s sake, I would want to warn on any printable
>>> (non-control) code point between 0020 and 007E inclusive,
>>> plus line terminators 000A and 000D.
>>> 
>>> Such warnings would help train users away from
>>> writing obfuscated code, even if they thought they
>>> had a reason to do so, and it would also help users
>>> detect maliciously obfuscated code.
>>> 
>>> Supposedly it?s useful to (once in a blue moon)
>>> re-encode everything in Java source file using
>>> unicode escapes (maybe for blank-free URLs?)
>>> but in such cases the warnings can be disabled
>>> and disregarded.  Apart from blue moons,
>>> nobody ever, ever wants to get confused by
>>> unicode escapes which make a program less
>>> readable.
>>> 
>>> ? John
>>> 
>>>> On Jun 21, 2021, at 2:56 PM, Jim Laskey  wrote:
>>>> 
>>>> "\u005C? should have been treated as a backslash. Will check into it.
>>>> 
>>>> Cheers,
>>>> 
>>>> ? Jim
>>>> 
>>>> ??
>>>> 
>>>>> On Jun 21, 2021, at 6:28 PM, Liam Miller-Cushon  wrote:
>>>>> 
>>>>> ?
>>>>> class T {
>>>>> public static void main(String[] args) {
>>>>>   System.err.println("\u005C\\u005D");
>>>>> }
>>>>> }
>>>>> 
>>>>> Before JDK-8254073, this prints `\]`.
>>>>> 
>>>>> After JDK-8254073, unicode escape processing results in `\\\u005D`, which results in an 'invalid escape' error for `\u`. Was that deliberate?
>>>>> 
>>>>> JLS 3.3 says
>>>>> 
>>>>>> for each raw input character that is a backslash \, input processing must consider how many other \ characters contiguously precede it, separating it from a non-\ character or the start of the input stream. If this number is even, then the \ is eligible to begin a Unicode escape; if the number is odd, then the \ is not eligible to begin a Unicode escape.
>>>>> The difference is in whether `\u005C` (the unicode escape for `\`) counts as one of the `\` preceding a valid unicode escape.
>>>>> 
>>>>> Does "how many other \ characters contiguously precede it" refer to preceding raw input characters, or does it refer to preceding characters after unicode escape processing is performed on them?
>>>>> 
>>>>> JLS 3.3 also mentions that a "character produced by a Unicode escape does not participate in further Unicode escapes", but I'm not sure if that applies here, since in the pre-JDK-8254073 interpretation the unicode-escaped backslash isn't really 'participating' in the second unicode escape.
>>>>> 
>>>>> Thanks,
>>>>> Liam
> 


From john.r.rose at oracle.com  Wed Jun 23 21:14:07 2021
From: john.r.rose at oracle.com (John Rose)
Date: Wed, 23 Jun 2021 21:14:07 +0000
Subject: JDK-8254073, unicode escape preprocessing, and \u005C
In-Reply-To: <19115305-D28F-4937-BDE4-0426994D6E2B@oracle.com>
References: 
 <86DC9BD0-1DDB-40D8-A46D-43A9C72EBFA9@oracle.com>
 
 <6ff1f145-e491-2be4-ff4a-c3196e67d6a6@oracle.com>
 <7F9C25F0-F34E-4DF3-AB91-5C032687D7CB@oracle.com>
 <19115305-D28F-4937-BDE4-0426994D6E2B@oracle.com>
Message-ID: <887C978B-5264-49D8-B9A7-AD0C2D3D7897@oracle.com>

On Jun 23, 2021, at 1:59 PM, John Rose > wrote:

The most legitimate uses of \uXXYY are when XX > 01.

My bad; meant to say something like:

The most legitimate uses of \uXXXY are when XXX > 007.

The least legitimate uses obfuscate visible 7-bit characters
(including newlines) that are significant to Java syntax.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From vromero at openjdk.java.net  Wed Jun 23 21:17:30 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Wed, 23 Jun 2021 21:17:30 GMT
Subject: RFR: 8261006: 'super' qualified method references cannot occur in
 a static context
In-Reply-To: 
References: 
Message-ID: 

On Sun, 6 Jun 2021 02:17:17 GMT, Vicente Romero  wrote:

> Please review this PR, currently javac is accepting code like:
> 
> 
> import java.util.function.Supplier;
> 
> public class MethodReferenceInConstructorInvocation {
>     interface Bar {
>         default String getString() { return ""; }
>     }
> 
>     static class Foo implements Bar {
>         public Foo() {  this(Bar.super::getString);  }
>         public Foo(Supplier sString) {}
>     }
> }
> 
> 
> but the spec states in `15.13 Method Reference Expressions`:
> 
> If a method reference expression has the form super :: [TypeArguments] Identifier
> or TypeName . super :: [TypeArguments] Identifier, it is a compile-time error if
> the expression occurs in a static context (?8.1.3).
> 
> and a constructor invocation is a static context. So method references of this form, qualified by `super`, should be rejected by the compiler if they appear in a static context.
> 
> TIA

ping

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

PR: https://git.openjdk.java.net/jdk/pull/4376

From jwilhelm at openjdk.java.net  Thu Jun 24 00:44:37 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Thu, 24 Jun 2021 00:44:37 GMT
Subject: RFR: Merge jdk17
Message-ID: 

Forwardport JDK 17 -> JDK 18

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

Commit messages:
 - Merge
 - 8266854: LibraryCallKit::inline_preconditions_checkIndex modifies control flow even if the intrinsic bailed out
 - 8254571: Erroneous generic type inference in a lambda expression with a checked exception
 - 8269125: Klass enqueue element size calculation wrong when traceid value cross compress limit
 - 8268961: Parenthesized pattern with guards does not work
 - 8269066: assert(ZAddress::is_marked(addr)) failed: Should be marked
 - 8269064: Dropped messages of AsyncLogWriter cause memleak
 - 8269148: Update minor GCC version in GitHub Actions pipeline
 - 8266885: [aarch64] Crash with 'Field too big for insn' for some tests under compiler/jvmci/jdk.vm.ci.code.test/src/jdk/vm/ci/code/test/

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.java.net/jdk/pull/4579/files
  Stats: 408 lines in 17 files changed: 347 ins; 32 del; 29 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4579.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4579/head:pull/4579

PR: https://git.openjdk.java.net/jdk/pull/4579

From manoj.palat at in.ibm.com  Thu Jun 24 00:56:17 2021
From: manoj.palat at in.ibm.com (Manoj Palat)
Date: Thu, 24 Jun 2021 00:56:17 +0000
Subject: Infinite Loop in Pattern switch with guarded patterns in JDK 17
 ea27/ea36
Message-ID: 

An HTML attachment was scrubbed...
URL: 

From lgxbslgx at gmail.com  Thu Jun 24 03:38:48 2021
From: lgxbslgx at gmail.com (Guoxiong Li)
Date: Thu, 24 Jun 2021 11:38:48 +0800
Subject: Type inference bug with method references in OpenJDK 16+
 discovered
In-Reply-To: <509ea1a0-5dba-86b0-205c-f23f4e5d6b9d@gmx.de>
References: 
 
 
 
 <509ea1a0-5dba-86b0-205c-f23f4e5d6b9d@gmx.de>
Message-ID: 

Hi Michael,

> the bug depends on the order in which the java files are compiled.
> It doesn't matter whether adopt-jdk16.0.1, oracle-opendjdk 16.0.1 or
openjdk 17 ea+27 is used.
> If StringLiteral.java and then Variable.java is compiled, the bug occurs.
> Otherwise it doesn't. Right?

Given you reproduce my idea locally, I believe the order I mentioned causes
this bug.

> I mean forcing the order in which the source code files are compiled
would be a workaround, of course.
> However, I have not found any way in maven yet how you can force one
specific order in which the java files are compiled.

Before solving this bug, it is good to use
`interpreter.query(MyFact::new);` to replace
`interpreter.query(MyFact::new);` as a workaround. No matter whether
directly using the compiler or using maven,
depending on the order of the input source files is not a good way to
eliminate the error.
As you mentioned, we can't force the maven to compile the source files by
using our specific order.
It depends on the maven implementation and the implementation may be
different from the maven version.
So we got different results when using maven which is mentioned in the
previous email.

> How big/small is the chance for me to find the bug and submit a fix for
you? What do you think?
> I mean I must run the javac tool in debug mode over my example project
and find out
> where and what goes wrong when the compile order is changed. Or am I
completely wrong?
> The javac code is here, isn't it?
>
https://github.com/openjdk/jdk/tree/master/src/jdk.compiler/share/classes/com/sun/tools/javac

> I would give it a try at the next weekend if you think I could fix it.

The code of the compiler is mainly in the module `jdk.compiler`
https://github.com/openjdk/jdk/tree/master/src/jdk.compiler.
And it requires the modules `java.compiler` and `java.base` which are
mentioned in its `module.info`.
The main code is in the packages  `com.sun.tools.javac` and its
sub-packages. So your link is right.
Here are some documents for you to understand the compiler:
http://openjdk.java.net/groups/compiler/

I remembered my first patch to the compiler:
https://github.com/openjdk/jdk16/pull/34/files
It actually only has one line code change:
```
-            names.ANNOTATION_TYPE, names.LOCAL_VARIABLE, names.PARAMETER};
+            names.ANNOTATION_TYPE, names.LOCAL_VARIABLE, names.PARAMETER,
names.MODULE };
```
I revisited the compiler knowledge at a long time and spent several days on
the bug.
I wanted to give it up during that time but finally, I found the cause and
fixed it.
So I can imagine that it may be hard for you to start. Just do it if *you
are interested on it* no matter how hard it is.
Maybe you can't solve the bug at last, but you can learn more(compiler
knowledge, code skill, debug skill or others) from it.
In my opinion, the most important point is the interest instead of the
difficulty of the problem when *we have enough time*.

> I discovered the exception comes from
src/java.base/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java
in line 295.

The exception is thrown at runtime which you can see at the exception stack.
But actually, the class file generated by the compiler may be wrong so that
the runtime exception is thrown.
So it seems that the cause is in the compiler instead of runtime.


PS:
I notice that your email was not sent to compiler-dev at openjdk.java.net.
Other folks can't read your email.
Please remember to sent or cc to the compiler-dev at openjdk.java.net in the
future.

Best Regards,
-- Guoxiong

On Thu, Jun 24, 2021 at 9:19 AM Michael Mirwaldt 
wrote:

> Hi Guoxiong,
> I can confirm your observation:
> the bug depends on the order in which the java files are compiled.
> It doesn't matter whether adopt-jdk16.0.1, oracle-opendjdk 16.0.1 or
> openjdk 17 ea+27 is used.
> If StringLiteral.java and then Variable.java is compiled, the bug occurs.
> Otherwise it doesn't. Right?
>
> I mean forcing the order in which the source code files are compiled would
> be a workaround, of course.
> However, I have not found any way in maven yet how you can force one
> specific order in which the java files are compiled.
>
> How big/small is the chance for me to find the bug and submit a fix for
> you? What do you think?
> I mean I must run the javac tool in debug mode over my example project and
> find out
> where and what goes wrong when the compile order is changed. Or am I
> completely wrong?
> The javac code is here, isn't it?
>
> https://github.com/openjdk/jdk/tree/master/src/jdk.compiler/share/classes/com/sun/tools/javac
> 
> I would give it a try at the next weekend if you think I could fix it.
>
> I discovered the exception comes from
> src/java.base/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java
> in line 295.
>
> All the best,
> Michael Mirwaldt
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From lgxbslgx at gmail.com  Thu Jun 24 03:43:29 2021
From: lgxbslgx at gmail.com (Guoxiong Li)
Date: Thu, 24 Jun 2021 11:43:29 +0800
Subject: Type inference bug with method references in OpenJDK 16+
 discovered
In-Reply-To: 
References: 
 
 
 
 <509ea1a0-5dba-86b0-205c-f23f4e5d6b9d@gmx.de>
 
Message-ID: 

> And it requires the modules `java.compiler` and `java.base` which are
mentioned in its `module.info`

The `module-info.java` is at
https://github.com/openjdk/jdk/blob/master/src/jdk.compiler/share/classes/module-info.java
The gmail resolves it mistakenly.

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From sadayapalam at openjdk.java.net  Thu Jun 24 04:17:32 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Thu, 24 Jun 2021 04:17:32 GMT
Subject: RFR: 8261006: 'super' qualified method references cannot occur in
 a static context
In-Reply-To: 
References: 
Message-ID: <_xl7tZE53QavW5SaVdysWMztPnurioMY5MkH6r-3I1k=.05c40826-eee8-445c-8ccf-dea976c873a5@github.com>

On Sun, 6 Jun 2021 02:17:17 GMT, Vicente Romero  wrote:

> Please review this PR, currently javac is accepting code like:
> 
> 
> import java.util.function.Supplier;
> 
> public class MethodReferenceInConstructorInvocation {
>     interface Bar {
>         default String getString() { return ""; }
>     }
> 
>     static class Foo implements Bar {
>         public Foo() {  this(Bar.super::getString);  }
>         public Foo(Supplier sString) {}
>     }
> }
> 
> 
> but the spec states in `15.13 Method Reference Expressions`:
> 
> If a method reference expression has the form super :: [TypeArguments] Identifier
> or TypeName . super :: [TypeArguments] Identifier, it is a compile-time error if
> the expression occurs in a static context (?8.1.3).
> 
> and a constructor invocation is a static context. So method references of this form, qualified by `super`, should be rejected by the compiler if they appear in a static context.
> 
> TIA

Do we need to invent a new diagnostics for this ?

I think it is better to check why we fail to issue the existing diagnostic compiler.err.non-static.cant.be.ref for the test case in question.

See that in the following simple test case:


public class X {
    interface I {
        int doit();
    }
    void foo() {
        I i = super::hashCode; // OK.
    }
    static void goo() {
        I i = super::hashCode; // Error
    }


JDK16 does report correctly:

X.java:9: error: non-static variable super cannot be referenced from a static context
        I i = super::hashCode; // Error
              ^
1 error

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

PR: https://git.openjdk.java.net/jdk/pull/4376

From sadayapalam at openjdk.java.net  Thu Jun 24 04:34:30 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Thu, 24 Jun 2021 04:34:30 GMT
Subject: RFR: 8261006: 'super' qualified method references cannot occur in
 a static context
In-Reply-To: 
References: 
Message-ID: <3MrTseY8XtoGhChX253CxInYFi0LXuSVikeH40VapU4=.d89fc6ea-931e-429e-9484-e20eb3ee3ac5@github.com>

On Sun, 6 Jun 2021 02:17:17 GMT, Vicente Romero  wrote:

> Please review this PR, currently javac is accepting code like:
> 
> 
> import java.util.function.Supplier;
> 
> public class MethodReferenceInConstructorInvocation {
>     interface Bar {
>         default String getString() { return ""; }
>     }
> 
>     static class Foo implements Bar {
>         public Foo() {  this(Bar.super::getString);  }
>         public Foo(Supplier sString) {}
>     }
> }
> 
> 
> but the spec states in `15.13 Method Reference Expressions`:
> 
> If a method reference expression has the form super :: [TypeArguments] Identifier
> or TypeName . super :: [TypeArguments] Identifier, it is a compile-time error if
> the expression occurs in a static context (?8.1.3).
> 
> and a constructor invocation is a static context. So method references of this form, qualified by `super`, should be rejected by the compiler if they appear in a static context.
> 
> TIA

Actually, taking a closer look, I don't think the problem is that we fail to issue compiler.err.non-static.cant.be.ref BUT that we fail to diagnose compiler.err.cant.ref.before.ctor.called for the case at hand.

What do you think ?

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

PR: https://git.openjdk.java.net/jdk/pull/4376

From sadayapalam at openjdk.java.net  Thu Jun 24 05:03:30 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Thu, 24 Jun 2021 05:03:30 GMT
Subject: RFR: 8261006: 'super' qualified method references cannot occur in
 a static context
In-Reply-To: 
References: 
Message-ID: 

On Sun, 6 Jun 2021 02:17:17 GMT, Vicente Romero  wrote:

> Please review this PR, currently javac is accepting code like:
> 
> 
> import java.util.function.Supplier;
> 
> public class MethodReferenceInConstructorInvocation {
>     interface Bar {
>         default String getString() { return ""; }
>     }
> 
>     static class Foo implements Bar {
>         public Foo() {  this(Bar.super::getString);  }
>         public Foo(Supplier sString) {}
>     }
> }
> 
> 
> but the spec states in `15.13 Method Reference Expressions`:
> 
> If a method reference expression has the form super :: [TypeArguments] Identifier
> or TypeName . super :: [TypeArguments] Identifier, it is a compile-time error if
> the expression occurs in a static context (?8.1.3).
> 
> and a constructor invocation is a static context. So method references of this form, qualified by `super`, should be rejected by the compiler if they appear in a static context.
> 
> TIA

I wonder if the call to com.sun.tools.javac.comp.Check#earlyRefError originating from com.sun.tools.javac.comp.Attr#visitSelect is not faulty.

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

PR: https://git.openjdk.java.net/jdk/pull/4376

From sadayapalam at openjdk.java.net  Thu Jun 24 05:22:29 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Thu, 24 Jun 2021 05:22:29 GMT
Subject: RFR: 8261006: 'super' qualified method references cannot occur in
 a static context
In-Reply-To: 
References: 
Message-ID: 

On Sun, 6 Jun 2021 02:17:17 GMT, Vicente Romero  wrote:

> Please review this PR, currently javac is accepting code like:
> 
> 
> import java.util.function.Supplier;
> 
> public class MethodReferenceInConstructorInvocation {
>     interface Bar {
>         default String getString() { return ""; }
>     }
> 
>     static class Foo implements Bar {
>         public Foo() {  this(Bar.super::getString);  }
>         public Foo(Supplier sString) {}
>     }
> }
> 
> 
> but the spec states in `15.13 Method Reference Expressions`:
> 
> If a method reference expression has the form super :: [TypeArguments] Identifier
> or TypeName . super :: [TypeArguments] Identifier, it is a compile-time error if
> the expression occurs in a static context (?8.1.3).
> 
> and a constructor invocation is a static context. So method references of this form, qualified by `super`, should be rejected by the compiler if they appear in a static context.
> 
> TIA

Also this test case:


import java.util.function.Supplier;

public class X {

    interface Feature {
        default String getString() {
            return "Hello World";
        }
    }

    private static class Broken implements Feature {
        private final String sString;

        public Broken() {
            this(Feature.super.getString());
        }

        public Broken(String sString) {
            this.sString = sString;
        }
    }
}


compiles both with JDK16 and your patch. 

Should we actually compile it ???

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

PR: https://git.openjdk.java.net/jdk/pull/4376

From jan.lahoda at oracle.com  Thu Jun 24 07:04:19 2021
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Thu, 24 Jun 2021 09:04:19 +0200
Subject: Switch statement containing pattern case label element gets in
 the loop during execution
In-Reply-To: 
References: 
Message-ID: <93c199b6-1fa2-faa9-0168-2f91e736e2fe@oracle.com>

Thanks for the report, Ilyas!


I've filled:

https://bugs.openjdk.java.net/browse/JDK-8269141


Thanks,

 ??? Jan


On 22. 06. 21 10:37, Ilyas Selimov wrote:
> Hello!
>
> I tried to execute the code using OpenJDK 17 (build 17-ea+27-2476):
>
> ? ? public static void main(String[] args) {
> ? ? ? ? test(1);
> ? ? }
>
> ? ? static void test(Integer i) {
> ? ? ? ? switch (i) {
> ? ? ? ? ? ? case Integer o && o != null:
> ? ? ? ? ? ? ? ? System.out.println("s1");
> ? ? ? ? ? ? default:
> ? ? ? ? ? ? ? ? System.out.println("def");
> ? ? ? ? }
> ? ? }
>
> and got the next output:
> s1
> def
> s1
> def
> ...
>
> As a result the switch statement gets in the loop.
> Looking at the bytecode of the method It seems the issue is related?to 
> the latest goto instruction:
>
> ?static void test(java.lang.Integer);
> ? ? Code:
> ? ? ? ?0: aload_0
> ? ? ? ?1: dup
> ? ? ? ?2: invokestatic ?#19 ? ? ? ? ? ? ? ? // Method 
> java/util/Objects.requireNonNull:
> ? ? ? ?5: pop
> ? ? ? ?6: astore_1
> ? ? ? ?7: iconst_0
> ? ? ? ?8: istore_2
> ? ? ? ?9: aload_1
> ? ? ? 10: iload_2
> ? ? ? 11: invokedynamic #25, ?0 ? ? ? ? ? ? // InvokeDynamic 
> #0:typeSwitch:(Ljava/lang/Object;I)I
> ? ? ? 16: lookupswitch ?{ // 1
> ? ? ? ? ? ? ? ? ? ? ?0: 36
> ? ? ? ? ? ? ? ?default: 55
> ? ? ? ? ? }
> ? ? ? 36: aload_1
> ? ? ? 37: astore_3
> ? ? ? 38: aload_3
> ? ? ? 39: ifnonnull ? ? 47
> ? ? ? 42: iconst_1
> ? ? ? 43: istore_2
> ? ? ? 44: goto ? ? ? ? ?9
> ? ? ? 47: getstatic ? ? #29 ? ? ? ? ? ? ? ? // Field 
> java/lang/System.out:Ljava/io/PrintStream;
> ? ? ? 50: ldc ? ? ? ? ? #35 ? ? ? ? ? ? ? ? // String s1
> ? ? ? 52: invokevirtual #37 ? ? ? ? ? ? ? ? // Method 
> java/io/PrintStream.println:(Ljava/lang/String;)V
> ? ? ? 55: getstatic ? ? #29 ? ? ? ? ? ? ? ? // Field 
> java/lang/System.out:Ljava/io/PrintStream;
> ? ? ? 58: ldc ? ? ? ? ? #43 ? ? ? ? ? ? ? ? // String def
> ? ? ? 60: invokevirtual #37 ? ? ? ? ? ? ? ? // Method 
> java/io/PrintStream.println:(Ljava/lang/String;)V
> ? ? ? 63: goto ? ? ? ? ?9
>
> Could somebody take a look?
>
> Thanks,
> Ilyas

From jan.lahoda at oracle.com  Thu Jun 24 07:06:15 2021
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Thu, 24 Jun 2021 09:06:15 +0200
Subject: Infinite Loop in Pattern switch with guarded patterns in JDK 17
 ea27/ea36
In-Reply-To: 
References: 
Message-ID: 

Hi Manoj,


thanks for the report. There is:

https://bugs.openjdk.java.net/browse/JDK-8269141

filled for this.


Thanks,

 ???? Jan


On 24. 06. 21 2:56, Manoj Palat wrote:
> Hi,
> I see an infinite loop with with JDK 17 ea27/ea26 for pattern switch;
> given switch pattern with guarded pattern case:
> public class X {
> ? private static void foo(Object o) {
> ? ? switch (o) {
> ? ? ? case String s1 && s1.length()>1: System.out.println("Guarded"); 
> break;
> ? ? ? default : System.out.println("Object");
> ? ? }
> ? }
> ? ?public static void main(String[] args) {
> ? ? foo(new Object());
> ? }
> }
> compiles fine with ea27 (and ea26), but while running gets into an 
> infinite loop.
>
> The disassembled code shows that there is a "goto 9" at 73 (to restart 
> the switch) - I believe that?this goto here is an error as switch need 
> not be restarted at default; omitting the generation of this?"goto" 
> should remove the infinite loop.
> ?private static void foo(java.lang.Object arg0);
> ? ? ?...
> ? ? ?9 ?aload_1
> ? ? 10 ?iload_2
> ? ? 11 ?invokedynamic 0 typeSwitch(java.lang.Object, int) : int [13]
> ? ? 16 ?lookupswitch default: 65
> ? ? ? ? ? case 0: 36
> ? ? ....
> ? ? 65 ?getstatic java.lang.System.out : java.io.PrintStream [23]
> ? ? 68 ?ldc  [37]
> ? ? 70 ?invokevirtual java.io.PrintStream.println(java.lang.String) : 
> void [31]
> ? ? 73 ?goto 9 <== this is an error
> ? ? 76 ?return
> Thanks,
> Manoj
> PS: Had sent a mail to jdk-dev, but I didn't see it in the list; also 
> raised bug with oracle internal id: 9070727
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jlahoda at openjdk.java.net  Thu Jun 24 10:56:40 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Thu, 24 Jun 2021 10:56:40 GMT
Subject: [jdk17] RFR: 8269141: Switch statement containing pattern case label
 element gets in the loop during execution
Message-ID: <1z-buK0Nwk94qrl8n6y96HSJQq7ZDugwTThAA0swqrk=.98d5ca3d-b37f-4446-914d-5062d14353f0@github.com>

Guards in the pattern matching switches are implemented internally through `continue` in switches (which cannot be written in the source, but can be used internally). Consider code:

switch (...) {
     case String s && s.isEmpty(): break;
     default: //fall through outside the switch
}

The current implementation in Gen will: `code.resolve(switchEnv.info.cont);` which puts (merges) the code paths for the `continue`s to `pendingJumps`. The `code.branch(goto_)` in `code.resolve(code.branch(goto_), switchStart)` will merge the `pendingJumps` (i.e. the continues) with the execution as it falls through the default case of the switch, and the `code.resolve` will jump for all the merged code paths to the beginning of the switch. This is wrong - we should only jump to the beginning of the switch for the `continue` code paths, not for the final fall-through code path. This is what the fix is trying to do.

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

Commit messages:
 - 8269141: Switch statement containing pattern case label element gets in the loop during execution

Changes: https://git.openjdk.java.net/jdk17/pull/135/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=135&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8269141
  Stats: 34 lines in 2 files changed: 31 ins; 1 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/135.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/135/head:pull/135

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

From jlahoda at openjdk.java.net  Thu Jun 24 10:57:55 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Thu, 24 Jun 2021 10:57:55 GMT
Subject: [jdk17] RFR: 8268871: Adjust javac to updated exhaustiveness
 specification [v2]
In-Reply-To: 
References: 
Message-ID: 

> 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.

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Improving tests, and performance of exhaustive switch detection.

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

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/78/files
  - new: https://git.openjdk.java.net/jdk17/pull/78/files/b7c067c9..a7a61692

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=78&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=78&range=00-01

  Stats: 129 lines in 2 files changed: 95 ins; 9 del; 25 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/78.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/78/head:pull/78

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

From jlahoda at openjdk.java.net  Thu Jun 24 11:02:29 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Thu, 24 Jun 2021 11:02:29 GMT
Subject: [jdk17] RFR: 8268871: Adjust javac to updated exhaustiveness
 specification [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 16 Jun 2021 16:48:24 GMT, Vicente Romero  wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improving tests, and performance of exhaustive switch detection.
>
> test/langtools/tools/javac/patterns/Exhaustiveness.java line 642:
> 
>> 640:         doTest(base,
>> 641:                new String[]{"""
>> 642:                             package lib;
> 
> it will be nice to have additional tests with conditional patterns (total and not) to stress all the possible code paths

Thanks Vicente! I've updated the patch based on your comments in https://github.com/openjdk/jdk17/pull/78/commits/a7a61692dcf3fbc8d24a5cf7c881ec635d654f62 .

What do you think?

Thanks!

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

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

From jlahoda at openjdk.java.net  Thu Jun 24 12:08:31 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Thu, 24 Jun 2021 12:08:31 GMT
Subject: [jdk17] RFR: 8267610: NPE at at
 jdk.compiler/com.sun.tools.javac.jvm.Code.emitop [v2]
In-Reply-To: <-yacICsemaeKfUoBDbmg0hZV5ZwjnlZNXlzk2pws0bw=.2ad3f4fa-fe7c-4305-839f-30fbc0cfcf29@github.com>
References: 
 <-yacICsemaeKfUoBDbmg0hZV5ZwjnlZNXlzk2pws0bw=.2ad3f4fa-fe7c-4305-839f-30fbc0cfcf29@github.com>
Message-ID: 

On Wed, 23 Jun 2021 18:34:58 GMT, Guoxiong Li  wrote:

>> Hi all,
>> 
>> Currently, the class TransPatterns sometimes doesn't transform the `pattern variables` and `pattern symbols` to the normal variables and symbols, especially the places where the pattern variables are used.
>> The following phases, such as LambdaToMethod, Lower and Gen, may crash or generate some wrong results.
>> 
>> The known issues are [JDK-8267610](https://bugs.openjdk.java.net/browse/JDK-8267610) and [JDK-8268748](https://bugs.openjdk.java.net/browse/JDK-8268748).
>> 
>> **JDK-8267610 is an issue that pattern symbol causes the compiler to crash.**
>> 
>> During transforming the InstanceOfTree (JCInstanceOf) , the `BindingSymbol`  instead of the `VarSymbol` is used to make the new `JCIdent` and `JCBinary` trees. At the phase LambdaToMethod, the compiler can't capture this variable so that the lambda method has uncorrect parameters. So at the phase Gen, the compiler crashes because of NPE.
>> 
>> **JDK-8268748 is an issue that pattern symbol causes that the compiler generates wrong bytecodes.**
>> 
>> When transforming the BindingPatternTree (JCBindingPattern), the `BindingSymbol` is also handled uncorrectly and used to make the new `JCIdent` and `JCAssign` trees. At the phase Gen, the compiler find the wrong variables, so that the wrong bytecodes are generated.
>> 
>> These two issues are similar and influence each other. So I solve them at one patch.
>> The lines 208-212 are to solve JDK-8267610 with the test `LambdaCannotCapturePatternVariables`. 
>> The lines 233-239 are to solve JDK-8268748 with the test `NestedPatternVariablesBytecode`.
>> 
>> If lines 208-212 are not included, the test  `NestedPatternVariablesBytecode` can't pass. 
>> If lines 233-239 are not included, the test `LambdaCannotCapturePatternVariables` can't pass. 
>> So I put them together.
>> 
>> Thanks for taking the time to review.
>> 
>> Best Regards,
>> -- Guoxiong.
>
> Guoxiong Li has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/master' into JDK-8267610
>  - Set currentValue after translating tree.expr
>  - JDK-8267610 and JDK-8268748

To me, looks good. @vicente-romero-oracle, could you please take a look? Thanks!

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

Marked as reviewed by jlahoda (Reviewer).

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

From jlaskey at openjdk.java.net  Thu Jun 24 13:40:01 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Thu, 24 Jun 2021 13:40:01 GMT
Subject: [jdk17] RFR: JDK-8269150 Unicode \u005C not treated as an
 escaping backslash [v3]
In-Reply-To: 
References: 
Message-ID: 

> \u005C Unicode escape sequence not being treated as a backslash for general escape sequences.

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Updated the test to include all combinations

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

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/126/files
  - new: https://git.openjdk.java.net/jdk17/pull/126/files/8293b8c5..3e2886d6

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=126&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=126&range=01-02

  Stats: 25 lines in 1 file changed: 23 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/126.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/126/head:pull/126

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

From vromero at openjdk.java.net  Thu Jun 24 15:05:40 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Thu, 24 Jun 2021 15:05:40 GMT
Subject: [jdk17] RFR: 8268871: Adjust javac to updated exhaustiveness
 specification [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 24 Jun 2021 10:57:55 GMT, Jan Lahoda  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.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improving tests, and performance of exhaustive switch detection.

lgtm

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

Marked as reviewed by vromero (Reviewer).

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

From vromero at openjdk.java.net  Thu Jun 24 16:13:30 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Thu, 24 Jun 2021 16:13:30 GMT
Subject: [jdk17] RFR: 8267610: NPE at at
 jdk.compiler/com.sun.tools.javac.jvm.Code.emitop [v2]
In-Reply-To: <-yacICsemaeKfUoBDbmg0hZV5ZwjnlZNXlzk2pws0bw=.2ad3f4fa-fe7c-4305-839f-30fbc0cfcf29@github.com>
References: 
 <-yacICsemaeKfUoBDbmg0hZV5ZwjnlZNXlzk2pws0bw=.2ad3f4fa-fe7c-4305-839f-30fbc0cfcf29@github.com>
Message-ID: <0Hptc2DRvlu-SsYtp973eJjbaJbvkrpfGdunZlHxXV4=.93927a56-0f02-4e79-b945-66eb8459a1a9@github.com>

On Wed, 23 Jun 2021 18:34:58 GMT, Guoxiong Li  wrote:

>> Hi all,
>> 
>> Currently, the class TransPatterns sometimes doesn't transform the `pattern variables` and `pattern symbols` to the normal variables and symbols, especially the places where the pattern variables are used.
>> The following phases, such as LambdaToMethod, Lower and Gen, may crash or generate some wrong results.
>> 
>> The known issues are [JDK-8267610](https://bugs.openjdk.java.net/browse/JDK-8267610) and [JDK-8268748](https://bugs.openjdk.java.net/browse/JDK-8268748).
>> 
>> **JDK-8267610 is an issue that pattern symbol causes the compiler to crash.**
>> 
>> During transforming the InstanceOfTree (JCInstanceOf) , the `BindingSymbol`  instead of the `VarSymbol` is used to make the new `JCIdent` and `JCBinary` trees. At the phase LambdaToMethod, the compiler can't capture this variable so that the lambda method has uncorrect parameters. So at the phase Gen, the compiler crashes because of NPE.
>> 
>> **JDK-8268748 is an issue that pattern symbol causes that the compiler generates wrong bytecodes.**
>> 
>> When transforming the BindingPatternTree (JCBindingPattern), the `BindingSymbol` is also handled uncorrectly and used to make the new `JCIdent` and `JCAssign` trees. At the phase Gen, the compiler find the wrong variables, so that the wrong bytecodes are generated.
>> 
>> These two issues are similar and influence each other. So I solve them at one patch.
>> The lines 208-212 are to solve JDK-8267610 with the test `LambdaCannotCapturePatternVariables`. 
>> The lines 233-239 are to solve JDK-8268748 with the test `NestedPatternVariablesBytecode`.
>> 
>> If lines 208-212 are not included, the test  `NestedPatternVariablesBytecode` can't pass. 
>> If lines 233-239 are not included, the test `LambdaCannotCapturePatternVariables` can't pass. 
>> So I put them together.
>> 
>> Thanks for taking the time to review.
>> 
>> Best Regards,
>> -- Guoxiong.
>
> Guoxiong Li has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/master' into JDK-8267610
>  - Set currentValue after translating tree.expr
>  - JDK-8267610 and JDK-8268748

test/langtools/tools/javac/patterns/NestedPatternVariablesBytecode.java line 96:

> 94:         List actualCode = getCodeInstructions(code_attribute);
> 95:         List expectedCode = Arrays.asList(
> 96:                 "aload_1", "instanceof", "ifeq", "aload_1", "checkcast", "astore_2", "aload_2", "instanceof",

not sure I like this code pattern check, if we change the generated code for whatever reason we will need to revisit this test. Is there other way of testing the same? like executing a code and checking its result(s) or throwing an exception if something unexpected happened?

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

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

From gli at openjdk.java.net  Thu Jun 24 17:01:34 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Thu, 24 Jun 2021 17:01:34 GMT
Subject: [jdk17] RFR: 8267610: NPE at at
 jdk.compiler/com.sun.tools.javac.jvm.Code.emitop [v2]
In-Reply-To: <0Hptc2DRvlu-SsYtp973eJjbaJbvkrpfGdunZlHxXV4=.93927a56-0f02-4e79-b945-66eb8459a1a9@github.com>
References: 
 <-yacICsemaeKfUoBDbmg0hZV5ZwjnlZNXlzk2pws0bw=.2ad3f4fa-fe7c-4305-839f-30fbc0cfcf29@github.com>
 <0Hptc2DRvlu-SsYtp973eJjbaJbvkrpfGdunZlHxXV4=.93927a56-0f02-4e79-b945-66eb8459a1a9@github.com>
Message-ID: 

On Thu, 24 Jun 2021 16:08:20 GMT, Vicente Romero  wrote:

>> Guoxiong Li has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'origin/master' into JDK-8267610
>>  - Set currentValue after translating tree.expr
>>  - JDK-8267610 and JDK-8268748
>
> test/langtools/tools/javac/patterns/NestedPatternVariablesBytecode.java line 96:
> 
>> 94:         List actualCode = getCodeInstructions(code_attribute);
>> 95:         List expectedCode = Arrays.asList(
>> 96:                 "aload_1", "instanceof", "ifeq", "aload_1", "checkcast", "astore_2", "aload_2", "instanceof",
> 
> not sure I like this code pattern check, if we change the generated code for whatever reason we will need to revisit this test. Is there other way of testing the same? like executing a code and checking its result(s) or throwing an exception if something unexpected happened?

@vicente-romero-oracle Thanks for your review.

In this test, if the bug is not fixed which means the `aload_2` would be `aload_1`, the code runs well too.
The `aload_1` or `aload_2` don't effect the result so that we can't check it by executing it.
There are some similar situations in the past when we want to verify the class files.
These tests would also fail if we change the logic of the code generation.

Another way is that only verify if the `aload_2` is at the right place instead of verify all the instruments.
But it also need to be revisited and revised if the logic of the code generation is changed in the future.
It seems a unavoidable issue about verifing the class files.

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

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

From vromero at openjdk.java.net  Thu Jun 24 19:40:32 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Thu, 24 Jun 2021 19:40:32 GMT
Subject: [jdk17] RFR: 8267610: NPE at at
 jdk.compiler/com.sun.tools.javac.jvm.Code.emitop [v2]
In-Reply-To: <-yacICsemaeKfUoBDbmg0hZV5ZwjnlZNXlzk2pws0bw=.2ad3f4fa-fe7c-4305-839f-30fbc0cfcf29@github.com>
References: 
 <-yacICsemaeKfUoBDbmg0hZV5ZwjnlZNXlzk2pws0bw=.2ad3f4fa-fe7c-4305-839f-30fbc0cfcf29@github.com>
Message-ID: 

On Wed, 23 Jun 2021 18:34:58 GMT, Guoxiong Li  wrote:

>> Hi all,
>> 
>> Currently, the class TransPatterns sometimes doesn't transform the `pattern variables` and `pattern symbols` to the normal variables and symbols, especially the places where the pattern variables are used.
>> The following phases, such as LambdaToMethod, Lower and Gen, may crash or generate some wrong results.
>> 
>> The known issues are [JDK-8267610](https://bugs.openjdk.java.net/browse/JDK-8267610) and [JDK-8268748](https://bugs.openjdk.java.net/browse/JDK-8268748).
>> 
>> **JDK-8267610 is an issue that pattern symbol causes the compiler to crash.**
>> 
>> During transforming the InstanceOfTree (JCInstanceOf) , the `BindingSymbol`  instead of the `VarSymbol` is used to make the new `JCIdent` and `JCBinary` trees. At the phase LambdaToMethod, the compiler can't capture this variable so that the lambda method has uncorrect parameters. So at the phase Gen, the compiler crashes because of NPE.
>> 
>> **JDK-8268748 is an issue that pattern symbol causes that the compiler generates wrong bytecodes.**
>> 
>> When transforming the BindingPatternTree (JCBindingPattern), the `BindingSymbol` is also handled uncorrectly and used to make the new `JCIdent` and `JCAssign` trees. At the phase Gen, the compiler find the wrong variables, so that the wrong bytecodes are generated.
>> 
>> These two issues are similar and influence each other. So I solve them at one patch.
>> The lines 208-212 are to solve JDK-8267610 with the test `LambdaCannotCapturePatternVariables`. 
>> The lines 233-239 are to solve JDK-8268748 with the test `NestedPatternVariablesBytecode`.
>> 
>> If lines 208-212 are not included, the test  `NestedPatternVariablesBytecode` can't pass. 
>> If lines 233-239 are not included, the test `LambdaCannotCapturePatternVariables` can't pass. 
>> So I put them together.
>> 
>> Thanks for taking the time to review.
>> 
>> Best Regards,
>> -- Guoxiong.
>
> Guoxiong Li has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/master' into JDK-8267610
>  - Set currentValue after translating tree.expr
>  - JDK-8267610 and JDK-8268748

Marked as reviewed by vromero (Reviewer).

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

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

From vromero at openjdk.java.net  Thu Jun 24 19:40:36 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Thu, 24 Jun 2021 19:40:36 GMT
Subject: [jdk17] RFR: 8267610: NPE at at
 jdk.compiler/com.sun.tools.javac.jvm.Code.emitop [v2]
In-Reply-To: <0Hptc2DRvlu-SsYtp973eJjbaJbvkrpfGdunZlHxXV4=.93927a56-0f02-4e79-b945-66eb8459a1a9@github.com>
References: 
 <-yacICsemaeKfUoBDbmg0hZV5ZwjnlZNXlzk2pws0bw=.2ad3f4fa-fe7c-4305-839f-30fbc0cfcf29@github.com>
 <0Hptc2DRvlu-SsYtp973eJjbaJbvkrpfGdunZlHxXV4=.93927a56-0f02-4e79-b945-66eb8459a1a9@github.com>
Message-ID: 

On Thu, 24 Jun 2021 16:08:20 GMT, Vicente Romero  wrote:

>> Guoxiong Li has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'origin/master' into JDK-8267610
>>  - Set currentValue after translating tree.expr
>>  - JDK-8267610 and JDK-8268748
>
> test/langtools/tools/javac/patterns/NestedPatternVariablesBytecode.java line 96:
> 
>> 94:         List actualCode = getCodeInstructions(code_attribute);
>> 95:         List expectedCode = Arrays.asList(
>> 96:                 "aload_1", "instanceof", "ifeq", "aload_1", "checkcast", "astore_2", "aload_2", "instanceof",
> 
> not sure I like this code pattern check, if we change the generated code for whatever reason we will need to revisit this test. Is there other way of testing the same? like executing a code and checking its result(s) or throwing an exception if something unexpected happened?

> @vicente-romero-oracle Thanks for your review.
> 
> In this test, if the bug is not fixed which means the `aload_2` would be `aload_1`, the code runs well too.
> The `aload_1` or `aload_2` don't effect the result so that we can't check it by executing it.
> There are some similar situations in the past when we want to verify the class files.
> These tests would also fail if we change the logic of the code generation.
> 
> Another way is that only verify if the `aload_2` is at the right place instead of verify all the instruments.
> But it also need to be revisited and revised if the logic of the code generation is changed in the future.
> It seems a unavoidable issue about verifing the class files.

I see, thanks for the clarification

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

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

From duke at openjdk.java.net  Thu Jun 24 23:03:08 2021
From: duke at openjdk.java.net (duke)
Date: Thu, 24 Jun 2021 23:03:08 GMT
Subject: Withdrawn: 8173970: jar tool should have a way to extract to a
 directory
In-Reply-To: 
References: 
Message-ID: 

On Fri, 26 Feb 2021 17:03:11 GMT, Jaikiran Pai  wrote:

> Can I please get a review for this patch which proposes to implement the enhancement request noted in https://bugs.openjdk.java.net/browse/JDK-8173970?
> 
> The commit in this PR introduces the `-o` and `--output-dir` option to the `jar` command. The option takes a path to a destination directory as a value and extracts the contents of the jar into that directory. This is an optional option and the changes in the commit continue to maintain backward compatibility where the jar is extracted into current directory, if no `-o` or `--output-dir` option has been specified.
> 
> As far as I know, there hasn't been any discussion on what the name of this new option should be. I was initially thinking of using `-d` but that is currently used by the `jar` command for a different purpose. So I decided to use `-o` and `--output-dir`. This is of course open for change depending on any suggestions in this PR.
> 
> The commit in this PR also updates the `jar.properties` file which contains the English version of the jar command's `--help` output. However, no changes have been done to the internationalization files corresponding to this one (for example: `jar_de.properties`), because I don't know what process needs to be followed to have those files updated (if at all they need to be updated).
> 
> The commit also includes a jtreg testcase which verifies the usage of this new option.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.java.net/jdk/pull/2752

From gli at openjdk.java.net  Thu Jun 24 23:12:12 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Thu, 24 Jun 2021 23:12:12 GMT
Subject: [jdk17] RFR: 8267610: NPE at at
 jdk.compiler/com.sun.tools.javac.jvm.Code.emitop
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 23 Jun 2021 15:48:04 GMT, Jan Lahoda  wrote:

>> Hi all,
>> 
>> Currently, the class TransPatterns sometimes doesn't transform the `pattern variables` and `pattern symbols` to the normal variables and symbols, especially the places where the pattern variables are used.
>> The following phases, such as LambdaToMethod, Lower and Gen, may crash or generate some wrong results.
>> 
>> The known issues are [JDK-8267610](https://bugs.openjdk.java.net/browse/JDK-8267610) and [JDK-8268748](https://bugs.openjdk.java.net/browse/JDK-8268748).
>> 
>> **JDK-8267610 is an issue that pattern symbol causes the compiler to crash.**
>> 
>> During transforming the InstanceOfTree (JCInstanceOf) , the `BindingSymbol`  instead of the `VarSymbol` is used to make the new `JCIdent` and `JCBinary` trees. At the phase LambdaToMethod, the compiler can't capture this variable so that the lambda method has uncorrect parameters. So at the phase Gen, the compiler crashes because of NPE.
>> 
>> **JDK-8268748 is an issue that pattern symbol causes that the compiler generates wrong bytecodes.**
>> 
>> When transforming the BindingPatternTree (JCBindingPattern), the `BindingSymbol` is also handled uncorrectly and used to make the new `JCIdent` and `JCAssign` trees. At the phase Gen, the compiler find the wrong variables, so that the wrong bytecodes are generated.
>> 
>> These two issues are similar and influence each other. So I solve them at one patch.
>> The lines 208-212 are to solve JDK-8267610 with the test `LambdaCannotCapturePatternVariables`. 
>> The lines 233-239 are to solve JDK-8268748 with the test `NestedPatternVariablesBytecode`.
>> 
>> If lines 208-212 are not included, the test  `NestedPatternVariablesBytecode` can't pass. 
>> If lines 233-239 are not included, the test `LambdaCannotCapturePatternVariables` can't pass. 
>> So I put them together.
>> 
>> Thanks for taking the time to review.
>> 
>> Best Regards,
>> -- Guoxiong.
>
> Do you have details on what goes wrong when the `currentValue` is set after translating the expression? Looking into the code, I am not sure what that should break, and I ran existing tests and none seem to fail. So I wonder where it fails. Thanks!

Thanks @lahodaj @vicente-romero-oracle for the review.

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

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

From gli at openjdk.java.net  Thu Jun 24 23:12:15 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Thu, 24 Jun 2021 23:12:15 GMT
Subject: [jdk17] Integrated: 8267610: NPE at at
 jdk.compiler/com.sun.tools.javac.jvm.Code.emitop
In-Reply-To: 
References: 
Message-ID: 

On Tue, 15 Jun 2021 15:05:40 GMT, Guoxiong Li  wrote:

> Hi all,
> 
> Currently, the class TransPatterns sometimes doesn't transform the `pattern variables` and `pattern symbols` to the normal variables and symbols, especially the places where the pattern variables are used.
> The following phases, such as LambdaToMethod, Lower and Gen, may crash or generate some wrong results.
> 
> The known issues are [JDK-8267610](https://bugs.openjdk.java.net/browse/JDK-8267610) and [JDK-8268748](https://bugs.openjdk.java.net/browse/JDK-8268748).
> 
> **JDK-8267610 is an issue that pattern symbol causes the compiler to crash.**
> 
> During transforming the InstanceOfTree (JCInstanceOf) , the `BindingSymbol`  instead of the `VarSymbol` is used to make the new `JCIdent` and `JCBinary` trees. At the phase LambdaToMethod, the compiler can't capture this variable so that the lambda method has uncorrect parameters. So at the phase Gen, the compiler crashes because of NPE.
> 
> **JDK-8268748 is an issue that pattern symbol causes that the compiler generates wrong bytecodes.**
> 
> When transforming the BindingPatternTree (JCBindingPattern), the `BindingSymbol` is also handled uncorrectly and used to make the new `JCIdent` and `JCAssign` trees. At the phase Gen, the compiler find the wrong variables, so that the wrong bytecodes are generated.
> 
> These two issues are similar and influence each other. So I solve them at one patch.
> The lines 208-212 are to solve JDK-8267610 with the test `LambdaCannotCapturePatternVariables`. 
> The lines 233-239 are to solve JDK-8268748 with the test `NestedPatternVariablesBytecode`.
> 
> If lines 208-212 are not included, the test  `NestedPatternVariablesBytecode` can't pass. 
> If lines 233-239 are not included, the test `LambdaCannotCapturePatternVariables` can't pass. 
> So I put them together.
> 
> Thanks for taking the time to review.
> 
> Best Regards,
> -- Guoxiong.

This pull request has now been integrated.

Changeset: 7ab12856
Author:    Guoxiong Li 
URL:       https://git.openjdk.java.net/jdk17/commit/7ab12856c4b914a2f7b7de3cd4963598aab0f330
Stats:     191 lines in 3 files changed: 189 ins; 2 del; 0 mod

8267610: NPE at at jdk.compiler/com.sun.tools.javac.jvm.Code.emitop
8268748: Javac generates uncorrect bytecodes when using nested pattern variables

Reviewed-by: jlahoda, vromero

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

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

From jjg at openjdk.java.net  Fri Jun 25 00:16:05 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Fri, 25 Jun 2021 00:16:05 GMT
Subject: RFR: 8248843: java in source-file mode suggests javac-only options
In-Reply-To: <8NKQP6iQM2BZ6BdJucN3wVFokZeO5bPIp8u19oE98sI=.22615f9d-bde2-4e70-9ff8-37b150b390ec@github.com>
References: <8NKQP6iQM2BZ6BdJucN3wVFokZeO5bPIp8u19oE98sI=.22615f9d-bde2-4e70-9ff8-37b150b390ec@github.com>
Message-ID: 

On Tue, 18 May 2021 14:09:07 GMT, Adam Sotona  wrote:

> `java` in source-file mode (see JEP 330) displays compiler notes suggesting `recompile with -Xdiags:verbose to get full output`. According JEP 330 these advanced `javac` optionns are not allowed. The goal with JEP 330 was to support developers that are at the early stages of learning Java, so options such as `-Xdiags:verbose` are out of their scope.
> 
> This patch prevents displaying `Note: Some messages have been simplified; recompile with -Xdiags:verbose to get full output` suggestion in `java` source-file mode by implicitly enabling `-Xdiags:verbose` in com.sun.tool.javac.launcher.Main for all invocations.
> 
> Beside avoiding prohibited `javac` option suggestion notes this patch has positive effect of more verbose compilation diagnostic. Higher diagnostic verbosity is appreciated by users learning Java on single-source programs in `java` source-file mode.

A test would have been nice.

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

PR: https://git.openjdk.java.net/jdk/pull/4094

From jlahoda at openjdk.java.net  Fri Jun 25 09:55:06 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Fri, 25 Jun 2021 09:55:06 GMT
Subject: [jdk17] Integrated: 8268871: Adjust javac to updated exhaustiveness
 specification
In-Reply-To: 
References: 
Message-ID: 

On Wed, 16 Jun 2021 12:47:22 GMT, Jan Lahoda  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.

This pull request has now been integrated.

Changeset: 4eb32129
Author:    Jan Lahoda 
URL:       https://git.openjdk.java.net/jdk17/commit/4eb321298a1abf6b24bd9515c5c0c3580b2f31f7
Stats:     350 lines in 2 files changed: 276 ins; 62 del; 12 mod

8268871: Adjust javac to updated exhaustiveness specification

Reviewed-by: vromero

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

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

From jlahoda at openjdk.java.net  Fri Jun 25 11:48:11 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Fri, 25 Jun 2021 11:48:11 GMT
Subject: RFR: 8268320: Better error recovery for broken patterns in switch
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 10 Jun 2021 09:59:44 GMT, R?mi Forax  wrote:

>> Trying to improve error recovery in case the user wanted to use a type-pattern in the switch construct, but didn't put a binding variable name after the type name. E.g.:
>> 
>> $ cat test/langtools/tools/javac/diags/examples/PatternExpected.java
>> [snip]
>> class PatternSwitch {
>>     private void doSwitch(Object o) {
>>         switch (o) {
>>             case String: break;
>>             default: break;
>>         }
>>     }
>> }
>> $ javac --enable-preview -source 17  test/langtools/tools/javac/diags/examples/PatternExpected.java
>> test/langtools/tools/javac/diags/examples/PatternExpected.java:32: error: type pattern expected
>>             case String: break;
>>                  ^
>> Note: test/langtools/tools/javac/diags/examples/PatternExpected.java uses preview features of Java SE 17.
>> Note: Recompile with -Xlint:preview for details.
>> 1 error
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1748:
> 
>> 1746:                                     }
>> 1747:                                 } else if (!stringSwitch && !types.isAssignable(seltype, syms.intType)) {
>> 1748:                                     log.error(pat.pos(), Errors.ConstantLabelNotCompatible(pattype, seltype));
> 
> I wonder if in the long term it's not better instead of having several ad-hoc way to find the kind of switch it is,
> `types.isAssignable(seltype, syms.intType)`, `stringSwitch` or `pattype.constValue() == null && s.kind == TYP`
> to have an enum with 4 values INT_SWITCH, STRING_SWITCH, ENUM_SWITCH and PATTERN_SWITCH.

I apologize for a belated answer. It is my plan to try to categorize switches, but when considering error recovery and various desugaring stages, it is not trivial. Also, please note that some of the conditions are not a property of the switch, but rather a property of the case (like in this case - saying `case String:` instead of `case String s:` is more a property of the case, than the switch.

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

PR: https://git.openjdk.java.net/jdk/pull/4441

From jlahoda at openjdk.java.net  Fri Jun 25 11:48:12 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Fri, 25 Jun 2021 11:48:12 GMT
Subject: RFR: 8268320: Better error recovery for broken patterns in switch
In-Reply-To: <_RD5Apgv1UJOjG9CWPt7otwidS45kW2gLfq8q5XQ5uk=.333bdd78-7a27-403a-b3dd-d2aa6f820381@github.com>
References: 
 <_RD5Apgv1UJOjG9CWPt7otwidS45kW2gLfq8q5XQ5uk=.333bdd78-7a27-403a-b3dd-d2aa6f820381@github.com>
Message-ID: 

On Thu, 10 Jun 2021 15:41:36 GMT, Vicente Romero  wrote:

>> Trying to improve error recovery in case the user wanted to use a type-pattern in the switch construct, but didn't put a binding variable name after the type name. E.g.:
>> 
>> $ cat test/langtools/tools/javac/diags/examples/PatternExpected.java
>> [snip]
>> class PatternSwitch {
>>     private void doSwitch(Object o) {
>>         switch (o) {
>>             case String: break;
>>             default: break;
>>         }
>>     }
>> }
>> $ javac --enable-preview -source 17  test/langtools/tools/javac/diags/examples/PatternExpected.java
>> test/langtools/tools/javac/diags/examples/PatternExpected.java:32: error: type pattern expected
>>             case String: break;
>>                  ^
>> Note: test/langtools/tools/javac/diags/examples/PatternExpected.java uses preview features of Java SE 17.
>> Note: Recompile with -Xlint:preview for details.
>> 1 error
>
> test/langtools/tools/javac/patterns/SwitchErrors-no-preview.out line 1:
> 
>> 1: SwitchErrors.java:35:31: compiler.err.preview.feature.disabled.plural: (compiler.misc.feature.pattern.switch)
> 
> I don't get why you want to test what happens when the `--enable-preview + source` options are not passed

I apologize for a belated answer. The idea to test what happens when preview is disabled is that the error recovery messages are different. The error message won't suggest to use a pattern when pattern matching in switch is not enabled. That may or may not be the ideal behavior, but it seemed prudent to verify that behavior. I can split it into a separate test case, to make that more obvious, if desired.

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

PR: https://git.openjdk.java.net/jdk/pull/4441

From forax at openjdk.java.net  Fri Jun 25 12:21:08 2021
From: forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Fri, 25 Jun 2021 12:21:08 GMT
Subject: RFR: 8268320: Better error recovery for broken patterns in switch
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 25 Jun 2021 11:42:59 GMT, Jan Lahoda  wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1748:
>> 
>>> 1746:                                     }
>>> 1747:                                 } else if (!stringSwitch && !types.isAssignable(seltype, syms.intType)) {
>>> 1748:                                     log.error(pat.pos(), Errors.ConstantLabelNotCompatible(pattype, seltype));
>> 
>> I wonder if in the long term it's not better instead of having several ad-hoc way to find the kind of switch it is,
>> `types.isAssignable(seltype, syms.intType)`, `stringSwitch` or `pattype.constValue() == null && s.kind == TYP`
>> to have an enum with 4 values INT_SWITCH, STRING_SWITCH, ENUM_SWITCH and PATTERN_SWITCH.
>
> I apologize for a belated answer. It is my plan to try to categorize switches, but when considering error recovery and various desugaring stages, it is not trivial. Also, please note that some of the conditions are not a property of the switch, but rather a property of the case (like in this case - saying `case String:` instead of `case String s:` is more a property of the case, than the switch.

Yes, it's not trivial, and it's not for that PR, but it's usually a good idea in a compiler to have such kind of canonical representation because it avoid bugs between different passes that does those checks in various non compatible ways. Especially when you have different desugaring stages.

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

PR: https://git.openjdk.java.net/jdk/pull/4441

From jlahoda at openjdk.java.net  Fri Jun 25 13:02:04 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Fri, 25 Jun 2021 13:02:04 GMT
Subject: RFR: 8268320: Better error recovery for broken patterns in switch
In-Reply-To: 
References: 
Message-ID: 

On Wed, 9 Jun 2021 19:50:00 GMT, Jan Lahoda  wrote:

> Trying to improve error recovery in case the user wanted to use a type-pattern in the switch construct, but didn't put a binding variable name after the type name. E.g.:
> 
> $ cat test/langtools/tools/javac/diags/examples/PatternExpected.java
> [snip]
> class PatternSwitch {
>     private void doSwitch(Object o) {
>         switch (o) {
>             case String: break;
>             default: break;
>         }
>     }
> }
> $ javac --enable-preview -source 17  test/langtools/tools/javac/diags/examples/PatternExpected.java
> test/langtools/tools/javac/diags/examples/PatternExpected.java:32: error: type pattern expected
>             case String: break;
>                  ^
> Note: test/langtools/tools/javac/diags/examples/PatternExpected.java uses preview features of Java SE 17.
> Note: Recompile with -Xlint:preview for details.
> 1 error

Transferred to openjdk/jdk17 as:
https://github.com/openjdk/jdk17/pull/146

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

PR: https://git.openjdk.java.net/jdk/pull/4441

From jlahoda at openjdk.java.net  Fri Jun 25 13:02:04 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Fri, 25 Jun 2021 13:02:04 GMT
Subject: Withdrawn: 8268320: Better error recovery for broken patterns in
 switch
In-Reply-To: 
References: 
Message-ID: 

On Wed, 9 Jun 2021 19:50:00 GMT, Jan Lahoda  wrote:

> Trying to improve error recovery in case the user wanted to use a type-pattern in the switch construct, but didn't put a binding variable name after the type name. E.g.:
> 
> $ cat test/langtools/tools/javac/diags/examples/PatternExpected.java
> [snip]
> class PatternSwitch {
>     private void doSwitch(Object o) {
>         switch (o) {
>             case String: break;
>             default: break;
>         }
>     }
> }
> $ javac --enable-preview -source 17  test/langtools/tools/javac/diags/examples/PatternExpected.java
> test/langtools/tools/javac/diags/examples/PatternExpected.java:32: error: type pattern expected
>             case String: break;
>                  ^
> Note: test/langtools/tools/javac/diags/examples/PatternExpected.java uses preview features of Java SE 17.
> Note: Recompile with -Xlint:preview for details.
> 1 error

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.java.net/jdk/pull/4441

From jlahoda at openjdk.java.net  Fri Jun 25 13:06:22 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Fri, 25 Jun 2021 13:06:22 GMT
Subject: [jdk17] RFR: 8268320: Better error recovery for broken patterns in
 switch
Message-ID: 

[a copy of https://github.com/openjdk/jdk/pull/4441 for JDK 17]

Trying to improve error recovery in case the user wanted to use a type-pattern in the switch construct, but didn't put a binding variable name after the type name. E.g.:

$ cat test/langtools/tools/javac/diags/examples/PatternExpected.java
[snip]
class PatternSwitch {
    private void doSwitch(Object o) {
        switch (o) {
            case String: break;
            default: break;
        }
    }
}
$ javac --enable-preview -source 17  test/langtools/tools/javac/diags/examples/PatternExpected.java
test/langtools/tools/javac/diags/examples/PatternExpected.java:32: error: type pattern expected
            case String: break;
                 ^
Note: test/langtools/tools/javac/diags/examples/PatternExpected.java uses preview features of Java SE 17.
Note: Recompile with -Xlint:preview for details.
1 error

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

Commit messages:
 - Merging master into JDK-8268320
 - 8268320: Better error recovery for broken patterns in switch

Changes: https://git.openjdk.java.net/jdk17/pull/146/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=146&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8268320
  Stats: 162 lines in 7 files changed: 110 ins; 3 del; 49 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/146.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/146/head:pull/146

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

From jlahoda at openjdk.java.net  Fri Jun 25 13:40:30 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Fri, 25 Jun 2021 13:40:30 GMT
Subject: [jdk17] RFR: 8268320: Better error recovery for broken patterns
 in switch [v2]
In-Reply-To: 
References: 
Message-ID: <2QZoOypR1Pp9-XHni-zW1J4CPZ7sfRwKhextuyPy2WA=.19a66a24-03df-44cb-a9ae-62e75fafeb8c@github.com>

> [a copy of https://github.com/openjdk/jdk/pull/4441 for JDK 17]
> 
> Trying to improve error recovery in case the user wanted to use a type-pattern in the switch construct, but didn't put a binding variable name after the type name. E.g.:
> 
> $ cat test/langtools/tools/javac/diags/examples/PatternExpected.java
> [snip]
> class PatternSwitch {
>     private void doSwitch(Object o) {
>         switch (o) {
>             case String: break;
>             default: break;
>         }
>     }
> }
> $ javac --enable-preview -source 17  test/langtools/tools/javac/diags/examples/PatternExpected.java
> test/langtools/tools/javac/diags/examples/PatternExpected.java:32: error: type pattern expected
>             case String: break;
>                  ^
> Note: test/langtools/tools/javac/diags/examples/PatternExpected.java uses preview features of Java SE 17.
> Note: Recompile with -Xlint:preview for details.
> 1 error

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Fixing output.

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

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/146/files
  - new: https://git.openjdk.java.net/jdk17/pull/146/files/f8264177..bf7a7109

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=146&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=146&range=00-01

  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/146.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/146/head:pull/146

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

From jlahoda at openjdk.java.net  Fri Jun 25 14:53:10 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Fri, 25 Jun 2021 14:53:10 GMT
Subject: [jdk17] RFR: 8269354: javac crashes when processing parenthesized
 pattern in instanceof
Message-ID: 

When having code like:

if (o instanceof String s) {
     System.err.println(s);
}


`javac` needs to hoist the `s` binding variable out of the `if` statement. This is done through `BindingContext` in `TransPatterns`. Sometimes, there is no statement out of which the variable would need to be hoisted, like:

boolean b = o instanceof String s && !s.isEmpty();


so some expressions (`&&` in the example) also serve as a place where the binding variables can be hoisted. With the addition of parenthesized and guarded patterns, the `instanceof` expression needs to be one of such expressions so that in expressions like:

boolean b = o instanceof (String s && !s.isEmpty());


the `s.isEmpty()` uses the correct translated/hoisted variable.

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

Commit messages:
 - 8269354: javac crashes when processing parenthesized pattern in instanceof

Changes: https://git.openjdk.java.net/jdk17/pull/147/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=147&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8269354
  Stats: 14 lines in 2 files changed: 7 ins; 0 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/147.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/147/head:pull/147

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

From vromero at openjdk.java.net  Fri Jun 25 15:35:05 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Fri, 25 Jun 2021 15:35:05 GMT
Subject: RFR: 8261006: 'super' qualified method references cannot occur in
 a static context
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 24 Jun 2021 05:19:58 GMT, Srikanth Adayapalam  wrote:

> Also this test case:
> 
> ```
> import java.util.function.Supplier;
> 
> public class X {
> 
>     interface Feature {
>         default String getString() {
>             return "Hello World";
>         }
>     }
> 
>     private static class Broken implements Feature {
>         private final String sString;
> 
>         public Broken() {
>             this(Feature.super.getString());
>         }
> 
>         public Broken(String sString) {
>             this.sString = sString;
>         }
>     }
> }
> ```
> 
> compiles both with JDK16 and your patch.
> 
> Should we actually compile it ???

my patch is focusing on `super` qualified method references this example won't stress my code, and it is correct to be accepted anyway as the method being invoked is `static`

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

PR: https://git.openjdk.java.net/jdk/pull/4376

From vromero at openjdk.java.net  Fri Jun 25 15:39:06 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Fri, 25 Jun 2021 15:39:06 GMT
Subject: RFR: 8261006: 'super' qualified method references cannot occur in
 a static context
In-Reply-To: <_xl7tZE53QavW5SaVdysWMztPnurioMY5MkH6r-3I1k=.05c40826-eee8-445c-8ccf-dea976c873a5@github.com>
References: 
 <_xl7tZE53QavW5SaVdysWMztPnurioMY5MkH6r-3I1k=.05c40826-eee8-445c-8ccf-dea976c873a5@github.com>
Message-ID: 

On Thu, 24 Jun 2021 04:14:07 GMT, Srikanth Adayapalam  wrote:

> Do we need to invent a new diagnostics for this ?
> 
> I think it is better to check why we fail to issue the existing diagnostic compiler.err.non-static.cant.be.ref for the test case in question.
> 
> See that in the following simple test case:
> 
> ```
> public class X {
>     interface I {
>         int doit();
>     }
>     void foo() {
>         I i = super::hashCode; // OK.
>     }
>     static void goo() {
>         I i = super::hashCode; // Error
>     }
> ```
> 
> JDK16 does report correctly:
> 
> X.java:9: error: non-static variable super cannot be referenced from a static context
> I i = super::hashCode; // Error
> ^
> 1 error

right I could reuse one of the already existing error messages but given that the spec explicitly mentions the case of `super` qualified method references, my thinking is that there could be a explicit error message for that case, just to give users a better idea of what is wrong and why

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

PR: https://git.openjdk.java.net/jdk/pull/4376

From psandoz at openjdk.java.net  Fri Jun 25 16:02:03 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Fri, 25 Jun 2021 16:02:03 GMT
Subject: [jdk17] RFR: 8268766: Desugaring of pattern matching enum switch
 should be improved [v5]
In-Reply-To: 
References: <3xKa946t0s_eRqnj0vfgjkfurBvZqKGe1QkYk-0lNO0=.518519f5-a2cb-44ed-946c-09e517e7c5d2@github.com>
 
Message-ID: 

On Wed, 23 Jun 2021 11:58:06 GMT, Jan Lahoda  wrote:

>> Currently, an enum switch with patterns is desugared in a very non-standard, and potentially slow, way. It would be better to use the standard `typeSwitch` bootstrap to classify the enum constants. The bootstrap needs to accept enum constants as labels in order to allow this. A complication is that if an enum constant is missing, that is not an incompatible change for the switch, and the switch should simply work as if the case for the missing constant didn't exist. So, the proposed solution is to have a new bootstrap `enumSwitch` that accepts `String`s in place of the enum constants, and will internally convert them to the appropriate enum constants, and then it will find the proper case similarly to `typeSwitch`.
>> 
>> How does this look?
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improving javadoc.

Bootstrap method looks. At first i thought why not let the class label just be an actual `Class.class` instance, signaling that target enum class should be used, but then thought perhaps it's better to be more literal: clarity of inputs, unlikely label lists will be shared, and further it might be easier to adapt them.

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 227:

> 225:                                       String invocationName,
> 226:                                       MethodType invocationType,
> 227:                                       Object... labels) throws NullPointerException,

I don't think there are any benefits to declaring the runtime exceptions in the method declaration.

Other bootstrap methods declare a checked exception when certain linkage constraints are violated (and the line between whats an `IllegalArgumentException` or an explicit linkage checked exception can be blurry). In your case, given the simplicity i think what you have is ok. We could refine later with a specific checked exception for switch linkage violations.

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 256:

> 254:         if (labelClass == Class.class) {
> 255:             if (label != enumClassTemplate) {
> 256:                 throw new IllegalArgumentException("illegal Class label: " + label);

Can we refine the message to state the class label is not equal to the enum class that is the target of the switch? LIkewise in the `else` block to state the label is not of class String or the target enum class.

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

Marked as reviewed by psandoz (Reviewer).

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

From vromero at openjdk.java.net  Fri Jun 25 17:08:39 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Fri, 25 Jun 2021 17:08:39 GMT
Subject: RFR: 8261006: 'super' qualified method references cannot occur in
 a static context [v2]
In-Reply-To: 
References: 
Message-ID: 

> Please review this PR, currently javac is accepting code like:
> 
> 
> import java.util.function.Supplier;
> 
> public class MethodReferenceInConstructorInvocation {
>     interface Bar {
>         default String getString() { return ""; }
>     }
> 
>     static class Foo implements Bar {
>         public Foo() {  this(Bar.super::getString);  }
>         public Foo(Supplier sString) {}
>     }
> }
> 
> 
> but the spec states in `15.13 Method Reference Expressions`:
> 
> If a method reference expression has the form super :: [TypeArguments] Identifier
> or TypeName . super :: [TypeArguments] Identifier, it is a compile-time error if
> the expression occurs in a static context (?8.1.3).
> 
> and a constructor invocation is a static context. So method references of this form, qualified by `super`, should be rejected by the compiler if they appear in a static context.
> 
> TIA

Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:

 - Merge branch 'master' into JDK-8261006
 - 8261006: fail to parse broken interface::method in lambda

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4376/files
  - new: https://git.openjdk.java.net/jdk/pull/4376/files/f320647e..7dfe9271

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4376&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4376&range=00-01

  Stats: 508480 lines in 1645 files changed: 478594 ins; 23029 del; 6857 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4376.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4376/head:pull/4376

PR: https://git.openjdk.java.net/jdk/pull/4376

From alex.buckley at oracle.com  Fri Jun 25 19:04:34 2021
From: alex.buckley at oracle.com (Alex Buckley)
Date: Fri, 25 Jun 2021 12:04:34 -0700
Subject: JDK-8254073, unicode escape preprocessing, and \u005C
In-Reply-To: <2feaea08-2217-a094-93ef-fc519cab793e@oracle.com>
References: 
 <86DC9BD0-1DDB-40D8-A46D-43A9C72EBFA9@oracle.com>
 <86520066-93a7-d24e-c86e-e9dda6b9bc9b@oracle.com>
 <2feaea08-2217-a094-93ef-fc519cab793e@oracle.com>
Message-ID: 

I filed https://bugs.openjdk.java.net/browse/JDK-8269406 with some 
additional discussion about what the result of the first lexical 
translation step is really meant to be.

Please take a look if you are familiar with the three-step translation 
described in JLS 3.2, and care about how the input stream is processed.

Alex

On 6/22/2021 10:38 AM, Alex Buckley wrote:
> I am minded to extend the final note in JLS 3.3 to help people 
> understand the multi-level escape story in play when they experiment 
> with Unicode escapes. Perhaps it will also improve some javac error 
> messages or test cases. Let me know what you think of this:
> 
> -----
> For example, the input stream \u005cu005a results in the six characters 
> \ u 0 0 5 a, because 005c is the Unicode value for \. It does not result 
> in the character Z, which is Unicode character 005a, because the \ that 
> resulted from the \u005c is not interpreted as the start of a further 
> Unicode escape.
> 
> Note that \u005cu005a cannot be written in a string literal to denote 
> the six characters \ u 0 0 5 a. This is because the first two characters 
> resulting from translation, \ and u, are interpreted in a string literal 
> as an illegal escape sequence (3.10.7).
> 
> Fortunately, the rule about contiguous \ characters helps programmers to 
> craft input streams that denote Unicode escapes in a string literal. 
> Denoting the six characters \ u 0 0 5 a in a string literal simply 
> requires another \ to be written adjacent to the existing \, such as in 
> "Z is \\u005a". This works because the second \ in the input stream 
> \\u005a is not eligible, so the first \ and second \ are preserved as 
> raw input characters; they are subsequently interpreted in a string 
> literal as the escape sequence for a backslash, resulting in the desired 
> six characters \ u 0 0 5 a. Without the rule, the input stream \\u005a 
> would be translated as the raw input character \ followed by the Unicode 
> escape \u005a (Z), but \Z is an illegal escape sequence in a string 
> literal.
> 
> The rule also allows programmers to craft input streams that denote 
> escape sequences in a string literal. For example, the input stream 
> \\\u006e results in the three characters \ \ n because the third \ is 
> eligible and thus \u006e is translated to n, while the first \ and 
> second \ are preserved as raw input characters. The three characters \ \ 
> n are subsequently interpreted in a string literal as \ n which denotes 
> the escape sequence for a linefeed. (The input stream \\\u006e may also 
> be written as \u005c\u005c\u006e.)
> -----
> 
> Alex
> 
> On 6/21/2021 4:41 PM, Alex Buckley wrote:
>> There's no question that the first six raw input characters \ u 0 0 5 
>> c are identified as a Unicode escape \u005c and translated to a 
>> backslash.
>>
>> The question is whether that backslash is then treated as:
>>
>> 1. a raw input character \ that is followed by seven more raw input 
>> characters \ \ u 0 0 5 d?? For these *eight* raw input characters, 
>> there are three raw input character \'s in a row. Due to contiguous-\ 
>> counting, the third raw input character \ is eligible to begin a 
>> Unicode escape; the first and second pass through and you get \ \ ] 
>> which further translates within a string literal as \]
>>
>> or
>>
>> 2. something which is independent of the subsequent seven raw input 
>> characters \ \ u 0 0 5 d?? For those *seven* subsequent raw input 
>> characters, there are two raw input character \'s in a row. Due to 
>> contiguous-\ counting, the second raw input character \ is not 
>> eligible to begin a Unicode escape, so all seven raw input characters 
>> pass through. You get (including the first "independent" backslash) \ 
>> \ \ u 0 0 5 d
>>
>>
>> The contiguous-\ counting is due to the fact that \\ is the escape 
>> sequence for backslash in a string literal, so we don't want too many 
>> raw \ input character to "disappear" into Unicode escapes.
>>
>>
>> The JDK 15 behavior was #1. That looks correct to me. \ u 0 0 5 c 
>> becomes a raw input character \ that cannot serve as the opening 
>> backslash for an *immediate* Unicode escape (the classic JLS 3.3 
>> scenario of \u005cu005a) but that can serve as a raw input character 
>> for the purpose of skipping over \\ pairs (the purpose of contiguous-\ 
>> counting) in order for a *later* Unicode escape to be recognized 
>> (\u005d).
>>
>>> Does "how many other \ characters contiguously precede it" refer to
>>> preceding raw input characters, or does it refer to preceding
>>> characters after unicode escape processing is performed on them?
>>
>> Where JLS 3.3 says "translating the ASCII characters \u followed by 
>> four hexadecimal digits to the UTF-16 code unit (?3.1) for the 
>> indicated hexadecimal value", it really means "translating the ASCII 
>> characters \u followed by four hexadecimal digits to *a raw input 
>> character which denotes* the UTF-16 code unit (?3.1) for the indicated 
>> hexadecimal value".
>>
>> Thus, the later clause "for each raw input character that is a 
>> backslash \, input processing must consider how many other [raw input] 
>> \ characters contiguously precede it" can be seen more easily to 
>> include characters that result from Unicode escape processing.
>>
>> Alex
>>
>> On 6/21/2021 2:56 PM, Jim Laskey wrote:
>>> "\u005C? should have been treated as a backslash. Will check into it.
>>>
>>> Cheers,
>>>
>>> ? Jim
>>>
>>> ??
>>>
>>>> On Jun 21, 2021, at 6:28 PM, Liam Miller-Cushon  
>>>> wrote:
>>>>
>>>> ?
>>>> class T {
>>>> ?? public static void main(String[] args) {
>>>> ???? System.err.println("\u005C\\u005D");
>>>> ?? }
>>>> }
>>>>
>>>> Before JDK-8254073, this prints `\]`.
>>>>
>>>> After JDK-8254073, unicode escape processing results in `\\\u005D`, 
>>>> which results in an 'invalid escape' error for `\u`. Was that 
>>>> deliberate?
>>>>
>>>> JLS 3.3 says
>>>>
>>>>> for each raw input character that is a backslash \, input 
>>>>> processing must consider how many other \ characters contiguously 
>>>>> precede it, separating it from a non-\ character or the start of 
>>>>> the input stream. If this number is even, then the \ is eligible to 
>>>>> begin a Unicode escape; if the number is odd, then the \ is not 
>>>>> eligible to begin a Unicode escape.
>>>>
>>>> The difference is in whether `\u005C` (the unicode escape for `\`) 
>>>> counts as one of the `\` preceding a valid unicode escape.
>>>>
>>>> Does "how many other \ characters contiguously precede it" refer to 
>>>> preceding raw input characters, or does it refer to preceding 
>>>> characters after unicode escape processing is performed on them?
>>>>
>>>> JLS 3.3 also mentions that a "character produced by a Unicode escape 
>>>> does not participate in further Unicode escapes", but I'm not sure 
>>>> if that applies here, since in the pre-JDK-8254073 interpretation 
>>>> the unicode-escaped backslash isn't really 'participating' in the 
>>>> second unicode escape.
>>>>
>>>> Thanks,
>>>> Liam

From john.r.rose at oracle.com  Fri Jun 25 19:29:44 2021
From: john.r.rose at oracle.com (John Rose)
Date: Fri, 25 Jun 2021 19:29:44 +0000
Subject: JDK-8254073, unicode escape preprocessing, and \u005C
In-Reply-To: 
References: 
 <86DC9BD0-1DDB-40D8-A46D-43A9C72EBFA9@oracle.com>
 <86520066-93a7-d24e-c86e-e9dda6b9bc9b@oracle.com>
 <2feaea08-2217-a094-93ef-fc519cab793e@oracle.com>
 
Message-ID: 

I added a comment.  I think it?s useful (in a non-normative way)
for people to see some representative puzzlers.  This will, of course,
further motivate a warning from javac.

> On Jun 25, 2021, at 12:04 PM, Alex Buckley  wrote:
> 
> I filed https://bugs.openjdk.java.net/browse/JDK-8269406 with some additional discussion about what the result of the first lexical translation step is really meant to be.
> 
> Please take a look if you are familiar with the three-step translation described in JLS 3.2, and care about how the input stream is processed.
> 
> Alex
> 
> On 6/22/2021 10:38 AM, Alex Buckley wrote:
>> I am minded to extend the final note in JLS 3.3 to help people understand the multi-level escape story in play when they experiment with Unicode escapes. Perhaps it will also improve some javac error messages or test cases. Let me know what you think of this:
>> -----
>> For example, the input stream \u005cu005a results in the six characters \ u 0 0 5 a, because 005c is the Unicode value for \. It does not result in the character Z, which is Unicode character 005a, because the \ that resulted from the \u005c is not interpreted as the start of a further Unicode escape.
>> Note that \u005cu005a cannot be written in a string literal to denote the six characters \ u 0 0 5 a. This is because the first two characters resulting from translation, \ and u, are interpreted in a string literal as an illegal escape sequence (3.10.7).
>> Fortunately, the rule about contiguous \ characters helps programmers to craft input streams that denote Unicode escapes in a string literal. Denoting the six characters \ u 0 0 5 a in a string literal simply requires another \ to be written adjacent to the existing \, such as in "Z is \\u005a". This works because the second \ in the input stream \\u005a is not eligible, so the first \ and second \ are preserved as raw input characters; they are subsequently interpreted in a string literal as the escape sequence for a backslash, resulting in the desired six characters \ u 0 0 5 a. Without the rule, the input stream \\u005a would be translated as the raw input character \ followed by the Unicode escape \u005a (Z), but \Z is an illegal escape sequence in a string literal.
>> The rule also allows programmers to craft input streams that denote escape sequences in a string literal. For example, the input stream \\\u006e results in the three characters \ \ n because the third \ is eligible and thus \u006e is translated to n, while the first \ and second \ are preserved as raw input characters. The three characters \ \ n are subsequently interpreted in a string literal as \ n which denotes the escape sequence for a linefeed. (The input stream \\\u006e may also be written as \u005c\u005c\u006e.)
>> -----
>> Alex
>> On 6/21/2021 4:41 PM, Alex Buckley wrote:
>>> There's no question that the first six raw input characters \ u 0 0 5 c are identified as a Unicode escape \u005c and translated to a backslash.
>>> 
>>> The question is whether that backslash is then treated as:
>>> 
>>> 1. a raw input character \ that is followed by seven more raw input characters \ \ u 0 0 5 d   For these *eight* raw input characters, there are three raw input character \'s in a row. Due to contiguous-\ counting, the third raw input character \ is eligible to begin a Unicode escape; the first and second pass through and you get \ \ ] which further translates within a string literal as \]
>>> 
>>> or
>>> 
>>> 2. something which is independent of the subsequent seven raw input characters \ \ u 0 0 5 d   For those *seven* subsequent raw input characters, there are two raw input character \'s in a row. Due to contiguous-\ counting, the second raw input character \ is not eligible to begin a Unicode escape, so all seven raw input characters pass through. You get (including the first "independent" backslash) \ \ \ u 0 0 5 d
>>> 
>>> 
>>> The contiguous-\ counting is due to the fact that \\ is the escape sequence for backslash in a string literal, so we don't want too many raw \ input character to "disappear" into Unicode escapes.
>>> 
>>> 
>>> The JDK 15 behavior was #1. That looks correct to me. \ u 0 0 5 c becomes a raw input character \ that cannot serve as the opening backslash for an *immediate* Unicode escape (the classic JLS 3.3 scenario of \u005cu005a) but that can serve as a raw input character for the purpose of skipping over \\ pairs (the purpose of contiguous-\ counting) in order for a *later* Unicode escape to be recognized (\u005d).
>>> 
>>>> Does "how many other \ characters contiguously precede it" refer to
>>>> preceding raw input characters, or does it refer to preceding
>>>> characters after unicode escape processing is performed on them?
>>> 
>>> Where JLS 3.3 says "translating the ASCII characters \u followed by four hexadecimal digits to the UTF-16 code unit (?3.1) for the indicated hexadecimal value", it really means "translating the ASCII characters \u followed by four hexadecimal digits to *a raw input character which denotes* the UTF-16 code unit (?3.1) for the indicated hexadecimal value".
>>> 
>>> Thus, the later clause "for each raw input character that is a backslash \, input processing must consider how many other [raw input] \ characters contiguously precede it" can be seen more easily to include characters that result from Unicode escape processing.
>>> 
>>> Alex
>>> 
>>> On 6/21/2021 2:56 PM, Jim Laskey wrote:
>>>> "\u005C? should have been treated as a backslash. Will check into it.
>>>> 
>>>> Cheers,
>>>> 
>>>> ? Jim
>>>> 
>>>> ??
>>>> 
>>>>> On Jun 21, 2021, at 6:28 PM, Liam Miller-Cushon  wrote:
>>>>> 
>>>>> ?
>>>>> class T {
>>>>>    public static void main(String[] args) {
>>>>>      System.err.println("\u005C\\u005D");
>>>>>    }
>>>>> }
>>>>> 
>>>>> Before JDK-8254073, this prints `\]`.
>>>>> 
>>>>> After JDK-8254073, unicode escape processing results in `\\\u005D`, which results in an 'invalid escape' error for `\u`. Was that deliberate?
>>>>> 
>>>>> JLS 3.3 says
>>>>> 
>>>>>> for each raw input character that is a backslash \, input processing must consider how many other \ characters contiguously precede it, separating it from a non-\ character or the start of the input stream. If this number is even, then the \ is eligible to begin a Unicode escape; if the number is odd, then the \ is not eligible to begin a Unicode escape.
>>>>> 
>>>>> The difference is in whether `\u005C` (the unicode escape for `\`) counts as one of the `\` preceding a valid unicode escape.
>>>>> 
>>>>> Does "how many other \ characters contiguously precede it" refer to preceding raw input characters, or does it refer to preceding characters after unicode escape processing is performed on them?
>>>>> 
>>>>> JLS 3.3 also mentions that a "character produced by a Unicode escape does not participate in further Unicode escapes", but I'm not sure if that applies here, since in the pre-JDK-8254073 interpretation the unicode-escaped backslash isn't really 'participating' in the second unicode escape.
>>>>> 
>>>>> Thanks,
>>>>> Liam


From vromero at openjdk.java.net  Sat Jun 26 02:18:25 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Sat, 26 Jun 2021 02:18:25 GMT
Subject: RFR: 8261006: 'super' qualified method references cannot occur in
 a static context [v3]
In-Reply-To: 
References: 
Message-ID: 

> Please review this PR, currently javac is accepting code like:
> 
> 
> import java.util.function.Supplier;
> 
> public class MethodReferenceInConstructorInvocation {
>     interface Bar {
>         default String getString() { return ""; }
>     }
> 
>     static class Foo implements Bar {
>         public Foo() {  this(Bar.super::getString);  }
>         public Foo(Supplier sString) {}
>     }
> }
> 
> 
> but the spec states in `15.13 Method Reference Expressions`:
> 
> If a method reference expression has the form super :: [TypeArguments] Identifier
> or TypeName . super :: [TypeArguments] Identifier, it is a compile-time error if
> the expression occurs in a static context (?8.1.3).
> 
> and a constructor invocation is a static context. So method references of this form, qualified by `super`, should be rejected by the compiler if they appear in a static context.
> 
> TIA

Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:

  addressing review comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4376/files
  - new: https://git.openjdk.java.net/jdk/pull/4376/files/7dfe9271..23bbeb43

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4376&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4376&range=01-02

  Stats: 13 lines in 4 files changed: 2 ins; 6 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4376.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4376/head:pull/4376

PR: https://git.openjdk.java.net/jdk/pull/4376

From vromero at openjdk.java.net  Sat Jun 26 02:23:26 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Sat, 26 Jun 2021 02:23:26 GMT
Subject: RFR: 8261006: 'super' qualified method references cannot occur in
 a static context
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 24 Jun 2021 05:19:58 GMT, Srikanth Adayapalam  wrote:

>> Please review this PR, currently javac is accepting code like:
>> 
>> 
>> import java.util.function.Supplier;
>> 
>> public class MethodReferenceInConstructorInvocation {
>>     interface Bar {
>>         default String getString() { return ""; }
>>     }
>> 
>>     static class Foo implements Bar {
>>         public Foo() {  this(Bar.super::getString);  }
>>         public Foo(Supplier sString) {}
>>     }
>> }
>> 
>> 
>> but the spec states in `15.13 Method Reference Expressions`:
>> 
>> If a method reference expression has the form super :: [TypeArguments] Identifier
>> or TypeName . super :: [TypeArguments] Identifier, it is a compile-time error if
>> the expression occurs in a static context (?8.1.3).
>> 
>> and a constructor invocation is a static context. So method references of this form, qualified by `super`, should be rejected by the compiler if they appear in a static context.
>> 
>> TIA
>
> Also this test case:
> 
> 
> import java.util.function.Supplier;
> 
> public class X {
> 
>     interface Feature {
>         default String getString() {
>             return "Hello World";
>         }
>     }
> 
>     private static class Broken implements Feature {
>         private final String sString;
> 
>         public Broken() {
>             this(Feature.super.getString());
>         }
> 
>         public Broken(String sString) {
>             this.sString = sString;
>         }
>     }
> }
> 
> 
> compiles both with JDK16 and your patch. 
> 
> Should we actually compile it ???

@sadayapalam, thanks for your comments, I have uploaded another iteration of the patch

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

PR: https://git.openjdk.java.net/jdk/pull/4376

From vromero at openjdk.java.net  Sat Jun 26 02:23:26 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Sat, 26 Jun 2021 02:23:26 GMT
Subject: RFR: 8261006: 'super' qualified method references cannot occur in
 a static context [v4]
In-Reply-To: 
References: 
Message-ID: 

> Please review this PR, currently javac is accepting code like:
> 
> 
> import java.util.function.Supplier;
> 
> public class MethodReferenceInConstructorInvocation {
>     interface Bar {
>         default String getString() { return ""; }
>     }
> 
>     static class Foo implements Bar {
>         public Foo() {  this(Bar.super::getString);  }
>         public Foo(Supplier sString) {}
>     }
> }
> 
> 
> but the spec states in `15.13 Method Reference Expressions`:
> 
> If a method reference expression has the form super :: [TypeArguments] Identifier
> or TypeName . super :: [TypeArguments] Identifier, it is a compile-time error if
> the expression occurs in a static context (?8.1.3).
> 
> and a constructor invocation is a static context. So method references of this form, qualified by `super`, should be rejected by the compiler if they appear in a static context.
> 
> TIA

Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:

  updating comment

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4376/files
  - new: https://git.openjdk.java.net/jdk/pull/4376/files/23bbeb43..a6056843

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4376&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4376&range=02-03

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4376.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4376/head:pull/4376

PR: https://git.openjdk.java.net/jdk/pull/4376

From jwilhelm at openjdk.java.net  Sun Jun 27 22:56:05 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Sun, 27 Jun 2021 22:56:05 GMT
Subject: Withdrawn: Merge jdk17
In-Reply-To: 
References: 
Message-ID: 

On Thu, 24 Jun 2021 00:36:38 GMT, Jesper Wilhelmsson  wrote:

> Forwardport JDK 17 -> JDK 18

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.java.net/jdk/pull/4579

From jwilhelm at openjdk.java.net  Sun Jun 27 23:14:43 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Sun, 27 Jun 2021 23:14:43 GMT
Subject: RFR: Merge jdk17
Message-ID: 

Forwardport JDK 17 -> JDK 18

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

Commit messages:
 - Merge
 - 8258746: illegal access to global field _jvmci_old_thread_counters by terminated thread causes crash
 - 8266269: Lookup::accessClass fails with IAE when accessing an arrayClass with a protected inner class as component class
 - 8269351: Proxy::newProxyInstance and MethodHandleProxies::asInterfaceInstance should reject sealed interfaces
 - 8269260: Add AVX512 and other SSE + AVX combinations testing for tests which generate vector instructions
 - 8269302: serviceability/dcmd/framework/InvalidCommandTest.java still fails after JDK-8268433
 - 8269036: tools/jpackage/share/AppImagePackageTest.java failed with "hdiutil: create failed - Resource busy"
 - 8269074: (fs) Files.copy fails to copy from /proc on some linux kernel versions
 - 8256919: BCEL: Utility.encode forget to close
 - 8269335: Unable to load svml library
 - ... and 20 more: https://git.openjdk.java.net/jdk/compare/8bed3534...2d9b73c0

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=4606&range=00.0
 - jdk17: https://webrevs.openjdk.java.net/?repo=jdk&pr=4606&range=00.1

Changes: https://git.openjdk.java.net/jdk/pull/4606/files
  Stats: 1925 lines in 90 files changed: 1452 ins; 227 del; 246 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4606.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4606/head:pull/4606

PR: https://git.openjdk.java.net/jdk/pull/4606

From jwilhelm at openjdk.java.net  Sun Jun 27 23:55:06 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Sun, 27 Jun 2021 23:55:06 GMT
Subject: Integrated: Merge jdk17
In-Reply-To: 
References: 
Message-ID: 

On Sun, 27 Jun 2021 23:05:10 GMT, Jesper Wilhelmsson  wrote:

> Forwardport JDK 17 -> JDK 18

This pull request has now been integrated.

Changeset: a29953d8
Author:    Jesper Wilhelmsson 
URL:       https://git.openjdk.java.net/jdk/commit/a29953d805ac6360bcfe005bcefa60e112788494
Stats:     1925 lines in 90 files changed: 1452 ins; 227 del; 246 mod

Merge

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

PR: https://git.openjdk.java.net/jdk/pull/4606

From sadayapalam at openjdk.java.net  Mon Jun 28 11:10:10 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Mon, 28 Jun 2021 11:10:10 GMT
Subject: RFR: 8261006: 'super' qualified method references cannot occur in
 a static context [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Sat, 26 Jun 2021 02:23:26 GMT, Vicente Romero  wrote:

>> Please review this PR, currently javac is accepting code like:
>> 
>> 
>> import java.util.function.Supplier;
>> 
>> public class MethodReferenceInConstructorInvocation {
>>     interface Bar {
>>         default String getString() { return ""; }
>>     }
>> 
>>     static class Foo implements Bar {
>>         public Foo() {  this(Bar.super::getString);  }
>>         public Foo(Supplier sString) {}
>>     }
>> }
>> 
>> 
>> but the spec states in `15.13 Method Reference Expressions`:
>> 
>> If a method reference expression has the form super :: [TypeArguments] Identifier
>> or TypeName . super :: [TypeArguments] Identifier, it is a compile-time error if
>> the expression occurs in a static context (?8.1.3).
>> 
>> and a constructor invocation is a static context. So method references of this form, qualified by `super`, should be rejected by the compiler if they appear in a static context.
>> 
>> TIA
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updating comment

The fix looks good to me - Could you please include a test for the

this(Feature.super.getString());

being rejected with this fix - i.e include the snippet from earlier comment into a test.

I am not super familiar with the rules for CSR - given we would reject code that we used to compile earlier, does it call for a CSR ?

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

PR: https://git.openjdk.java.net/jdk/pull/4376

From sadayapalam at openjdk.java.net  Mon Jun 28 11:17:03 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Mon, 28 Jun 2021 11:17:03 GMT
Subject: RFR: 8261006: 'super' qualified method references cannot occur in
 a static context [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Sat, 26 Jun 2021 02:23:26 GMT, Vicente Romero  wrote:

>> Please review this PR, currently javac is accepting code like:
>> 
>> 
>> import java.util.function.Supplier;
>> 
>> public class MethodReferenceInConstructorInvocation {
>>     interface Bar {
>>         default String getString() { return ""; }
>>     }
>> 
>>     static class Foo implements Bar {
>>         public Foo() {  this(Bar.super::getString);  }
>>         public Foo(Supplier sString) {}
>>     }
>> }
>> 
>> 
>> but the spec states in `15.13 Method Reference Expressions`:
>> 
>> If a method reference expression has the form super :: [TypeArguments] Identifier
>> or TypeName . super :: [TypeArguments] Identifier, it is a compile-time error if
>> the expression occurs in a static context (?8.1.3).
>> 
>> and a constructor invocation is a static context. So method references of this form, qualified by `super`, should be rejected by the compiler if they appear in a static context.
>> 
>> TIA
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updating comment

Marked as reviewed by sadayapalam (Reviewer).

The diags/examples test is redundant I think since we already have CantRefBeforeConstr.java there and it is a duplicate of lambda/MethodReferenceInConstructorInvocation

With the minor nits in tests addressed and additional test added, this patch looks good to go!

test/langtools/tools/javac/diags/examples/MethodReferenceNotAllowedStaticContext.java line 44:

> 42:         }
> 43:     }
> 44: }

I think this test is redundant

test/langtools/tools/javac/lambda/methodReference/MethodReferenceInConstructorInvocation.java line 4:

> 2:  * @test /nodynamiccopyright/
> 3:  * @bug 8261006
> 4:  * @summary fail to parse broken interface::method in lambda

The summary looks copy pasted ?? Sorry didn't catch earlier.

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

PR: https://git.openjdk.java.net/jdk/pull/4376

From jlahoda at openjdk.java.net  Mon Jun 28 11:44:01 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Mon, 28 Jun 2021 11:44:01 GMT
Subject: [jdk17] RFR: 8266036: class file for sun.misc.Contended not found
 [v2]
In-Reply-To: 
References: 
Message-ID: 

> [this is an improved version of openjdk/jdk PR:
> https://github.com/openjdk/jdk/pull/4428
> ]
> 
> The ct.sym may contain classfiles referring to annotations that are not present in ct.sym (liek JDK's internal annotation sun.misc.Contended). If javac will try to load them (while discovering annotations for the purpose of detecting which annotation processors should be run), an error will be produced (please see the issue). The proposal is to strip annotations that are not present in ct.sym when generating ct.sym.
> 
> As noted by @jddarcy, we also need a special handling of ValueBased, which this patch should do, so it also solves https://bugs.openjdk.java.net/browse/JDK-8258421

Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:

 - Adding notes on annotations handled specially by javac, as suggested.
 - Merge branch 'master' into JDK-8266036
 - 8258421: (jdeprscan) tools/jdeprscan/tests/jdk/jdeprscan/TestRelease.java failed with "error: cannot access jdk.internal.ValueBased"
 - Removing a test from the ProblemList.txt
 - Merge branch 'master' into JDK-8266036
 - 8266035: class file for sun.misc.Contended not found

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

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/27/files
  - new: https://git.openjdk.java.net/jdk17/pull/27/files/d9d44fde..187ad580

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=27&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=27&range=00-01

  Stats: 20125 lines in 373 files changed: 11802 ins; 7219 del; 1104 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/27.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/27/head:pull/27

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

From asotona at openjdk.java.net  Mon Jun 28 13:40:26 2021
From: asotona at openjdk.java.net (Adam Sotona)
Date: Mon, 28 Jun 2021 13:40:26 GMT
Subject: RFR: 8268869: java in source-file mode suggests javac-only Xlint flags
Message-ID: 

java in source-file mode (see JEP 330) displays compiler notes suggesting recompile with -Xlint:deprecation and -Xlint:unchecked. According JEP 330 these advanced javac optionns are not allowed. The goal with JEP 330 was to support developers that are at the early stages of learning Java, so options such as -Xlint are out of their scope.

This patch prevents displaying "Note: Recompile with -Xlint:deprecation for details." and "Note: Recompile with -Xlint:unchecked for details."   by implicitly enabling -Xlint:deprecation and -Xlint:unchecked in com.sun.tool.javac.launcher.Main for all invocations.

Beside avoiding prohibited javac option suggestion notes this patch has positive effect of more verbose compilation diagnostic. Higher diagnostic verbosity is appreciated by users learning Java on single-source programs in java source-file mode.

Similar case with -Xdiags:verbose was reported in JDK-8248843 and resolved in commit openjdk/jdk/31d0f0d8after review openjdk/jdk/4094

The patch also provides new test "testNoRecompileWithSuggestions" detecting unwanted recompilation suggestions in java in source-file mode execution. The test cover also case from JDK-8248843 with -Xdiags:verbose

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

Commit messages:
 - 8268869: java in source-file mode suggests javac-only Xlint flags

Changes: https://git.openjdk.java.net/jdk/pull/4613/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4613&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8268869
  Stats: 35 lines in 2 files changed: 33 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4613.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4613/head:pull/4613

PR: https://git.openjdk.java.net/jdk/pull/4613

From gli at openjdk.java.net  Mon Jun 28 13:59:09 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Mon, 28 Jun 2021 13:59:09 GMT
Subject: RFR: 8268869: java in source-file mode suggests javac-only Xlint
 flags
In-Reply-To: 
References: 
Message-ID: 

On Mon, 28 Jun 2021 13:33:04 GMT, Adam Sotona  wrote:

> java in source-file mode (see JEP 330) displays compiler notes suggesting recompile with -Xlint:deprecation and -Xlint:unchecked. According JEP 330 these advanced javac optionns are not allowed. The goal with JEP 330 was to support developers that are at the early stages of learning Java, so options such as -Xlint are out of their scope.
> 
> This patch prevents displaying "Note: Recompile with -Xlint:deprecation for details." and "Note: Recompile with -Xlint:unchecked for details."   by implicitly enabling -Xlint:deprecation and -Xlint:unchecked in com.sun.tool.javac.launcher.Main for all invocations.
> 
> Beside avoiding prohibited javac option suggestion notes this patch has positive effect of more verbose compilation diagnostic. Higher diagnostic verbosity is appreciated by users learning Java on single-source programs in java source-file mode.
> 
> Similar case with -Xdiags:verbose was reported in JDK-8248843 and resolved in commit openjdk/jdk/31d0f0d8after review openjdk/jdk/4094
> 
> The patch also provides new test "testNoRecompileWithSuggestions" detecting unwanted recompilation suggestions in java in source-file mode execution. The test cover also case from JDK-8248843 with -Xdiags:verbose

test/langtools/tools/javac/launcher/SourceLauncherTest.java line 604:

> 602:     public void testNoRecompileWithSuggestions(Path base) throws IOException {
> 603:         tb.writeJavaFiles(base,
> 604:             "class NoRecompile {\n" +

It is better to use text block `"""` to improve the readability.

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

PR: https://git.openjdk.java.net/jdk/pull/4613

From jlahoda at openjdk.java.net  Mon Jun 28 14:02:10 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Mon, 28 Jun 2021 14:02:10 GMT
Subject: [jdk17] RFR: 8266036: class file for sun.misc.Contended not found
 [v2]
In-Reply-To: 
References: 
 
Message-ID: <_werM8X9bD5xHJ7V4wGt5OtYb_x9QGqkUCVyJJR6pjg=.568f276e-52ef-4c4d-8562-a1e4ecc969d4@github.com>

On Fri, 11 Jun 2021 21:06:41 GMT, Joe Darcy  wrote:

>> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
>> 
>>  - Adding notes on annotations handled specially by javac, as suggested.
>>  - Merge branch 'master' into JDK-8266036
>>  - 8258421: (jdeprscan) tools/jdeprscan/tests/jdk/jdeprscan/TestRelease.java failed with "error: cannot access jdk.internal.ValueBased"
>>  - Removing a test from the ProblemList.txt
>>  - Merge branch 'master' into JDK-8266036
>>  - 8266035: class file for sun.misc.Contended not found
>
> I was wondering how better to document that the addition of new JDK-specific annotation types might require more updates to this list.
> 
> Perhaps adding notes in the existing annotation types would help, as people might cut-and-paste the old types when creating new ones. That may be more effective than adding package-level documentation on the internal packages.

@jddarcy thanks for the comment, and sorry for delays. I've updated the annotation with a note on the special annotations, as suggested. Does the text make sense? Thanks!

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

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

From asotona at openjdk.java.net  Mon Jun 28 14:21:11 2021
From: asotona at openjdk.java.net (Adam Sotona)
Date: Mon, 28 Jun 2021 14:21:11 GMT
Subject: RFR: 8268869: java in source-file mode suggests javac-only Xlint
 flags
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 28 Jun 2021 13:56:35 GMT, Guoxiong Li  wrote:

>> java in source-file mode (see JEP 330) displays compiler notes suggesting recompile with -Xlint:deprecation and -Xlint:unchecked. According JEP 330 these advanced javac optionns are not allowed. The goal with JEP 330 was to support developers that are at the early stages of learning Java, so options such as -Xlint are out of their scope.
>> 
>> This patch prevents displaying "Note: Recompile with -Xlint:deprecation for details." and "Note: Recompile with -Xlint:unchecked for details."   by implicitly enabling -Xlint:deprecation and -Xlint:unchecked in com.sun.tool.javac.launcher.Main for all invocations.
>> 
>> Beside avoiding prohibited javac option suggestion notes this patch has positive effect of more verbose compilation diagnostic. Higher diagnostic verbosity is appreciated by users learning Java on single-source programs in java source-file mode.
>> 
>> Similar case with -Xdiags:verbose was reported in JDK-8248843 and resolved in commit openjdk/jdk/31d0f0d8after review openjdk/jdk/4094
>> 
>> The patch also provides new test "testNoRecompileWithSuggestions" detecting unwanted recompilation suggestions in java in source-file mode execution. The test cover also case from JDK-8248843 with -Xdiags:verbose
>
> test/langtools/tools/javac/launcher/SourceLauncherTest.java line 604:
> 
>> 602:     public void testNoRecompileWithSuggestions(Path base) throws IOException {
>> 603:         tb.writeJavaFiles(base,
>> 604:             "class NoRecompile {\n" +
> 
> It is better to use text block `"""` to improve the readability.

Right, however it will prevent clean backports to older JDK versions

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

PR: https://git.openjdk.java.net/jdk/pull/4613

From vromero at openjdk.java.net  Mon Jun 28 18:11:08 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Mon, 28 Jun 2021 18:11:08 GMT
Subject: RFR: 8261006: 'super' qualified method references cannot occur in
 a static context [v5]
In-Reply-To: 
References: 
Message-ID: 

> Please review this PR, currently javac is accepting code like:
> 
> 
> import java.util.function.Supplier;
> 
> public class MethodReferenceInConstructorInvocation {
>     interface Bar {
>         default String getString() { return ""; }
>     }
> 
>     static class Foo implements Bar {
>         public Foo() {  this(Bar.super::getString);  }
>         public Foo(Supplier sString) {}
>     }
> }
> 
> 
> but the spec states in `15.13 Method Reference Expressions`:
> 
> If a method reference expression has the form super :: [TypeArguments] Identifier
> or TypeName . super :: [TypeArguments] Identifier, it is a compile-time error if
> the expression occurs in a static context (?8.1.3).
> 
> and a constructor invocation is a static context. So method references of this form, qualified by `super`, should be rejected by the compiler if they appear in a static context.
> 
> TIA

Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:

  addressing review comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4376/files
  - new: https://git.openjdk.java.net/jdk/pull/4376/files/a6056843..d728b8be

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4376&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4376&range=03-04

  Stats: 51 lines in 3 files changed: 2 ins; 44 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4376.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4376/head:pull/4376

PR: https://git.openjdk.java.net/jdk/pull/4376

From github.com+11896137+pzygielo at openjdk.java.net  Mon Jun 28 19:40:08 2021
From: github.com+11896137+pzygielo at openjdk.java.net (Piotrek =?UTF-8?B?xbt5Z2llxYJv?=)
Date: Mon, 28 Jun 2021 19:40:08 GMT
Subject: RFR: 8268549: Typo in file name in example for -Xlint:processing
In-Reply-To: 
References: 
Message-ID: 

On Sat, 8 May 2021 19:45:22 GMT, Piotrek ?ygie?o  wrote:

> Presented class is public, hence it has to be defined in AnnoProc.java.

I think there is also chance to fix source for line 2114 https://github.com/openjdk/jdk/blob/e9b2c058a4ed5de29b991360f78fc1c5263c9268/src/jdk.compiler/share/man/javac.1#L2112-L2114 as I suppose it shall be _type of **annotation**_.

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

PR: https://git.openjdk.java.net/jdk/pull/3937

From github.com+11896137+pzygielo at openjdk.java.net  Mon Jun 28 19:45:13 2021
From: github.com+11896137+pzygielo at openjdk.java.net (Piotrek =?UTF-8?B?xbt5Z2llxYJv?=)
Date: Mon, 28 Jun 2021 19:45:13 GMT
Subject: Withdrawn: 8268549: Typo in file name in example for -Xlint:processing
In-Reply-To: 
References: 
Message-ID: 

On Sat, 8 May 2021 19:45:22 GMT, Piotrek ?ygie?o  wrote:

> Presented class is public, hence it has to be defined in AnnoProc.java.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.java.net/jdk/pull/3937

From github.com+11896137+pzygielo at openjdk.java.net  Mon Jun 28 19:45:13 2021
From: github.com+11896137+pzygielo at openjdk.java.net (Piotrek =?UTF-8?B?xbt5Z2llxYJv?=)
Date: Mon, 28 Jun 2021 19:45:13 GMT
Subject: RFR: 8268549: Typo in file name in example for -Xlint:processing
In-Reply-To: 
References: 
Message-ID: <6-MbVkA9C9afVhCccog-2WtTrTMoDgvLMxc4q2gED10=.c99f6f90-f184-4f41-a2cf-0e50244c62ea@github.com>

On Sat, 8 May 2021 19:45:22 GMT, Piotrek ?ygie?o  wrote:

> Presented class is public, hence it has to be defined in AnnoProc.java.

Closing with the hope it would be fixed in the source.

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

PR: https://git.openjdk.java.net/jdk/pull/3937

From vromero at openjdk.java.net  Tue Jun 29 02:54:07 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Tue, 29 Jun 2021 02:54:07 GMT
Subject: [jdk17] RFR: 8269141: Switch statement containing pattern case
 label element gets in the loop during execution
In-Reply-To: <1z-buK0Nwk94qrl8n6y96HSJQq7ZDugwTThAA0swqrk=.98d5ca3d-b37f-4446-914d-5062d14353f0@github.com>
References: <1z-buK0Nwk94qrl8n6y96HSJQq7ZDugwTThAA0swqrk=.98d5ca3d-b37f-4446-914d-5062d14353f0@github.com>
Message-ID: 

On Thu, 24 Jun 2021 10:50:16 GMT, Jan Lahoda  wrote:

> Guards in the pattern matching switches are implemented internally through `continue` in switches (which cannot be written in the source, but can be used internally). Consider code:
> 
> switch (...) {
>      case String s && s.isEmpty(): break;
>      default: //fall through outside the switch
> }
> 
> The current implementation in Gen will: `code.resolve(switchEnv.info.cont);` which puts (merges) the code paths for the `continue`s to `pendingJumps`. The `code.branch(goto_)` in `code.resolve(code.branch(goto_), switchStart)` will merge the `pendingJumps` (i.e. the continues) with the execution as it falls through the default case of the switch, and the `code.resolve` will jump for all the merged code paths to the beginning of the switch. This is wrong - we should only jump to the beginning of the switch for the `continue` code paths, not for the final fall-through code path. This is what the fix is trying to do.

lgtm

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

Marked as reviewed by vromero (Reviewer).

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

From sadayapalam at openjdk.java.net  Tue Jun 29 03:46:02 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Tue, 29 Jun 2021 03:46:02 GMT
Subject: RFR: 8261006: 'super' qualified method references cannot occur in
 a static context [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 28 Jun 2021 18:11:08 GMT, Vicente Romero  wrote:

>> Please review this PR, currently javac is accepting code like:
>> 
>> 
>> import java.util.function.Supplier;
>> 
>> public class MethodReferenceInConstructorInvocation {
>>     interface Bar {
>>         default String getString() { return ""; }
>>     }
>> 
>>     static class Foo implements Bar {
>>         public Foo() {  this(Bar.super::getString);  }
>>         public Foo(Supplier sString) {}
>>     }
>> }
>> 
>> 
>> but the spec states in `15.13 Method Reference Expressions`:
>> 
>> If a method reference expression has the form super :: [TypeArguments] Identifier
>> or TypeName . super :: [TypeArguments] Identifier, it is a compile-time error if
>> the expression occurs in a static context (?8.1.3).
>> 
>> and a constructor invocation is a static context. So method references of this form, qualified by `super`, should be rejected by the compiler if they appear in a static context.
>> 
>> TIA
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   addressing review comments

I glanced through the latest changes and they look good and incorporate all review comments. 

+1

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

PR: https://git.openjdk.java.net/jdk/pull/4376

From peter.levart at gmail.com  Tue Jun 29 07:05:03 2021
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 29 Jun 2021 09:05:03 +0200
Subject: RFR: 8173970: jar tool should have a way to extract to a directory
In-Reply-To: <495db34e-48a8-489d-8a86-36ba74870d60@gmail.com>
References: 
 <1BB8805F-174A-4EB9-B26A-060B2251A40C@oracle.com>
 
 <6242cfe8-cef7-0603-33fc-b3428209a1ac@gmail.com>
 
 
 
 <1e14f8e1-c4d2-1e11-df88-8af083bac8f9@gmail.com>
 <9B159F65-A7CC-4FEA-BAB8-77D66D7AD5AB@oracle.com>
 <73dcce4d-0b53-23bd-b706-bf4fdbcbe256@oracle.com>
 <9030C4FE-9D94-496B-9E06-C8B9B7664651@oracle.com>
 <2a54cca7-1132-37e6-d8cc-9f9db7b3f6b5@oracle.com>
 <69369159-FB85-4812-976B-53019FCD5FC6@oracle.com>
 <237e6c14-8593-69df-5866-4a238e020fce@oracle.com>
 
 
 
 <495db34e-48a8-489d-8a86-36ba74870d60@gmail.com>
Message-ID: <8dc22ac8-01e4-b511-b0e1-0d8c416daa00@gmail.com>

Hi,

On 29/03/2021 12:46, Jaikiran Pai wrote:
>> Given the support of -C/-dir is new and -P is there for backwards 
>> compatibility then I see the choices are:
>>
>>   * Issue an error when -P and -C/-dir are specified together with -x
>>   * Silently ignore the -P option
>>   * Ignore -C/-dir and the behavior is if -xfP was specified.
>>
>>
>> I am leaning towards an error given this is a new feature when -P and 
>> -C/-dir are specified with -x
>
> That sounds reasonable to me. I'll update the PR accordingly to take 
> this into account.
>
> -Jaikiran
>

If we are trying to follow the semantics of tar -C option (gnutar and 
other Unix tar(s)) then I think -P may be combined with -C when 
extracting. The manpage for gnutar says:

 ?????? -C, --directory=DIR
 ????????????? Change to DIR before performing any operations. This 
option is order-sensitive, i.e. it affects all options that follow.

...the meaning is that relative paths from archive get extracted 
relative to current dir (possibly modified by -C) and that absolute 
paths get extracted to their absolute positions (i.e. not affected by 
current dir). The -C option (as implemented by tar) is also useful when 
gathering files/dirs from different base paths into common archive 
structure. Say you have the following (relative) directory/file structure:

dir1/subdir1/a.txt
dir1/subdir1/b.txt
dir1/file1.txt
dir2/subdir2/a.txt
dir2/subdir2/b.txt
dir2/file2.txt

The command:

tar -cf archive.tar -C dir1 . -C ../dir2 .

...will create archive.tar with the following content (notice the 2nd -C 
option is dependent on the 1st: -C literally changes the current 
directory before executing further options):

./
./subdir1/
./subdir1/a.txt
./subdir1/b.txt
./file1.txt
./
./subdir2/
./subdir2/a.txt
./subdir2/b.txt
./file2.txt


When extracting, -C may be used to scatter different relative archive 
files/dirs into different base paths. For example, the archive.tar from 
above can be extracted into original directory structure with the 
following command (empty dir1 and dir2 have to be already present):

tar -xf archive.tar -C dir1 ./file1.txt ./subdir1 -C ../dir2 ./file2.txt 
./subdir2


So here's a hint about the behavior of multiple -C options: if the 
option is -C, it should follow tar -C behavior.


Regards, Peter


-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From peter.levart at gmail.com  Tue Jun 29 07:16:16 2021
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 29 Jun 2021 09:16:16 +0200
Subject: RFR: 8173970: jar tool should have a way to extract to a directory
In-Reply-To: <8dc22ac8-01e4-b511-b0e1-0d8c416daa00@gmail.com>
References: 
 
 <6242cfe8-cef7-0603-33fc-b3428209a1ac@gmail.com>
 
 
 
 <1e14f8e1-c4d2-1e11-df88-8af083bac8f9@gmail.com>
 <9B159F65-A7CC-4FEA-BAB8-77D66D7AD5AB@oracle.com>
 <73dcce4d-0b53-23bd-b706-bf4fdbcbe256@oracle.com>
 <9030C4FE-9D94-496B-9E06-C8B9B7664651@oracle.com>
 <2a54cca7-1132-37e6-d8cc-9f9db7b3f6b5@oracle.com>
 <69369159-FB85-4812-976B-53019FCD5FC6@oracle.com>
 <237e6c14-8593-69df-5866-4a238e020fce@oracle.com>
 
 
 
 <495db34e-48a8-489d-8a86-36ba74870d60@gmail.com>
 <8dc22ac8-01e4-b511-b0e1-0d8c416daa00@gmail.com>
Message-ID: <75b4dc37-39ba-ee83-6657-de3a2a2d4335@gmail.com>

A word about "compatibility" with other jdk tools...

jar is a specific tool. It was initially conceived to be user-friendly 
with users that are already familiar with tar tool:

"The syntax for the jar command resembles the syntax for the tar command."

Mixing-in behaviors not consistent with tar will make it a strange 
hybrid. Trying to find common ground with other JDK tools will make it 
less flexible.


Regards, Peter


On 29/06/2021 09:05, Peter Levart wrote:
>
> Hi,
>
> On 29/03/2021 12:46, Jaikiran Pai wrote:
>>> Given the support of -C/-dir is new and -P is there for backwards 
>>> compatibility then I see the choices are:
>>>
>>>   * Issue an error when -P and -C/-dir are specified together with -x
>>>   * Silently ignore the -P option
>>>   * Ignore -C/-dir and the behavior is if -xfP was specified.
>>>
>>>
>>> I am leaning towards an error given this is a new feature when -P 
>>> and -C/-dir are specified with -x
>>
>> That sounds reasonable to me. I'll update the PR accordingly to take 
>> this into account.
>>
>> -Jaikiran
>>
>
> If we are trying to follow the semantics of tar -C option (gnutar and 
> other Unix tar(s)) then I think -P may be combined with -C when 
> extracting. The manpage for gnutar says:
>
> ?????? -C, --directory=DIR
> ????????????? Change to DIR before performing any operations. This 
> option is order-sensitive, i.e. it affects all options that follow.
>
> ...the meaning is that relative paths from archive get extracted 
> relative to current dir (possibly modified by -C) and that absolute 
> paths get extracted to their absolute positions (i.e. not affected by 
> current dir). The -C option (as implemented by tar) is also useful 
> when gathering files/dirs from different base paths into common 
> archive structure. Say you have the following (relative) 
> directory/file structure:
>
> dir1/subdir1/a.txt
> dir1/subdir1/b.txt
> dir1/file1.txt
> dir2/subdir2/a.txt
> dir2/subdir2/b.txt
> dir2/file2.txt
>
> The command:
>
> tar -cf archive.tar -C dir1 . -C ../dir2 .
>
> ...will create archive.tar with the following content (notice the 2nd 
> -C option is dependent on the 1st: -C literally changes the current 
> directory before executing further options):
>
> ./
> ./subdir1/
> ./subdir1/a.txt
> ./subdir1/b.txt
> ./file1.txt
> ./
> ./subdir2/
> ./subdir2/a.txt
> ./subdir2/b.txt
> ./file2.txt
>
>
> When extracting, -C may be used to scatter different relative archive 
> files/dirs into different base paths. For example, the archive.tar 
> from above can be extracted into original directory structure with the 
> following command (empty dir1 and dir2 have to be already present):
>
> tar -xf archive.tar -C dir1 ./file1.txt ./subdir1 -C ../dir2 
> ./file2.txt ./subdir2
>
>
> So here's a hint about the behavior of multiple -C options: if the 
> option is -C, it should follow tar -C behavior.
>
>
> Regards, Peter
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From vromero at openjdk.java.net  Tue Jun 29 21:31:05 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Tue, 29 Jun 2021 21:31:05 GMT
Subject: [jdk17] RFR: 8269354: javac crashes when processing parenthesized
 pattern in instanceof
In-Reply-To: 
References: 
Message-ID: 

On Fri, 25 Jun 2021 14:37:53 GMT, Jan Lahoda  wrote:

> When having code like:
> 
> if (o instanceof String s) {
>      System.err.println(s);
> }
> 
> 
> `javac` needs to hoist the `s` binding variable out of the `if` statement. This is done through `BindingContext` in `TransPatterns`. Sometimes, there is no statement out of which the variable would need to be hoisted, like:
> 
> boolean b = o instanceof String s && !s.isEmpty();
> 
> 
> so some expressions (`&&` in the example) also serve as a place where the binding variables can be hoisted. With the addition of parenthesized and guarded patterns, the `instanceof` expression needs to be one of such expressions so that in expressions like:
> 
> boolean b = o instanceof (String s && !s.isEmpty());
> 
> 
> the `s.isEmpty()` uses the correct translated/hoisted variable.

lgtm

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

Marked as reviewed by vromero (Reviewer).

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

From vromero at openjdk.java.net  Tue Jun 29 22:31:01 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Tue, 29 Jun 2021 22:31:01 GMT
Subject: [jdk17] RFR: 8268320: Better error recovery for broken patterns
 in switch [v2]
In-Reply-To: <2QZoOypR1Pp9-XHni-zW1J4CPZ7sfRwKhextuyPy2WA=.19a66a24-03df-44cb-a9ae-62e75fafeb8c@github.com>
References: 
 <2QZoOypR1Pp9-XHni-zW1J4CPZ7sfRwKhextuyPy2WA=.19a66a24-03df-44cb-a9ae-62e75fafeb8c@github.com>
Message-ID: 

On Fri, 25 Jun 2021 13:40:30 GMT, Jan Lahoda  wrote:

>> [a copy of https://github.com/openjdk/jdk/pull/4441 for JDK 17]
>> 
>> Trying to improve error recovery in case the user wanted to use a type-pattern in the switch construct, but didn't put a binding variable name after the type name. E.g.:
>> 
>> $ cat test/langtools/tools/javac/diags/examples/PatternExpected.java
>> [snip]
>> class PatternSwitch {
>>     private void doSwitch(Object o) {
>>         switch (o) {
>>             case String: break;
>>             default: break;
>>         }
>>     }
>> }
>> $ javac --enable-preview -source 17  test/langtools/tools/javac/diags/examples/PatternExpected.java
>> test/langtools/tools/javac/diags/examples/PatternExpected.java:32: error: type pattern expected
>>             case String: break;
>>                  ^
>> Note: test/langtools/tools/javac/diags/examples/PatternExpected.java uses preview features of Java SE 17.
>> Note: Recompile with -Xlint:preview for details.
>> 1 error
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixing output.

lgtm

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

Marked as reviewed by vromero (Reviewer).

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

From jjg at openjdk.java.net  Tue Jun 29 22:41:09 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Tue, 29 Jun 2021 22:41:09 GMT
Subject: RFR: 8268549: Typo in file name in example for -Xlint:processing
In-Reply-To: 
References: 
Message-ID: 

On Sat, 8 May 2021 19:45:22 GMT, Piotrek ?ygie?o  wrote:

> Presented class is public, hence it has to be defined in AnnoProc.java.

I'll fix the issues upstream.

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

PR: https://git.openjdk.java.net/jdk/pull/3937

From tvoniadka at openjdk.java.net  Wed Jun 30 08:29:17 2021
From: tvoniadka at openjdk.java.net (Thejasvi Voniadka)
Date: Wed, 30 Jun 2021 08:29:17 GMT
Subject: [jdk17] RFR: 8269656: The test
 test/langtools/tools/javac/versions/Versions.java has duplicate test cycles
Message-ID: 

The test "test test/langtools/tools/javac/versions/Versions.java" duplicates some operations, while missing some others.

>From the execution log:

...
test: check_source_target 52.0 8 8
...
test: check_source_target 52.0 8 8
...
test: check_source_target 53.0 9 9
...
test: check_source_target 53.0 9 9
...


We can notice the duplicates. Also some combinations are missed out. For example, "check -source 7 -target 8" is an expected combination in the output, but it is missed.

I have updated the index boundaries of the inner for-loop to address this discrepancy.

In addition, the test code contains an unreachable block of code, that causes the combination "most recent target" without a "-source" specifier to be missed out. I have updated the corresponding "if" condition too.

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

Commit messages:
 - 8269656: The test test/langtools/tools/javac/versions/Versions.java has duplicate test cycles

Changes: https://git.openjdk.java.net/jdk17/pull/179/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=179&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8269656
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/179.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/179/head:pull/179

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

From jlahoda at openjdk.java.net  Wed Jun 30 08:48:06 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Wed, 30 Jun 2021 08:48:06 GMT
Subject: [jdk17] Integrated: 8269141: Switch statement containing pattern case
 label element gets in the loop during execution
In-Reply-To: <1z-buK0Nwk94qrl8n6y96HSJQq7ZDugwTThAA0swqrk=.98d5ca3d-b37f-4446-914d-5062d14353f0@github.com>
References: <1z-buK0Nwk94qrl8n6y96HSJQq7ZDugwTThAA0swqrk=.98d5ca3d-b37f-4446-914d-5062d14353f0@github.com>
Message-ID: 

On Thu, 24 Jun 2021 10:50:16 GMT, Jan Lahoda  wrote:

> Guards in the pattern matching switches are implemented internally through `continue` in switches (which cannot be written in the source, but can be used internally). Consider code:
> 
> switch (...) {
>      case String s && s.isEmpty(): break;
>      default: //fall through outside the switch
> }
> 
> The current implementation in Gen will: `code.resolve(switchEnv.info.cont);` which puts (merges) the code paths for the `continue`s to `pendingJumps`. The `code.branch(goto_)` in `code.resolve(code.branch(goto_), switchStart)` will merge the `pendingJumps` (i.e. the continues) with the execution as it falls through the default case of the switch, and the `code.resolve` will jump for all the merged code paths to the beginning of the switch. This is wrong - we should only jump to the beginning of the switch for the `continue` code paths, not for the final fall-through code path. This is what the fix is trying to do.

This pull request has now been integrated.

Changeset: c3c91892
Author:    Jan Lahoda 
URL:       https://git.openjdk.java.net/jdk17/commit/c3c918928cab49d970ddf74d53db1e57e91dc30c
Stats:     34 lines in 2 files changed: 31 ins; 1 del; 2 mod

8269141: Switch statement containing pattern case label element gets in the loop during execution

Reviewed-by: vromero

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

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

From gli at openjdk.java.net  Wed Jun 30 08:52:00 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Wed, 30 Jun 2021 08:52:00 GMT
Subject: [jdk17] RFR: 8269656: The test
 test/langtools/tools/javac/versions/Versions.java has duplicate test cycles
In-Reply-To: 
References: 
Message-ID: 

On Wed, 30 Jun 2021 08:23:02 GMT, Thejasvi Voniadka  wrote:

> The test "test test/langtools/tools/javac/versions/Versions.java" duplicates some operations, while missing some others.
> 
> From the execution log:
> 
> ...
> test: check_source_target 52.0 8 8
> ...
> test: check_source_target 52.0 8 8
> ...
> test: check_source_target 53.0 9 9
> ...
> test: check_source_target 53.0 9 9
> ...
> 
> 
> We can notice the duplicates. Also some combinations are missed out. For example, "check -source 7 -target 8" is an expected combination in the output, but it is missed.
> 
> I have updated the index boundaries of the inner for-loop to address this discrepancy.
> 
> In addition, the test code contains an unreachable block of code, that causes the combination "most recent target" without a "-source" specifier to be missed out. I have updated the corresponding "if" condition too.

Maybe it should be fixed at JDK18 instead of JDK17 according to its priority `P4` and the test passed in the past.

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

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

From jlahoda at openjdk.java.net  Wed Jun 30 09:52:07 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Wed, 30 Jun 2021 09:52:07 GMT
Subject: [jdk17] Integrated: 8268320: Better error recovery for broken
 patterns in switch
In-Reply-To: 
References: 
Message-ID: 

On Fri, 25 Jun 2021 12:58:59 GMT, Jan Lahoda  wrote:

> [a copy of https://github.com/openjdk/jdk/pull/4441 for JDK 17]
> 
> Trying to improve error recovery in case the user wanted to use a type-pattern in the switch construct, but didn't put a binding variable name after the type name. E.g.:
> 
> $ cat test/langtools/tools/javac/diags/examples/PatternExpected.java
> [snip]
> class PatternSwitch {
>     private void doSwitch(Object o) {
>         switch (o) {
>             case String: break;
>             default: break;
>         }
>     }
> }
> $ javac --enable-preview -source 17  test/langtools/tools/javac/diags/examples/PatternExpected.java
> test/langtools/tools/javac/diags/examples/PatternExpected.java:32: error: type pattern expected
>             case String: break;
>                  ^
> Note: test/langtools/tools/javac/diags/examples/PatternExpected.java uses preview features of Java SE 17.
> Note: Recompile with -Xlint:preview for details.
> 1 error

This pull request has now been integrated.

Changeset: 4ee400ae
Author:    Jan Lahoda 
URL:       https://git.openjdk.java.net/jdk17/commit/4ee400ae433efbccd71cbebce6847033e76bc949
Stats:     164 lines in 7 files changed: 112 ins; 3 del; 49 mod

8268320: Better error recovery for broken patterns in switch

Reviewed-by: vromero

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

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

From tvoniadka at openjdk.java.net  Wed Jun 30 10:15:04 2021
From: tvoniadka at openjdk.java.net (Thejasvi Voniadka)
Date: Wed, 30 Jun 2021 10:15:04 GMT
Subject: [jdk17] RFR: 8269656: The test
 test/langtools/tools/javac/versions/Versions.java has duplicate test cycles
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 30 Jun 2021 08:49:28 GMT, Guoxiong Li  wrote:

> Maybe it should be fixed at JDK18 instead of JDK17 according to its priority `P4` and the test passed in the past.

Alright, I will close this PR and create a new one against JDK18.

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

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

From tvoniadka at openjdk.java.net  Wed Jun 30 10:15:04 2021
From: tvoniadka at openjdk.java.net (Thejasvi Voniadka)
Date: Wed, 30 Jun 2021 10:15:04 GMT
Subject: [jdk17] Withdrawn: 8269656: The test
 test/langtools/tools/javac/versions/Versions.java has duplicate test cycles
In-Reply-To: 
References: 
Message-ID: 

On Wed, 30 Jun 2021 08:23:02 GMT, Thejasvi Voniadka  wrote:

> The test "test test/langtools/tools/javac/versions/Versions.java" duplicates some operations, while missing some others.
> 
> From the execution log:
> 
> ...
> test: check_source_target 52.0 8 8
> ...
> test: check_source_target 52.0 8 8
> ...
> test: check_source_target 53.0 9 9
> ...
> test: check_source_target 53.0 9 9
> ...
> 
> 
> We can notice the duplicates. Also some combinations are missed out. For example, "check -source 7 -target 8" is an expected combination in the output, but it is missed.
> 
> I have updated the index boundaries of the inner for-loop to address this discrepancy.
> 
> In addition, the test code contains an unreachable block of code, that causes the combination "most recent target" without a "-source" specifier to be missed out. I have updated the corresponding "if" condition too.

This pull request has been closed without being integrated.

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

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

From jlahoda at openjdk.java.net  Wed Jun 30 10:23:32 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Wed, 30 Jun 2021 10:23:32 GMT
Subject: [jdk17] RFR: 8268766: Desugaring of pattern matching enum switch
 should be improved [v6]
In-Reply-To: <3xKa946t0s_eRqnj0vfgjkfurBvZqKGe1QkYk-0lNO0=.518519f5-a2cb-44ed-946c-09e517e7c5d2@github.com>
References: <3xKa946t0s_eRqnj0vfgjkfurBvZqKGe1QkYk-0lNO0=.518519f5-a2cb-44ed-946c-09e517e7c5d2@github.com>
Message-ID: 

> Currently, an enum switch with patterns is desugared in a very non-standard, and potentially slow, way. It would be better to use the standard `typeSwitch` bootstrap to classify the enum constants. The bootstrap needs to accept enum constants as labels in order to allow this. A complication is that if an enum constant is missing, that is not an incompatible change for the switch, and the switch should simply work as if the case for the missing constant didn't exist. So, the proposed solution is to have a new bootstrap `enumSwitch` that accepts `String`s in place of the enum constants, and will internally convert them to the appropriate enum constants, and then it will find the proper case similarly to `typeSwitch`.
> 
> How does this look?

Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:

 - Reflecting review comments.
 - Merge branch 'master' into JDK-8268766
 - Improving javadoc.
 - Updating javadoc, as suggested.
 - Updating javadoc, code and tests as suggested.
 - Creating a new bootstrap method for (pattern matching) enum switches, as suggested.
 - Adding and fixing test.
 - Merging master.
 - 8268766: Desugaring of pattern matching enum switch should be improved

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

Changes: https://git.openjdk.java.net/jdk17/pull/81/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=81&range=05
  Stats: 416 lines in 6 files changed: 278 ins; 68 del; 70 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/81.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/81/head:pull/81

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

From tvoniadka at openjdk.java.net  Wed Jun 30 12:11:12 2021
From: tvoniadka at openjdk.java.net (Thejasvi Voniadka)
Date: Wed, 30 Jun 2021 12:11:12 GMT
Subject: RFR: 8269656: The test
 test/langtools/tools/javac/versions/Versions.java has duplicate test cycles
Message-ID: <-ZjbbIHEMR26D1eHVaVwhE87ZvfvbI0OqVXEMy4jSCs=.86be1787-f3c3-4a7f-bea3-967535511f9a@github.com>

The test "test test/langtools/tools/javac/versions/Versions.java" duplicates some operations, while missing some others.

>From the execution log:

...
test: check_source_target 52.0 8 8
...
test: check_source_target 52.0 8 8
...
test: check_source_target 53.0 9 9
...
test: check_source_target 53.0 9 9
...

We can notice the duplicates. Also some combinations are missed out. For example, "check -source 7 -target 8" is an expected combination in the output, but it is missed.

I have updated the index boundaries of the inner for-loop to address this discrepancy.

In addition, the test code contains an unreachable block of code, that causes the combination "most recent target" without a "-source" specifier to be missed out. I have updated the corresponding "if" condition too.

I have verified that the test passes on all platforms.

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

Commit messages:
 - 8269656: The test test/langtools/tools/javac/versions/Versions.java has duplicate test cycles

Changes: https://git.openjdk.java.net/jdk/pull/4639/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4639&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8269656
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4639.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4639/head:pull/4639

PR: https://git.openjdk.java.net/jdk/pull/4639

From psandoz at openjdk.java.net  Wed Jun 30 15:21:03 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Wed, 30 Jun 2021 15:21:03 GMT
Subject: [jdk17] RFR: 8268766: Desugaring of pattern matching enum switch
 should be improved [v6]
In-Reply-To: 
References: <3xKa946t0s_eRqnj0vfgjkfurBvZqKGe1QkYk-0lNO0=.518519f5-a2cb-44ed-946c-09e517e7c5d2@github.com>
 
Message-ID: <5LvETl-jl0M3RUn1HU69_5Q-_auEweOY-2psiJH7QN0=.4caaa103-6aac-4caf-be45-a05e6e12e02b@github.com>

On Wed, 30 Jun 2021 10:23:32 GMT, Jan Lahoda  wrote:

>> Currently, an enum switch with patterns is desugared in a very non-standard, and potentially slow, way. It would be better to use the standard `typeSwitch` bootstrap to classify the enum constants. The bootstrap needs to accept enum constants as labels in order to allow this. A complication is that if an enum constant is missing, that is not an incompatible change for the switch, and the switch should simply work as if the case for the missing constant didn't exist. So, the proposed solution is to have a new bootstrap `enumSwitch` that accepts `String`s in place of the enum constants, and will internally convert them to the appropriate enum constants, and then it will find the proper case similarly to `typeSwitch`.
>> 
>> How does this look?
>
> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:
> 
>  - Reflecting review comments.
>  - Merge branch 'master' into JDK-8268766
>  - Improving javadoc.
>  - Updating javadoc, as suggested.
>  - Updating javadoc, code and tests as suggested.
>  - Creating a new bootstrap method for (pattern matching) enum switches, as suggested.
>  - Adding and fixing test.
>  - Merging master.
>  - 8268766: Desugaring of pattern matching enum switch should be improved

Marked as reviewed by psandoz (Reviewer).

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

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

From darcy at openjdk.java.net  Wed Jun 30 17:02:21 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 30 Jun 2021 17:02:21 GMT
Subject: RFR: 8268637: Update --release 17 symbol information for JDK 17 build
 28
Message-ID: 

JDK 17 b28 had two fixes which updated the symbol information. A CallerSensitive annotation was removed as part of JDK-8268349 and API changes in JDK-8268888.

These should be reflected in the JDK 18 symbol information for 17.

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

Commit messages:
 - 8268637: Update --release 17 symbol information for JDK 17 build 28

Changes: https://git.openjdk.java.net/jdk/pull/4641/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4641&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8268637
  Stats: 6 lines in 2 files changed: 2 ins; 4 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4641.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4641/head:pull/4641

PR: https://git.openjdk.java.net/jdk/pull/4641

From iris at openjdk.java.net  Wed Jun 30 20:33:06 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Wed, 30 Jun 2021 20:33:06 GMT
Subject: RFR: 8268637: Update --release 17 symbol information for JDK 17
 build 28
In-Reply-To: 
References: 
Message-ID: 

On Wed, 30 Jun 2021 16:54:57 GMT, Joe Darcy  wrote:

> JDK 17 b28 had two fixes which updated the symbol information. A CallerSensitive annotation was removed as part of JDK-8268349 and API changes in JDK-8268888.
> 
> These should be reflected in the JDK 18 symbol information for 17.

Marked as reviewed by iris (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/4641

From darcy at openjdk.java.net  Wed Jun 30 21:49:06 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 30 Jun 2021 21:49:06 GMT
Subject: Integrated: 8268637: Update --release 17 symbol information for JDK
 17 build 28
In-Reply-To: 
References: 
Message-ID: 

On Wed, 30 Jun 2021 16:54:57 GMT, Joe Darcy  wrote:

> JDK 17 b28 had two fixes which updated the symbol information. A CallerSensitive annotation was removed as part of JDK-8268349 and API changes in JDK-8268888.
> 
> These should be reflected in the JDK 18 symbol information for 17.

This pull request has now been integrated.

Changeset: 85262c71
Author:    Joe Darcy 
URL:       https://git.openjdk.java.net/jdk/commit/85262c71834e9293ee1fe90baf84bf928405cf98
Stats:     6 lines in 2 files changed: 2 ins; 4 del; 0 mod

8268637: Update --release 17 symbol information for JDK 17 build 28

Reviewed-by: iris

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

PR: https://git.openjdk.java.net/jdk/pull/4641

From vromero at openjdk.java.net  Wed Jun 30 22:17:04 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Wed, 30 Jun 2021 22:17:04 GMT
Subject: RFR: 8268592: JDK-8262891 causes an NPE in Lint.augment
In-Reply-To: 
References: 
Message-ID: 

On Tue, 15 Jun 2021 22:36:03 GMT, Liam Miller-Cushon  wrote:

> Avoid descending into lambdas in `Flow.aliveAfter`, since the lambda won't affect the result,
> and to avoid descending into lambda bodies that haven't been attributed yet when `aliveAfter`
> is used while attributing switches.

looks good to me, only a minor comment in the test

test/langtools/tools/javac/T8268592/T8268592.java line 27:

> 25:  * @bug 8268592
> 26:  * @summary JDK-8262891 causes an NPE in Lint.augment
> 27:  * @modules java.compiler

these modules are not being used and can be removed I think

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

Marked as reviewed by vromero (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4502

From cushon at openjdk.java.net  Wed Jun 30 22:31:50 2021
From: cushon at openjdk.java.net (Liam Miller-Cushon)
Date: Wed, 30 Jun 2021 22:31:50 GMT
Subject: RFR: 8268592: JDK-8262891 causes an NPE in Lint.augment [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 30 Jun 2021 22:13:08 GMT, Vicente Romero  wrote:

>> Liam Miller-Cushon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
>> 
>>  - Remove unused modules from test
>>  - 8268592: JDK-8262891 causes an NPE in Lint.augment
>
> test/langtools/tools/javac/T8268592/T8268592.java line 27:
> 
>> 25:  * @bug 8268592
>> 26:  * @summary JDK-8262891 causes an NPE in Lint.augment
>> 27:  * @modules java.compiler
> 
> these modules are not being used and can be removed I think

done

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

PR: https://git.openjdk.java.net/jdk/pull/4502

From cushon at openjdk.java.net  Wed Jun 30 22:31:45 2021
From: cushon at openjdk.java.net (Liam Miller-Cushon)
Date: Wed, 30 Jun 2021 22:31:45 GMT
Subject: RFR: 8268592: JDK-8262891 causes an NPE in Lint.augment
In-Reply-To: 
References: 
Message-ID: 

On Tue, 15 Jun 2021 22:36:03 GMT, Liam Miller-Cushon  wrote:

> Avoid descending into lambdas in `Flow.aliveAfter`, since the lambda won't affect the result,
> and to avoid descending into lambda bodies that haven't been attributed yet when `aliveAfter`
> is used while attributing switches.

I fixed the issue with the test, thanks for the review!

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

PR: https://git.openjdk.java.net/jdk/pull/4502

From cushon at openjdk.java.net  Wed Jun 30 22:31:44 2021
From: cushon at openjdk.java.net (Liam Miller-Cushon)
Date: Wed, 30 Jun 2021 22:31:44 GMT
Subject: RFR: 8268592: JDK-8262891 causes an NPE in Lint.augment [v2]
In-Reply-To: 
References: 
Message-ID: 

> Avoid descending into lambdas in `Flow.aliveAfter`, since the lambda won't affect the result,
> and to avoid descending into lambda bodies that haven't been attributed yet when `aliveAfter`
> is used while attributing switches.

Liam Miller-Cushon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:

 - Remove unused modules from test
 - 8268592: JDK-8262891 causes an NPE in Lint.augment

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4502/files
  - new: https://git.openjdk.java.net/jdk/pull/4502/files/b5b2d54d..559d898f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4502&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4502&range=00-01

  Stats: 44774 lines in 908 files changed: 23539 ins; 18119 del; 3116 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4502.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4502/head:pull/4502

PR: https://git.openjdk.java.net/jdk/pull/4502

From cushon at openjdk.java.net  Wed Jun 30 22:47:11 2021
From: cushon at openjdk.java.net (Liam Miller-Cushon)
Date: Wed, 30 Jun 2021 22:47:11 GMT
Subject: RFR: 8268592: JDK-8262891 causes an NPE in Lint.augment [v2]
In-Reply-To: 
References: 
 
Message-ID: <48wAgIdRv7HZAUqlNdATEP768IQvNLtviirFfOHUYlE=.4e29f34f-519f-4d8d-a2d3-9aa4a233d7ed@github.com>

On Wed, 30 Jun 2021 22:31:44 GMT, Liam Miller-Cushon  wrote:

>> Avoid descending into lambdas in `Flow.aliveAfter`, since the lambda won't affect the result,
>> and to avoid descending into lambda bodies that haven't been attributed yet when `aliveAfter`
>> is used while attributing switches.
>
> Liam Miller-Cushon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Remove unused modules from test
>  - 8268592: JDK-8262891 causes an NPE in Lint.augment

I just realized that since this is a candidate for fixing in 17, I think I'm supposed to send the PR there and it will get automatically merged to mainline (instead of merging it here and backporting to 17) per [the RDP1 thread](https://mail.openjdk.java.net/pipermail/jdk-dev/2021-June/005660.html)?

I opened https://github.com/openjdk/jdk17/pull/188

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

PR: https://git.openjdk.java.net/jdk/pull/4502

From cushon at openjdk.java.net  Wed Jun 30 22:47:21 2021
From: cushon at openjdk.java.net (Liam Miller-Cushon)
Date: Wed, 30 Jun 2021 22:47:21 GMT
Subject: [jdk17] RFR: 8268592: JDK-8262891 causes an NPE in Lint.augment
Message-ID: 

8268592: JDK-8262891 causes an NPE in Lint.augment

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

Commit messages:
 - 8268592: JDK-8262891 causes an NPE in Lint.augment

Changes: https://git.openjdk.java.net/jdk17/pull/188/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=188&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8268592
  Stats: 63 lines in 2 files changed: 63 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/188.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/188/head:pull/188

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

From vromero at openjdk.java.net  Wed Jun 30 23:45:06 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Wed, 30 Jun 2021 23:45:06 GMT
Subject: RFR: 8268592: JDK-8262891 causes an NPE in Lint.augment [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 30 Jun 2021 22:31:44 GMT, Liam Miller-Cushon  wrote:

>> Avoid descending into lambdas in `Flow.aliveAfter`, since the lambda won't affect the result,
>> and to avoid descending into lambda bodies that haven't been attributed yet when `aliveAfter`
>> is used while attributing switches.
>
> Liam Miller-Cushon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Remove unused modules from test
>  - 8268592: JDK-8262891 causes an NPE in Lint.augment

> I just realized that since this is a candidate for fixing in 17, I think I'm supposed to send the PR there and it will get automatically merged to mainline (instead of merging it here and backporting to 17) per [the RDP1 thread](https://mail.openjdk.java.net/pipermail/jdk-dev/2021-June/005660.html)?
> 
> I opened [openjdk/jdk17#188](https://github.com/openjdk/jdk17/pull/188)

right I didn't realized either, just close this one. I have already reviewed the one for 17, thanks

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

PR: https://git.openjdk.java.net/jdk/pull/4502

From vromero at openjdk.java.net  Wed Jun 30 23:44:02 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Wed, 30 Jun 2021 23:44:02 GMT
Subject: [jdk17] RFR: 8268592: JDK-8262891 causes an NPE in Lint.augment
In-Reply-To: 
References: 
Message-ID: 

On Wed, 30 Jun 2021 22:40:50 GMT, Liam Miller-Cushon  wrote:

> 8268592: JDK-8262891 causes an NPE in Lint.augment

looks good

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

Marked as reviewed by vromero (Reviewer).

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

From cushon at openjdk.java.net  Wed Jun 30 23:50:05 2021
From: cushon at openjdk.java.net (Liam Miller-Cushon)
Date: Wed, 30 Jun 2021 23:50:05 GMT
Subject: Withdrawn: 8268592: JDK-8262891 causes an NPE in Lint.augment
In-Reply-To: 
References: 
Message-ID: <4A_Ka4laT3mPSF2TXb6Hk696dJ5UaPKbh0O9yBjs7tg=.75e98152-09e7-4d45-85eb-6681dae62948@github.com>

On Tue, 15 Jun 2021 22:36:03 GMT, Liam Miller-Cushon  wrote:

> Avoid descending into lambdas in `Flow.aliveAfter`, since the lambda won't affect the result,
> and to avoid descending into lambda bodies that haven't been attributed yet when `aliveAfter`
> is used while attributing switches.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.java.net/jdk/pull/4502

