From abimpoudis at openjdk.org  Mon May  1 22:29:27 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 1 May 2023 22:29:27 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v8]
In-Reply-To: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
Message-ID: <pHIzCdIv1Df6qXfNBnxDB0WlFhCUI4J-vXvPhxAeg2Q=.0128fac3-0229-4a8f-9441-0b11ce15734a@github.com>

> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java.
> 
> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/

Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:

  Address comments around JavacParser (remove identOrFlagUnderscore)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13528/files
  - new: https://git.openjdk.org/jdk/pull/13528/files/e39dd6dd..47d738bb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13528&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13528&range=06-07

  Stats: 39 lines in 1 file changed: 12 ins; 20 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/13528.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13528/head:pull/13528

PR: https://git.openjdk.org/jdk/pull/13528

From abimpoudis at openjdk.org  Mon May  1 22:29:30 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 1 May 2023 22:29:30 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v4]
In-Reply-To: <KWkhcjT0YrtpQbu3TRuBU-vbeE-N2jR_L9iwXYu1uNY=.83e2aebb-7dbe-4558-a57c-254d5a213918@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
 <hnd9UyOUlz7cDrjBGvM0cDikvHsUGUPHH5_PW47SJQ8=.65a06139-496b-47a5-832a-62f0367d35f2@github.com>
 <KWkhcjT0YrtpQbu3TRuBU-vbeE-N2jR_L9iwXYu1uNY=.83e2aebb-7dbe-4558-a57c-254d5a213918@github.com>
Message-ID: <FtwLB9zDe9eY-EiqQRoZQQ0tuqmRpBtcUTpsqZD6enY=.bb123da2-db8a-4a44-92d1-1a61eba54205@github.com>

On Fri, 28 Apr 2023 08:56:38 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update test files with JDK 8307007 bug id
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 839:
> 
>> 837:     }
>> 838: 
>> 839:     private UnnamedDetails identOrFlagUnderscore(JCModifiers mods) {
> 
> I'm not 100% sure this is required - the main use seems to be in `variableDeclarator` - but in that method you already have a token to look at, and a set of modifiers that you can augment - so why not just doing everything in that method (instead of preprocessing it?)

Good point. That was an artifact of code evolution. Everything is integrated in `variableDeclarator` now.

> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 3555:
> 
>> 3553:      */
>> 3554:     JCVariableDecl variableDeclarator(JCModifiers mods, JCExpression type, boolean reqInit, Comment dc, boolean localDecl) {
>> 3555:         UnnamedDetails result = identOrFlagUnderscore(mods);
> 
> Why do we need to get the "unnamed details" here, instead of letting the code flow to `variableDeclaratorRest` and do it there?

Indeed. I removed it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1181937000
PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1181937191

From abimpoudis at openjdk.org  Mon May  1 22:32:31 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 1 May 2023 22:32:31 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v4]
In-Reply-To: <KWkhcjT0YrtpQbu3TRuBU-vbeE-N2jR_L9iwXYu1uNY=.83e2aebb-7dbe-4558-a57c-254d5a213918@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
 <hnd9UyOUlz7cDrjBGvM0cDikvHsUGUPHH5_PW47SJQ8=.65a06139-496b-47a5-832a-62f0367d35f2@github.com>
 <KWkhcjT0YrtpQbu3TRuBU-vbeE-N2jR_L9iwXYu1uNY=.83e2aebb-7dbe-4558-a57c-254d5a213918@github.com>
Message-ID: <x1EBPebhAYdhDBa1HqQem0cwRN4CJCpOzrbNSIpbDFE=.58d65c44-2b16-4c50-befc-72b3657e8506@github.com>

On Fri, 28 Apr 2023 09:07:22 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update test files with JDK 8307007 bug id
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1777:
> 
>> 1775:                                 log.error(guard.pos(), Errors.GuardHasConstantExpressionFalse);
>> 1776:                             }
>> 1777:                         } else if (guard != null) {
> 
> I guess this is caused by something like:
> 
> case _ when ...
> 
> If now a guard can appear regardless of how many labels there are, should be refactor this code so that if `guard != null` it is always attributed? And then we do other stuff in case `labels.tail.isEmpty()` ? Note that the code for attributing the guard is slightly different in the two cases in this patch: the original code creates a nested scope - while the new code doesn't.

Actually this is for the case where we have `case A(_), B(C _) when ... `. In that case we are sure that the only scope we can use is the switch environment (since no bindings are introduced). Hm, I don't see another way of refactoring this without depending on `labels.tail.isEmpty()`

> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 826:
> 
>> 824:                 //type test pattern:
>> 825:                 UnnamedDetails result = identOrFlagUnderscore(mods);
>> 826:                 JCVariableDecl var = toP(F.at(result.varPos()).VarDef(mods, result.name(), e, null));
> 
> Do you think we can delegate to `variableDeclarator` here?

The behavior I observe is that `variableDeclarator` does not behave well when we have a `var` instead of a type in a type pattern. `variableDeclarator` is well suited for variable declarations but not for type patterns. But I can investigate further.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1181938984
PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1181938402

From duke at openjdk.org  Tue May  2 00:02:26 2023
From: duke at openjdk.org (duke)
Date: Tue, 2 May 2023 00:02:26 GMT
Subject: Withdrawn: 8303625:
 jdk/jshell/JdiFailingLaunchExecutionControlTest.java fail with -Xcomp
In-Reply-To: <NdskZRNlq86qQ5MIlxr3IXb8T5znS8W3uJ_d8tUvtPM=.9f10c8aa-8ec4-4c9e-aa87-ce4fe5e05408@github.com>
References: <NdskZRNlq86qQ5MIlxr3IXb8T5znS8W3uJ_d8tUvtPM=.9f10c8aa-8ec4-4c9e-aa87-ce4fe5e05408@github.com>
Message-ID: <oLWQdqDIkqW87jqsSAhaJ1L2FlDiQ9uK13GRhIV0A7o=.09842dd5-e24c-4d54-80b6-6553ebf19afc@github.com>

On Mon, 6 Mar 2023 02:38:19 GMT, SUN Guoyun <duke at openjdk.org> wrote:

> This tests failed with VM_OPTIONS=-Xcomp and CONF=fastdebug on the LOONGARCH64 architecture because JdiExecutionControlProvider`s timeout.
> jdk/jshell/JdiFailingLaunchExecutionControlTest.java
> jdk/jshell/JdiFailingListenExecutionControlTest.java
> 
> This PR fix the issue, Please help review it.
> 
> Thanks.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk/pull/12873

From abimpoudis at openjdk.org  Tue May  2 08:20:19 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Tue, 2 May 2023 08:20:19 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v4]
In-Reply-To: <KWkhcjT0YrtpQbu3TRuBU-vbeE-N2jR_L9iwXYu1uNY=.83e2aebb-7dbe-4558-a57c-254d5a213918@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
 <hnd9UyOUlz7cDrjBGvM0cDikvHsUGUPHH5_PW47SJQ8=.65a06139-496b-47a5-832a-62f0367d35f2@github.com>
 <KWkhcjT0YrtpQbu3TRuBU-vbeE-N2jR_L9iwXYu1uNY=.83e2aebb-7dbe-4558-a57c-254d5a213918@github.com>
Message-ID: <xt8H4lrxPjRJhcOEnGU65EcRJ3NRtWdsSjljmRyItM4=.d495fcbc-a254-45ca-a918-7273d0e34978@github.com>

On Fri, 28 Apr 2023 08:59:35 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update test files with JDK 8307007 bug id
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 3660:
> 
>> 3658:         int pos = token.pos;
>> 3659:         Name name;
>> 3660:         if (allowThisIdent ||
> 
> I note that now the error re. underscore on lambda is no longer given even if preview features are disabled. But I guess that's ok. (instead you will probably get an error that unnamed parameters are a preview feature)

Yes, indeed.


~/dev/jdk unnamed !1 > javac Unnamed.java
Unnamed.java:61: error: unnamed variables are a preview feature and are disabled by default.
        TwoParams p1 = (_, _) -> {};
                        ^
  (use --enable-preview to enable unnamed variables)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1182230562

From abimpoudis at openjdk.org  Tue May  2 08:27:20 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Tue, 2 May 2023 08:27:20 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v4]
In-Reply-To: <KWkhcjT0YrtpQbu3TRuBU-vbeE-N2jR_L9iwXYu1uNY=.83e2aebb-7dbe-4558-a57c-254d5a213918@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
 <hnd9UyOUlz7cDrjBGvM0cDikvHsUGUPHH5_PW47SJQ8=.65a06139-496b-47a5-832a-62f0367d35f2@github.com>
 <KWkhcjT0YrtpQbu3TRuBU-vbeE-N2jR_L9iwXYu1uNY=.83e2aebb-7dbe-4558-a57c-254d5a213918@github.com>
Message-ID: <B7qDd8v-AsvIyMeq2UPHLDb848br6nlRGXhfxWp1PXQ=.63596e87-fca8-4e97-b3b5-136d03687260@github.com>

On Fri, 28 Apr 2023 09:20:12 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update test files with JDK 8307007 bug id
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 746:
> 
>> 744: 
>> 745:         sealed interface PatternDescription {
>> 746:             public static PatternDescription from(Types types, Type selectorType, JCPattern pattern, Symtab syms) {
> 
> Optional comment: the fact that this factory needs so much compiler state makes me think that perhaps a better place for it would be as an instance method of Flow, rather than a static method in PatternDescription.

@lahodaj WDYT? Looks like it can be easily refactored and it is used only in one place (apart from the recursive call). I can refactor it in this PR or u can do it in #13074.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1182237560

From abimpoudis at openjdk.org  Tue May  2 09:49:38 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Tue, 2 May 2023 09:49:38 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v9]
In-Reply-To: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
Message-ID: <l7TjQ_VMjFnomt_hmQaAPdqnK61nTcblURH-ZvTkgpY=.e9879992-65c8-45fd-85f4-b4e8037a9ec8@github.com>

> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java.
> 
> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/

Aggelos Biboudis has updated the pull request incrementally with two additional commits since the last revision:

 - Address comments around JavacParser (reuse variableDeclaratorRest in parsePattern)
 - Add new lines and revise comment in Unnamed.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13528/files
  - new: https://git.openjdk.org/jdk/pull/13528/files/47d738bb..3d83fa14

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13528&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13528&range=07-08

  Stats: 49 lines in 4 files changed: 8 ins; 7 del; 34 mod
  Patch: https://git.openjdk.org/jdk/pull/13528.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13528/head:pull/13528

PR: https://git.openjdk.org/jdk/pull/13528

From abimpoudis at openjdk.org  Tue May  2 09:49:42 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Tue, 2 May 2023 09:49:42 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v4]
In-Reply-To: <x1EBPebhAYdhDBa1HqQem0cwRN4CJCpOzrbNSIpbDFE=.58d65c44-2b16-4c50-befc-72b3657e8506@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
 <hnd9UyOUlz7cDrjBGvM0cDikvHsUGUPHH5_PW47SJQ8=.65a06139-496b-47a5-832a-62f0367d35f2@github.com>
 <KWkhcjT0YrtpQbu3TRuBU-vbeE-N2jR_L9iwXYu1uNY=.83e2aebb-7dbe-4558-a57c-254d5a213918@github.com>
 <x1EBPebhAYdhDBa1HqQem0cwRN4CJCpOzrbNSIpbDFE=.58d65c44-2b16-4c50-befc-72b3657e8506@github.com>
Message-ID: <u0__tyRjxt0bQNcwXuKQV4mimQ096EAk0HqdFKuFyLE=.b68eba17-ecbb-4a4f-a09f-420699fd62b5@github.com>

On Mon, 1 May 2023 22:28:00 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 826:
>> 
>>> 824:                 //type test pattern:
>>> 825:                 UnnamedDetails result = identOrFlagUnderscore(mods);
>>> 826:                 JCVariableDecl var = toP(F.at(result.varPos()).VarDef(mods, result.name(), e, null));
>> 
>> Do you think we can delegate to `variableDeclarator` here?
>
> The behavior I observe is that `variableDeclarator` does not behave well when we have a `var` instead of a type in a type pattern. `variableDeclarator` is well suited for variable declarations but not for type patterns. But I can investigate further.

What about reusing `variableDeclaratorRest`? 

https://github.com/openjdk/jdk/pull/13528/commits/3d83fa14ae26981d5b6fc75faa0d3ba9336952b1

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1182329080

From abimpoudis at openjdk.org  Tue May  2 19:27:12 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Tue, 2 May 2023 19:27:12 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v10]
In-Reply-To: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
Message-ID: <IpUNY7S3XYB4Z2GmnMj_jZzw7Tt4yakwDlPFhetEmIE=.f2db4c6a-d920-4afb-8d58-6d669bb5e7b8@github.com>

> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java.
> 
> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/

Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:

  Remove flag
  
  - Fixes unnamed errors
  - Fixes missing test in TestUnnamedVariableElement
  - Removes scope elements from erroneous source file tests in TestGetScopeResult (names.empty is used to signify error when we mix and match implicit and explicit parameters in lambdas)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13528/files
  - new: https://git.openjdk.org/jdk/pull/13528/files/3d83fa14..5c9314d3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13528&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13528&range=08-09

  Stats: 29 lines in 9 files changed: 8 ins; 11 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/13528.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13528/head:pull/13528

PR: https://git.openjdk.org/jdk/pull/13528

From abimpoudis at openjdk.org  Tue May  2 19:27:16 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Tue, 2 May 2023 19:27:16 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v9]
In-Reply-To: <l7TjQ_VMjFnomt_hmQaAPdqnK61nTcblURH-ZvTkgpY=.e9879992-65c8-45fd-85f4-b4e8037a9ec8@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
 <l7TjQ_VMjFnomt_hmQaAPdqnK61nTcblURH-ZvTkgpY=.e9879992-65c8-45fd-85f4-b4e8037a9ec8@github.com>
Message-ID: <eU-tJk0lkGw5x8k28sWCcHPfKbgg1tVPYkwhHLIoYIE=.074f124e-ba76-4c80-8bfb-90b495216833@github.com>

On Tue, 2 May 2023 09:49:38 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java.
>> 
>> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/
>
> Aggelos Biboudis has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Address comments around JavacParser (reuse variableDeclaratorRest in parsePattern)
>  - Add new lines and revise comment in Unnamed.java

@mcimadamore 
@vicente-romero-oracle 
Flag removed in https://github.com/openjdk/jdk/pull/13528/commits/5c9314d3f39dc0e3084c80b7f2ff06e70a363425

re-requesting review ? 

cc-ing @lahodaj

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

PR Comment: https://git.openjdk.org/jdk/pull/13528#issuecomment-1532022476

From jlahoda at openjdk.org  Wed May  3 09:35:03 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 3 May 2023 09:35:03 GMT
Subject: RFR: JDK-8306983: Do not invoke external programs when switch terminal
 to raw mode on selected platforms
Message-ID: <cGOTtVG_NmpIQ7Xpy9rMkVds3JC8az9jj530vVZr134=.4675f46c-8423-4957-ab24-00939d669563@github.com>

To support JShell and other usecases, the JDK uses JLine, which provides line-editing functionality inside a terminal.

JLine has several ways to work with the terminal, based on various additional libraries and tools. Most of them are not directly usable inside the JDK, so currently, on non-Windows platforms, the JLine inside the JDK will use external programs, like `stty`, to inspect the terminal's properties and to switch the terminal to raw mode.

This is slightly problematic, as the external programs might be missing, and while this is not that big problem for JShell, it might be a problem for other potential uses of JLine, like using it inside `System.console()`.

So, the proposal here is to call the corresponding native methods directly, on selected platforms for now (Linux and Mac OS/X), instead of invoking the external programs. On Windows, this has always been the case, we are using a custom implementation of the interface that maps native and Java function for JNA there, and the proposal is to do the same here. We take the appropriate mapping interface for JNA, and provide hand-written implementation for it, using JNI.

The Windows implementation is mostly unchanged, the changes are mostly non-Windows only. The overview of the changes is:
 - `LastErrorException` is moved from the Windows-specific code to the platform-neutral code, as it is used by all the native implementations. This is the only change that directly affects the Windows-specific code
 -  `unix/classes/jdk/internal/org/jline/terminal/impl/jna/JnaNativePty.java` and `unix/classes/jdk/internal/org/jline/terminal/impl/jna/JnaTerminalProvider.java` are created based on the corresponding files from JLine. In JLine, these files directly call platform-specific implementations, but in this patch, the platform specific code is commented out, and replaced with calls to `JDKNativePty`, which is a new platform-specific class, that delegates to the actual platform-specific implementations. Note the `JnaNativePty.java` and `JnaTerminalProvider.java` already exist in the Windows part, but have different pieces of code commented out, which makes them substantially different.
 - for Linux and Mac OS/X, there are platform-specific implementations based on the corresponding code from JLine, with the hand-written JNI-based implementation of the JNA-based existing interfaces. They also have an implementation of `JDKNativePty`, which just delegates to the given platform's `"NativePty"` implementation.
 - the `JdkConsoleProviderImpl.java` has been tweaked to not allow the implementation based on the external programs, and gracefully falling back to the standard implementation. JShell is kept unchanged.

The reasons for this organization are: limiting duplication, mostly adhering to the JDK's platform specific build (which is different from the normal JLine's platform-neutral build) and limiting the difference between standard JLine and JLine inside JDK, to help future upgrades.

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

Commit messages:
 - Removing tabs
 - Adding handling of errors in the jni code.
 - Permit dumb terminals.
 - Only create JLine-based Console when the direct terminal access passes.
 - Attempting to minimize the diff between JDK and vanilla JLine on Mac.
 - Reorganizing the native classes.
 - mac impl
 - Using direct native calls instead of stty on Linux.

Changes: https://git.openjdk.org/jdk/pull/13687/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13687&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8306983
  Stats: 2144 lines in 23 files changed: 2096 ins; 40 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/13687.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13687/head:pull/13687

PR: https://git.openjdk.org/jdk/pull/13687

From erikj at openjdk.org  Wed May  3 13:56:16 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 3 May 2023 13:56:16 GMT
Subject: RFR: JDK-8306983: Do not invoke external programs when switch
 terminal to raw mode on selected platforms
In-Reply-To: <cGOTtVG_NmpIQ7Xpy9rMkVds3JC8az9jj530vVZr134=.4675f46c-8423-4957-ab24-00939d669563@github.com>
References: <cGOTtVG_NmpIQ7Xpy9rMkVds3JC8az9jj530vVZr134=.4675f46c-8423-4957-ab24-00939d669563@github.com>
Message-ID: <r7JG-8OhdmxHG4Co6FDmTYz1w2MVEPjvek-7Ry-Usyo=.817b87f3-acc0-4dfa-a196-39a73f3469b0@github.com>

On Thu, 27 Apr 2023 11:21:04 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> To support JShell and other usecases, the JDK uses JLine, which provides line-editing functionality inside a terminal.
> 
> JLine has several ways to work with the terminal, based on various additional libraries and tools. Most of them are not directly usable inside the JDK, so currently, on non-Windows platforms, the JLine inside the JDK will use external programs, like `stty`, to inspect the terminal's properties and to switch the terminal to raw mode.
> 
> This is slightly problematic, as the external programs might be missing, and while this is not that big problem for JShell, it might be a problem for other potential uses of JLine, like using it inside `System.console()`.
> 
> So, the proposal here is to call the corresponding native methods directly, on selected platforms for now (Linux and Mac OS/X), instead of invoking the external programs. On Windows, this has always been the case, we are using a custom implementation of the interface that maps native and Java function for JNA there, and the proposal is to do the same here. We take the appropriate mapping interface for JNA, and provide hand-written implementation for it, using JNI.
> 
> The Windows implementation is mostly unchanged, the changes are mostly non-Windows only. The overview of the changes is:
>  - `LastErrorException` is moved from the Windows-specific code to the platform-neutral code, as it is used by all the native implementations. This is the only change that directly affects the Windows-specific code
>  -  `unix/classes/jdk/internal/org/jline/terminal/impl/jna/JnaNativePty.java` and `unix/classes/jdk/internal/org/jline/terminal/impl/jna/JnaTerminalProvider.java` are created based on the corresponding files from JLine. In JLine, these files directly call platform-specific implementations, but in this patch, the platform specific code is commented out, and replaced with calls to `JDKNativePty`, which is a new platform-specific class, that delegates to the actual platform-specific implementations. Note the `JnaNativePty.java` and `JnaTerminalProvider.java` already exist in the Windows part, but have different pieces of code commented out, which makes them substantially different.
>  - for Linux and Mac OS/X, there are platform-specific implementations based on the corresponding code from JLine, with the hand-written JNI-based implementation of the JNA-based existing interfaces. They also have an implementation of `JDKNativePty`, which just delegates to the given platform's `"NativePty"` implementation.
>  - the `JdkConsoleProviderImpl.java` has been tweaked to not allow the implementation based on the external programs, and gracefully falling back to the standard implementation. JShell is kept unchanged.
> 
> The reasons for this organization are: limiting duplication, mostly adhering to the JDK's platform specific build (which is different from the normal JLine's platform-neutral build) and limiting the difference between standard JLine and JLine inside JDK, to help future upgrades.

make/modules/jdk.internal.le/Lib.gmk line 38:

> 36:       LDFLAGS := $(LDFLAGS_JDKLIB), \
> 37:       LIBS_windows := $(JDKLIB_LIBS) user32.lib, \
> 38:       LIBS_unix := $(JDKLIB_LIBS) -lstdc++, \

If this is a C++ library, I think it's better to specify `TOOLCHAIN := TOOLCHAIN_LINK_CXX` than adding `-lstdc++`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13687#discussion_r1183721435

From erikj at openjdk.org  Wed May  3 14:01:23 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 3 May 2023 14:01:23 GMT
Subject: RFR: JDK-8306983: Do not invoke external programs when switch
 terminal to raw mode on selected platforms
In-Reply-To: <r7JG-8OhdmxHG4Co6FDmTYz1w2MVEPjvek-7Ry-Usyo=.817b87f3-acc0-4dfa-a196-39a73f3469b0@github.com>
References: <cGOTtVG_NmpIQ7Xpy9rMkVds3JC8az9jj530vVZr134=.4675f46c-8423-4957-ab24-00939d669563@github.com>
 <r7JG-8OhdmxHG4Co6FDmTYz1w2MVEPjvek-7Ry-Usyo=.817b87f3-acc0-4dfa-a196-39a73f3469b0@github.com>
Message-ID: <ovA9Co_nKY_oepVda0ew2WxsFC26a-k5I6RHsH3RrwI=.b1eb0a8a-891a-4081-ad07-ce2bb8e8fea9@github.com>

On Wed, 3 May 2023 13:53:20 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> To support JShell and other usecases, the JDK uses JLine, which provides line-editing functionality inside a terminal.
>> 
>> JLine has several ways to work with the terminal, based on various additional libraries and tools. Most of them are not directly usable inside the JDK, so currently, on non-Windows platforms, the JLine inside the JDK will use external programs, like `stty`, to inspect the terminal's properties and to switch the terminal to raw mode.
>> 
>> This is slightly problematic, as the external programs might be missing, and while this is not that big problem for JShell, it might be a problem for other potential uses of JLine, like using it inside `System.console()`.
>> 
>> So, the proposal here is to call the corresponding native methods directly, on selected platforms for now (Linux and Mac OS/X), instead of invoking the external programs. On Windows, this has always been the case, we are using a custom implementation of the interface that maps native and Java function for JNA there, and the proposal is to do the same here. We take the appropriate mapping interface for JNA, and provide hand-written implementation for it, using JNI.
>> 
>> The Windows implementation is mostly unchanged, the changes are mostly non-Windows only. The overview of the changes is:
>>  - `LastErrorException` is moved from the Windows-specific code to the platform-neutral code, as it is used by all the native implementations. This is the only change that directly affects the Windows-specific code
>>  -  `unix/classes/jdk/internal/org/jline/terminal/impl/jna/JnaNativePty.java` and `unix/classes/jdk/internal/org/jline/terminal/impl/jna/JnaTerminalProvider.java` are created based on the corresponding files from JLine. In JLine, these files directly call platform-specific implementations, but in this patch, the platform specific code is commented out, and replaced with calls to `JDKNativePty`, which is a new platform-specific class, that delegates to the actual platform-specific implementations. Note the `JnaNativePty.java` and `JnaTerminalProvider.java` already exist in the Windows part, but have different pieces of code commented out, which makes them substantially different.
>>  - for Linux and Mac OS/X, there are platform-specific implementations based on the corresponding code from JLine, with the hand-written JNI-based implementation of the JNA-based existing interfaces. They also have an implementation of `JDKNativePty`, which just delegates to the given platform's `"NativePty"` implementation.
>>  - the `JdkConsoleProviderImpl.java` has been tweaked to not allow the implementation based on the external programs, and gracefully falling back to the standard implementation. JShell is kept unchanged.
>> 
>> The reasons for this organization are: limiting duplication, mostly adhering to the JDK's platform specific build (which is different from the normal JLine's platform-neutral build) and limiting the difference between standard JLine and JLine inside JDK, to help future upgrades.
>
> make/modules/jdk.internal.le/Lib.gmk line 38:
> 
>> 36:       LDFLAGS := $(LDFLAGS_JDKLIB), \
>> 37:       LIBS_windows := $(JDKLIB_LIBS) user32.lib, \
>> 38:       LIBS_unix := $(JDKLIB_LIBS) -lstdc++, \
> 
> If this is a C++ library, I think it's better to specify `TOOLCHAIN := TOOLCHAIN_LINK_CXX` than adding `-lstdc++`.

We may also need `$(LIBCXX)` to force static linking when that is enabled for the build.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13687#discussion_r1183728006

From abimpoudis at openjdk.org  Wed May  3 14:29:23 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 3 May 2023 14:29:23 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v11]
In-Reply-To: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
Message-ID: <Ho2Jw4chf6MFi3CZimytOd7KcqRimKecY3GsoRxc-p0=.f5b3d099-d073-4a7e-b3ac-df4b13636416@github.com>

> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java.
> 
> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/

Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:

  Add guard test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13528/files
  - new: https://git.openjdk.org/jdk/pull/13528/files/5c9314d3..e95465ed

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13528&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13528&range=09-10

  Stats: 15 lines in 2 files changed: 14 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13528.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13528/head:pull/13528

PR: https://git.openjdk.org/jdk/pull/13528

From abimpoudis at openjdk.org  Wed May  3 15:41:19 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 3 May 2023 15:41:19 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v4]
In-Reply-To: <KWkhcjT0YrtpQbu3TRuBU-vbeE-N2jR_L9iwXYu1uNY=.83e2aebb-7dbe-4558-a57c-254d5a213918@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
 <hnd9UyOUlz7cDrjBGvM0cDikvHsUGUPHH5_PW47SJQ8=.65a06139-496b-47a5-832a-62f0367d35f2@github.com>
 <KWkhcjT0YrtpQbu3TRuBU-vbeE-N2jR_L9iwXYu1uNY=.83e2aebb-7dbe-4558-a57c-254d5a213918@github.com>
Message-ID: <jwyMS6mf5hWnF03GAi-kSZpkqvKE-TX8V8MSEvrFslg=.c4501fe4-db20-4da1-a298-3a4851d9ffd8@github.com>

On Fri, 28 Apr 2023 09:16:29 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update test files with JDK 8307007 bug id
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/MemberEnter.java line 295:
> 
>> 293:                 : tree.vartype.type;
>> 294:         Name name;
>> 295:         if (Feature.UNNAMED_VARIABLES.allowedInSource(source) && (tree.mods.flags & UNNAMED) != 0) {
> 
> Not 100% sure what this code does. E.g. shouldn't we just set the name of the variable as the name stored in the tree? It seems more economical if we could just set in the parser the name as empty (if preview features are enabled etc.) - and then all these special cases can disappear. After all, you still have the flag (and even then, do we need a flag? Can't we just see whether the name is empty to see that it's unnamed?)

This is still needed because we want to have a different name for the Tree API (_) and the symbol (empty).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1183863324

From naoto at openjdk.org  Wed May  3 17:51:19 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 3 May 2023 17:51:19 GMT
Subject: RFR: JDK-8306983: Do not invoke external programs when switch
 terminal to raw mode on selected platforms
In-Reply-To: <cGOTtVG_NmpIQ7Xpy9rMkVds3JC8az9jj530vVZr134=.4675f46c-8423-4957-ab24-00939d669563@github.com>
References: <cGOTtVG_NmpIQ7Xpy9rMkVds3JC8az9jj530vVZr134=.4675f46c-8423-4957-ab24-00939d669563@github.com>
Message-ID: <D8xh9HL08eTQ1spEaQFMBo_SQwApd3jgocysAqLNrNA=.fcb37874-1492-427a-b98e-e13732a6aa97@github.com>

On Thu, 27 Apr 2023 11:21:04 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> To support JShell and other usecases, the JDK uses JLine, which provides line-editing functionality inside a terminal.
> 
> JLine has several ways to work with the terminal, based on various additional libraries and tools. Most of them are not directly usable inside the JDK, so currently, on non-Windows platforms, the JLine inside the JDK will use external programs, like `stty`, to inspect the terminal's properties and to switch the terminal to raw mode.
> 
> This is slightly problematic, as the external programs might be missing, and while this is not that big problem for JShell, it might be a problem for other potential uses of JLine, like using it inside `System.console()`.
> 
> So, the proposal here is to call the corresponding native methods directly, on selected platforms for now (Linux and Mac OS/X), instead of invoking the external programs. On Windows, this has always been the case, we are using a custom implementation of the interface that maps native and Java function for JNA there, and the proposal is to do the same here. We take the appropriate mapping interface for JNA, and provide hand-written implementation for it, using JNI.
> 
> The Windows implementation is mostly unchanged, the changes are mostly non-Windows only. The overview of the changes is:
>  - `LastErrorException` is moved from the Windows-specific code to the platform-neutral code, as it is used by all the native implementations. This is the only change that directly affects the Windows-specific code
>  -  `unix/classes/jdk/internal/org/jline/terminal/impl/jna/JnaNativePty.java` and `unix/classes/jdk/internal/org/jline/terminal/impl/jna/JnaTerminalProvider.java` are created based on the corresponding files from JLine. In JLine, these files directly call platform-specific implementations, but in this patch, the platform specific code is commented out, and replaced with calls to `JDKNativePty`, which is a new platform-specific class, that delegates to the actual platform-specific implementations. Note the `JnaNativePty.java` and `JnaTerminalProvider.java` already exist in the Windows part, but have different pieces of code commented out, which makes them substantially different.
>  - for Linux and Mac OS/X, there are platform-specific implementations based on the corresponding code from JLine, with the hand-written JNI-based implementation of the JNA-based existing interfaces. They also have an implementation of `JDKNativePty`, which just delegates to the given platform's `"NativePty"` implementation.
>  - the `JdkConsoleProviderImpl.java` has been tweaked to not allow the implementation based on the external programs, and gracefully falling back to the standard implementation. JShell is kept unchanged.
> 
> The reasons for this organization are: limiting duplication, mostly adhering to the JDK's platform specific build (which is different from the normal JLine's platform-neutral build) and limiting the difference between standard JLine and JLine inside JDK, to help future upgrades.

Changes in `JdkConsoleProviderImpl.java` look good to me. Didn't look at other diffs closely, but it seems some other files are missing Oracle copyright text.

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

PR Review: https://git.openjdk.org/jdk/pull/13687#pullrequestreview-1411449102

From coffeys at openjdk.org  Thu May  4 15:01:19 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Thu, 4 May 2023 15:01:19 GMT
Subject: RFR: 8305714 : Add an extra test for JDK-8292755 [v2]
In-Reply-To: <zjm8VwExtNx-yK6UEniF3NgwHSkHvD9Tz-8OzlUaDig=.cc6ce6a0-8b80-4665-b3cc-6a5b230bfcd3@github.com>
References: <Qgv51p9m_Qj9-1EW_Ehh75Fgij7jOA-PFeEAW1Xndls=.18de61e9-f15a-44f4-9b43-05284b4c82df@github.com>
 <zjm8VwExtNx-yK6UEniF3NgwHSkHvD9Tz-8OzlUaDig=.cc6ce6a0-8b80-4665-b3cc-6a5b230bfcd3@github.com>
Message-ID: <pqtav6X84bpa8CpsgCjQ2MRtLty61R5nXqX803uTOdg=.4a1822ab-d798-4271-ad79-d9a182ecef66@github.com>

On Fri, 28 Apr 2023 16:20:24 GMT, Weibing Xiao <duke at openjdk.org> wrote:

>> Add a testing case for undefined classes in Java JShell to make sure JShell does not crash when an undefined class is used.
>> 
>> This test was passed for Linux, MacOS, and Windows by mach5 build and test in Oracle.
>> 
>> Reviewer: @coffeys @lahodaj
>
> Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   modify bug id

Looks good - minor suggestions

test/langtools/jdk/jshell/UndefinedClassTest.java line 27:

> 25:  * @test
> 26:  * @bug 8292755
> 27:  * @summary make sure JShell not crashing while throwing undefined exception

I'd suggest "InternalError seen while throwing undefined exception" as summary.

test/langtools/jdk/jshell/UndefinedClassTest.java line 55:

> 53:                 " void run() throws Throwable;\n" +
> 54:                 "\n" +
> 55:                 " // You can also replace `static` with `default` and test again\n" +

why the comment in test code ? maybe you can create a 2nd test instead :


    public void testUndefinedClass1() throws Exception{
        String code = "@FunctionalInterface\n" +
                "interface RunnableWithThrowable {\n" +
                " void run() throws Throwable;\n" +
                "\n" +
                " default RunnableWithThrowable getInstance() {\n" +
                " return () -> { throw new NotExist(); };\n" +
                " }\n" +
                "}";
        // set terminal height so that help output won't hit page breaks
        System.setProperty("test.terminal.height", "1000000");
        doRunTest((inputSink, out) -> {
            inputSink.write(code + "\n");
            waitOutput(out, "NotExist");
        });
    }

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

PR Review: https://git.openjdk.org/jdk/pull/13719#pullrequestreview-1413326124
PR Review Comment: https://git.openjdk.org/jdk/pull/13719#discussion_r1185147502
PR Review Comment: https://git.openjdk.org/jdk/pull/13719#discussion_r1185147670

From abimpoudis at openjdk.org  Thu May  4 15:08:21 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 4 May 2023 15:08:21 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v12]
In-Reply-To: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
Message-ID: <Cayb1Dvz1LPjI6b-pCwms_qjyoLqWrAvhuaC3vfEOb4=.63d57ccc-33a2-4fff-8d51-172365113457@github.com>

> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java.
> 
> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/

Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:

  8307444: java.lang.AssertionError when using unnamed patterns

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13528/files
  - new: https://git.openjdk.org/jdk/pull/13528/files/e95465ed..12ce9e19

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13528&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13528&range=10-11

  Stats: 18 lines in 2 files changed: 15 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/13528.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13528/head:pull/13528

PR: https://git.openjdk.org/jdk/pull/13528

From duke at openjdk.org  Thu May  4 16:34:32 2023
From: duke at openjdk.org (Weibing Xiao)
Date: Thu, 4 May 2023 16:34:32 GMT
Subject: RFR: 8305714 : Add an extra test for JDK-8292755 [v3]
In-Reply-To: <Qgv51p9m_Qj9-1EW_Ehh75Fgij7jOA-PFeEAW1Xndls=.18de61e9-f15a-44f4-9b43-05284b4c82df@github.com>
References: <Qgv51p9m_Qj9-1EW_Ehh75Fgij7jOA-PFeEAW1Xndls=.18de61e9-f15a-44f4-9b43-05284b4c82df@github.com>
Message-ID: <KpaKnjGs-9Du1_S9J87fxoBsgCLi9ozBNrXTDzczqCs=.2ce531af-24ec-4142-8156-5c61e5d73423@github.com>

> Add a testing case for undefined classes in Java JShell to make sure JShell does not crash when an undefined class is used.
> 
> This test was passed for Linux, MacOS, and Windows by mach5 build and test in Oracle.
> 
> Reviewer: @coffeys @lahodaj

Weibing Xiao has updated the pull request incrementally with two additional commits since the last revision:

 - add an empty to see if remote repo got updated
 - update according to the comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13719/files
  - new: https://git.openjdk.org/jdk/pull/13719/files/5750a105..36e72a6f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13719&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13719&range=01-02

  Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/13719.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13719/head:pull/13719

PR: https://git.openjdk.org/jdk/pull/13719

From duke at openjdk.org  Thu May  4 17:21:50 2023
From: duke at openjdk.org (Weibing Xiao)
Date: Thu, 4 May 2023 17:21:50 GMT
Subject: RFR: 8305714 : Add an extra test for JDK-8292755 [v4]
In-Reply-To: <Qgv51p9m_Qj9-1EW_Ehh75Fgij7jOA-PFeEAW1Xndls=.18de61e9-f15a-44f4-9b43-05284b4c82df@github.com>
References: <Qgv51p9m_Qj9-1EW_Ehh75Fgij7jOA-PFeEAW1Xndls=.18de61e9-f15a-44f4-9b43-05284b4c82df@github.com>
Message-ID: <adIn5KC7Za-FhHAVfsjTiXHZAhqjUoe6nFlKFb87HyE=.253d4b94-3c92-4e49-ba7e-be5e24936ccf@github.com>

> Add a testing case for undefined classes in Java JShell to make sure JShell does not crash when an undefined class is used.
> 
> This test was passed for Linux, MacOS, and Windows by mach5 build and test in Oracle.
> 
> Reviewer: @coffeys @lahodaj

Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision:

  Revert "add an empty to see if remote repo got updated"
  
  This reverts commit 36e72a6f3b63813cb4fd8cce94ca6571415c7093.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13719/files
  - new: https://git.openjdk.org/jdk/pull/13719/files/36e72a6f..c83caa98

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13719&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13719&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13719.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13719/head:pull/13719

PR: https://git.openjdk.org/jdk/pull/13719

From mcimadamore at openjdk.org  Thu May  4 17:23:26 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 4 May 2023 17:23:26 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v12]
In-Reply-To: <Cayb1Dvz1LPjI6b-pCwms_qjyoLqWrAvhuaC3vfEOb4=.63d57ccc-33a2-4fff-8d51-172365113457@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
 <Cayb1Dvz1LPjI6b-pCwms_qjyoLqWrAvhuaC3vfEOb4=.63d57ccc-33a2-4fff-8d51-172365113457@github.com>
Message-ID: <nKJajz0Cn8d82HReHtqyd122PMBiWreRQGX6cOz-Cg4=.56f78c17-4572-4a25-a021-a2012dc8857b@github.com>

On Thu, 4 May 2023 15:08:21 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java.
>> 
>> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8307444: java.lang.AssertionError when using unnamed patterns

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 4165:

> 4163:         tree.type = tree.var.type = type;
> 4164:         Name name = tree.var.name;
> 4165:         if (name == names.underscore) name = names.empty;

Why isn't the parser doing this?

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/MemberEnter.java line 295:

> 293:                 : tree.vartype.type;
> 294:         Name name = tree.name;
> 295:         if (Feature.UNNAMED_VARIABLES.allowedInSource(source) && name == names.underscore) name = names.empty;

Same, I believe the parser should have set the right name on this

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 3591:

> 3589:                 }
> 3590:             }
> 3591:             result = toP(F.at(pos).VarDef(mods, name, type, init, declaredUsingVar));

I think this should check whether name is underscore (and feature is enabled) and, if that's the case, replace the name with an empty name, so that the rest of the compiler is already correct.

Also, related, no matter what, I think javac's Pretty class should be updated to render variables with empty name as "_" when the tree is turned back into source.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1185294832
PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1185295283
PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1185299587

From duke at openjdk.org  Thu May  4 17:35:19 2023
From: duke at openjdk.org (Weibing Xiao)
Date: Thu, 4 May 2023 17:35:19 GMT
Subject: RFR: 8305714 : Add an extra test for JDK-8292755 [v4]
In-Reply-To: <adIn5KC7Za-FhHAVfsjTiXHZAhqjUoe6nFlKFb87HyE=.253d4b94-3c92-4e49-ba7e-be5e24936ccf@github.com>
References: <Qgv51p9m_Qj9-1EW_Ehh75Fgij7jOA-PFeEAW1Xndls=.18de61e9-f15a-44f4-9b43-05284b4c82df@github.com>
 <adIn5KC7Za-FhHAVfsjTiXHZAhqjUoe6nFlKFb87HyE=.253d4b94-3c92-4e49-ba7e-be5e24936ccf@github.com>
Message-ID: <hHVNhYSrylIdmnzSsjXB88u6xFWA4YBXdtvWkAmzQSc=.fd7f68b1-f1a6-4b95-918f-653d9d59de9c@github.com>

On Thu, 4 May 2023 17:21:50 GMT, Weibing Xiao <duke at openjdk.org> wrote:

>> Add a testing case for undefined classes in Java JShell to make sure JShell does not crash when an undefined class is used.
>> 
>> This test was passed for Linux, MacOS, and Windows by mach5 build and test in Oracle.
>> 
>> Reviewer: @coffeys @lahodaj
>
> Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "add an empty to see if remote repo got updated"
>   
>   This reverts commit 36e72a6f3b63813cb4fd8cce94ca6571415c7093.

@lahodaj , let me know if you have any concerns and comments. Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/13719#issuecomment-1535154083

From duke at openjdk.org  Thu May  4 17:35:23 2023
From: duke at openjdk.org (Weibing Xiao)
Date: Thu, 4 May 2023 17:35:23 GMT
Subject: RFR: 8305714 : Add an extra test for JDK-8292755 [v2]
In-Reply-To: <pqtav6X84bpa8CpsgCjQ2MRtLty61R5nXqX803uTOdg=.4a1822ab-d798-4271-ad79-d9a182ecef66@github.com>
References: <Qgv51p9m_Qj9-1EW_Ehh75Fgij7jOA-PFeEAW1Xndls=.18de61e9-f15a-44f4-9b43-05284b4c82df@github.com>
 <zjm8VwExtNx-yK6UEniF3NgwHSkHvD9Tz-8OzlUaDig=.cc6ce6a0-8b80-4665-b3cc-6a5b230bfcd3@github.com>
 <pqtav6X84bpa8CpsgCjQ2MRtLty61R5nXqX803uTOdg=.4a1822ab-d798-4271-ad79-d9a182ecef66@github.com>
Message-ID: <bf1zbM83fv__V6q3s-Isf1UZFpz-SycocG-gZoe1oM8=.4b222e93-200a-4c54-87c5-1869805ab839@github.com>

On Thu, 4 May 2023 14:57:37 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   modify bug id
>
> test/langtools/jdk/jshell/UndefinedClassTest.java line 55:
> 
>> 53:                 " void run() throws Throwable;\n" +
>> 54:                 "\n" +
>> 55:                 " // You can also replace `static` with `default` and test again\n" +
> 
> why the comment in test code ? maybe you can create a 2nd test instead :
> 
> 
>     public void testUndefinedClass1() throws Exception{
>         String code = "@FunctionalInterface\n" +
>                 "interface RunnableWithThrowable {\n" +
>                 " void run() throws Throwable;\n" +
>                 "\n" +
>                 " default RunnableWithThrowable getInstance() {\n" +
>                 " return () -> { throw new NotExist(); };\n" +
>                 " }\n" +
>                 "}";
>         // set terminal height so that help output won't hit page breaks
>         System.setProperty("test.terminal.height", "1000000");
>         doRunTest((inputSink, out) -> {
>             inputSink.write(code + "\n");
>             waitOutput(out, "NotExist");
>         });
>     }

Updated the summary. And I remove the code to set the terminal height. I don't think it is necessary since there are only two lines for the print-out.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13719#discussion_r1185311268

From abimpoudis at openjdk.org  Thu May  4 17:48:28 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 4 May 2023 17:48:28 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v13]
In-Reply-To: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
Message-ID: <7x1mAOBwhQdGgCaHjiOQ1O9BCmgJFKASy7yFJHsGVbI=.842ee2fe-8819-4e43-935a-120303815fd5@github.com>

> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java.
> 
> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/

Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:

  Add test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13528/files
  - new: https://git.openjdk.org/jdk/pull/13528/files/12ce9e19..ffae4e0e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13528&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13528&range=11-12

  Stats: 46 lines in 1 file changed: 46 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13528.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13528/head:pull/13528

PR: https://git.openjdk.org/jdk/pull/13528

From vromero at openjdk.org  Thu May  4 17:51:22 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 4 May 2023 17:51:22 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v12]
In-Reply-To: <nKJajz0Cn8d82HReHtqyd122PMBiWreRQGX6cOz-Cg4=.56f78c17-4572-4a25-a021-a2012dc8857b@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
 <Cayb1Dvz1LPjI6b-pCwms_qjyoLqWrAvhuaC3vfEOb4=.63d57ccc-33a2-4fff-8d51-172365113457@github.com>
 <nKJajz0Cn8d82HReHtqyd122PMBiWreRQGX6cOz-Cg4=.56f78c17-4572-4a25-a021-a2012dc8857b@github.com>
Message-ID: <Y0ieP2NFRNAlY6yJDOrzDc1QtXrxuj23cKVxupFsjis=.bba83b2d-ef93-49e8-ad61-e966d7a8c2f1@github.com>

On Thu, 4 May 2023 17:20:35 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8307444: java.lang.AssertionError when using unnamed patterns
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 3591:
> 
>> 3589:                 }
>> 3590:             }
>> 3591:             result = toP(F.at(pos).VarDef(mods, name, type, init, declaredUsingVar));
> 
> I think this should check whether name is underscore (and feature is enabled) and, if that's the case, replace the name with an empty name, so that the rest of the compiler is already correct.
> 
> Also, related, no matter what, I think javac's Pretty class should be updated to render variables with empty name as "_" when the tree is turned back into source.

yep I agree with this, the parser should set the right name as soon as it sees a `_`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1185327903

From abimpoudis at openjdk.org  Thu May  4 18:23:24 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 4 May 2023 18:23:24 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v12]
In-Reply-To: <Y0ieP2NFRNAlY6yJDOrzDc1QtXrxuj23cKVxupFsjis=.bba83b2d-ef93-49e8-ad61-e966d7a8c2f1@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
 <Cayb1Dvz1LPjI6b-pCwms_qjyoLqWrAvhuaC3vfEOb4=.63d57ccc-33a2-4fff-8d51-172365113457@github.com>
 <nKJajz0Cn8d82HReHtqyd122PMBiWreRQGX6cOz-Cg4=.56f78c17-4572-4a25-a021-a2012dc8857b@github.com>
 <Y0ieP2NFRNAlY6yJDOrzDc1QtXrxuj23cKVxupFsjis=.bba83b2d-ef93-49e8-ad61-e966d7a8c2f1@github.com>
Message-ID: <QwtC1Vpb7MiYwCY1TEZw_9ycQpOcITtbYDq3HkaEF3M=.9dbfa789-df0a-42c4-aeaf-56ea134de822@github.com>

On Thu, 4 May 2023 17:48:31 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 3591:
>> 
>>> 3589:                 }
>>> 3590:             }
>>> 3591:             result = toP(F.at(pos).VarDef(mods, name, type, init, declaredUsingVar));
>> 
>> I think this should check whether name is underscore (and feature is enabled) and, if that's the case, replace the name with an empty name, so that the rest of the compiler is already correct.
>> 
>> Also, related, no matter what, I think javac's Pretty class should be updated to render variables with empty name as "_" when the tree is turned back into source.
>
> yep I agree with this, the parser should set the right name as soon as it sees a `_`

We could indeed if we wanted to store `empty` everywhere. However, after some off-list discussions I updated the CSR (and the code) to include `empty` as the name at the symbol-level (for consistency with javax model) and `_` at the Tree API-level for its version of a name. This is the rationale behind what you see in Attr (for patterns) and member enter for all other cases. @jddarcy what do you think?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1185358285

From vromero at openjdk.org  Thu May  4 18:55:21 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 4 May 2023 18:55:21 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v13]
In-Reply-To: <7x1mAOBwhQdGgCaHjiOQ1O9BCmgJFKASy7yFJHsGVbI=.842ee2fe-8819-4e43-935a-120303815fd5@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
 <7x1mAOBwhQdGgCaHjiOQ1O9BCmgJFKASy7yFJHsGVbI=.842ee2fe-8819-4e43-935a-120303815fd5@github.com>
Message-ID: <YJbiOqulqaNjr_uPG-xXFWnZc3LHyDalyjzQ_aktkEQ=.6dfcaa14-e07c-4553-9da2-aab82d84efd9@github.com>

On Thu, 4 May 2023 17:48:28 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java.
>> 
>> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add test

src/jdk.compiler/share/classes/com/sun/source/tree/VariableTree.java line 54:

> 52: 
> 53:     /**
> 54:      * Returns the name of the variable being declared or `_` if the variable

I guess if we go full for the empty name then this will need to change too

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java line 69:

> 67: import com.sun.tools.javac.util.Names;
> 68: 
> 69: import java.util.*;

nit: I think we prefer not using star imports, this was probably done by the IDE

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1185336672
PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1185393785

From vromero at openjdk.org  Thu May  4 19:33:28 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 4 May 2023 19:33:28 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v13]
In-Reply-To: <7x1mAOBwhQdGgCaHjiOQ1O9BCmgJFKASy7yFJHsGVbI=.842ee2fe-8819-4e43-935a-120303815fd5@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
 <7x1mAOBwhQdGgCaHjiOQ1O9BCmgJFKASy7yFJHsGVbI=.842ee2fe-8819-4e43-935a-120303815fd5@github.com>
Message-ID: <RJpTnXC2Mia4Nmj9GIF0jg22cpjKXNi300Y3LOP-FyI=.a0d946c1-e6fa-4ade-9149-5c6d440a020b@github.com>

On Thu, 4 May 2023 17:48:28 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java.
>> 
>> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add test

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java line 535:

> 533:                 if (clearedPatterns.size() > 1) {
> 534:                     validCaseLabelList = clearedPatterns.stream().allMatch(cP -> cP.hasTag(Tag.PATTERNCASELABEL));
> 535:                 } else validCaseLabelList = clearedPatterns.size() == 1 && clearedPatterns.head.hasTag(Tag.PATTERNCASELABEL);

style: I would use `{}` for the code in the `else` branch here, same way as it has been done for the `then` branch. Also in the `else` branch isn't the `clearedPatterns.size() == 1` condition always true?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1185430664

From darcy at openjdk.org  Thu May  4 20:01:23 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 4 May 2023 20:01:23 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v12]
In-Reply-To: <QwtC1Vpb7MiYwCY1TEZw_9ycQpOcITtbYDq3HkaEF3M=.9dbfa789-df0a-42c4-aeaf-56ea134de822@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
 <Cayb1Dvz1LPjI6b-pCwms_qjyoLqWrAvhuaC3vfEOb4=.63d57ccc-33a2-4fff-8d51-172365113457@github.com>
 <nKJajz0Cn8d82HReHtqyd122PMBiWreRQGX6cOz-Cg4=.56f78c17-4572-4a25-a021-a2012dc8857b@github.com>
 <Y0ieP2NFRNAlY6yJDOrzDc1QtXrxuj23cKVxupFsjis=.bba83b2d-ef93-49e8-ad61-e966d7a8c2f1@github.com>
 <QwtC1Vpb7MiYwCY1TEZw_9ycQpOcITtbYDq3HkaEF3M=.9dbfa789-df0a-42c4-aeaf-56ea134de822@github.com>
Message-ID: <wr568XlVH2TS7NJBHZhtVMCnBuN9ZhTKm5xpk1qsxH8=.b0dec4a2-96e4-4889-81c6-80693b2a2f4c@github.com>

On Thu, 4 May 2023 18:20:30 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> yep I agree with this, the parser should set the right name as soon as it sees a `_`
>
> We could indeed if we wanted to store `empty` everywhere. However, after some off-list discussions I updated the CSR (and the code) to include `empty` as the name at the symbol-level (for consistency with javax model) and `_` at the Tree API-level for its version of a name. This is the rationale behind what you see in Attr (for patterns) and member enter for all other cases. @jddarcy what do you think?

> 

In terms of pretty printing, src/jdk.compiler/share/classes/com/sun/tools/javac/processing/PrintingProcessor.java may need to be updated too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1185457942

From vromero at openjdk.org  Thu May  4 20:07:19 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 4 May 2023 20:07:19 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v13]
In-Reply-To: <7x1mAOBwhQdGgCaHjiOQ1O9BCmgJFKASy7yFJHsGVbI=.842ee2fe-8819-4e43-935a-120303815fd5@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
 <7x1mAOBwhQdGgCaHjiOQ1O9BCmgJFKASy7yFJHsGVbI=.842ee2fe-8819-4e43-935a-120303815fd5@github.com>
Message-ID: <m_Bt11TjVke4TN19jm8GrQ2upjcMIa4_wE4DGvTXYQM=.6fa00ad2-1488-45c6-8ef8-4b97faaaafce@github.com>

On Thu, 4 May 2023 17:48:28 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java.
>> 
>> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add test

src/jdk.compiler/share/classes/com/sun/tools/javac/model/JavacElements.java line 88:

> 86:  * or deletion without notice.</b></p>
> 87:  */
> 88: @SuppressWarnings("preview")

isn't it better to apply the annotation to the method below?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1185463034

From duke at openjdk.org  Thu May  4 20:30:47 2023
From: duke at openjdk.org (Weibing Xiao)
Date: Thu, 4 May 2023 20:30:47 GMT
Subject: RFR: 8305714 : Add an extra test for JDK-8292755 [v5]
In-Reply-To: <Qgv51p9m_Qj9-1EW_Ehh75Fgij7jOA-PFeEAW1Xndls=.18de61e9-f15a-44f4-9b43-05284b4c82df@github.com>
References: <Qgv51p9m_Qj9-1EW_Ehh75Fgij7jOA-PFeEAW1Xndls=.18de61e9-f15a-44f4-9b43-05284b4c82df@github.com>
Message-ID: <WDBMCahIp9Yfzocqg5mtxEg2psdbyrGe7OBPBISYUAE=.c3d34a58-40cf-45ff-90cc-4f883667c5ce@github.com>

> Add a testing case for undefined classes in Java JShell to make sure JShell does not crash when an undefined class is used.
> 
> This test was passed for Linux, MacOS, and Windows by mach5 build and test in Oracle.
> 
> Reviewer: @coffeys @lahodaj

Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision:

  add one more test case

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13719/files
  - new: https://git.openjdk.org/jdk/pull/13719/files/c83caa98..baa82f6f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13719&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13719&range=03-04

  Stats: 17 lines in 1 file changed: 15 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13719.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13719/head:pull/13719

PR: https://git.openjdk.org/jdk/pull/13719

From darcy at openjdk.org  Thu May  4 20:50:28 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 4 May 2023 20:50:28 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v13]
In-Reply-To: <7x1mAOBwhQdGgCaHjiOQ1O9BCmgJFKASy7yFJHsGVbI=.842ee2fe-8819-4e43-935a-120303815fd5@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
 <7x1mAOBwhQdGgCaHjiOQ1O9BCmgJFKASy7yFJHsGVbI=.842ee2fe-8819-4e43-935a-120303815fd5@github.com>
Message-ID: <2f6yNQHJy1t65PBsSelcHM2episYeYxt7gdYtQV1Zsc=.ff0f7299-3378-496d-ad92-0ed1cbdf90e8@github.com>

On Thu, 4 May 2023 17:48:28 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java.
>> 
>> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add test

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java line 438:

> 436:     }
> 437: 
> 438:     public boolean isUnnamed() {

Should this method get the '@Override @DefinedBy(Api.LANGUAGE_MODEL)' markup?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1185497754

From darcy at openjdk.org  Thu May  4 21:00:25 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 4 May 2023 21:00:25 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v13]
In-Reply-To: <7x1mAOBwhQdGgCaHjiOQ1O9BCmgJFKASy7yFJHsGVbI=.842ee2fe-8819-4e43-935a-120303815fd5@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
 <7x1mAOBwhQdGgCaHjiOQ1O9BCmgJFKASy7yFJHsGVbI=.842ee2fe-8819-4e43-935a-120303815fd5@github.com>
Message-ID: <HLMuveBJGifEIxiIwoQ_cdiOJT_1dMF1SewbtfuM7ns=.8a76f8d8-2a6e-486d-a569-f73f760f030d@github.com>

On Thu, 4 May 2023 17:48:28 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java.
>> 
>> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add test

src/java.compiler/share/classes/javax/lang/model/element/VariableElement.java line 114:

> 112:      */
> 113:     @PreviewFeature(feature=PreviewFeature.Feature.UNNAMED, reflective = true)
> 114:     default boolean isUnnamed() { return false; }

Looking at the various sources more closely, I'll revise my previous guidance and recommend the default method be defined as:
return getSimpleName().isEmpty()
which would also avoid the strict need to override the method in Symbol.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1185505824

From darcy at openjdk.org  Thu May  4 21:06:23 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 4 May 2023 21:06:23 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v13]
In-Reply-To: <7x1mAOBwhQdGgCaHjiOQ1O9BCmgJFKASy7yFJHsGVbI=.842ee2fe-8819-4e43-935a-120303815fd5@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
 <7x1mAOBwhQdGgCaHjiOQ1O9BCmgJFKASy7yFJHsGVbI=.842ee2fe-8819-4e43-935a-120303815fd5@github.com>
Message-ID: <gIiLCKY63xXvwZQYsfRf5_1GLOffHamTSAjdDv_c5MY=.449e53ae-5769-46f4-9c7a-af6d65073ab0@github.com>

On Thu, 4 May 2023 17:48:28 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java.
>> 
>> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add test

src/java.compiler/share/classes/javax/lang/model/util/Elements.java line 724:

> 722:     @PreviewFeature(feature=PreviewFeature.Feature.UNNAMED, reflective = true)
> 723:     default boolean isUnnamed(Element element) {
> 724:         return false;

Analogous suggestion to switch to "return element.getSimpleName().isEmpty();"

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1185512905

From coffeys at openjdk.org  Thu May  4 21:42:15 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Thu, 4 May 2023 21:42:15 GMT
Subject: RFR: 8305714 : Add an extra test for JDK-8292755 [v5]
In-Reply-To: <WDBMCahIp9Yfzocqg5mtxEg2psdbyrGe7OBPBISYUAE=.c3d34a58-40cf-45ff-90cc-4f883667c5ce@github.com>
References: <Qgv51p9m_Qj9-1EW_Ehh75Fgij7jOA-PFeEAW1Xndls=.18de61e9-f15a-44f4-9b43-05284b4c82df@github.com>
 <WDBMCahIp9Yfzocqg5mtxEg2psdbyrGe7OBPBISYUAE=.c3d34a58-40cf-45ff-90cc-4f883667c5ce@github.com>
Message-ID: <xDGBFPv78i7yd4uo9MvP6R3ygybMqdMDqnqlb3rFRb0=.c977661b-8f96-4ab0-aca0-667d734442fe@github.com>

On Thu, 4 May 2023 20:30:47 GMT, Weibing Xiao <duke at openjdk.org> wrote:

>> Add a testing case for undefined classes in Java JShell to make sure JShell does not crash when an undefined class is used.
>> 
>> This test was passed for Linux, MacOS, and Windows by mach5 build and test in Oracle.
>> 
>> Reviewer: @coffeys @lahodaj
>
> Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add one more test case

Marked as reviewed by coffeys (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13719#pullrequestreview-1413960279

From darcy at openjdk.org  Thu May  4 21:43:22 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 4 May 2023 21:43:22 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v12]
In-Reply-To: <wr568XlVH2TS7NJBHZhtVMCnBuN9ZhTKm5xpk1qsxH8=.b0dec4a2-96e4-4889-81c6-80693b2a2f4c@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
 <Cayb1Dvz1LPjI6b-pCwms_qjyoLqWrAvhuaC3vfEOb4=.63d57ccc-33a2-4fff-8d51-172365113457@github.com>
 <nKJajz0Cn8d82HReHtqyd122PMBiWreRQGX6cOz-Cg4=.56f78c17-4572-4a25-a021-a2012dc8857b@github.com>
 <Y0ieP2NFRNAlY6yJDOrzDc1QtXrxuj23cKVxupFsjis=.bba83b2d-ef93-49e8-ad61-e966d7a8c2f1@github.com>
 <QwtC1Vpb7MiYwCY1TEZw_9ycQpOcITtbYDq3HkaEF3M=.9dbfa789-df0a-42c4-aeaf-56ea134de822@github.com>
 <wr568XlVH2TS7NJBHZhtVMCnBuN9ZhTKm5xpk1qsxH8=.b0dec4a2-96e4-4889-81c6-80693b2a2f4c@github.com>
Message-ID: <kze8mz2LQK6e9UU4khH-jWTH7sa4E8ltOXYse6ccqq4=.f9669938-7db6-4ec4-bbde-b0a6447dc8a6@github.com>

On Thu, 4 May 2023 19:58:37 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> We could indeed if we wanted to store `empty` everywhere. However, after some off-list discussions I updated the CSR (and the code) to include `empty` as the name at the symbol-level (for consistency with javax model) and `_` at the Tree API-level for its version of a name. This is the rationale behind what you see in Attr (for patterns) and member enter for all other cases. @jddarcy what do you think?
>
>> 
> 
> In terms of pretty printing, src/jdk.compiler/share/classes/com/sun/tools/javac/processing/PrintingProcessor.java may need to be updated too.

> 

For the user-facing javax.lang.model languages, I think the current convention of "empty name means unnamed" is reasonable and is consistent with how other unnamed items are handled in that API.

I assumed for the lower-level tree API "_" would be a more appropriate choice, but I'm open to discussions alternative conventions there.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1185544462

From vromero at openjdk.org  Thu May  4 22:04:20 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 4 May 2023 22:04:20 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v13]
In-Reply-To: <7x1mAOBwhQdGgCaHjiOQ1O9BCmgJFKASy7yFJHsGVbI=.842ee2fe-8819-4e43-935a-120303815fd5@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
 <7x1mAOBwhQdGgCaHjiOQ1O9BCmgJFKASy7yFJHsGVbI=.842ee2fe-8819-4e43-935a-120303815fd5@github.com>
Message-ID: <4dcjzbL_QNyX1L-n4dCOlV6ZvWQBsnrlqbHhDEku8jg=.0c82bcea-6c43-45c5-9e4b-f64aa914bc59@github.com>

On Thu, 4 May 2023 17:48:28 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java.
>> 
>> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add test

src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeCopier.java line 496:

> 494:     @DefinedBy(Api.COMPILER_TREE)
> 495:     public JCTree visitAnyPattern(AnyPatternTree node, P p) {
> 496:         JCBindingPattern t = (JCBindingPattern) node;

not sure this is correct, are we returning a JCBindingPattern?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1185555175

From vromero at openjdk.org  Thu May  4 22:08:24 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 4 May 2023 22:08:24 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v13]
In-Reply-To: <7x1mAOBwhQdGgCaHjiOQ1O9BCmgJFKASy7yFJHsGVbI=.842ee2fe-8819-4e43-935a-120303815fd5@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
 <7x1mAOBwhQdGgCaHjiOQ1O9BCmgJFKASy7yFJHsGVbI=.842ee2fe-8819-4e43-935a-120303815fd5@github.com>
Message-ID: <zCPYJ9cNf4ubrT0fdfmGagOFoZsqOQUNMuBViqrk3kA=.4c0b09f7-62f0-48e4-8570-772f88c302d2@github.com>

On Thu, 4 May 2023 17:48:28 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java.
>> 
>> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add test

test/langtools/tools/javac/patterns/Unnamed.java line 4:

> 2: 
> 3: /**
> 4:  * @test /nodynamiccopyright/

there is no golden file for this test so full copyright will be needed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1185559074

From abimpoudis at openjdk.org  Thu May  4 23:28:29 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 4 May 2023 23:28:29 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v14]
In-Reply-To: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
Message-ID: <bo3Uaby0n1XXjjjH5Ny-XS-0nSYu8PchTE29iNziuys=.32f9e5c3-1706-4c63-b5ba-1b57d8f67c4a@github.com>

> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java.
> 
> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/

Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:

  8307482: Compiler should accept var _ in nested patterns in switch case

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13528/files
  - new: https://git.openjdk.org/jdk/pull/13528/files/ffae4e0e..888297ef

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13528&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13528&range=12-13

  Stats: 49 lines in 4 files changed: 35 ins; 0 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/13528.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13528/head:pull/13528

PR: https://git.openjdk.org/jdk/pull/13528

From abimpoudis at openjdk.org  Thu May  4 23:28:29 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 4 May 2023 23:28:29 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v12]
In-Reply-To: <kze8mz2LQK6e9UU4khH-jWTH7sa4E8ltOXYse6ccqq4=.f9669938-7db6-4ec4-bbde-b0a6447dc8a6@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
 <Cayb1Dvz1LPjI6b-pCwms_qjyoLqWrAvhuaC3vfEOb4=.63d57ccc-33a2-4fff-8d51-172365113457@github.com>
 <nKJajz0Cn8d82HReHtqyd122PMBiWreRQGX6cOz-Cg4=.56f78c17-4572-4a25-a021-a2012dc8857b@github.com>
 <Y0ieP2NFRNAlY6yJDOrzDc1QtXrxuj23cKVxupFsjis=.bba83b2d-ef93-49e8-ad61-e966d7a8c2f1@github.com>
 <QwtC1Vpb7MiYwCY1TEZw_9ycQpOcITtbYDq3HkaEF3M=.9dbfa789-df0a-42c4-aeaf-56ea134de822@github.com>
 <wr568XlVH2TS7NJBHZhtVMCnBuN9ZhTKm5xpk1qsxH8=.b0dec4a2-96e4-4889-81c6-80693b2a2f4c@github.com>
 <kze8mz2LQK6e9UU4khH-jWTH7sa4E8ltOXYse6ccqq4=.f9669938-7db6-4ec4-bbde-b0a6447dc8a6@github.com>
Message-ID: <_2IbNlxLzlbXs3UkPWmrTTuMVRsvTnHnX4JqN35kbPU=.e1053192-5d69-4b31-b1d0-8bfa12adefda@github.com>

On Thu, 4 May 2023 21:40:38 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>>> 
>> 
>> In terms of pretty printing, src/jdk.compiler/share/classes/com/sun/tools/javac/processing/PrintingProcessor.java may need to be updated too.
>
>> 
> 
> For the user-facing javax.lang.model languages, I think the current convention of "empty name means unnamed" is reasonable and is consistent with how other unnamed items are handled in that API.
> 
> I assumed for the lower-level tree API "_" would be a more appropriate choice, but I'm open to discussions alternative conventions there.

Recently, I realized that `names.empty` also signifies an error in `variableDeclaratorId` in some occasion around lambdas:  https://github.com/openjdk/jdk/blob/ffae4e0e97b19b1c1ad2865ed618ba380a861b7e/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java#L3688-L3697
I don't believe that this would be a blocker but it could pose a possible minor challenge.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1185595137

From abimpoudis at openjdk.org  Fri May  5 08:44:23 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Fri, 5 May 2023 08:44:23 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v13]
In-Reply-To: <m_Bt11TjVke4TN19jm8GrQ2upjcMIa4_wE4DGvTXYQM=.6fa00ad2-1488-45c6-8ef8-4b97faaaafce@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
 <7x1mAOBwhQdGgCaHjiOQ1O9BCmgJFKASy7yFJHsGVbI=.842ee2fe-8819-4e43-935a-120303815fd5@github.com>
 <m_Bt11TjVke4TN19jm8GrQ2upjcMIa4_wE4DGvTXYQM=.6fa00ad2-1488-45c6-8ef8-4b97faaaafce@github.com>
Message-ID: <dpIukQjXp9zW4c3GoZP3r77X0XrUF-RMAwUiADH2Kt4=.0694fda9-b3b5-4cd7-a027-3110e4c34286@github.com>

On Thu, 4 May 2023 20:04:49 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add test
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/model/JavacElements.java line 88:
> 
>> 86:  * or deletion without notice.</b></p>
>> 87:  */
>> 88: @SuppressWarnings("preview")
> 
> isn't it better to apply the annotation to the method below?

Yeap, this is what I thought at first but I was getting  "warnings found and -Werror specified". So compilation was failing.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1185840546

From jlahoda at openjdk.org  Fri May  5 09:29:35 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 5 May 2023 09:29:35 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v14]
In-Reply-To: <bo3Uaby0n1XXjjjH5Ny-XS-0nSYu8PchTE29iNziuys=.32f9e5c3-1706-4c63-b5ba-1b57d8f67c4a@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
 <bo3Uaby0n1XXjjjH5Ny-XS-0nSYu8PchTE29iNziuys=.32f9e5c3-1706-4c63-b5ba-1b57d8f67c4a@github.com>
Message-ID: <3eNbxZ47pN094c130bnXzkaRcts92buDBG_EPBM4DJg=.3d354d72-17c5-4f5f-8c78-2166e56455c6@github.com>

On Thu, 4 May 2023 23:28:29 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java.
>> 
>> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8307482: Compiler should accept var _ in nested patterns in switch case

src/jdk.compiler/share/classes/com/sun/source/tree/AnyPatternTree.java line 32:

> 30:  *
> 31:  */
> 32: public interface AnyPatternTree extends PatternTree {

`@PreviewFeature` here.

src/jdk.compiler/share/classes/com/sun/source/tree/Tree.java line 227:

> 225:          * @since 21
> 226:          */
> 227:         ANY_PATTERN(AnyPatternTree.class),

@PreviewFeature here.

src/jdk.compiler/share/classes/com/sun/source/tree/TreeVisitor.java line 267:

> 265:      * @since 21
> 266:      */
> 267:     R visitAnyPattern(AnyPatternTree node, P p);

@PreviewFeature here.

src/jdk.compiler/share/classes/com/sun/source/util/SimpleTreeVisitor.java line 641:

> 639:      */
> 640:     @Override
> 641:     public R visitAnyPattern(AnyPatternTree node, P p) {

`@PreviewFeature` here.

src/jdk.compiler/share/classes/com/sun/source/util/TreeScanner.java line 773:

> 771:      */
> 772:     @Override
> 773:     public R visitAnyPattern(AnyPatternTree node, P p) {

`@PreviewFeature` here.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java line 329:

> 327:                 nestedBinding = nestedDesugared.primaryPattern();
> 328:                 allowNull = false;
> 329:             } else if (nestedPattern instanceof JCAnyPattern nestedRecordPattern) {

Nit: `nestedRecordPattern` -> `nestedAnyPattern`?

test/langtools/tools/javac/patterns/Unnamed.java line 8:

> 6:  * @summary Compiler Implementation for Unnamed patterns and variables
> 7:  * @enablePreview
> 8:  * @compile --enable-preview -source ${jdk.version} Unnamed.java

+1 on keeping the `@compile` tag, but `--enable-preview -source ${jdk.version}` shouldn't be needed when `@enablePreview` is present.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1185805923
PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1185807097
PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1185807170
PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1185807989
PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1185808102
PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1185819402
PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1185871609

From jlahoda at openjdk.org  Fri May  5 09:29:40 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 5 May 2023 09:29:40 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v13]
In-Reply-To: <YJbiOqulqaNjr_uPG-xXFWnZc3LHyDalyjzQ_aktkEQ=.6dfcaa14-e07c-4553-9da2-aab82d84efd9@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
 <7x1mAOBwhQdGgCaHjiOQ1O9BCmgJFKASy7yFJHsGVbI=.842ee2fe-8819-4e43-935a-120303815fd5@github.com>
 <YJbiOqulqaNjr_uPG-xXFWnZc3LHyDalyjzQ_aktkEQ=.6dfcaa14-e07c-4553-9da2-aab82d84efd9@github.com>
Message-ID: <4GXVg3R1xzO-tFQenVIh_6FGWvSeXUfs5-17WDaM6m0=.ab0ae8c0-9fd0-4f2d-aade-d841f8fbece7@github.com>

On Thu, 4 May 2023 17:56:37 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add test
>
> src/jdk.compiler/share/classes/com/sun/source/tree/VariableTree.java line 54:
> 
>> 52: 
>> 53:     /**
>> 54:      * Returns the name of the variable being declared or `_` if the variable
> 
> I guess if we go full for the empty name then this will need to change too

Maybe also add a mention that unnamed is a preview feature?

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java line 535:
> 
>> 533:                 if (clearedPatterns.size() > 1) {
>> 534:                     validCaseLabelList = clearedPatterns.stream().allMatch(cP -> cP.hasTag(Tag.PATTERNCASELABEL));
>> 535:                 } else validCaseLabelList = clearedPatterns.size() == 1 && clearedPatterns.head.hasTag(Tag.PATTERNCASELABEL);
> 
> style: I would use `{}` for the code in the `else` branch here, same way as it has been done for the `then` branch. Also in the `else` branch isn't the `clearedPatterns.size() == 1` condition always true?

True - if I read the code correctly, the list should never be empty at this place.

> src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeCopier.java line 496:
> 
>> 494:     @DefinedBy(Api.COMPILER_TREE)
>> 495:     public JCTree visitAnyPattern(AnyPatternTree node, P p) {
>> 496:         JCBindingPattern t = (JCBindingPattern) node;
> 
> not sure this is correct, are we returning a JCBindingPattern?

+1

> test/langtools/tools/javac/patterns/Unnamed.java line 4:
> 
>> 2: 
>> 3: /**
>> 4:  * @test /nodynamiccopyright/
> 
> there is no golden file for this test so full copyright will be needed

Also, it is a custom that the comment with `@test` is before any imports, AFAIK.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1185807820
PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1185823113
PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1185870099
PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1185871058

From jlahoda at openjdk.org  Fri May  5 09:29:49 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 5 May 2023 09:29:49 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v12]
In-Reply-To: <_2IbNlxLzlbXs3UkPWmrTTuMVRsvTnHnX4JqN35kbPU=.e1053192-5d69-4b31-b1d0-8bfa12adefda@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
 <Cayb1Dvz1LPjI6b-pCwms_qjyoLqWrAvhuaC3vfEOb4=.63d57ccc-33a2-4fff-8d51-172365113457@github.com>
 <nKJajz0Cn8d82HReHtqyd122PMBiWreRQGX6cOz-Cg4=.56f78c17-4572-4a25-a021-a2012dc8857b@github.com>
 <Y0ieP2NFRNAlY6yJDOrzDc1QtXrxuj23cKVxupFsjis=.bba83b2d-ef93-49e8-ad61-e966d7a8c2f1@github.com>
 <QwtC1Vpb7MiYwCY1TEZw_9ycQpOcITtbYDq3HkaEF3M=.9dbfa789-df0a-42c4-aeaf-56ea134de822@github.com>
 <wr568XlVH2TS7NJBHZhtVMCnBuN9ZhTKm5xpk1qsxH8=.b0dec4a2-96e4-4889-81c6-80693b2a2f4c@github.com>
 <kze8mz2LQK6e9UU4khH-jWTH7sa4E8ltOXYse6ccqq4=.f9669938-7db6-4ec4-bbde-b0a6447dc8a6@github.com>
 <_2IbNlxLzlbXs3UkPWmrTTuMVRsvTnHnX4JqN35kbPU=.e1053192-5d69-4b31-b1d0-8bfa12adefda@github.com>
Message-ID: <0lJobZbHgtHyGKnoyvKcj8COkObRQo448AlEJxwIzIw=.5061dc4b-0900-4e6c-a36a-93c444c3effd@github.com>

On Thu, 4 May 2023 23:19:26 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>>> 
>> 
>> For the user-facing javax.lang.model languages, I think the current convention of "empty name means unnamed" is reasonable and is consistent with how other unnamed items are handled in that API.
>> 
>> I assumed for the lower-level tree API "_" would be a more appropriate choice, but I'm open to discussions alternative conventions there.
>
> Recently, I realized that `names.empty` also signifies an error in `variableDeclaratorId` in some occasion around lambdas:  https://github.com/openjdk/jdk/blob/ffae4e0e97b19b1c1ad2865ed618ba380a861b7e/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java#L3688-L3697
> I don't believe that this would be a blocker but it could pose a possible minor challenge.

FWIW, I don't have a strong opinion on whether the name in the AST should be empty or underscore. (But I agree empty name is more consistent in the Language Model.) For missing names where names are expected (which is the above case), we could revisit later, there are more cases like this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1185869588

From jlahoda at openjdk.org  Fri May  5 09:29:44 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 5 May 2023 09:29:44 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v4]
In-Reply-To: <x1EBPebhAYdhDBa1HqQem0cwRN4CJCpOzrbNSIpbDFE=.58d65c44-2b16-4c50-befc-72b3657e8506@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
 <hnd9UyOUlz7cDrjBGvM0cDikvHsUGUPHH5_PW47SJQ8=.65a06139-496b-47a5-832a-62f0367d35f2@github.com>
 <KWkhcjT0YrtpQbu3TRuBU-vbeE-N2jR_L9iwXYu1uNY=.83e2aebb-7dbe-4558-a57c-254d5a213918@github.com>
 <x1EBPebhAYdhDBa1HqQem0cwRN4CJCpOzrbNSIpbDFE=.58d65c44-2b16-4c50-befc-72b3657e8506@github.com>
Message-ID: <q5L_oTxXA2Be2acqCjSZDSqaGfIuwFjeXd4qcQ0WKJ4=.9fd24291-bccf-41a8-a6f7-64e517bfc1b7@github.com>

On Mon, 1 May 2023 22:29:21 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1777:
>> 
>>> 1775:                                 log.error(guard.pos(), Errors.GuardHasConstantExpressionFalse);
>>> 1776:                             }
>>> 1777:                         } else if (guard != null) {
>> 
>> I guess this is caused by something like:
>> 
>> case _ when ...
>> 
>> If now a guard can appear regardless of how many labels there are, should be refactor this code so that if `guard != null` it is always attributed? And then we do other stuff in case `labels.tail.isEmpty()` ? Note that the code for attributing the guard is slightly different in the two cases in this patch: the original code creates a nested scope - while the new code doesn't.
>
> Actually this is for the case where we have `case A(_), B(C _) when ... `. In that case we are sure that the only scope we can use is the switch environment (since no bindings are introduced). Hm, I don't see another way of refactoring this without depending on `labels.tail.isEmpty()`

I was looking into this again, and I am afraid this is not quite correct. One of the issues is that this attrib will place any binding variables from the guard into the current `matchBindings`, and when the guard is attributed again, the variables in the `matchBindings` will collide. For example:

    String unnamedGuardAddsBindings(Object o1, Object o2) {
        return switch (o1) {
            case String _, Object _ when o2 instanceof String s: yield s;
            case Object _: yield "any";
        };
    }


My current proposal would be to (try to):
 - attribute the guard when handling the first pattern (so that we can detect whether or not it is constant)
 - but, do not merge the bindings from the guard immediately, but only after all the patterns are handled

It could look like this:

diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
index e9c3ca27f1c..bade6b530eb 100644
--- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
+++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
@@ -1688,7 +1688,7 @@ public class Attr extends JCTree.Visitor {
                     wasError = true;
                 }
                 MatchBindings currentBindings = null;
-                boolean wasUnconditionalPattern = hasUnconditionalPattern;
+                MatchBindings guardBindings = null;
                 for (List<JCCaseLabel> labels = c.labels; labels.nonEmpty(); labels = labels.tail) {
                     JCCaseLabel label = labels.head;
                     if (label instanceof JCConstantCaseLabel constLabel) {
@@ -1761,7 +1761,7 @@ public class Attr extends JCTree.Visitor {
                         checkCastablePattern(pat.pos(), seltype, primaryType);
                         Type patternType = types.erasure(primaryType);
                         JCExpression guard = c.guard;
-                        if (labels.tail.isEmpty() && guard != null) {
+                        if (labels == c.labels && guard != null) {
                             MatchBindings afterPattern = matchBindings;
                             Env<AttrContext> bodyEnv = bindingEnv(switchEnv, matchBindings.bindingsWhenTrue);
                             try {
@@ -1769,14 +1769,13 @@ public class Attr extends JCTree.Visitor {
                             } finally {
                                 bodyEnv.info.scope.leave();
                             }
-                            matchBindings = matchBindingsComputer.caseGuard(c, afterPattern, matchBindings);
+
+                            guardBindings = matchBindings;
+                            matchBindings = afterPattern;
 
                             if (TreeInfo.isBooleanWithValue(guard, 0)) {
                                 log.error(guard.pos(), Errors.GuardHasConstantExpressionFalse);
                             }
-                        } else if (guard != null) {
-                            // if the label has multiple patterns and a guard (with binding from the switch environment)
-                            attribExpr(guard, switchEnv, syms.booleanType);
                         }
                         boolean unguarded = TreeInfo.unguardedCase(c) && !pat.hasTag(RECORDPATTERN);
                         boolean unconditional =
@@ -1799,6 +1798,10 @@ public class Attr extends JCTree.Visitor {
                     currentBindings = matchBindingsComputer.switchCase(label, currentBindings, matchBindings);
                 }
 
+                if (guardBindings != null) {
+                    currentBindings = matchBindingsComputer.caseGuard(c, currentBindings, guardBindings);
+                }
+
                 Env<AttrContext> caseEnv =
                         bindingEnv(switchEnv, c, currentBindings.bindingsWhenTrue);
                 try {


(I didn't run tests on this, though.)

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 746:
>> 
>>> 744: 
>>> 745:         sealed interface PatternDescription {
>>> 746:             public static PatternDescription from(Types types, Type selectorType, JCPattern pattern, Symtab syms) {
>> 
>> Optional comment: the fact that this factory needs so much compiler state makes me think that perhaps a better place for it would be as an instance method of Flow, rather than a static method in PatternDescription.
>
> @lahodaj WDYT? Looks like it can be easily refactored and it is used only in one place (apart from the recursive call). I can refactor it in this PR or u can do it in #13074.

I somewhat liked the "factory method" aspect to this, but I admit the parameter list is getting longer. So, up to you, I think.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1185881273
PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1185817955

From jlahoda at openjdk.org  Fri May  5 09:29:42 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 5 May 2023 09:29:42 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v13]
In-Reply-To: <2f6yNQHJy1t65PBsSelcHM2episYeYxt7gdYtQV1Zsc=.ff0f7299-3378-496d-ad92-0ed1cbdf90e8@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
 <7x1mAOBwhQdGgCaHjiOQ1O9BCmgJFKASy7yFJHsGVbI=.842ee2fe-8819-4e43-935a-120303815fd5@github.com>
 <2f6yNQHJy1t65PBsSelcHM2episYeYxt7gdYtQV1Zsc=.ff0f7299-3378-496d-ad92-0ed1cbdf90e8@github.com>
Message-ID: <8fbux7W7kkd8KYN9Z6ks6IHYdtrFIPhQPTZ6lI816tw=.156e8b6d-0b18-4690-9f5a-21bbbca30bc5@github.com>

On Thu, 4 May 2023 20:47:54 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add test
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java line 438:
> 
>> 436:     }
>> 437: 
>> 438:     public boolean isUnnamed() {
> 
> Should this method get the '@Override @DefinedBy(Api.LANGUAGE_MODEL)' markup?

+1 (I am a bit surprised the tests don't complain, that might be something to look at as well)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1185809422

From jlahoda at openjdk.org  Fri May  5 09:29:47 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 5 May 2023 09:29:47 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v13]
In-Reply-To: <dpIukQjXp9zW4c3GoZP3r77X0XrUF-RMAwUiADH2Kt4=.0694fda9-b3b5-4cd7-a027-3110e4c34286@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
 <7x1mAOBwhQdGgCaHjiOQ1O9BCmgJFKASy7yFJHsGVbI=.842ee2fe-8819-4e43-935a-120303815fd5@github.com>
 <m_Bt11TjVke4TN19jm8GrQ2upjcMIa4_wE4DGvTXYQM=.6fa00ad2-1488-45c6-8ef8-4b97faaaafce@github.com>
 <dpIukQjXp9zW4c3GoZP3r77X0XrUF-RMAwUiADH2Kt4=.0694fda9-b3b5-4cd7-a027-3110e4c34286@github.com>
Message-ID: <A0qiV-hF4cVcZ_7yKYMC-IeicEgHMoEAMF3NhOvRQ3A=.e32e4f7f-6cbf-446b-99a5-de3b0caffcff@github.com>

On Fri, 5 May 2023 08:41:08 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/model/JavacElements.java line 88:
>> 
>>> 86:  * or deletion without notice.</b></p>
>>> 87:  */
>>> 88: @SuppressWarnings("preview")
>> 
>> isn't it better to apply the annotation to the method below?
>
> Yeap, this is what I thought at first but I was getting  "warnings found and -Werror specified". So compilation was failing.

IIRC the error is reported on the class level (with position on the class), so suppressing the warning on the method is not sufficient. We might want to review if the warning could have a better position, but we probably should not do it under this patch.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1185855689

From abimpoudis at openjdk.org  Fri May  5 10:41:24 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Fri, 5 May 2023 10:41:24 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v13]
In-Reply-To: <8fbux7W7kkd8KYN9Z6ks6IHYdtrFIPhQPTZ6lI816tw=.156e8b6d-0b18-4690-9f5a-21bbbca30bc5@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
 <7x1mAOBwhQdGgCaHjiOQ1O9BCmgJFKASy7yFJHsGVbI=.842ee2fe-8819-4e43-935a-120303815fd5@github.com>
 <2f6yNQHJy1t65PBsSelcHM2episYeYxt7gdYtQV1Zsc=.ff0f7299-3378-496d-ad92-0ed1cbdf90e8@github.com>
 <8fbux7W7kkd8KYN9Z6ks6IHYdtrFIPhQPTZ6lI816tw=.156e8b6d-0b18-4690-9f5a-21bbbca30bc5@github.com>
Message-ID: <GSv1LAteLBvO4ITvTDyZg4yI__QUomsfGIrrOe7ILA8=.a396c45d-cd3c-4d4f-a65a-8a91636fc066@github.com>

On Fri, 5 May 2023 08:06:19 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java line 438:
>> 
>>> 436:     }
>>> 437: 
>>> 438:     public boolean isUnnamed() {
>> 
>> Should this method get the '@Override @DefinedBy(Api.LANGUAGE_MODEL)' markup?
>
> +1 (I am a bit surprised the tests don't complain, that might be something to look at as well)

Note that `Element` does not declare `isUnnamed`.

`isUnnamed` overrides method in `VariableElement` (javax.lang.model.element) via subclass `VarSymbol` in `Symbol`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1185944024

From jlahoda at openjdk.org  Fri May  5 12:34:29 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 5 May 2023 12:34:29 GMT
Subject: RFR: JDK-8306983: Do not invoke external programs when switch
 terminal to raw mode on selected platforms [v2]
In-Reply-To: <cGOTtVG_NmpIQ7Xpy9rMkVds3JC8az9jj530vVZr134=.4675f46c-8423-4957-ab24-00939d669563@github.com>
References: <cGOTtVG_NmpIQ7Xpy9rMkVds3JC8az9jj530vVZr134=.4675f46c-8423-4957-ab24-00939d669563@github.com>
Message-ID: <g4Wfl35cnWC3CAhOjVVEi0KykmEpf216n97gidgkyC0=.721e88f1-509e-4ec3-972b-1e61c7a6143f@github.com>

> To support JShell and other usecases, the JDK uses JLine, which provides line-editing functionality inside a terminal.
> 
> JLine has several ways to work with the terminal, based on various additional libraries and tools. Most of them are not directly usable inside the JDK, so currently, on non-Windows platforms, the JLine inside the JDK will use external programs, like `stty`, to inspect the terminal's properties and to switch the terminal to raw mode.
> 
> This is slightly problematic, as the external programs might be missing, and while this is not that big problem for JShell, it might be a problem for other potential uses of JLine, like using it inside `System.console()`.
> 
> So, the proposal here is to call the corresponding native methods directly, on selected platforms for now (Linux and Mac OS/X), instead of invoking the external programs. On Windows, this has always been the case, we are using a custom implementation of the interface that maps native and Java function for JNA there, and the proposal is to do the same here. We take the appropriate mapping interface for JNA, and provide hand-written implementation for it, using JNI.
> 
> The Windows implementation is mostly unchanged, the changes are mostly non-Windows only. The overview of the changes is:
>  - `LastErrorException` is moved from the Windows-specific code to the platform-neutral code, as it is used by all the native implementations. This is the only change that directly affects the Windows-specific code
>  -  `unix/classes/jdk/internal/org/jline/terminal/impl/jna/JnaNativePty.java` and `unix/classes/jdk/internal/org/jline/terminal/impl/jna/JnaTerminalProvider.java` are created based on the corresponding files from JLine. In JLine, these files directly call platform-specific implementations, but in this patch, the platform specific code is commented out, and replaced with calls to `JDKNativePty`, which is a new platform-specific class, that delegates to the actual platform-specific implementations. Note the `JnaNativePty.java` and `JnaTerminalProvider.java` already exist in the Windows part, but have different pieces of code commented out, which makes them substantially different.
>  - for Linux and Mac OS/X, there are platform-specific implementations based on the corresponding code from JLine, with the hand-written JNI-based implementation of the JNA-based existing interfaces. They also have an implementation of `JDKNativePty`, which just delegates to the given platform's `"NativePty"` implementation.
>  - the `JdkConsoleProviderImpl.java` has been tweaked to not allow the implementation based on the external programs, and gracefully falling back to the standard implementation. JShell is kept unchanged.
> 
> The reasons for this organization are: limiting duplication, mostly adhering to the JDK's platform specific build (which is different from the normal JLine's platform-neutral build) and limiting the difference between standard JLine and JLine inside JDK, to help future upgrades.

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

  Adjusting build script as suggested on the review.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13687/files
  - new: https://git.openjdk.org/jdk/pull/13687/files/f14e7fb5..4cf8f67e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13687&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13687&range=00-01

  Stats: 3 lines in 1 file changed: 2 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13687.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13687/head:pull/13687

PR: https://git.openjdk.org/jdk/pull/13687

From duke at openjdk.org  Fri May  5 13:22:29 2023
From: duke at openjdk.org (Weibing Xiao)
Date: Fri, 5 May 2023 13:22:29 GMT
Subject: Integrated: 8305714 : Add an extra test for JDK-8292755
In-Reply-To: <Qgv51p9m_Qj9-1EW_Ehh75Fgij7jOA-PFeEAW1Xndls=.18de61e9-f15a-44f4-9b43-05284b4c82df@github.com>
References: <Qgv51p9m_Qj9-1EW_Ehh75Fgij7jOA-PFeEAW1Xndls=.18de61e9-f15a-44f4-9b43-05284b4c82df@github.com>
Message-ID: <cmqnFDkkT9pqQhyfDDe8udsOj7ILHiz-Et58A6oJm2w=.9da4e51b-63cd-4d24-8002-fe75bd8af16b@github.com>

On Fri, 28 Apr 2023 13:47:40 GMT, Weibing Xiao <duke at openjdk.org> wrote:

> Add a testing case for undefined classes in Java JShell to make sure JShell does not crash when an undefined class is used.
> 
> This test was passed for Linux, MacOS, and Windows by mach5 build and test in Oracle.
> 
> Reviewer: @coffeys @lahodaj

This pull request has now been integrated.

Changeset: 746f8d13
Author:    Weibing Xiao <weibing.xiao at oracle.com>
Committer: Sean Coffey <coffeys at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/746f8d133323c1caca019b507a6ccd9d5c98f2f9
Stats:     79 lines in 1 file changed: 79 ins; 0 del; 0 mod

8305714: Add an extra test for JDK-8292755

Reviewed-by: coffeys

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

PR: https://git.openjdk.org/jdk/pull/13719

From erikj at openjdk.org  Fri May  5 13:24:17 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 5 May 2023 13:24:17 GMT
Subject: RFR: JDK-8306983: Do not invoke external programs when switch
 terminal to raw mode on selected platforms [v2]
In-Reply-To: <g4Wfl35cnWC3CAhOjVVEi0KykmEpf216n97gidgkyC0=.721e88f1-509e-4ec3-972b-1e61c7a6143f@github.com>
References: <cGOTtVG_NmpIQ7Xpy9rMkVds3JC8az9jj530vVZr134=.4675f46c-8423-4957-ab24-00939d669563@github.com>
 <g4Wfl35cnWC3CAhOjVVEi0KykmEpf216n97gidgkyC0=.721e88f1-509e-4ec3-972b-1e61c7a6143f@github.com>
Message-ID: <r9l7mq9y9jWivgajTu5dL8raiVEQ0T9askeHKJWykjc=.39e48d2f-37c5-4972-bcab-1a978ceaa646@github.com>

On Fri, 5 May 2023 12:34:29 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> To support JShell and other usecases, the JDK uses JLine, which provides line-editing functionality inside a terminal.
>> 
>> JLine has several ways to work with the terminal, based on various additional libraries and tools. Most of them are not directly usable inside the JDK, so currently, on non-Windows platforms, the JLine inside the JDK will use external programs, like `stty`, to inspect the terminal's properties and to switch the terminal to raw mode.
>> 
>> This is slightly problematic, as the external programs might be missing, and while this is not that big problem for JShell, it might be a problem for other potential uses of JLine, like using it inside `System.console()`.
>> 
>> So, the proposal here is to call the corresponding native methods directly, on selected platforms for now (Linux and Mac OS/X), instead of invoking the external programs. On Windows, this has always been the case, we are using a custom implementation of the interface that maps native and Java function for JNA there, and the proposal is to do the same here. We take the appropriate mapping interface for JNA, and provide hand-written implementation for it, using JNI.
>> 
>> The Windows implementation is mostly unchanged, the changes are mostly non-Windows only. The overview of the changes is:
>>  - `LastErrorException` is moved from the Windows-specific code to the platform-neutral code, as it is used by all the native implementations. This is the only change that directly affects the Windows-specific code
>>  -  `unix/classes/jdk/internal/org/jline/terminal/impl/jna/JnaNativePty.java` and `unix/classes/jdk/internal/org/jline/terminal/impl/jna/JnaTerminalProvider.java` are created based on the corresponding files from JLine. In JLine, these files directly call platform-specific implementations, but in this patch, the platform specific code is commented out, and replaced with calls to `JDKNativePty`, which is a new platform-specific class, that delegates to the actual platform-specific implementations. Note the `JnaNativePty.java` and `JnaTerminalProvider.java` already exist in the Windows part, but have different pieces of code commented out, which makes them substantially different.
>>  - for Linux and Mac OS/X, there are platform-specific implementations based on the corresponding code from JLine, with the hand-written JNI-based implementation of the JNA-based existing interfaces. They also have an implementation of `JDKNativePty`, which just delegates to the given platform's `"NativePty"` implementation.
>>  - the `JdkConsoleProviderImpl.java` has been tweaked to not allow the implementation based on the external programs, and gracefully falling back to the standard implementation. JShell is kept unchanged.
>> 
>> The reasons for this organization are: limiting duplication, mostly adhering to the JDK's platform specific build (which is different from the normal JLine's platform-neutral build) and limiting the difference between standard JLine and JLine inside JDK, to help future upgrades.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjusting build script as suggested on the review.

Build changes look good.

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

Marked as reviewed by erikj (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13687#pullrequestreview-1414782534

From abimpoudis at openjdk.org  Fri May  5 16:01:00 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Fri, 5 May 2023 16:01:00 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v15]
In-Reply-To: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
Message-ID: <SvZujPd840GM1ukJyFUK4wKKqdgmxjr4aIAzO6c2N8w=.1d578c2f-1310-4a28-8b31-30a842627cce@github.com>

> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java.
> 
> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/

Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:

  Address comments
  
  - Annotate with Preview
  - Fix isUnnamed hierarchy
  - Flow names.empty for underscore in both model and API
  - Adjust pretty printing and annotation pretty printing
  - Fix guard bindings (great catch and thx @lahodaj!)
  - Fix TreeVisitor
  - Remove test with lambda which has a parse error from VarTree (names.empty is used to signal error)
  - Various adjustments
  
  Co-authored-by: Jan Lahoda <jan.lahoda at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13528/files
  - new: https://git.openjdk.org/jdk/pull/13528/files/888297ef..5d9a1ba7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13528&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13528&range=13-14

  Stats: 348 lines in 25 files changed: 189 ins; 102 del; 57 mod
  Patch: https://git.openjdk.org/jdk/pull/13528.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13528/head:pull/13528

PR: https://git.openjdk.org/jdk/pull/13528

From abimpoudis at openjdk.org  Fri May  5 16:07:24 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Fri, 5 May 2023 16:07:24 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v15]
In-Reply-To: <SvZujPd840GM1ukJyFUK4wKKqdgmxjr4aIAzO6c2N8w=.1d578c2f-1310-4a28-8b31-30a842627cce@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
 <SvZujPd840GM1ukJyFUK4wKKqdgmxjr4aIAzO6c2N8w=.1d578c2f-1310-4a28-8b31-30a842627cce@github.com>
Message-ID: <QE9egEYTs7akFN2hRD-4KrpTBojPHsZ916LoNPw34uI=.70dc2aa5-5bf3-4120-acf2-511cc683d522@github.com>

On Fri, 5 May 2023 16:01:00 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java.
>> 
>> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address comments
>   
>   - Annotate with Preview
>   - Fix isUnnamed hierarchy
>   - Flow names.empty for underscore in both model and API
>   - Adjust pretty printing and annotation pretty printing
>   - Fix guard bindings (great catch and thx @lahodaj!)
>   - Fix TreeVisitor
>   - Remove test with lambda which has a parse error from VarTree (names.empty is used to signal error)
>   - Various adjustments
>   
>   Co-authored-by: Jan Lahoda <jan.lahoda at oracle.com>

Addressed all comments in https://github.com/openjdk/jdk/pull/13528/commits/5d9a1ba74aad4ee95dad6892d40e0aa68e04af18

Thx @lahodaj, @vicente-romero-oracle, @mcimadamore, @jddarcy ???

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

PR Comment: https://git.openjdk.org/jdk/pull/13528#issuecomment-1536469342

From darcy at openjdk.org  Fri May  5 21:25:23 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 5 May 2023 21:25:23 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v15]
In-Reply-To: <SvZujPd840GM1ukJyFUK4wKKqdgmxjr4aIAzO6c2N8w=.1d578c2f-1310-4a28-8b31-30a842627cce@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
 <SvZujPd840GM1ukJyFUK4wKKqdgmxjr4aIAzO6c2N8w=.1d578c2f-1310-4a28-8b31-30a842627cce@github.com>
Message-ID: <tjmx6Hf7yOOJByMsOYVJbGhAvvqdCHOSXYy_tCwnzUc=.d246ea05-03c6-4805-9486-74a8879bca0e@github.com>

On Fri, 5 May 2023 16:01:00 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java.
>> 
>> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address comments
>   
>   - Annotate with Preview
>   - Fix isUnnamed hierarchy
>   - Flow names.empty for underscore in both model and API
>   - Adjust pretty printing and annotation pretty printing
>   - Fix guard bindings (great catch and thx @lahodaj!)
>   - Fix TreeVisitor
>   - Remove test with lambda which has a parse error from VarTree (names.empty is used to signal error)
>   - Various adjustments
>   
>   Co-authored-by: Jan Lahoda <jan.lahoda at oracle.com>

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java line 1788:

> 1786:         }
> 1787: 
> 1788:         @Override @DefinedBy(Api.LANGUAGE_MODEL)

It's not incorrect to have this override, but I don't think it is necessary now either with the update to the default method.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1186509423

From duke at openjdk.org  Sat May  6 00:40:24 2023
From: duke at openjdk.org (duke)
Date: Sat, 6 May 2023 00:40:24 GMT
Subject: Withdrawn: 8299934: LocalExecutionControl replaces default uncaught
 exception handler
In-Reply-To: <mP7SjLQS9NvZJq2KVoD_VrW2lNi3CHBANSmc4RRWmH0=.f4ae105e-b3a1-4b2e-b547-dde595b3d206@github.com>
References: <mP7SjLQS9NvZJq2KVoD_VrW2lNi3CHBANSmc4RRWmH0=.f4ae105e-b3a1-4b2e-b547-dde595b3d206@github.com>
Message-ID: <T9_Q_ae2o9ZViaCI7ZyCMmAh47sr6kshN6FQcR6jmo4=.ec638981-16fa-4732-8193-55ca26cb1c30@github.com>

On Fri, 10 Mar 2023 19:48:42 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> The JShell's `LocalExecutionControl` set the global default uncaught exception handler, causing problems to external code that might rely on it (even if only for logging/debugging purposes).
> 
> The proposal here is to do what the bug is suggesting, and only handling the exception inside the `ThreadGroup` that JShell creates. The patch does not strive to do further changes to how the exception handling is done.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk/pull/12982

From darcy at openjdk.org  Sat May  6 02:44:30 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Sat, 6 May 2023 02:44:30 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v65]
In-Reply-To: <MO9fOyqaeyudnk0FP4X1BjFQkhKTwBdqimUxl68iulc=.19f1303d-f095-4cf3-b052-29b46135e6c0@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <MO9fOyqaeyudnk0FP4X1BjFQkhKTwBdqimUxl68iulc=.19f1303d-f095-4cf3-b052-29b46135e6c0@github.com>
Message-ID: <nAe_DBQxds8A45LkLzTNlflVBLc09_E1Dnhtj4cUjZ4=.2d01b306-25a5-4217-91dc-b64c439f1bef@github.com>

On Thu, 27 Apr 2023 17:21:23 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   CSR recommendations

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 123:

> 121:     @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES)
> 122:     public static final int MAX_INDY_CONCAT_ARG_SLOTS;
> 123:     static { MAX_INDY_CONCAT_ARG_SLOTS = 200; }

I think this deserve a comment such as "use static initialize block to avoid MAX_INDY_CONCAT_ARG_SLOTS being treating as a constant for constant folding," assuming that is the intention here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1186599844

From darcy at openjdk.org  Sat May  6 02:57:20 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Sat, 6 May 2023 02:57:20 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v65]
In-Reply-To: <MO9fOyqaeyudnk0FP4X1BjFQkhKTwBdqimUxl68iulc=.19f1303d-f095-4cf3-b052-29b46135e6c0@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <MO9fOyqaeyudnk0FP4X1BjFQkhKTwBdqimUxl68iulc=.19f1303d-f095-4cf3-b052-29b46135e6c0@github.com>
Message-ID: <0lyLXXpOtSz0C8DvkpexUAyj3IPrqUkP4WuLHrw_30c=.512031ec-bacb-4918-a4be-6054a684fddb@github.com>

On Thu, 27 Apr 2023 17:21:23 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   CSR recommendations

src/java.base/share/classes/java/lang/StringTemplate.java line 427:

> 425:      * {@link StringTemplate}. To accommodate concatenation, values are converted to strings
> 426:      * as if invoking {@link String#valueOf(Object)}.
> 427:      * @implNote {@link StringTemplate#STR} is statically imported implicitly into every

IMO the remark regarding  STR being auto-imported works better as an apiNote rather than an implNote.

Regarding interning, I think an implSpec of "may or may not be interned" provides maximum flexibility to the implementation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1186601013

From acobbs at openjdk.org  Sat May  6 15:28:28 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Sat, 6 May 2023 15:28:28 GMT
Subject: RFR: 8247403: JShell: No custom input (e.g. from GUI) possible
 with JavaShellToolBuilder [v3]
In-Reply-To: <IlZSSWqIq_TKrhMFJWcDbgeRm8CEhFacsMhoOAjXpQk=.7ed1ea83-5bc7-4ea2-83b1-4333d1744bbd@github.com>
References: <LG3Ko-Xn6aySWkkgG2YXLUtVLhpiFcJ7prYtQm-Fzns=.b2c17f87-faef-46e6-ac0d-6f08187dde69@github.com>
 <IlZSSWqIq_TKrhMFJWcDbgeRm8CEhFacsMhoOAjXpQk=.7ed1ea83-5bc7-4ea2-83b1-4333d1744bbd@github.com>
Message-ID: <qh-o1PuLrR7-9ueZhHhcpzmuOQ0mtxTeZMKXyJgc3SE=.bfa20e64-5e4b-4f6b-8a8c-8187dcc6890f@github.com>

On Mon, 24 May 2021 08:20:44 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Basically, JShell's ConsoleIOContext always uses the JLine's default terminal, which uses System.in, or equivalent, for input. But, if the JShell tool has been created using JavaShellToolBuilder, a different input might have been provided. The proposed solution is to use a different JLine's terminal in this case, based on the provided input.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding note about the default behavior, as suggested.

src/jdk.internal.le/share/classes/jdk/internal/org/jline/reader/impl/LineReaderImpl.java line 4160:

> 4158:                 sb.append(ch);
> 4159:         }
> 4160:         if (padToWidth > cols) {

Random blast-from-the-past question: would it be appropriate to submit this change back to the jline project? It doesn't appear to be in the current jline3 master.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/2509#discussion_r1186711227

From abimpoudis at openjdk.org  Sat May  6 21:23:32 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Sat, 6 May 2023 21:23:32 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v16]
In-Reply-To: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
Message-ID: <kPZKlHHE3yS_xw9IBAokmmJ-KAeKLFIAqbCBKfkZwrc=.07126b4e-5be6-4873-920c-7f3d25ebca4a@github.com>

> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java.
> 
> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/

Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:

  Remove @Override from VarSymbol.isUnnamed

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13528/files
  - new: https://git.openjdk.org/jdk/pull/13528/files/5d9a1ba7..482dbfa2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13528&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13528&range=14-15

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13528.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13528/head:pull/13528

PR: https://git.openjdk.org/jdk/pull/13528

From abimpoudis at openjdk.org  Mon May  8 10:17:35 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 8 May 2023 10:17:35 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v16]
In-Reply-To: <kPZKlHHE3yS_xw9IBAokmmJ-KAeKLFIAqbCBKfkZwrc=.07126b4e-5be6-4873-920c-7f3d25ebca4a@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
 <kPZKlHHE3yS_xw9IBAokmmJ-KAeKLFIAqbCBKfkZwrc=.07126b4e-5be6-4873-920c-7f3d25ebca4a@github.com>
Message-ID: <W9zmET-GjGsbd7WYLLR2iSxQOvP116b0yFSm4y6ERVg=.a56a8673-3418-42a6-bd98-f6e6a400a679@github.com>

On Sat, 6 May 2023 21:23:32 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java.
>> 
>> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove @Override from VarSymbol.isUnnamed

BTW we can remove the `isUnnamed` from `VarSymbol` as @jddarcy pointed me out correctly. 

By keeping it we avoid sprinkling 5 core places with `@SuppressWarnings("preview")`. However, I think it will be cleaner without that override, despite the annotation and I would be in favor of that. Are there any concerns? e.g.,


diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java
index 631b0ce61ac..dc84c89f88e 100644
--- a/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java
+++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java
@@ -1784,11 +1784,6 @@ public abstract class Symbol extends AnnoConstruct implements PoolConstant, Elem
         public <R, P> R accept(Symbol.Visitor<R, P> v, P p) {
             return v.visitVarSymbol(this, p);
         }
-
-        @DefinedBy(Api.LANGUAGE_MODEL)
-        public boolean isUnnamed() {
-            return name.isEmpty();
-        }
     }
 
     public static class RecordComponent extends VarSymbol implements RecordComponentElement {
diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
index 986f2e9fe89..26ef1c41156 100644
--- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
+++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
@@ -93,6 +93,7 @@ import com.sun.tools.javac.util.JCDiagnostic.DiagnosticFlag;
  *  This code and its internal interfaces are subject to change or
  *  deletion without notice.</b>
  */
+ at SuppressWarnings("preview")
 public class Attr extends JCTree.Visitor {
     protected static final Context.Key<Attr> attrKey = new Context.Key<>();
 
diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java
index 725a8a5e37d..537635a9490 100644
--- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java
+++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java
@@ -93,6 +93,7 @@ import javax.lang.model.util.ElementKindVisitor14;
  *  This code and its internal interfaces are subject to change or
  *  deletion without notice.</b>
  */
+ at SuppressWarnings("preview")
 public class Check {
     protected static final Context.Key<Check> checkKey = new Context.Key<>();
 
diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java
index 452a823a46e..997ae7e3d81 100644
--- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java
+++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java
@@ -203,6 +203,7 @@ import static java.util.stream.Collectors.groupingBy;
  *  This code and its internal interfaces are subject to change or
  *  deletion without notice.</b>
  */
+ at SuppressWarnings("preview")
 public class Flow {
     protected static final Context.Key<Flow> flowKey = new Context.Key<>();
 
diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/MemberEnter.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/MemberEnter.java
index 13a4dd6c2cd..220aaf220d0 100644
--- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/MemberEnter.java
+++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/MemberEnter.java
@@ -53,6 +53,7 @@ import static com.sun.tools.javac.code.TypeTag.TYPEVAR;
  *  This code and its internal interfaces are subject to change or
  *  deletion without notice.</b>
  */
+ at SuppressWarnings("preview")
 public class MemberEnter extends JCTree.Visitor {
     protected static final Context.Key<MemberEnter> memberEnterKey = new Context.Key<>();
 
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 44ea3f904bd..cdf7d18b599 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
@@ -113,6 +113,7 @@ import com.sun.tools.javac.util.List;
 /**
  * This pass translates pattern-matching constructs, such as instanceof <pattern>.
  */
+ at SuppressWarnings("preview")
 public class TransPatterns extends TreeTranslator {
 
     protected static final Context.Key<TransPatterns> transPatternsKey = new Context.Key<>();

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

PR Comment: https://git.openjdk.org/jdk/pull/13528#issuecomment-1538121683

From abimpoudis at openjdk.org  Mon May  8 12:05:53 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 8 May 2023 12:05:53 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v17]
In-Reply-To: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
Message-ID: <avAPtvy1DwzSBKKJNSq3td6c4RmOdOAunzZJP4BS27g=.5a706ca1-21bc-4cb5-82f3-01a6117dd268@github.com>

> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java.
> 
> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/

Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:

  Remove isUnnamed from VarSymbol

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13528/files
  - new: https://git.openjdk.org/jdk/pull/13528/files/482dbfa2..a46b674a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13528&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13528&range=15-16

  Stats: 10 lines in 6 files changed: 5 ins; 5 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13528.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13528/head:pull/13528

PR: https://git.openjdk.org/jdk/pull/13528

From mcimadamore at openjdk.org  Mon May  8 12:15:36 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 8 May 2023 12:15:36 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v16]
In-Reply-To: <W9zmET-GjGsbd7WYLLR2iSxQOvP116b0yFSm4y6ERVg=.a56a8673-3418-42a6-bd98-f6e6a400a679@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
 <kPZKlHHE3yS_xw9IBAokmmJ-KAeKLFIAqbCBKfkZwrc=.07126b4e-5be6-4873-920c-7f3d25ebca4a@github.com>
 <W9zmET-GjGsbd7WYLLR2iSxQOvP116b0yFSm4y6ERVg=.a56a8673-3418-42a6-bd98-f6e6a400a679@github.com>
Message-ID: <88NQ70nvZPnIC71TrH1ftnD68fD0df972hGWdKBqgAo=.46bee3cd-75ad-4ddb-a269-cbc0925e7843@github.com>

On Mon, 8 May 2023 10:13:24 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> BTW we can remove the `isUnnamed` from `VarSymbol` as @jddarcy pointed me out correctly.
> 
> By keeping it we avoid sprinkling 5 core places with `@SuppressWarnings("preview")`. However, I think it will be cleaner without that override, despite the annotation and I would be in favor of that. Are there any concerns? e.g.,
> 
> ```
> diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java
> index 631b0ce61ac..dc84c89f88e 100644
> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java
> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java
> @@ -1784,11 +1784,6 @@ public abstract class Symbol extends AnnoConstruct implements PoolConstant, Elem
>          public <R, P> R accept(Symbol.Visitor<R, P> v, P p) {
>              return v.visitVarSymbol(this, p);
>          }
> -
> -        @DefinedBy(Api.LANGUAGE_MODEL)
> -        public boolean isUnnamed() {
> -            return name.isEmpty();
> -        }
>      }
>  
>      public static class RecordComponent extends VarSymbol implements RecordComponentElement {
> diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
> index 986f2e9fe89..26ef1c41156 100644
> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
> @@ -93,6 +93,7 @@ import com.sun.tools.javac.util.JCDiagnostic.DiagnosticFlag;
>   *  This code and its internal interfaces are subject to change or
>   *  deletion without notice.</b>
>   */
> + at SuppressWarnings("preview")
>  public class Attr extends JCTree.Visitor {
>      protected static final Context.Key<Attr> attrKey = new Context.Key<>();
>  
> diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java
> index 725a8a5e37d..537635a9490 100644
> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java
> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java
> @@ -93,6 +93,7 @@ import javax.lang.model.util.ElementKindVisitor14;
>   *  This code and its internal interfaces are subject to change or
>   *  deletion without notice.</b>
>   */
> + at SuppressWarnings("preview")
>  public class Check {
>      protected static final Context.Key<Check> checkKey = new Context.Key<>();
>  
> diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java
> index 452a823a46e..997ae7e3d81 100644
> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java
> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java
> @@ -203,6 +203,7 @@ import static java.util.stream.Collectors.groupingBy;
>   *  This code and its internal interfaces are subject to change or
>   *  deletion without notice.</b>
>   */
> + at SuppressWarnings("preview")
>  public class Flow {
>      protected static final Context.Key<Flow> flowKey = new Context.Key<>();
>  
> diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/MemberEnter.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/MemberEnter.java
> index 13a4dd6c2cd..220aaf220d0 100644
> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/MemberEnter.java
> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/MemberEnter.java
> @@ -53,6 +53,7 @@ import static com.sun.tools.javac.code.TypeTag.TYPEVAR;
>   *  This code and its internal interfaces are subject to change or
>   *  deletion without notice.</b>
>   */
> + at SuppressWarnings("preview")
>  public class MemberEnter extends JCTree.Visitor {
>      protected static final Context.Key<MemberEnter> memberEnterKey = new Context.Key<>();
>  
> 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 44ea3f904bd..cdf7d18b599 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
> @@ -113,6 +113,7 @@ import com.sun.tools.javac.util.List;
>  /**
>   * This pass translates pattern-matching constructs, such as instanceof <pattern>.
>   */
> + at SuppressWarnings("preview")
>  public class TransPatterns extends TreeTranslator {
>  
>      protected static final Context.Key<TransPatterns> transPatternsKey = new Context.Key<>();
> ```

One thing we did in other places was to have a private equivalent of some public API method, so that we can call it internally from the compiler, w/o too much hassle (the internal version doesn't need to be marked as preview).

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

PR Comment: https://git.openjdk.org/jdk/pull/13528#issuecomment-1538257990

From jlaskey at openjdk.org  Mon May  8 12:51:08 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 8 May 2023 12:51:08 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v65]
In-Reply-To: <nAe_DBQxds8A45LkLzTNlflVBLc09_E1Dnhtj4cUjZ4=.2d01b306-25a5-4217-91dc-b64c439f1bef@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <MO9fOyqaeyudnk0FP4X1BjFQkhKTwBdqimUxl68iulc=.19f1303d-f095-4cf3-b052-29b46135e6c0@github.com>
 <nAe_DBQxds8A45LkLzTNlflVBLc09_E1Dnhtj4cUjZ4=.2d01b306-25a5-4217-91dc-b64c439f1bef@github.com>
Message-ID: <YJrw2TYcIl3YSbBUhC8lZkj80rjtMCCRbdxd9wK8sqM=.2b8176bd-a66d-4256-b407-9b9ea7529f01@github.com>

On Sat, 6 May 2023 02:42:14 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   CSR recommendations
>
> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 123:
> 
>> 121:     @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES)
>> 122:     public static final int MAX_INDY_CONCAT_ARG_SLOTS;
>> 123:     static { MAX_INDY_CONCAT_ARG_SLOTS = 200; }
> 
> I think this deserve a comment such as "use static initialize block to avoid MAX_INDY_CONCAT_ARG_SLOTS being treating as a constant for constant folding," assuming that is the intention here.

Changed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1187407224

From jlaskey at openjdk.org  Mon May  8 12:53:16 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 8 May 2023 12:53:16 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v65]
In-Reply-To: <0lyLXXpOtSz0C8DvkpexUAyj3IPrqUkP4WuLHrw_30c=.512031ec-bacb-4918-a4be-6054a684fddb@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <MO9fOyqaeyudnk0FP4X1BjFQkhKTwBdqimUxl68iulc=.19f1303d-f095-4cf3-b052-29b46135e6c0@github.com>
 <0lyLXXpOtSz0C8DvkpexUAyj3IPrqUkP4WuLHrw_30c=.512031ec-bacb-4918-a4be-6054a684fddb@github.com>
Message-ID: <u3aYXVcsp34hfkaxT-GO3Q5czUxnrxeSis416oflJQI=.8685258b-3c9d-404f-a98d-c6a512c044a0@github.com>

On Sat, 6 May 2023 02:53:49 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   CSR recommendations
>
> src/java.base/share/classes/java/lang/StringTemplate.java line 427:
> 
>> 425:      * {@link StringTemplate}. To accommodate concatenation, values are converted to strings
>> 426:      * as if invoking {@link String#valueOf(Object)}.
>> 427:      * @implNote {@link StringTemplate#STR} is statically imported implicitly into every
> 
> IMO the remark regarding  STR being auto-imported works better as an apiNote rather than an implNote.
> 
> Regarding interning, I think an implSpec of "may or may not be interned" provides maximum flexibility to the implementation.

Changed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1187409617

From abimpoudis at openjdk.org  Mon May  8 13:27:55 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 8 May 2023 13:27:55 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v18]
In-Reply-To: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
Message-ID: <oqsa2uw1baTZcyqwRWTH2576kAOiuwuq6HAffDUvubk=.3b3c9396-b4a1-48a1-9762-a4d7c3cf4404@github.com>

> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java.
> 
> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/

Aggelos Biboudis has updated the pull request incrementally with two additional commits since the last revision:

 - Reintroduce isUnnamed from VarSymbol with different name
 - Revert "Remove isUnnamed from VarSymbol"
   
   This reverts commit a46b674a5077da603c400f2005cf4a7a48d104b2.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13528/files
  - new: https://git.openjdk.org/jdk/pull/13528/files/a46b674a..8def897a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13528&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13528&range=16-17

  Stats: 15 lines in 7 files changed: 4 ins; 5 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/13528.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13528/head:pull/13528

PR: https://git.openjdk.org/jdk/pull/13528

From abimpoudis at openjdk.org  Mon May  8 13:43:42 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 8 May 2023 13:43:42 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v19]
In-Reply-To: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
Message-ID: <MhxtZfvyhKq5p3yOul_oB3bhOXBjCVRsnqtDkx7WqMs=.3d29e90b-9ea2-4deb-8355-f64258906014@github.com>

> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java.
> 
> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/

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

 - Merge branch 'JDK-8300543' into unnamed
 - Reintroduce isUnnamed from VarSymbol with different name
 - Revert "Remove isUnnamed from VarSymbol"
   
   This reverts commit a46b674a5077da603c400f2005cf4a7a48d104b2.
 - Remove isUnnamed from VarSymbol
 - Remove @Override from VarSymbol.isUnnamed
 - Address comments
   
   - Annotate with Preview
   - Fix isUnnamed hierarchy
   - Flow names.empty for underscore in both model and API
   - Adjust pretty printing and annotation pretty printing
   - Fix guard bindings (great catch and thx @lahodaj!)
   - Fix TreeVisitor
   - Remove test with lambda which has a parse error from VarTree (names.empty is used to signal error)
   - Various adjustments
   
   Co-authored-by: Jan Lahoda <jan.lahoda at oracle.com>
 - 8307482: Compiler should accept var _ in nested patterns in switch case
 - Add test
 - 8307444: java.lang.AssertionError when using unnamed patterns
 - Add guard test
 - ... and 34 more: https://git.openjdk.org/jdk/compare/79bbd717...c9387a26

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

Changes: https://git.openjdk.org/jdk/pull/13528/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13528&range=18
  Stats: 1536 lines in 49 files changed: 1217 ins; 144 del; 175 mod
  Patch: https://git.openjdk.org/jdk/pull/13528.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13528/head:pull/13528

PR: https://git.openjdk.org/jdk/pull/13528

From abimpoudis at openjdk.org  Mon May  8 14:07:16 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 8 May 2023 14:07:16 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v20]
In-Reply-To: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
Message-ID: <7W_6EL5-SFADT46s6FLPgRJejqu5VUcdNbzAX5z9Gss=.99e557be-83c8-4581-b389-f7f208c05434@github.com>

> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java.
> 
> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/

Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:

  Doc adjustments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13528/files
  - new: https://git.openjdk.org/jdk/pull/13528/files/c9387a26..2580f603

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13528&range=19
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13528&range=18-19

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/13528.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13528/head:pull/13528

PR: https://git.openjdk.org/jdk/pull/13528

From vromero at openjdk.org  Mon May  8 17:35:36 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 8 May 2023 17:35:36 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v20]
In-Reply-To: <7W_6EL5-SFADT46s6FLPgRJejqu5VUcdNbzAX5z9Gss=.99e557be-83c8-4581-b389-f7f208c05434@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
 <7W_6EL5-SFADT46s6FLPgRJejqu5VUcdNbzAX5z9Gss=.99e557be-83c8-4581-b389-f7f208c05434@github.com>
Message-ID: <-W_OQ97X7IF57Q5y8_-X3lyEWq8dGhtxglrDYG5dP30=.23bcb69d-b2c4-4188-a8d6-4889032b2f52@github.com>

On Mon, 8 May 2023 14:07:16 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java.
>> 
>> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Doc adjustments

looks good

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13528#pullrequestreview-1417214589

From jlaskey at openjdk.org  Mon May  8 19:13:47 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 8 May 2023 19:13:47 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v66]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <q4SwaaWMYKvgNUafmFVdnuH4ZbvRWQ6sUBbiccMQ6ag=.18c6b403-544a-417b-ad05-a7901ecf97df@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

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

  Requested changes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/fb406d23..53f6280d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=65
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=64-65

  Stats: 16 lines in 3 files changed: 13 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/10889/head:pull/10889

PR: https://git.openjdk.org/jdk/pull/10889

From abimpoudis at openjdk.org  Mon May  8 20:15:46 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 8 May 2023 20:15:46 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v21]
In-Reply-To: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
Message-ID: <f95zuqChwUB5NtD18YizwoPEZvbd7eqLXHjjGwuGFN8=.1839431d-a064-46cb-83b5-07cf4180481f@github.com>

> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java.
> 
> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/

Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:

  Remove Elements.isUnamed(VariableElement) given the presence of VariableElement.isUnamed

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13528/files
  - new: https://git.openjdk.org/jdk/pull/13528/files/2580f603..19870563

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13528&range=20
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13528&range=19-20

  Stats: 52 lines in 4 files changed: 1 ins; 49 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/13528.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13528/head:pull/13528

PR: https://git.openjdk.org/jdk/pull/13528

From abimpoudis at openjdk.org  Mon May  8 20:36:02 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 8 May 2023 20:36:02 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v22]
In-Reply-To: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
Message-ID: <htyUrGmMzJfWvNlwOEvhuPKqGC8sCv12CJFY98dprs8=.3d7ee53e-d83e-45ac-82e0-1fc21f3680bd@github.com>

> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java.
> 
> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/

Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:

  Add at since tag

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13528/files
  - new: https://git.openjdk.org/jdk/pull/13528/files/19870563..0437b20f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13528&range=21
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13528&range=20-21

  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13528.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13528/head:pull/13528

PR: https://git.openjdk.org/jdk/pull/13528

From darcy at openjdk.org  Tue May  9 02:12:32 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 9 May 2023 02:12:32 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v22]
In-Reply-To: <htyUrGmMzJfWvNlwOEvhuPKqGC8sCv12CJFY98dprs8=.3d7ee53e-d83e-45ac-82e0-1fc21f3680bd@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
 <htyUrGmMzJfWvNlwOEvhuPKqGC8sCv12CJFY98dprs8=.3d7ee53e-d83e-45ac-82e0-1fc21f3680bd@github.com>
Message-ID: <DU9C7ecpeVbBcmjVDtRLXG2jhPTlhm0GK7nUUS2x5uE=.a0a2653a-8b82-40e0-ad6d-572d3e46c709@github.com>

On Mon, 8 May 2023 20:36:02 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java.
>> 
>> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add at since tag

src/java.compiler/share/classes/javax/lang/model/util/Elements.java line 28:

> 26: package javax.lang.model.util;
> 27: 
> 28: import jdk.internal.javac.PreviewFeature;

I believe this import can now be removed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1188046153

From darcy at openjdk.org  Tue May  9 02:35:31 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 9 May 2023 02:35:31 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v13]
In-Reply-To: <KRKEVfFpcgrUwYrZ5JIDMczuKJcV9l7juArbkNMRNmw=.8c7d87b3-92ef-41e3-8c96-fa4abefc5c6b@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
 <7x1mAOBwhQdGgCaHjiOQ1O9BCmgJFKASy7yFJHsGVbI=.842ee2fe-8819-4e43-935a-120303815fd5@github.com>
 <2f6yNQHJy1t65PBsSelcHM2episYeYxt7gdYtQV1Zsc=.ff0f7299-3378-496d-ad92-0ed1cbdf90e8@github.com>
 <8fbux7W7kkd8KYN9Z6ks6IHYdtrFIPhQPTZ6lI816tw=.156e8b6d-0b18-4690-9f5a-21bbbca30bc5@github.com>
 <GSv1LAteLBvO4ITvTDyZg4yI__QUomsfGIrrOe7ILA8=.a396c45d-cd3c-4d4f-a65a-8a91636fc066@github.com>
 <KRKEVfFpcgrUwYrZ5JIDMczuKJcV9l7juArbkNMRNmw=.8c7d87b3-92ef-41e3-8c96-fa4abefc5c6b@github.com>
Message-ID: <JxVFVwfQnH1cjHA11r3x7g0fgRwhuzJg4vNnVRG3g4o=.0e22a0df-8679-4af5-bb6e-2b0f4d15a36f@github.com>

On Tue, 9 May 2023 02:29:07 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Note that `Element` does not declare `isUnnamed`.
>> 
>> `isUnnamed` overrides method in `VariableElement` (javax.lang.model.element) via subclass `VarSymbol` in `Symbol`.
>
>> Note that `Element` does not declare `isUnnamed`.
>> 
>> `isUnnamed` overrides method in `VariableElement` (javax.lang.model.element) via subclass `VarSymbol` in `Symbol`.
> 
> I think it is preferable for VarSymbol.isUnnamed to be deleted; it is functionally the same as the default method defined on VariableElement.

> 

PS Just saw the additional discussion on this point below.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1188055782

From darcy at openjdk.org  Tue May  9 02:35:30 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 9 May 2023 02:35:30 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v13]
In-Reply-To: <GSv1LAteLBvO4ITvTDyZg4yI__QUomsfGIrrOe7ILA8=.a396c45d-cd3c-4d4f-a65a-8a91636fc066@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
 <7x1mAOBwhQdGgCaHjiOQ1O9BCmgJFKASy7yFJHsGVbI=.842ee2fe-8819-4e43-935a-120303815fd5@github.com>
 <2f6yNQHJy1t65PBsSelcHM2episYeYxt7gdYtQV1Zsc=.ff0f7299-3378-496d-ad92-0ed1cbdf90e8@github.com>
 <8fbux7W7kkd8KYN9Z6ks6IHYdtrFIPhQPTZ6lI816tw=.156e8b6d-0b18-4690-9f5a-21bbbca30bc5@github.com>
 <GSv1LAteLBvO4ITvTDyZg4yI__QUomsfGIrrOe7ILA8=.a396c45d-cd3c-4d4f-a65a-8a91636fc066@github.com>
Message-ID: <KRKEVfFpcgrUwYrZ5JIDMczuKJcV9l7juArbkNMRNmw=.8c7d87b3-92ef-41e3-8c96-fa4abefc5c6b@github.com>

On Fri, 5 May 2023 10:38:21 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> Note that `Element` does not declare `isUnnamed`.
> 
> `isUnnamed` overrides method in `VariableElement` (javax.lang.model.element) via subclass `VarSymbol` in `Symbol`.

I think it is preferable for VarSymbol.isUnnamed to be deleted; it is functionally the same as the default method defined on VariableElement.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1188054212

From darcy at openjdk.org  Tue May  9 02:35:32 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 9 May 2023 02:35:32 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v13]
In-Reply-To: <A0qiV-hF4cVcZ_7yKYMC-IeicEgHMoEAMF3NhOvRQ3A=.e32e4f7f-6cbf-446b-99a5-de3b0caffcff@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
 <7x1mAOBwhQdGgCaHjiOQ1O9BCmgJFKASy7yFJHsGVbI=.842ee2fe-8819-4e43-935a-120303815fd5@github.com>
 <m_Bt11TjVke4TN19jm8GrQ2upjcMIa4_wE4DGvTXYQM=.6fa00ad2-1488-45c6-8ef8-4b97faaaafce@github.com>
 <dpIukQjXp9zW4c3GoZP3r77X0XrUF-RMAwUiADH2Kt4=.0694fda9-b3b5-4cd7-a027-3110e4c34286@github.com>
 <A0qiV-hF4cVcZ_7yKYMC-IeicEgHMoEAMF3NhOvRQ3A=.e32e4f7f-6cbf-446b-99a5-de3b0caffcff@github.com>
Message-ID: <gskM_p4YyCK3H6WTdrVsU220uzGNgKukiJb-ZRzzhTs=.b7a6d52d-76dd-4a4c-b5e2-b175391e686d@github.com>

On Fri, 5 May 2023 08:57:43 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Yeap, this is what I thought at first but I was getting  "warnings found and -Werror specified". So compilation was failing.
>
> IIRC the error is reported on the class level (with position on the class), so suppressing the warning on the method is not sufficient. We might want to review if the warning could have a better position, but we probably should not do it under this patch.

I think the suppress warnings annotation can be deleted now that the isUnnamed method has been removed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1188055506

From darcy at openjdk.org  Tue May  9 02:40:25 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 9 May 2023 02:40:25 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v22]
In-Reply-To: <htyUrGmMzJfWvNlwOEvhuPKqGC8sCv12CJFY98dprs8=.3d7ee53e-d83e-45ac-82e0-1fc21f3680bd@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
 <htyUrGmMzJfWvNlwOEvhuPKqGC8sCv12CJFY98dprs8=.3d7ee53e-d83e-45ac-82e0-1fc21f3680bd@github.com>
Message-ID: <-4RKGiOsEIAs4izpQO8bpM90d2N-0sWIilYEtMxlh3s=.ed7e1e05-f29a-4f41-9776-229d3ac32436@github.com>

On Mon, 8 May 2023 20:36:02 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java.
>> 
>> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add at since tag

Modulo the few nits noted, the javax.lang.model changes look fine.

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

Marked as reviewed by darcy (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13528#pullrequestreview-1417754881

From abimpoudis at openjdk.org  Tue May  9 09:15:44 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Tue, 9 May 2023 09:15:44 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v23]
In-Reply-To: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
Message-ID: <6s6Gpc-w89RTMO6yAQqb3PKmaelt59nvpOoZK0ZSfCM=.a1e933d4-e3e5-496d-b8f6-dbae2f8048a0@github.com>

> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java.
> 
> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/

Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:

  Cleanup

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13528/files
  - new: https://git.openjdk.org/jdk/pull/13528/files/0437b20f..a0e04e93

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13528&range=22
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13528&range=21-22

  Stats: 3 lines in 2 files changed: 0 ins; 3 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13528.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13528/head:pull/13528

PR: https://git.openjdk.org/jdk/pull/13528

From jlaskey at openjdk.org  Tue May  9 12:54:50 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 9 May 2023 12:54:50 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v67]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <l7J5wI3ZLIVlZLDWAOSqMm43O9LPr7wZMEAlXpAz3ek=.15f31874-1c70-45ac-b63b-97a262b0fd51@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

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

  Recommended changes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/53f6280d..8e83e10d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=66
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=65-66

  Stats: 4 lines in 1 file changed: 0 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/10889/head:pull/10889

PR: https://git.openjdk.org/jdk/pull/10889

From jlaskey at openjdk.org  Tue May  9 12:58:27 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 9 May 2023 12:58:27 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v68]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <-604u-rNn9gRrC9Q6UVQOjKKmfhlKoNzyTZnhrnv2lw=.448fc7f3-6aea-4352-abc7-2a4a252565da@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

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

  Dangling <p>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/8e83e10d..2ac6252b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=67
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=66-67

  Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/10889/head:pull/10889

PR: https://git.openjdk.org/jdk/pull/10889

From darcy at openjdk.org  Tue May  9 16:04:48 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 9 May 2023 16:04:48 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v68]
In-Reply-To: <-604u-rNn9gRrC9Q6UVQOjKKmfhlKoNzyTZnhrnv2lw=.448fc7f3-6aea-4352-abc7-2a4a252565da@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <-604u-rNn9gRrC9Q6UVQOjKKmfhlKoNzyTZnhrnv2lw=.448fc7f3-6aea-4352-abc7-2a4a252565da@github.com>
Message-ID: <FZfpnNgeSWv_zBF2Zi_t9N__2HRiPM9om-prQVYkQPo=.0f6bb954-3f1e-499d-9967-cad643fb6548@github.com>

On Tue, 9 May 2023 12:58:27 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Dangling <p>

Marked as reviewed by darcy (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/10889#pullrequestreview-1418983197

From jlaskey at openjdk.org  Tue May  9 16:24:24 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 9 May 2023 16:24:24 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v69]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <gSSu4Qochcw-uAqANO3_VCC5shkeMFjeyyqUZU3wPPI=.cd287eb8-87bf-4378-90c7-ed395fe164c5@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 88 commits:

 - Merge branch 'master' into 8285932
 - Dangling <p>
 - Recommended changes
 - Requested changes
 - CSR recommendations
 - Merge branch 'master' into 8285932
 - Spacing
 - Tidy up
 - Remove @PeviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES) from non-public classes
 - Typo
 - ... and 78 more: https://git.openjdk.org/jdk/compare/44fa12e7...f4f26611

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

Changes: https://git.openjdk.org/jdk/pull/10889/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=68
  Stats: 9330 lines in 73 files changed: 9233 ins; 23 del; 74 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/10889/head:pull/10889

PR: https://git.openjdk.org/jdk/pull/10889

From liach at openjdk.org  Tue May  9 16:26:08 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 9 May 2023 16:26:08 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v68]
In-Reply-To: <-604u-rNn9gRrC9Q6UVQOjKKmfhlKoNzyTZnhrnv2lw=.448fc7f3-6aea-4352-abc7-2a4a252565da@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <-604u-rNn9gRrC9Q6UVQOjKKmfhlKoNzyTZnhrnv2lw=.448fc7f3-6aea-4352-abc7-2a4a252565da@github.com>
Message-ID: <cC6vWaC5XidjKv1fz6EfLtnEJSwFegkRZE_RKgc07VI=.2b746469-a931-4895-bb79-60871bb91afd@github.com>

On Tue, 9 May 2023 12:58:27 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Dangling <p>

TestJavacTaskScanner is failing because of the new `setPrevToken` added that changes the total element count. Just need to update the count to take the changes to `Scanner` into account.

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

PR Comment: https://git.openjdk.org/jdk/pull/10889#issuecomment-1540490098

From jlaskey at openjdk.org  Tue May  9 16:37:07 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 9 May 2023 16:37:07 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v69]
In-Reply-To: <gSSu4Qochcw-uAqANO3_VCC5shkeMFjeyyqUZU3wPPI=.cd287eb8-87bf-4378-90c7-ed395fe164c5@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <gSSu4Qochcw-uAqANO3_VCC5shkeMFjeyyqUZU3wPPI=.cd287eb8-87bf-4378-90c7-ed395fe164c5@github.com>
Message-ID: <VpUv5E3jOqLwYbNZ1xOWJ66XkPl27KYKeoIZBXIaoh0=.ee44084f-cdb4-4808-befb-5b0d7fabe20e@github.com>

On Tue, 9 May 2023 16:24:24 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 88 commits:
> 
>  - Merge branch 'master' into 8285932
>  - Dangling <p>
>  - Recommended changes
>  - Requested changes
>  - CSR recommendations
>  - Merge branch 'master' into 8285932
>  - Spacing
>  - Tidy up
>  - Remove @PeviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES) from non-public classes
>  - Typo
>  - ... and 78 more: https://git.openjdk.org/jdk/compare/44fa12e7...f4f26611

Thanks for the heads up.

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

PR Comment: https://git.openjdk.org/jdk/pull/10889#issuecomment-1540506421

From jlaskey at openjdk.org  Tue May  9 16:43:15 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 9 May 2023 16:43:15 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v70]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <9L5IuWB-IyF4NqldYaPlYKVt-29_ykeIwOu8z-x9jbk=.bb0ecc60-87aa-4a92-a6a0-d67cdf61050c@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

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

  Update TestJavacTaskScanner.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/f4f26611..6b09d2e4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=69
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=68-69

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/10889/head:pull/10889

PR: https://git.openjdk.org/jdk/pull/10889

From bpb at openjdk.org  Tue May  9 20:59:35 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 9 May 2023 20:59:35 GMT
Subject: RFR: JDK-8306983: Do not invoke external programs when switch
 terminal to raw mode on selected platforms [v2]
In-Reply-To: <g4Wfl35cnWC3CAhOjVVEi0KykmEpf216n97gidgkyC0=.721e88f1-509e-4ec3-972b-1e61c7a6143f@github.com>
References: <cGOTtVG_NmpIQ7Xpy9rMkVds3JC8az9jj530vVZr134=.4675f46c-8423-4957-ab24-00939d669563@github.com>
 <g4Wfl35cnWC3CAhOjVVEi0KykmEpf216n97gidgkyC0=.721e88f1-509e-4ec3-972b-1e61c7a6143f@github.com>
Message-ID: <SCctPXIHMDzzITzQbbBFDxmuBl2z6vhHE5GrCgRnrlQ=.c2ade825-e8de-4ec6-96bb-f495014a2561@github.com>

On Fri, 5 May 2023 12:34:29 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> To support JShell and other usecases, the JDK uses JLine, which provides line-editing functionality inside a terminal.
>> 
>> JLine has several ways to work with the terminal, based on various additional libraries and tools. Most of them are not directly usable inside the JDK, so currently, on non-Windows platforms, the JLine inside the JDK will use external programs, like `stty`, to inspect the terminal's properties and to switch the terminal to raw mode.
>> 
>> This is slightly problematic, as the external programs might be missing, and while this is not that big problem for JShell, it might be a problem for other potential uses of JLine, like using it inside `System.console()`.
>> 
>> So, the proposal here is to call the corresponding native methods directly, on selected platforms for now (Linux and Mac OS/X), instead of invoking the external programs. On Windows, this has always been the case, we are using a custom implementation of the interface that maps native and Java function for JNA there, and the proposal is to do the same here. We take the appropriate mapping interface for JNA, and provide hand-written implementation for it, using JNI.
>> 
>> The Windows implementation is mostly unchanged, the changes are mostly non-Windows only. The overview of the changes is:
>>  - `LastErrorException` is moved from the Windows-specific code to the platform-neutral code, as it is used by all the native implementations. This is the only change that directly affects the Windows-specific code
>>  -  `unix/classes/jdk/internal/org/jline/terminal/impl/jna/JnaNativePty.java` and `unix/classes/jdk/internal/org/jline/terminal/impl/jna/JnaTerminalProvider.java` are created based on the corresponding files from JLine. In JLine, these files directly call platform-specific implementations, but in this patch, the platform specific code is commented out, and replaced with calls to `JDKNativePty`, which is a new platform-specific class, that delegates to the actual platform-specific implementations. Note the `JnaNativePty.java` and `JnaTerminalProvider.java` already exist in the Windows part, but have different pieces of code commented out, which makes them substantially different.
>>  - for Linux and Mac OS/X, there are platform-specific implementations based on the corresponding code from JLine, with the hand-written JNI-based implementation of the JNA-based existing interfaces. They also have an implementation of `JDKNativePty`, which just delegates to the given platform's `"NativePty"` implementation.
>>  - the `JdkConsoleProviderImpl.java` has been tweaked to not allow the implementation based on the external programs, and gracefully falling back to the standard implementation. JShell is kept unchanged.
>> 
>> The reasons for this organization are: limiting duplication, mostly adhering to the JDK's platform specific build (which is different from the normal JLine's platform-neutral build) and limiting the difference between standard JLine and JLine inside JDK, to help future upgrades.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjusting build script as suggested on the review.

src/jdk.internal.le/linux/native/lible/CLibrary.cpp line 2:

> 1: /*
> 2:  * Copyright (c) 2015, 2018, Oracle and/or its affiliates. All rights reserved.

Copyright year 2023 only if this is new.

src/jdk.internal.le/linux/native/lible/CLibrary.cpp line 103:

> 101: 
> 102:     if (tcgetattr(fd, &data) != 0) {
> 103:         jobject exc = env->NewObject(lastErrorExceptionClass,

Could lines 103-106 be converted to a utility function which would then be invoked at current lines 103, 141, 163, and 197?

src/jdk.internal.le/linux/native/lible/CLibrary.cpp line 116:

> 114:     env->SetIntField(result, c_line, data.c_line);
> 115:     jbyteArray c_ccValue = (jbyteArray) env->GetObjectField(result, c_cc);
> 116:     env->SetByteArrayRegion(c_ccValue, 0, NCCS, (signed char *) data.c_cc);//TODO: cast?

Cast instead to `(jbyte*)` here and at lines 136 and 204?

src/jdk.internal.le/linux/native/lible/CLibrary.cpp line 183:

> 181: JNIEXPORT jint JNICALL Java_jdk_internal_org_jline_terminal_impl_jna_linux_CLibraryImpl_isatty
> 182:   (JNIEnv *, jobject, jint fd) {
> 183:     return isatty(fd);

Do we care if the native `isatty()` returns zero? Or is this dealt with somewhere else?

src/jdk.internal.le/macosx/native/lible/CLibrary.cpp line 2:

> 1: /*
> 2:  * Copyright (c) 2015, 2018, Oracle and/or its affiliates. All rights reserved.

Copyright year 2023 only?

src/jdk.internal.le/macosx/native/lible/CLibrary.cpp line 59:

> 57: 
> 58: JNIEXPORT void JNICALL Java_jdk_internal_org_jline_terminal_impl_jna_osx_CLibraryImpl_initIDs
> 59:   (JNIEnv *env, jclass) {

Missing parameter for `jclass`? Maybe add `clazz` or `unused` or something?

src/jdk.internal.le/macosx/native/lible/CLibrary.cpp line 109:

> 107: 
> 108:     if (tcgetattr(fd, &data) != 0) {
> 109:         jobject exc = env->NewObject(lastErrorExceptionClass,

Could lines 109-112 be converted to a utility function which would then be invoked at current lines 109, 145, 167, and 197?

src/jdk.internal.le/macosx/native/lible/CLibrary.cpp line 121:

> 119:     env->SetLongField(env->GetObjectField(result, c_lflag), nativelong_value, data.c_lflag);
> 120:     jbyteArray c_ccValue = (jbyteArray) env->GetObjectField(result, c_cc);
> 121:     env->SetByteArrayRegion(c_ccValue, 0, NCCS, (signed char *) data.c_cc);

Cast instead to `(jbyte*)` here and at lines 140 and 208?

src/jdk.internal.le/macosx/native/lible/CLibrary.cpp line 187:

> 185: JNIEXPORT jint JNICALL Java_jdk_internal_org_jline_terminal_impl_jna_osx_CLibraryImpl_isatty
> 186:   (JNIEnv *, jobject, jint fd) {
> 187:     return isatty(fd);

Do we care if the native `isatty()` returns zero? Or is this dealt with somewhere else?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13687#discussion_r1189114958
PR Review Comment: https://git.openjdk.org/jdk/pull/13687#discussion_r1189116097
PR Review Comment: https://git.openjdk.org/jdk/pull/13687#discussion_r1189116683
PR Review Comment: https://git.openjdk.org/jdk/pull/13687#discussion_r1189117836
PR Review Comment: https://git.openjdk.org/jdk/pull/13687#discussion_r1189123411
PR Review Comment: https://git.openjdk.org/jdk/pull/13687#discussion_r1189118782
PR Review Comment: https://git.openjdk.org/jdk/pull/13687#discussion_r1189120027
PR Review Comment: https://git.openjdk.org/jdk/pull/13687#discussion_r1189121218
PR Review Comment: https://git.openjdk.org/jdk/pull/13687#discussion_r1189121521

From jlaskey at openjdk.org  Wed May 10 11:38:34 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 10 May 2023 11:38:34 GMT
Subject: Integrated: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview)
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <BRO6F0Nwun-KAL86AIlKg6QjPxW-8E4_-wWH8VpPu0M=.e092c60c-021c-455d-b85e-f1265fd65082@github.com>

On Thu, 27 Oct 2022 20:16:14 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

This pull request has now been integrated.

Changeset: 4aa65cbe
Author:    Jim Laskey <jlaskey at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4aa65cbeefe44f29fbe6ea013809dcee579df9ff
Stats:     9331 lines in 74 files changed: 9233 ins; 23 del; 75 mod

8285932: Implementation of JEP 430 String Templates (Preview)

Reviewed-by: mcimadamore, rriggs, darcy

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

PR: https://git.openjdk.org/jdk/pull/10889

From jlahoda at openjdk.org  Thu May 11 07:26:47 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 11 May 2023 07:26:47 GMT
Subject: RFR: JDK-8306983: Do not invoke external programs when switch
 terminal to raw mode on selected platforms [v2]
In-Reply-To: <SCctPXIHMDzzITzQbbBFDxmuBl2z6vhHE5GrCgRnrlQ=.c2ade825-e8de-4ec6-96bb-f495014a2561@github.com>
References: <cGOTtVG_NmpIQ7Xpy9rMkVds3JC8az9jj530vVZr134=.4675f46c-8423-4957-ab24-00939d669563@github.com>
 <g4Wfl35cnWC3CAhOjVVEi0KykmEpf216n97gidgkyC0=.721e88f1-509e-4ec3-972b-1e61c7a6143f@github.com>
 <SCctPXIHMDzzITzQbbBFDxmuBl2z6vhHE5GrCgRnrlQ=.c2ade825-e8de-4ec6-96bb-f495014a2561@github.com>
Message-ID: <kZAeWRP5SvWYZNQE86skPgUFCfSluW9mYayH7okjnPk=.52cd732d-57d7-4351-af73-47a5c1440c2a@github.com>

On Tue, 9 May 2023 20:49:16 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adjusting build script as suggested on the review.
>
> src/jdk.internal.le/linux/native/lible/CLibrary.cpp line 183:
> 
>> 181: JNIEXPORT jint JNICALL Java_jdk_internal_org_jline_terminal_impl_jna_linux_CLibraryImpl_isatty
>> 182:   (JNIEnv *, jobject, jint fd) {
>> 183:     return isatty(fd);
> 
> Do we care if the native `isatty()` returns zero? Or is this dealt with somewhere else?

This method is only used to determine with the fd is attached to a terminal (returns 1) or not (return 0). The reasons why it is not attached to a terminal are not really important. The value is used here:
https://github.com/lahodaj/jdk/blob/4cf8f67e43f442a5c48cd30349740ac2cb638d6e/src/jdk.internal.le/unix/classes/jdk/internal/org/jline/terminal/impl/jna/JnaNativePty.java#L186

> src/jdk.internal.le/macosx/native/lible/CLibrary.cpp line 187:
> 
>> 185: JNIEXPORT jint JNICALL Java_jdk_internal_org_jline_terminal_impl_jna_osx_CLibraryImpl_isatty
>> 186:   (JNIEnv *, jobject, jint fd) {
>> 187:     return isatty(fd);
> 
> Do we care if the native `isatty()` returns zero? Or is this dealt with somewhere else?

This method is only used to determine with the fd is attached to a terminal (returns 1) or not (return 0). The reasons why it is not attached to a terminal are not really important. The value is used here:
https://github.com/lahodaj/jdk/blob/4cf8f67e43f442a5c48cd30349740ac2cb638d6e/src/jdk.internal.le/unix/classes/jdk/internal/org/jline/terminal/impl/jna/JnaNativePty.java#L186

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13687#discussion_r1190739079
PR Review Comment: https://git.openjdk.org/jdk/pull/13687#discussion_r1190741351

From jlahoda at openjdk.org  Thu May 11 14:17:56 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 11 May 2023 14:17:56 GMT
Subject: RFR: JDK-8306983: Do not invoke external programs when switch
 terminal to raw mode on selected platforms [v3]
In-Reply-To: <cGOTtVG_NmpIQ7Xpy9rMkVds3JC8az9jj530vVZr134=.4675f46c-8423-4957-ab24-00939d669563@github.com>
References: <cGOTtVG_NmpIQ7Xpy9rMkVds3JC8az9jj530vVZr134=.4675f46c-8423-4957-ab24-00939d669563@github.com>
Message-ID: <HrfEZxDlJq2JoBowZmaTPMAfQrj2A223KMqz6jf90WY=.da514cdb-2416-4eb4-8d1e-e14784fcf6d9@github.com>

> To support JShell and other usecases, the JDK uses JLine, which provides line-editing functionality inside a terminal.
> 
> JLine has several ways to work with the terminal, based on various additional libraries and tools. Most of them are not directly usable inside the JDK, so currently, on non-Windows platforms, the JLine inside the JDK will use external programs, like `stty`, to inspect the terminal's properties and to switch the terminal to raw mode.
> 
> This is slightly problematic, as the external programs might be missing, and while this is not that big problem for JShell, it might be a problem for other potential uses of JLine, like using it inside `System.console()`.
> 
> So, the proposal here is to call the corresponding native methods directly, on selected platforms for now (Linux and Mac OS/X), instead of invoking the external programs. On Windows, this has always been the case, we are using a custom implementation of the interface that maps native and Java function for JNA there, and the proposal is to do the same here. We take the appropriate mapping interface for JNA, and provide hand-written implementation for it, using JNI.
> 
> The Windows implementation is mostly unchanged, the changes are mostly non-Windows only. The overview of the changes is:
>  - `LastErrorException` is moved from the Windows-specific code to the platform-neutral code, as it is used by all the native implementations. This is the only change that directly affects the Windows-specific code
>  -  `unix/classes/jdk/internal/org/jline/terminal/impl/jna/JnaNativePty.java` and `unix/classes/jdk/internal/org/jline/terminal/impl/jna/JnaTerminalProvider.java` are created based on the corresponding files from JLine. In JLine, these files directly call platform-specific implementations, but in this patch, the platform specific code is commented out, and replaced with calls to `JDKNativePty`, which is a new platform-specific class, that delegates to the actual platform-specific implementations. Note the `JnaNativePty.java` and `JnaTerminalProvider.java` already exist in the Windows part, but have different pieces of code commented out, which makes them substantially different.
>  - for Linux and Mac OS/X, there are platform-specific implementations based on the corresponding code from JLine, with the hand-written JNI-based implementation of the JNA-based existing interfaces. They also have an implementation of `JDKNativePty`, which just delegates to the given platform's `"NativePty"` imple...

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

  Reflecting review feedback.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13687/files
  - new: https://git.openjdk.org/jdk/pull/13687/files/4cf8f67e..edeba637

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13687&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13687&range=01-02

  Stats: 63 lines in 2 files changed: 24 ins; 24 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/13687.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13687/head:pull/13687

PR: https://git.openjdk.org/jdk/pull/13687

From vromero at openjdk.org  Thu May 11 16:15:39 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 11 May 2023 16:15:39 GMT
Subject: RFR: JDK-8306983: Do not invoke external programs when switch
 terminal to raw mode on selected platforms [v3]
In-Reply-To: <HrfEZxDlJq2JoBowZmaTPMAfQrj2A223KMqz6jf90WY=.da514cdb-2416-4eb4-8d1e-e14784fcf6d9@github.com>
References: <cGOTtVG_NmpIQ7Xpy9rMkVds3JC8az9jj530vVZr134=.4675f46c-8423-4957-ab24-00939d669563@github.com>
 <HrfEZxDlJq2JoBowZmaTPMAfQrj2A223KMqz6jf90WY=.da514cdb-2416-4eb4-8d1e-e14784fcf6d9@github.com>
Message-ID: <qPG7pfNjOfU0ixI9Vm9K_fRK3X4KbcBqETVYiqeK30M=.2ef42d37-9b2d-4426-9ea4-d7aa2c222950@github.com>

On Thu, 11 May 2023 14:17:56 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> To support JShell and other usecases, the JDK uses JLine, which provides line-editing functionality inside a terminal.
>> 
>> JLine has several ways to work with the terminal, based on various additional libraries and tools. Most of them are not directly usable inside the JDK, so currently, on non-Windows platforms, the JLine inside the JDK will use external programs, like `stty`, to inspect the terminal's properties and to switch the terminal to raw mode.
>> 
>> This is slightly problematic, as the external programs might be missing, and while this is not that big problem for JShell, it might be a problem for other potential uses of JLine, like using it inside `System.console()`.
>> 
>> So, the proposal here is to call the corresponding native methods directly, on selected platforms for now (Linux and Mac OS/X), instead of invoking the external programs. On Windows, this has always been the case, we are using a custom implementation of the interface that maps native and Java function for JNA there, and the proposal is to do the same here. We take the appropriate mapping interface for JNA, and provide hand-written implementation for it, using JNI.
>> 
>> The Windows implementation is mostly unchanged, the changes are mostly non-Windows only. The overview of the changes is:
>>  - `LastErrorException` is moved from the Windows-specific code to the platform-neutral code, as it is used by all the native implementations. This is the only change that directly affects the Windows-specific code
>>  -  `unix/classes/jdk/internal/org/jline/terminal/impl/jna/JnaNativePty.java` and `unix/classes/jdk/internal/org/jline/terminal/impl/jna/JnaTerminalProvider.java` are created based on the corresponding files from JLine. In JLine, these files directly call platform-specific implementations, but in this patch, the platform specific code is commented out, and replaced with calls to `JDKNativePty`, which is a new platform-specific class, that delegates to the actual platform-specific implementations. Note the `JnaNativePty.java` and `JnaTerminalProvider.java` already exist in the Windows part, but have different pieces of code commented out, which makes them substantially different.
>>  - for Linux and Mac OS/X, there are platform-specific implementations based on the corresponding code from JLine, with the hand-written JNI-based implementation of the JNA-based existing interfaces. They also have an implementation of `JDKNativePty`, which just delegates to the given platform's `"Nati...
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflecting review feedback.

src/jdk.internal.le/linux/classes/jdk/internal/org/jline/terminal/impl/jna/linux/CLibrary.java line 2:

> 1: /*
> 2:  * Copyright (c) 2002-2020, the original author or authors.

2023 only?

src/jdk.internal.le/linux/classes/jdk/internal/org/jline/terminal/impl/jna/linux/CLibrary.java line 16:

> 14: import java.util.List;
> 15: 
> 16: //import com.sun.jna.LastErrorException;

there is a lot of commented code in this file, not sure if it has a purpose or just left overs?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13687#discussion_r1191336939
PR Review Comment: https://git.openjdk.org/jdk/pull/13687#discussion_r1191336400

From jlahoda at openjdk.org  Thu May 11 16:29:05 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 11 May 2023 16:29:05 GMT
Subject: RFR: JDK-8306983: Do not invoke external programs when switch
 terminal to raw mode on selected platforms [v3]
In-Reply-To: <qPG7pfNjOfU0ixI9Vm9K_fRK3X4KbcBqETVYiqeK30M=.2ef42d37-9b2d-4426-9ea4-d7aa2c222950@github.com>
References: <cGOTtVG_NmpIQ7Xpy9rMkVds3JC8az9jj530vVZr134=.4675f46c-8423-4957-ab24-00939d669563@github.com>
 <HrfEZxDlJq2JoBowZmaTPMAfQrj2A223KMqz6jf90WY=.da514cdb-2416-4eb4-8d1e-e14784fcf6d9@github.com>
 <qPG7pfNjOfU0ixI9Vm9K_fRK3X4KbcBqETVYiqeK30M=.2ef42d37-9b2d-4426-9ea4-d7aa2c222950@github.com>
Message-ID: <0FgB-dcc7qb7_2KzkJd3vSwgx-xHwGAUOVYxqF2EXS4=.92ac158b-1389-41a5-890c-a23a083a0563@github.com>

On Thu, 11 May 2023 15:15:02 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reflecting review feedback.
>
> src/jdk.internal.le/linux/classes/jdk/internal/org/jline/terminal/impl/jna/linux/CLibrary.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2002-2020, the original author or authors.
> 
> 2023 only?

This is the original header from JLine, which we generally keep.

> src/jdk.internal.le/linux/classes/jdk/internal/org/jline/terminal/impl/jna/linux/CLibrary.java line 16:
> 
>> 14: import java.util.List;
>> 15: 
>> 16: //import com.sun.jna.LastErrorException;
> 
> there is a lot of commented code in this file, not sure if it has a purpose or just left overs?

I've intentionally left the original JLine code commented here and on other places, to see what the code was doing originally, and to possibly aid future merges of new versions of JLine.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13687#discussion_r1191427112
PR Review Comment: https://git.openjdk.org/jdk/pull/13687#discussion_r1191428160

From vromero at openjdk.org  Thu May 11 16:39:07 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 11 May 2023 16:39:07 GMT
Subject: RFR: JDK-8306983: Do not invoke external programs when switch
 terminal to raw mode on selected platforms [v3]
In-Reply-To: <HrfEZxDlJq2JoBowZmaTPMAfQrj2A223KMqz6jf90WY=.da514cdb-2416-4eb4-8d1e-e14784fcf6d9@github.com>
References: <cGOTtVG_NmpIQ7Xpy9rMkVds3JC8az9jj530vVZr134=.4675f46c-8423-4957-ab24-00939d669563@github.com>
 <HrfEZxDlJq2JoBowZmaTPMAfQrj2A223KMqz6jf90WY=.da514cdb-2416-4eb4-8d1e-e14784fcf6d9@github.com>
Message-ID: <ey2sw4CLQz8vd7Ocp3ZqfJ-gtdb_g9qLkPJ_b-Mimjg=.48685868-b798-44d1-9f71-f13678977c37@github.com>

On Thu, 11 May 2023 14:17:56 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> To support JShell and other usecases, the JDK uses JLine, which provides line-editing functionality inside a terminal.
>> 
>> JLine has several ways to work with the terminal, based on various additional libraries and tools. Most of them are not directly usable inside the JDK, so currently, on non-Windows platforms, the JLine inside the JDK will use external programs, like `stty`, to inspect the terminal's properties and to switch the terminal to raw mode.
>> 
>> This is slightly problematic, as the external programs might be missing, and while this is not that big problem for JShell, it might be a problem for other potential uses of JLine, like using it inside `System.console()`.
>> 
>> So, the proposal here is to call the corresponding native methods directly, on selected platforms for now (Linux and Mac OS/X), instead of invoking the external programs. On Windows, this has always been the case, we are using a custom implementation of the interface that maps native and Java function for JNA there, and the proposal is to do the same here. We take the appropriate mapping interface for JNA, and provide hand-written implementation for it, using JNI.
>> 
>> The Windows implementation is mostly unchanged, the changes are mostly non-Windows only. The overview of the changes is:
>>  - `LastErrorException` is moved from the Windows-specific code to the platform-neutral code, as it is used by all the native implementations. This is the only change that directly affects the Windows-specific code
>>  -  `unix/classes/jdk/internal/org/jline/terminal/impl/jna/JnaNativePty.java` and `unix/classes/jdk/internal/org/jline/terminal/impl/jna/JnaTerminalProvider.java` are created based on the corresponding files from JLine. In JLine, these files directly call platform-specific implementations, but in this patch, the platform specific code is commented out, and replaced with calls to `JDKNativePty`, which is a new platform-specific class, that delegates to the actual platform-specific implementations. Note the `JnaNativePty.java` and `JnaTerminalProvider.java` already exist in the Windows part, but have different pieces of code commented out, which makes them substantially different.
>>  - for Linux and Mac OS/X, there are platform-specific implementations based on the corresponding code from JLine, with the hand-written JNI-based implementation of the JNA-based existing interfaces. They also have an implementation of `JDKNativePty`, which just delegates to the given platform's `"Nati...
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflecting review feedback.

Marked as reviewed by vromero (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13687#pullrequestreview-1423023134

From jlu at openjdk.org  Thu May 11 20:21:57 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 11 May 2023 20:21:57 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v6]
In-Reply-To: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
Message-ID: <cqbVzCGKX2oiVnvlF5eU47L-vXRpPXyuI7DK6Eu9Nf0=.7375f607-3413-4171-a51b-b841908e0684@github.com>

> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii.
> 
> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file.

Justin Lu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:

 - Convert the merged master changes to UTF-8
 - Merge master and fix conflicts
 - Close streams when finished loading into props
 - Adjust CF test to read in with UTF-8 to fix failing test
 - Reconvert CS.properties to UTF-8
 - Revert all changes to CurrencySymbols.properties
 - Bug6204853 should not be converted
 - Copyright year for CompileProperties
 - Redo translation for CS.properties
 - Spot convert CurrencySymbols.properties
 - ... and 6 more: https://git.openjdk.org/jdk/compare/4386d42d...f15b373a

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

Changes: https://git.openjdk.org/jdk/pull/12726/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12726&range=05
  Stats: 28877 lines in 493 files changed: 14 ins; 1 del; 28862 mod
  Patch: https://git.openjdk.org/jdk/pull/12726.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12726/head:pull/12726

PR: https://git.openjdk.org/jdk/pull/12726

From jlu at openjdk.org  Thu May 11 21:39:50 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 11 May 2023 21:39:50 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v6]
In-Reply-To: <cqbVzCGKX2oiVnvlF5eU47L-vXRpPXyuI7DK6Eu9Nf0=.7375f607-3413-4171-a51b-b841908e0684@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
 <cqbVzCGKX2oiVnvlF5eU47L-vXRpPXyuI7DK6Eu9Nf0=.7375f607-3413-4171-a51b-b841908e0684@github.com>
Message-ID: <w-aBr-h4WVCyWPDEHHatqoQcdQJp6dN4eld2Y-85Ak4=.558819ae-881a-42fb-8b67-7a6b5618e323@github.com>

On Thu, 11 May 2023 20:21:57 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii.
>> 
>> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file.
>
> Justin Lu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:
> 
>  - Convert the merged master changes to UTF-8
>  - Merge master and fix conflicts
>  - Close streams when finished loading into props
>  - Adjust CF test to read in with UTF-8 to fix failing test
>  - Reconvert CS.properties to UTF-8
>  - Revert all changes to CurrencySymbols.properties
>  - Bug6204853 should not be converted
>  - Copyright year for CompileProperties
>  - Redo translation for CS.properties
>  - Spot convert CurrencySymbols.properties
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/4386d42d...f15b373a

Wondering if anyone has any thoughts on the consequences of this PR, in relation to Intellj's (and other IDEs) default encoding for .properties files. Intellj sets the default encoding for .properties files to ISO-8859-1, which would be the wrong encoding if the .properties files are converted to UTF-8 native. This would cause certain key,values to be skewed when represented in the file. 

Although the default file-encoding for .properties can be switched to UTF-8, it is not the default.

Wondering what some solutions/thoughts to this are.

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

PR Comment: https://git.openjdk.org/jdk/pull/12726#issuecomment-1544708830

From naoto at openjdk.org  Thu May 11 21:51:13 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 11 May 2023 21:51:13 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v6]
In-Reply-To: <cqbVzCGKX2oiVnvlF5eU47L-vXRpPXyuI7DK6Eu9Nf0=.7375f607-3413-4171-a51b-b841908e0684@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
 <cqbVzCGKX2oiVnvlF5eU47L-vXRpPXyuI7DK6Eu9Nf0=.7375f607-3413-4171-a51b-b841908e0684@github.com>
Message-ID: <2apKDcin5cwY53zz5jOIPhqm7cCWhyYMdsXGU4TauEk=.781d695e-39fe-46f7-bd03-be514ca0b85c@github.com>

On Thu, 11 May 2023 20:21:57 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii.
>> 
>> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file.
>
> Justin Lu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:
> 
>  - Convert the merged master changes to UTF-8
>  - Merge master and fix conflicts
>  - Close streams when finished loading into props
>  - Adjust CF test to read in with UTF-8 to fix failing test
>  - Reconvert CS.properties to UTF-8
>  - Revert all changes to CurrencySymbols.properties
>  - Bug6204853 should not be converted
>  - Copyright year for CompileProperties
>  - Redo translation for CS.properties
>  - Spot convert CurrencySymbols.properties
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/4386d42d...f15b373a

I think this is fine, as those properties files are JDK's own. I believe the benefit of moving to UTF-8 outweighs the issue you wrote, which can be remedied by changing the encoding in the IDEs.

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

PR Comment: https://git.openjdk.org/jdk/pull/12726#issuecomment-1544722480

From abimpoudis at openjdk.org  Thu May 11 22:13:58 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 11 May 2023 22:13:58 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v24]
In-Reply-To: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
Message-ID: <NEx410enYnZTe9EFA_72R0bNKU3A8khekwdySUwV8W0=.2e053850-81bb-4a7e-9601-e6691e91a203@github.com>

> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java.
> 
> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/

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

 - Merge branch 'JDK-8300543' into unnamed
   
   # Conflicts:
   #	src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java
   #	src/jdk.compiler/share/classes/com/sun/source/tree/TreeVisitor.java
   #	src/jdk.compiler/share/classes/com/sun/tools/javac/code/Preview.java
 - Cleanup
 - Add at since tag
 - Remove Elements.isUnamed(VariableElement) given the presence of VariableElement.isUnamed
 - Doc adjustments
 - Merge branch 'JDK-8300543' into unnamed
 - Reintroduce isUnnamed from VarSymbol with different name
 - Revert "Remove isUnnamed from VarSymbol"
   
   This reverts commit a46b674a5077da603c400f2005cf4a7a48d104b2.
 - Remove isUnnamed from VarSymbol
 - Remove @Override from VarSymbol.isUnnamed
 - ... and 39 more: https://git.openjdk.org/jdk/compare/69ba2a57...94997d16

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

Changes: https://git.openjdk.org/jdk/pull/13528/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13528&range=23
  Stats: 1480 lines in 46 files changed: 1159 ins; 144 del; 177 mod
  Patch: https://git.openjdk.org/jdk/pull/13528.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13528/head:pull/13528

PR: https://git.openjdk.org/jdk/pull/13528

From acobbs at openjdk.org  Tue May 16 21:36:42 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 16 May 2023 21:36:42 GMT
Subject: RFR: 8194743: Compiler implementation for Statements before
 super() [v3]
In-Reply-To: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>
References: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>
Message-ID: <mQhIcPr3oKfRXy2_pLs6M1RgAOID9gpgxjGQA93V3Ek=.c41666d7-fe39-4690-84c9-750476c8661b@github.com>

> This is a first draft of a patch for JEP 447.
> 
> Summary of changes:
> 
> 1. Track when we're within a constructor "prologue" via new flag `AttrContext.ctorPrologue`
> 1. Add checks for illegal early access to `this` in constructor prologues, and update existing checks to distinguish between static context vs. constructor prologue context
> 1. Verify allowed placement of `super()`/`this()` calls via new method `Check.checkSuperInitCalls()`
> 1. Remove/refactor assumptions in several places that `super()`/`this()` was always the first statement
> 
> The changes in `Flow.java` are an example of <span>#</span>4. `Flow.FlowAnalyzer` checks for uncaught checked exceptions. For initializer blocks, this was previously done by requiring that any checked exceptions thrown be declared as thrown by all constructors containing `super()`. This list of checked exceptions was being pre-calculated before recursing into the initial constructors. This worked because initializer blocks were executed at the beginning of each initial constructor right after `super()` is called.
> 
> Now initializer blocks are traversed as each `super()` invocation is encountered, reflecting what actually happens at runtime. Similarly, final fields are marked as DA after encountering `this()`, not automatically at the beginning of those  constructors. These changes produce equivalent checks, but are compatible with the new flexibility of placement of `super()`/`this()` as well as possible future changes that could occur along these same lines.

Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:

  Make "statements before super()" support a preview feature.
  
  Thanks to Jim Laskey for help with preview logic.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13656/files
  - new: https://git.openjdk.org/jdk/pull/13656/files/0e638da2..3c9322b6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13656&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13656&range=01-02

  Stats: 58 lines in 9 files changed: 55 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/13656.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13656/head:pull/13656

PR: https://git.openjdk.org/jdk/pull/13656

From james.laskey at oracle.com  Tue May 16 21:49:02 2023
From: james.laskey at oracle.com (Jim Laskey)
Date: Tue, 16 May 2023 21:49:02 +0000
Subject: RFR: 8194743: Compiler implementation for Statements before
 super() [v3]
In-Reply-To: <mQhIcPr3oKfRXy2_pLs6M1RgAOID9gpgxjGQA93V3Ek=.c41666d7-fe39-4690-84c9-750476c8661b@github.com>
References: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>
 <mQhIcPr3oKfRXy2_pLs6M1RgAOID9gpgxjGQA93V3Ek=.c41666d7-fe39-4690-84c9-750476c8661b@github.com>
Message-ID: <23BF8C74-F574-4330-B20F-02CCA7BD467A@oracle.com>

Don?t forget to update the tests to use the @enablePreview flag. 

?

> On May 16, 2023, at 6:37 PM, Archie Cobbs <acobbs at openjdk.org> wrote:
> 
> ?
>> 
>> This is a first draft of a patch for JEP 447.
>> 
>> Summary of changes:
>> 
>> 1. Track when we're within a constructor "prologue" via new flag `AttrContext.ctorPrologue`
>> 1. Add checks for illegal early access to `this` in constructor prologues, and update existing checks to distinguish between static context vs. constructor prologue context
>> 1. Verify allowed placement of `super()`/`this()` calls via new method `Check.checkSuperInitCalls()`
>> 1. Remove/refactor assumptions in several places that `super()`/`this()` was always the first statement
>> 
>> The changes in `Flow.java` are an example of <span>#</span>4. `Flow.FlowAnalyzer` checks for uncaught checked exceptions. For initializer blocks, this was previously done by requiring that any checked exceptions thrown be declared as thrown by all constructors containing `super()`. This list of checked exceptions was being pre-calculated before recursing into the initial constructors. This worked because initializer blocks were executed at the beginning of each initial constructor right after `super()` is called.
>> 
>> Now initializer blocks are traversed as each `super()` invocation is encountered, reflecting what actually happens at runtime. Similarly, final fields are marked as DA after encountering `this()`, not automatically at the beginning of those  constructors. These changes produce equivalent checks, but are compatible with the new flexibility of placement of `super()`/`this()` as well as possible future changes that could occur along these same lines.
> 
> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>  Make "statements before super()" support a preview feature.
> 
>  Thanks to Jim Laskey for help with preview logic.
> 
> -------------
> 
> Changes:
>  - all: https://git.openjdk.org/jdk/pull/13656/files
>  - new: https://git.openjdk.org/jdk/pull/13656/files/0e638da2..3c9322b6
> 
> Webrevs:
> - full: https://webrevs.openjdk.org/?repo=jdk&pr=13656&range=02
> - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13656&range=01-02
> 
>  Stats: 58 lines in 9 files changed: 55 ins; 0 del; 3 mod
>  Patch: https://git.openjdk.org/jdk/pull/13656.diff
>  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13656/head:pull/13656
> 
> PR: https://git.openjdk.org/jdk/pull/13656

From manderse at redhat.com  Tue May 16 22:52:02 2023
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Wed, 17 May 2023 00:52:02 +0200
Subject: jshell --enable-preview --execution=local bug?
Message-ID: <D3690861-D443-4810-8477-114DE11383B7@redhat.com>

Hi,

As part of adding `--enable-preview` support to [JBang 
0.107](https://github.com/jbangdev/jbang/releases/tag/v0.107.0) I 
spotted this discrepancy in jshell behaviour. Is this to be expected or 
a bug?

First what is expected right behaviour:

```bash
$ jshell --enable-preview
|  Welcome to JShell -- Version 21-ea
|  For an introduction type: /help intro

jshell> var name="test"; STR."\{name} test";
name ==> "test"
$2 ==> "test test"

jshell> $2.length();
$3 ==> 9
```

but now when running with `--execution=local`:

```bash
jshell --enable-preview --execution=local
|  Welcome to JShell -- Version 21-ea
|  For an introduction type: /help intro

jshell> var name="test"; STR."\{name} test";
name ==> "test"
$2 ==>

jshell> $2.length();
|  Exception java.lang.UnsupportedClassVersionError: Preview features 
are not enabled for REPL/$JShell$12 (class file version 65.65535). Try 
running with '--enable-preview'
|        at ClassLoader.defineClass1 (Native Method)
|        at ClassLoader.defineClass (ClassLoader.java:1018)
|        at SecureClassLoader.defineClass (SecureClassLoader.java:150)
|        at DefaultLoaderDelegate$RemoteClassLoader.findClass 
(DefaultLoaderDelegate.java:156)
|        at ClassLoader.loadClass (ClassLoader.java:593)
|        at ClassLoader.loadClass (ClassLoader.java:526)
|        at (#3:1)
```

I found that by duplicating `--enable-preview` in runtime options fixes 
things:

```
$ jshell --enable-preview --execution=local -J--enable-preview
|  Welcome to JShell -- Version 21-ea
|  For an introduction type: /help intro

jshell> var name="test"; STR."\{name} test";
name ==> "test"
$2 ==> "test test"

jshell> $2.length();
$3 ==> 9
```

Seems like a bug to me, wdyt? and where to open/report this best or is 
it enough here?

/max
https://xam.dk/about
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/kulla-dev/attachments/20230517/2481393a/attachment.htm>

From acobbs at openjdk.org  Wed May 17 02:32:02 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 17 May 2023 02:32:02 GMT
Subject: RFR: 8194743: Compiler implementation for Statements before
 super() [v4]
In-Reply-To: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>
References: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>
Message-ID: <7azJLOKDvP96da2ZY2082Adq57bC9RS8C6Opc9mT1hE=.1169b0ec-39ad-40fa-91d4-a33cceb02def@github.com>

> This is a first draft of a patch for JEP 447.
> 
> Summary of changes:
> 
> 1. Track when we're within a constructor "prologue" via new flag `AttrContext.ctorPrologue`
> 1. Add checks for illegal early access to `this` in constructor prologues, and update existing checks to distinguish between static context vs. constructor prologue context
> 1. Verify allowed placement of `super()`/`this()` calls via new method `Check.checkSuperInitCalls()`
> 1. Remove/refactor assumptions in several places that `super()`/`this()` was always the first statement
> 
> The changes in `Flow.java` are an example of <span>#</span>4. `Flow.FlowAnalyzer` checks for uncaught checked exceptions. For initializer blocks, this was previously done by requiring that any checked exceptions thrown be declared as thrown by all constructors containing `super()`. This list of checked exceptions was being pre-calculated before recursing into the initial constructors. This worked because initializer blocks were executed at the beginning of each initial constructor right after `super()` is called.
> 
> Now initializer blocks are traversed as each `super()` invocation is encountered, reflecting what actually happens at runtime. Similarly, final fields are marked as DA after encountering `this()`, not automatically at the beginning of those  constructors. These changes produce equivalent checks, but are compatible with the new flexibility of placement of `super()`/`this()` as well as possible future changes that could occur along these same lines.

Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:

  Use @enablePreview in tests in preference to explicit command line flags.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13656/files
  - new: https://git.openjdk.org/jdk/pull/13656/files/3c9322b6..73bb3270

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13656&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13656&range=02-03

  Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/13656.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13656/head:pull/13656

PR: https://git.openjdk.org/jdk/pull/13656

From abimpoudis at openjdk.org  Wed May 17 11:30:05 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 17 May 2023 11:30:05 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v25]
In-Reply-To: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
Message-ID: <BuJO2SrKJN14TNLZNjc1KMIji4uQosxlJExh3e5cKCo=.f2161afb-1bf3-4d42-92d6-585cd1abd735@github.com>

> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java.
> 
> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/

Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:

  Fix compiler bugs
  
  - Fix skipped errors when using unnamed locals without initializer
  - Fix lambdas with mix unnamed and named parameters

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13528/files
  - new: https://git.openjdk.org/jdk/pull/13528/files/94997d16..175d6459

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13528&range=24
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13528&range=23-24

  Stats: 50 lines in 5 files changed: 41 ins; 1 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/13528.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13528/head:pull/13528

PR: https://git.openjdk.org/jdk/pull/13528

From abimpoudis at openjdk.org  Wed May 17 14:23:37 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 17 May 2023 14:23:37 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v26]
In-Reply-To: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
Message-ID: <faZVxWbcOqz6D3bIi2gRevSfIgEbHZP0OgOFGmP-oWs=.e61c7612-9a66-4a39-aee0-a0363c1d9879@github.com>

> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java.
> 
> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/

Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:

  Simplify `LambdaClassifier`
  
  Co-authored-by: Maurizio Cimadamore <maurizio.cimadamore at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13528/files
  - new: https://git.openjdk.org/jdk/pull/13528/files/175d6459..804d41af

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13528&range=25
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13528&range=24-25

  Stats: 27 lines in 1 file changed: 16 ins; 8 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/13528.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13528/head:pull/13528

PR: https://git.openjdk.org/jdk/pull/13528

From jan.lahoda at oracle.com  Wed May 17 17:41:30 2023
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Wed, 17 May 2023 19:41:30 +0200
Subject: jshell --enable-preview --execution=local bug?
In-Reply-To: <D3690861-D443-4810-8477-114DE11383B7@redhat.com>
References: <D3690861-D443-4810-8477-114DE11383B7@redhat.com>
Message-ID: <f37e5d31-cff7-5aba-558d-946ec0275686@oracle.com>

Hi Max,


I've filled:

https://bugs.openjdk.org/browse/JDK-8308305


Thanks for the report.


Jan


On 17. 05. 23 0:52, Max Rydahl Andersen wrote:
>
> Hi,
>
> As part of adding |--enable-preview| support to JBang 0.107 
> <https://github.com/jbangdev/jbang/releases/tag/v0.107.0> I spotted 
> this discrepancy in jshell behaviour. Is this to be expected or a bug?
>
> First what is expected right behaviour:
>
> |$ jshell --enable-preview | Welcome to JShell -- Version 21-ea | For 
> an introduction type: /help intro jshell> var name="test"; 
> STR."\{name} test"; name ==> "test" $2 ==> "test test" jshell> 
> $2.length(); $3 ==> 9 |
>
> but now when running with |--execution=local|:
>
> |jshell --enable-preview --execution=local | Welcome to JShell -- 
> Version 21-ea | For an introduction type: /help intro jshell> var 
> name="test"; STR."\{name} test"; name ==> "test" $2 ==> jshell> 
> $2.length(); | Exception java.lang.UnsupportedClassVersionError: 
> Preview features are not enabled for REPL/$JShell$12 (class file 
> version 65.65535). Try running with '--enable-preview' | at 
> ClassLoader.defineClass1 (Native Method) | at ClassLoader.defineClass 
> (ClassLoader.java:1018) | at SecureClassLoader.defineClass 
> (SecureClassLoader.java:150) | at 
> DefaultLoaderDelegate$RemoteClassLoader.findClass 
> (DefaultLoaderDelegate.java:156) | at ClassLoader.loadClass 
> (ClassLoader.java:593) | at ClassLoader.loadClass 
> (ClassLoader.java:526) | at (#3:1) |
>
> I found that by duplicating |--enable-preview| in runtime options 
> fixes things:
>
> |$ jshell --enable-preview --execution=local -J--enable-preview | 
> Welcome to JShell -- Version 21-ea | For an introduction type: /help 
> intro jshell> var name="test"; STR."\{name} test"; name ==> "test" $2 
> ==> "test test" jshell> $2.length(); $3 ==> 9 |
>
> Seems like a bug to me, wdyt? and where to open/report this best or is 
> it enough here?
>
> /max
> https://xam.dk/about
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/kulla-dev/attachments/20230517/fc4f1d9d/attachment-0001.htm>

From michel.trudeau at oracle.com  Wed May 17 18:24:33 2023
From: michel.trudeau at oracle.com (Michel Trudeau)
Date: Wed, 17 May 2023 18:24:33 +0000
Subject: jshell --enable-preview --execution=local bug?
In-Reply-To: <D3690861-D443-4810-8477-114DE11383B7@redhat.com>
References: <D3690861-D443-4810-8477-114DE11383B7@redhat.com>
Message-ID: <MW4PR10MB58370C014155C2C7F44ADCEDED7E9@MW4PR10MB5837.namprd10.prod.outlook.com>

Max,

FYI ? https://bugs.openjdk.org/browse/JDK-8308305

-Michel

From: kulla-dev <kulla-dev-retn at openjdk.org> on behalf of Max Rydahl Andersen <manderse at redhat.com>
Date: Tuesday, May 16, 2023 at 3:53 PM
To: kulla-dev at openjdk.org <kulla-dev at openjdk.org>
Subject: jshell --enable-preview --execution=local bug?

Hi,

As part of adding --enable-preview support to JBang 0.107<https://github.com/jbangdev/jbang/releases/tag/v0.107.0> I spotted this discrepancy in jshell behaviour. Is this to be expected or a bug?

First what is expected right behaviour:

$ jshell --enable-preview

|  Welcome to JShell -- Version 21-ea

|  For an introduction type: /help intro



jshell> var name="test"; STR."\{name} test";

name ==> "test"

$2 ==> "test test"



jshell> $2.length();

$3 ==> 9

but now when running with --execution=local:

jshell --enable-preview --execution=local

|  Welcome to JShell -- Version 21-ea

|  For an introduction type: /help intro



jshell> var name="test"; STR."\{name} test";

name ==> "test"

$2 ==>



jshell> $2.length();

|  Exception java.lang.UnsupportedClassVersionError: Preview features are not enabled for REPL/$JShell$12 (class file version 65.65535). Try running with '--enable-preview'

|        at ClassLoader.defineClass1 (Native Method)

|        at ClassLoader.defineClass (ClassLoader.java:1018)

|        at SecureClassLoader.defineClass (SecureClassLoader.java:150)

|        at DefaultLoaderDelegate$RemoteClassLoader.findClass (DefaultLoaderDelegate.java:156)

|        at ClassLoader.loadClass (ClassLoader.java:593)

|        at ClassLoader.loadClass (ClassLoader.java:526)

|        at (#3:1)

I found that by duplicating --enable-preview in runtime options fixes things:

$ jshell --enable-preview --execution=local -J--enable-preview

|  Welcome to JShell -- Version 21-ea

|  For an introduction type: /help intro



jshell> var name="test"; STR."\{name} test";

name ==> "test"

$2 ==> "test test"



jshell> $2.length();

$3 ==> 9

Seems like a bug to me, wdyt? and where to open/report this best or is it enough here?

/max
https://xam.dk/about
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/kulla-dev/attachments/20230517/53040314/attachment-0001.htm>

From mcimadamore at openjdk.org  Wed May 17 23:34:03 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 17 May 2023 23:34:03 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v26]
In-Reply-To: <faZVxWbcOqz6D3bIi2gRevSfIgEbHZP0OgOFGmP-oWs=.e61c7612-9a66-4a39-aee0-a0363c1d9879@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
 <faZVxWbcOqz6D3bIi2gRevSfIgEbHZP0OgOFGmP-oWs=.e61c7612-9a66-4a39-aee0-a0363c1d9879@github.com>
Message-ID: <lNGhPpdMDZ3wMShy4JV3zUV3a3Es6-sRjDD_Y4Yig3s=.4453c0d0-1915-471a-8616-50cbc6e61a85@github.com>

On Wed, 17 May 2023 14:23:37 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java.
>> 
>> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify `LambdaClassifier`
>   
>   Co-authored-by: Maurizio Cimadamore <maurizio.cimadamore at oracle.com>

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 2070:

> 2068: 
> 2069:         /**
> 2070:          * analyzeParens() has already classified the lambda as EXPLICIT_LAMBDA, due to

Many thanks for adding these precious comments!

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 2083:

> 2081:             if (param.name == names.error) {
> 2082:                 reduce(LambdaParameterKind.IMPLICIT);
> 2083:                 return;

could we use if/else if/else and get rid of return?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1197162301
PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1197162518

From mcimadamore at openjdk.org  Wed May 17 23:42:04 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 17 May 2023 23:42:04 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v26]
In-Reply-To: <faZVxWbcOqz6D3bIi2gRevSfIgEbHZP0OgOFGmP-oWs=.e61c7612-9a66-4a39-aee0-a0363c1d9879@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
 <faZVxWbcOqz6D3bIi2gRevSfIgEbHZP0OgOFGmP-oWs=.e61c7612-9a66-4a39-aee0-a0363c1d9879@github.com>
Message-ID: <3k5XTy1xj90EuCWIY-2F8I2yU_dT1a1T7M4n__m9nt8=.f25a7007-8d3f-4f8b-8d3c-7a8404c9da2c@github.com>

On Wed, 17 May 2023 14:23:37 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java.
>> 
>> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify `LambdaClassifier`
>   
>   Co-authored-by: Maurizio Cimadamore <maurizio.cimadamore at oracle.com>

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 2071:

> 2069:         /**
> 2070:          * analyzeParens() has already classified the lambda as EXPLICIT_LAMBDA, due to
> 2071:          * two consecutive identifiers. adding an erroneous parameter (one that

Shouldn't the second sentence say something more like:

Because of that (<explicit lambda>), the parser will always attempt to parse a type, followed by a name.
If the lambda contains an illegal mix of implicit and explicit parameters, it is possible for the parser to see a `,` when expecting a name, in which case the variable is created with an erroneous name.
The logic below makes sure that the lambda parameters are all declared with either an explicit type (e.g. `String x`), or with an inferred type (using `var x`).
Any other combination is rejected.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1197166447

From abimpoudis at openjdk.org  Thu May 18 16:56:29 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 18 May 2023 16:56:29 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v27]
In-Reply-To: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
Message-ID: <eClQHeZBw5oLORObD6QDhNciuiBbf6AU_h0XkwRm0XY=.6743f023-82e8-4e4c-ae0f-2338618dc90f@github.com>

> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java.
> 
> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/

Aggelos Biboudis has updated the pull request incrementally with two additional commits since the last revision:

 - Improve error reporting
 - Address review around `LambdaClassifier`

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13528/files
  - new: https://git.openjdk.org/jdk/pull/13528/files/804d41af..04e8029f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13528&range=26
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13528&range=25-26

  Stats: 240 lines in 12 files changed: 99 ins; 2 del; 139 mod
  Patch: https://git.openjdk.org/jdk/pull/13528.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13528/head:pull/13528

PR: https://git.openjdk.org/jdk/pull/13528

From abimpoudis at openjdk.org  Thu May 18 16:57:06 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 18 May 2023 16:57:06 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v16]
In-Reply-To: <88NQ70nvZPnIC71TrH1ftnD68fD0df972hGWdKBqgAo=.46bee3cd-75ad-4ddb-a269-cbc0925e7843@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
 <kPZKlHHE3yS_xw9IBAokmmJ-KAeKLFIAqbCBKfkZwrc=.07126b4e-5be6-4873-920c-7f3d25ebca4a@github.com>
 <W9zmET-GjGsbd7WYLLR2iSxQOvP116b0yFSm4y6ERVg=.a56a8673-3418-42a6-bd98-f6e6a400a679@github.com>
 <88NQ70nvZPnIC71TrH1ftnD68fD0df972hGWdKBqgAo=.46bee3cd-75ad-4ddb-a269-cbc0925e7843@github.com>
Message-ID: <wcgRdpsEYWuSWvjJ9BRsX8VJAwfjIh_79bMEmMG_BWE=.a7908a03-78b7-41b4-8c1a-4296d8166e8a@github.com>

On Mon, 8 May 2023 12:12:11 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> BTW we can remove the `isUnnamed` from `VarSymbol` as @jddarcy pointed me out correctly. 
>> 
>> By keeping it we avoid sprinkling 5 core places with `@SuppressWarnings("preview")`. However, I think it will be cleaner without that override, despite the annotation and I would be in favor of that. Are there any concerns? e.g.,
>> 
>> 
>> diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java
>> index 631b0ce61ac..dc84c89f88e 100644
>> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java
>> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java
>> @@ -1784,11 +1784,6 @@ public abstract class Symbol extends AnnoConstruct implements PoolConstant, Elem
>>          public <R, P> R accept(Symbol.Visitor<R, P> v, P p) {
>>              return v.visitVarSymbol(this, p);
>>          }
>> -
>> -        @DefinedBy(Api.LANGUAGE_MODEL)
>> -        public boolean isUnnamed() {
>> -            return name.isEmpty();
>> -        }
>>      }
>>  
>>      public static class RecordComponent extends VarSymbol implements RecordComponentElement {
>> diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
>> index 986f2e9fe89..26ef1c41156 100644
>> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
>> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
>> @@ -93,6 +93,7 @@ import com.sun.tools.javac.util.JCDiagnostic.DiagnosticFlag;
>>   *  This code and its internal interfaces are subject to change or
>>   *  deletion without notice.</b>
>>   */
>> + at SuppressWarnings("preview")
>>  public class Attr extends JCTree.Visitor {
>>      protected static final Context.Key<Attr> attrKey = new Context.Key<>();
>>  
>> diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java
>> index 725a8a5e37d..537635a9490 100644
>> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java
>> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java
>> @@ -93,6 +93,7 @@ import javax.lang.model.util.ElementKindVisitor14;
>>   *  This code and its internal interfaces are subject to change or
>>   *  deletion without notice.</b>
>>   */
>> + at SuppressWarnings("preview")
>>  public class Check {
>>      protected static final Context.Key<Check> checkKey = new Conte...
>
>> BTW we can remove the `isUnnamed` from `VarSymbol` as @jddarcy pointed me out correctly.
>> 
>> By keeping it we avoid sprinkling 5 core places with `@SuppressWarnings("preview")`. However, I think it will be cleaner without that override, despite the annotation and I would be in favor of that. Are there any concerns? e.g.,
>> 
>> ```
>> diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java
>> index 631b0ce61ac..dc84c89f88e 100644
>> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java
>> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java
>> @@ -1784,11 +1784,6 @@ public abstract class Symbol extends AnnoConstruct implements PoolConstant, Elem
>>          public <R, P> R accept(Symbol.Visitor<R, P> v, P p) {
>>              return v.visitVarSymbol(this, p);
>>          }
>> -
>> -        @DefinedBy(Api.LANGUAGE_MODEL)
>> -        public boolean isUnnamed() {
>> -            return name.isEmpty();
>> -        }
>>      }
>>  
>>      public static class RecordComponent extends VarSymbol implements RecordComponentElement {
>> diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
>> index 986f2e9fe89..26ef1c41156 100644
>> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
>> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
>> @@ -93,6 +93,7 @@ import com.sun.tools.javac.util.JCDiagnostic.DiagnosticFlag;
>>   *  This code and its internal interfaces are subject to change or
>>   *  deletion without notice.</b>
>>   */
>> + at SuppressWarnings("preview")
>>  public class Attr extends JCTree.Visitor {
>>      protected static final Context.Key<Attr> attrKey = new Context.Key<>();
>>  
>> diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java
>> index 725a8a5e37d..537635a9490 100644
>> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java
>> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java
>> @@ -93,6 +93,7 @@ import javax.lang.model.util.ElementKindVisitor14;
>>   *  This code and its internal interfaces are subject to change or
>>   *  deletion without notice.</b>
>>   */
>> + at SuppressWarnings("preview")
>>  public class Check {
>>      protected static ...

Thank you for the review @mcimadamore. 

I have also improved error reporting a bit; in the case `_` is present.

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

PR Comment: https://git.openjdk.org/jdk/pull/13528#issuecomment-1553341008

From abimpoudis at openjdk.org  Thu May 18 21:03:22 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 18 May 2023 21:03:22 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v28]
In-Reply-To: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
Message-ID: <zxWxMqhRQcaI2O3bzLFhNv-4-iV34QTEXhBbFTzd3YA=.64289f44-913c-44df-b0c9-d94a8407e4f1@github.com>

> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java.
> 
> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/

Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:

  Reduce the error message

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13528/files
  - new: https://git.openjdk.org/jdk/pull/13528/files/04e8029f..4d693c14

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13528&range=27
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13528&range=26-27

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/13528.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13528/head:pull/13528

PR: https://git.openjdk.org/jdk/pull/13528

From abimpoudis at openjdk.org  Fri May 19 08:46:35 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Fri, 19 May 2023 08:46:35 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v29]
In-Reply-To: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
Message-ID: <AkRAClXLsnHK9De11yfydeyDPaUZtvtqArwJI39V-1M=.705ce75e-2e22-4b8b-8bc1-cdaa1c07b3c3@github.com>

> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java.
> 
> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/

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

 - Merge branch 'JDK-8300543' into unnamed
   
   # Conflicts:
   #	src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java
 - Reduce the error message
 - Improve error reporting
 - Address review around `LambdaClassifier`
 - Simplify `LambdaClassifier`
   
   Co-authored-by: Maurizio Cimadamore <maurizio.cimadamore at oracle.com>
 - Fix compiler bugs
   
   - Fix skipped errors when using unnamed locals without initializer
   - Fix lambdas with mix unnamed and named parameters
 - Merge branch 'JDK-8300543' into unnamed
   
   # Conflicts:
   #	src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java
   #	src/jdk.compiler/share/classes/com/sun/source/tree/TreeVisitor.java
   #	src/jdk.compiler/share/classes/com/sun/tools/javac/code/Preview.java
 - Cleanup
 - Add at since tag
 - Remove Elements.isUnamed(VariableElement) given the presence of VariableElement.isUnamed
 - ... and 45 more: https://git.openjdk.org/jdk/compare/924ca58d...9502c1e9

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

Changes: https://git.openjdk.org/jdk/pull/13528/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13528&range=28
  Stats: 1765 lines in 53 files changed: 1313 ins; 153 del; 299 mod
  Patch: https://git.openjdk.org/jdk/pull/13528.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13528/head:pull/13528

PR: https://git.openjdk.org/jdk/pull/13528

From abimpoudis at openjdk.org  Fri May 19 13:22:12 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Fri, 19 May 2023 13:22:12 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v30]
In-Reply-To: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
Message-ID: <e1E_3mWUKfkRj2jbBYduRp5bBBKsFuIJXLVtNkRkz7Q=.69781574-751b-4ceb-9529-da0ac9cebec6@github.com>

> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java.
> 
> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/

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

 - Merge branch 'JDK-8300543' into unnamed
 - Merge branch 'JDK-8300543' into unnamed
   
   # Conflicts:
   #	src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java
 - Reduce the error message
 - Improve error reporting
 - Address review around `LambdaClassifier`
 - Simplify `LambdaClassifier`
   
   Co-authored-by: Maurizio Cimadamore <maurizio.cimadamore at oracle.com>
 - Fix compiler bugs
   
   - Fix skipped errors when using unnamed locals without initializer
   - Fix lambdas with mix unnamed and named parameters
 - Merge branch 'JDK-8300543' into unnamed
   
   # Conflicts:
   #	src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java
   #	src/jdk.compiler/share/classes/com/sun/source/tree/TreeVisitor.java
   #	src/jdk.compiler/share/classes/com/sun/tools/javac/code/Preview.java
 - Cleanup
 - Add at since tag
 - ... and 46 more: https://git.openjdk.org/jdk/compare/b641efca...87ac7412

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

Changes: https://git.openjdk.org/jdk/pull/13528/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13528&range=29
  Stats: 1765 lines in 53 files changed: 1313 ins; 153 del; 299 mod
  Patch: https://git.openjdk.org/jdk/pull/13528.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13528/head:pull/13528

PR: https://git.openjdk.org/jdk/pull/13528

From bpb at openjdk.org  Fri May 19 23:50:53 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 19 May 2023 23:50:53 GMT
Subject: RFR: JDK-8306983: Do not invoke external programs when switch
 terminal to raw mode on selected platforms [v3]
In-Reply-To: <HrfEZxDlJq2JoBowZmaTPMAfQrj2A223KMqz6jf90WY=.da514cdb-2416-4eb4-8d1e-e14784fcf6d9@github.com>
References: <cGOTtVG_NmpIQ7Xpy9rMkVds3JC8az9jj530vVZr134=.4675f46c-8423-4957-ab24-00939d669563@github.com>
 <HrfEZxDlJq2JoBowZmaTPMAfQrj2A223KMqz6jf90WY=.da514cdb-2416-4eb4-8d1e-e14784fcf6d9@github.com>
Message-ID: <SKHV6gojmqKlfjjUAwMzoBiFh1HJ4eTxqV0iHikbavQ=.e82d718e-8544-459a-a790-e4f9451a2a07@github.com>

On Thu, 11 May 2023 14:17:56 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> To support JShell and other usecases, the JDK uses JLine, which provides line-editing functionality inside a terminal.
>> 
>> JLine has several ways to work with the terminal, based on various additional libraries and tools. Most of them are not directly usable inside the JDK, so currently, on non-Windows platforms, the JLine inside the JDK will use external programs, like `stty`, to inspect the terminal's properties and to switch the terminal to raw mode.
>> 
>> This is slightly problematic, as the external programs might be missing, and while this is not that big problem for JShell, it might be a problem for other potential uses of JLine, like using it inside `System.console()`.
>> 
>> So, the proposal here is to call the corresponding native methods directly, on selected platforms for now (Linux and Mac OS/X), instead of invoking the external programs. On Windows, this has always been the case, we are using a custom implementation of the interface that maps native and Java function for JNA there, and the proposal is to do the same here. We take the appropriate mapping interface for JNA, and provide hand-written implementation for it, using JNI.
>> 
>> The Windows implementation is mostly unchanged, the changes are mostly non-Windows only. The overview of the changes is:
>>  - `LastErrorException` is moved from the Windows-specific code to the platform-neutral code, as it is used by all the native implementations. This is the only change that directly affects the Windows-specific code
>>  -  `unix/classes/jdk/internal/org/jline/terminal/impl/jna/JnaNativePty.java` and `unix/classes/jdk/internal/org/jline/terminal/impl/jna/JnaTerminalProvider.java` are created based on the corresponding files from JLine. In JLine, these files directly call platform-specific implementations, but in this patch, the platform specific code is commented out, and replaced with calls to `JDKNativePty`, which is a new platform-specific class, that delegates to the actual platform-specific implementations. Note the `JnaNativePty.java` and `JnaTerminalProvider.java` already exist in the Windows part, but have different pieces of code commented out, which makes them substantially different.
>>  - for Linux and Mac OS/X, there are platform-specific implementations based on the corresponding code from JLine, with the hand-written JNI-based implementation of the JNA-based existing interfaces. They also have an implementation of `JDKNativePty`, which just delegates to the given platform's `"Nati...
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflecting review feedback.

C++ looks fine.

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

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13687#pullrequestreview-1435272595

From liach at openjdk.org  Mon May 22 04:19:01 2023
From: liach at openjdk.org (Chen Liang)
Date: Mon, 22 May 2023 04:19:01 GMT
Subject: RFR: 8194743: Compiler implementation for Statements before
 super() [v4]
In-Reply-To: <7azJLOKDvP96da2ZY2082Adq57bC9RS8C6Opc9mT1hE=.1169b0ec-39ad-40fa-91d4-a33cceb02def@github.com>
References: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>
 <7azJLOKDvP96da2ZY2082Adq57bC9RS8C6Opc9mT1hE=.1169b0ec-39ad-40fa-91d4-a33cceb02def@github.com>
Message-ID: <3NqC36tQj0MnK6c99_0IgtccSZGQcVI_lb0S2UaNKpo=.6b0237b1-edd1-43c8-bd09-a7e90062a80e@github.com>

On Wed, 17 May 2023 02:32:02 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> This is a first draft of a patch for JEP 447.
>> 
>> Summary of changes:
>> 
>> 1. Track when we're within a constructor "prologue" via new flag `AttrContext.ctorPrologue`
>> 1. Add checks for illegal early access to `this` in constructor prologues, and update existing checks to distinguish between static context vs. constructor prologue context
>> 1. Verify allowed placement of `super()`/`this()` calls via new method `Check.checkSuperInitCalls()`
>> 1. Remove/refactor assumptions in several places that `super()`/`this()` was always the first statement
>> 
>> The changes in `Flow.java` are an example of <span>#</span>4. `Flow.FlowAnalyzer` checks for uncaught checked exceptions. For initializer blocks, this was previously done by requiring that any checked exceptions thrown be declared as thrown by all constructors containing `super()`. This list of checked exceptions was being pre-calculated before recursing into the initial constructors. This worked because initializer blocks were executed at the beginning of each initial constructor right after `super()` is called.
>> 
>> Now initializer blocks are traversed as each `super()` invocation is encountered, reflecting what actually happens at runtime. Similarly, final fields are marked as DA after encountering `this()`, not automatically at the beginning of those  constructors. These changes produce equivalent checks, but are compatible with the new flexibility of placement of `super()`/`this()` as well as possible future changes that could occur along these same lines.
>
> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use @enablePreview in tests in preference to explicit command line flags.

Quick question, since I don't know much about javac, I wonder what happens if you declare a local class or an anonymous class in the ctor prologue? Will that local/anonymous class have a mandated outer instance parameter in its constructor, and thus having access to a newly allocated but non-initialized object via `ClassName.this`?

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

PR Comment: https://git.openjdk.org/jdk/pull/13656#issuecomment-1556500408

From abimpoudis at openjdk.org  Mon May 22 07:12:44 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 22 May 2023 07:12:44 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v31]
In-Reply-To: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
Message-ID: <6NR-JJxTB2700ifm7aW-OtW1qgURlT7ge399YU4Zw_0=.59561eef-0dba-4573-a6ba-2bf37e4d8bb0@github.com>

> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java.
> 
> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/

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

 - Merging master into unnamed
 - Merge branch 'JDK-8300543' into unnamed
 - Removing obsolette test, as suggested.
 - Merge branch 'JDK-8300543' into unnamed
   
   # Conflicts:
   #	src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java
 - Disallowing annotations on record patterns.
 - Reduce the error message
 - Improve error reporting
 - Address review around `LambdaClassifier`
 - Simplify `LambdaClassifier`
   
   Co-authored-by: Maurizio Cimadamore <maurizio.cimadamore at oracle.com>
 - Fix compiler bugs
   
   - Fix skipped errors when using unnamed locals without initializer
   - Fix lambdas with mix unnamed and named parameters
 - ... and 92 more: https://git.openjdk.org/jdk/compare/eaa80ad0...56686142

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

Changes: https://git.openjdk.org/jdk/pull/13528/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13528&range=30
  Stats: 1765 lines in 53 files changed: 1313 ins; 153 del; 299 mod
  Patch: https://git.openjdk.org/jdk/pull/13528.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13528/head:pull/13528

PR: https://git.openjdk.org/jdk/pull/13528

From abimpoudis at openjdk.org  Mon May 22 08:56:29 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 22 May 2023 08:56:29 GMT
Subject: Integrated: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview)
In-Reply-To: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
Message-ID: <eRApHPho3p__GB72ETFQCz9fbPpQYVZIgnW8yG4HJoc=.2d8cbbd1-4eac-44f1-ba47-a8735a213d5c@github.com>

On Wed, 19 Apr 2023 09:47:39 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java.
> 
> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/

This pull request has now been integrated.

Changeset: 8aa50288
Author:    Aggelos Biboudis <abimpoudis at openjdk.org>
Committer: Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8aa50288a1a6a853bf4d8d97b1849d5744ed7a32
Stats:     1765 lines in 53 files changed: 1313 ins; 153 del; 299 mod

8302344: Compiler Implementation for Unnamed patterns and variables (Preview)
8307444: java.lang.AssertionError when using unnamed patterns
8307482: Compiler should accept var _ in nested patterns in switch case
8307007: Implementation for javax.lang.model for unnamed variables (Preview)
8308312: Compiler should fail when a local variable declaration does not include an Identifier and does not have an initializer
8308309: Compiler should accept mixed masked and unmasked variables in lambda parameters

Co-authored-by: Jan Lahoda <jlahoda at openjdk.org>
Co-authored-by: Aggelos Biboudis <abimpoudis at openjdk.org>
Reviewed-by: vromero, darcy

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

PR: https://git.openjdk.org/jdk/pull/13528

From jlahoda at openjdk.org  Mon May 22 10:42:59 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 22 May 2023 10:42:59 GMT
Subject: Integrated: JDK-8306983: Do not invoke external programs when switch
 terminal to raw mode on selected platforms
In-Reply-To: <cGOTtVG_NmpIQ7Xpy9rMkVds3JC8az9jj530vVZr134=.4675f46c-8423-4957-ab24-00939d669563@github.com>
References: <cGOTtVG_NmpIQ7Xpy9rMkVds3JC8az9jj530vVZr134=.4675f46c-8423-4957-ab24-00939d669563@github.com>
Message-ID: <4Le44LFGRnDuEc3h-oLJ8VXi2ET31F080YKx96zYeD4=.8e0c4545-616a-4074-8688-335c62313456@github.com>

On Thu, 27 Apr 2023 11:21:04 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> To support JShell and other usecases, the JDK uses JLine, which provides line-editing functionality inside a terminal.
> 
> JLine has several ways to work with the terminal, based on various additional libraries and tools. Most of them are not directly usable inside the JDK, so currently, on non-Windows platforms, the JLine inside the JDK will use external programs, like `stty`, to inspect the terminal's properties and to switch the terminal to raw mode.
> 
> This is slightly problematic, as the external programs might be missing, and while this is not that big problem for JShell, it might be a problem for other potential uses of JLine, like using it inside `System.console()`.
> 
> So, the proposal here is to call the corresponding native methods directly, on selected platforms for now (Linux and Mac OS/X), instead of invoking the external programs. On Windows, this has always been the case, we are using a custom implementation of the interface that maps native and Java function for JNA there, and the proposal is to do the same here. We take the appropriate mapping interface for JNA, and provide hand-written implementation for it, using JNI.
> 
> The Windows implementation is mostly unchanged, the changes are mostly non-Windows only. The overview of the changes is:
>  - `LastErrorException` is moved from the Windows-specific code to the platform-neutral code, as it is used by all the native implementations. This is the only change that directly affects the Windows-specific code
>  -  `unix/classes/jdk/internal/org/jline/terminal/impl/jna/JnaNativePty.java` and `unix/classes/jdk/internal/org/jline/terminal/impl/jna/JnaTerminalProvider.java` are created based on the corresponding files from JLine. In JLine, these files directly call platform-specific implementations, but in this patch, the platform specific code is commented out, and replaced with calls to `JDKNativePty`, which is a new platform-specific class, that delegates to the actual platform-specific implementations. Note the `JnaNativePty.java` and `JnaTerminalProvider.java` already exist in the Windows part, but have different pieces of code commented out, which makes them substantially different.
>  - for Linux and Mac OS/X, there are platform-specific implementations based on the corresponding code from JLine, with the hand-written JNI-based implementation of the JNA-based existing interfaces. They also have an implementation of `JDKNativePty`, which just delegates to the given platform's `"NativePty"` imple...

This pull request has now been integrated.

Changeset: a9705196
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a9705196cea7d6f468b76b1cfff561352ee0b6b2
Stats:     2145 lines in 23 files changed: 2097 ins; 40 del; 8 mod

8306983: Do not invoke external programs when switch terminal to raw mode on selected platforms

Co-authored-by: Adam Sotona <asotona at openjdk.org>
Reviewed-by: erikj, vromero, bpb

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

PR: https://git.openjdk.org/jdk/pull/13687

From duke at openjdk.org  Mon May 22 12:52:49 2023
From: duke at openjdk.org (Jan Kratochvil)
Date: Mon, 22 May 2023 12:52:49 GMT
Subject: RFR: 8308544: Fix compilation regression from JDK-8306983 on musl libc
Message-ID: <A5c-ALjAzzPPuiLfOuxUNm0Fi8xwUJC8YndS2g4CJP8=.794d207d-4677-42e1-adde-7547a3a958f4@github.com>

Since [JDK-8306983](https://bugs.openjdk.org/browse/JDK-8306983) compilation on Alpine Linux using musl libc:

../src/jdk.internal.le/linux/native/lible/CLibrary.cpp: In function 'void Java_jdk_internal_org_jline_terminal_impl_jna_linux_CLibraryImpl_tcgetattr(JNIEnv*, jobject, jint, jobject)':
../src/jdk.internal.le/linux/native/lible/CLibrary.cpp:116:45: error: 'struct termios' has no member named 'c_ispeed'; did you mean '__c_ispeed'?
  116 | env->SetIntField(result, c_ispeed, data.c_ispeed);
      | ^~~~~~~~
      | __c_ispeed
../src/jdk.internal.le/linux/native/lible/CLibrary.cpp:117:45: error: 'struct termios' has no member named 'c_ospeed'; did you mean '__c_ospeed'?
  117 | env->SetIntField(result, c_ospeed, data.c_ospeed);
      | ^~~~~~~~
      | __c_ospeed
../src/jdk.internal.le/linux/native/lible/CLibrary.cpp: In function 'void Java_jdk_internal_org_jline_terminal_impl_jna_linux_CLibraryImpl_tcsetattr(JNIEnv*, jobject, jint, jint, jobject)':
../src/jdk.internal.le/linux/native/lible/CLibrary.cpp:136:10: error: 'struct termios' has no member named 'c_ispeed'; did you mean '__c_ispeed'?
  136 | data.c_ispeed = env->GetIntField(input, c_ispeed);
      | ^~~~~~~~
      | __c_ispeed
../src/jdk.internal.le/linux/native/lible/CLibrary.cpp:137:10: error: 'struct termios' has no member named 'c_ospeed'; did you mean '__c_ospeed'?
   ... (rest of output omitted)

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

Commit messages:
 - 8308544: Fix compilation regression from JDK-8306983 on musl libc

Changes: https://git.openjdk.org/jdk/pull/14080/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14080&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8308544
  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/14080.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14080/head:pull/14080

PR: https://git.openjdk.org/jdk/pull/14080

From jlahoda at openjdk.org  Mon May 22 13:12:50 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 22 May 2023 13:12:50 GMT
Subject: RFR: 8308544: Fix compilation regression from JDK-8306983 on musl
 libc
In-Reply-To: <A5c-ALjAzzPPuiLfOuxUNm0Fi8xwUJC8YndS2g4CJP8=.794d207d-4677-42e1-adde-7547a3a958f4@github.com>
References: <A5c-ALjAzzPPuiLfOuxUNm0Fi8xwUJC8YndS2g4CJP8=.794d207d-4677-42e1-adde-7547a3a958f4@github.com>
Message-ID: <PNEC56KnWFxDQKtF_GsbsZDuFvFw-nOdZxcFstKrjaU=.0e2861e3-995a-4d20-97c7-5977bfc4e107@github.com>

On Mon, 22 May 2023 12:46:02 GMT, Jan Kratochvil <duke at openjdk.org> wrote:

> Since [JDK-8306983](https://bugs.openjdk.org/browse/JDK-8306983) compilation on Alpine Linux using musl libc:
> 
> ../src/jdk.internal.le/linux/native/lible/CLibrary.cpp: In function 'void Java_jdk_internal_org_jline_terminal_impl_jna_linux_CLibraryImpl_tcgetattr(JNIEnv*, jobject, jint, jobject)':
> ../src/jdk.internal.le/linux/native/lible/CLibrary.cpp:116:45: error: 'struct termios' has no member named 'c_ispeed'; did you mean '__c_ispeed'?
>   116 | env->SetIntField(result, c_ispeed, data.c_ispeed);
>       | ^~~~~~~~
>       | __c_ispeed
> ../src/jdk.internal.le/linux/native/lible/CLibrary.cpp:117:45: error: 'struct termios' has no member named 'c_ospeed'; did you mean '__c_ospeed'?
>   117 | env->SetIntField(result, c_ospeed, data.c_ospeed);
>       | ^~~~~~~~
>       | __c_ospeed
> ../src/jdk.internal.le/linux/native/lible/CLibrary.cpp: In function 'void Java_jdk_internal_org_jline_terminal_impl_jna_linux_CLibraryImpl_tcsetattr(JNIEnv*, jobject, jint, jint, jobject)':
> ../src/jdk.internal.le/linux/native/lible/CLibrary.cpp:136:10: error: 'struct termios' has no member named 'c_ispeed'; did you mean '__c_ispeed'?
>   136 | data.c_ispeed = env->GetIntField(input, c_ispeed);
>       | ^~~~~~~~
>       | __c_ispeed
> ../src/jdk.internal.le/linux/native/lible/CLibrary.cpp:137:10: error: 'struct termios' has no member named 'c_ospeed'; did you mean '__c_ospeed'?
>    ... (rest of output omitted)

Looks good to me - but @bplb, could you please review? Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/14080#issuecomment-1557194443

From acobbs at openjdk.org  Mon May 22 14:45:51 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 22 May 2023 14:45:51 GMT
Subject: RFR: 8194743: Compiler implementation for Statements before
 super() [v4]
In-Reply-To: <3NqC36tQj0MnK6c99_0IgtccSZGQcVI_lb0S2UaNKpo=.6b0237b1-edd1-43c8-bd09-a7e90062a80e@github.com>
References: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>
 <7azJLOKDvP96da2ZY2082Adq57bC9RS8C6Opc9mT1hE=.1169b0ec-39ad-40fa-91d4-a33cceb02def@github.com>
 <3NqC36tQj0MnK6c99_0IgtccSZGQcVI_lb0S2UaNKpo=.6b0237b1-edd1-43c8-bd09-a7e90062a80e@github.com>
Message-ID: <n37ZHmg3QUhLMGDwwHrBKLJnWWg7GMrZ4nIkf86m0CQ=.3bab8f16-70e1-4bdb-a86f-20be563b56ec@github.com>

On Mon, 22 May 2023 04:15:35 GMT, Chen Liang <liach at openjdk.org> wrote:

> what happens if you declare a local class or an anonymous class in the ctor prologue?

You can declare such a class in the prologue, but you can't instantiate it there:

    public static class LocalTest {
        public LocalTest() {
            class Foo {
                Foo() {
                    LocalTest.this.hashCode();
                }
            }
            new Foo();    // ILLEGAL
            super();
            new Foo();    // ALLOWED 
        }
    }       


Note that:
* The prologue includes the statements prior to the superclass constructor *and* the parameter expressions within the superclass constructor invocation
* The rules that apply to the prologue are the *same rules* that previously applied only to parameter expressions within the superclass constructor invocation

So if we "backport" your question to JDK 20, you get the current behavior:

import java.util.concurrent.atomic.*;
public class LocalTest extends AtomicReference<Object> {
    public class Inner {
    }
    public LocalTest(int x) {
        super(new Inner());     // ILLEGAL
    }
    public LocalTest(char x) {
        super(null);
        new Inner();            // ALLOWED
    }
}

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

PR Comment: https://git.openjdk.org/jdk/pull/13656#issuecomment-1557347709

From bpb at openjdk.org  Mon May 22 16:06:58 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 22 May 2023 16:06:58 GMT
Subject: RFR: 8308544: Fix compilation regression from JDK-8306983 on musl
 libc
In-Reply-To: <A5c-ALjAzzPPuiLfOuxUNm0Fi8xwUJC8YndS2g4CJP8=.794d207d-4677-42e1-adde-7547a3a958f4@github.com>
References: <A5c-ALjAzzPPuiLfOuxUNm0Fi8xwUJC8YndS2g4CJP8=.794d207d-4677-42e1-adde-7547a3a958f4@github.com>
Message-ID: <U92SA07Sy9IPY3dD0sm9FwrczgpOpKQN8sN6fo9sbS8=.2f40fe97-90d2-41bb-a6df-feed0d7541f4@github.com>

On Mon, 22 May 2023 12:46:02 GMT, Jan Kratochvil <duke at openjdk.org> wrote:

> Since [JDK-8306983](https://bugs.openjdk.org/browse/JDK-8306983) compilation on Alpine Linux using musl libc:
> 
> ../src/jdk.internal.le/linux/native/lible/CLibrary.cpp: In function 'void Java_jdk_internal_org_jline_terminal_impl_jna_linux_CLibraryImpl_tcgetattr(JNIEnv*, jobject, jint, jobject)':
> ../src/jdk.internal.le/linux/native/lible/CLibrary.cpp:116:45: error: 'struct termios' has no member named 'c_ispeed'; did you mean '__c_ispeed'?
>   116 | env->SetIntField(result, c_ispeed, data.c_ispeed);
>       | ^~~~~~~~
>       | __c_ispeed
> ../src/jdk.internal.le/linux/native/lible/CLibrary.cpp:117:45: error: 'struct termios' has no member named 'c_ospeed'; did you mean '__c_ospeed'?
>   117 | env->SetIntField(result, c_ospeed, data.c_ospeed);
>       | ^~~~~~~~
>       | __c_ospeed
> ../src/jdk.internal.le/linux/native/lible/CLibrary.cpp: In function 'void Java_jdk_internal_org_jline_terminal_impl_jna_linux_CLibraryImpl_tcsetattr(JNIEnv*, jobject, jint, jint, jobject)':
> ../src/jdk.internal.le/linux/native/lible/CLibrary.cpp:136:10: error: 'struct termios' has no member named 'c_ispeed'; did you mean '__c_ispeed'?
>   136 | data.c_ispeed = env->GetIntField(input, c_ispeed);
>       | ^~~~~~~~
>       | __c_ispeed
> ../src/jdk.internal.le/linux/native/lible/CLibrary.cpp:137:10: error: 'struct termios' has no member named 'c_ospeed'; did you mean '__c_ospeed'?
>    ... (rest of output omitted)

Looks all right.

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

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14080#pullrequestreview-1436969462

From duke at openjdk.org  Tue May 23 07:29:28 2023
From: duke at openjdk.org (Jan Kratochvil)
Date: Tue, 23 May 2023 07:29:28 GMT
Subject: RFR: 8308544: Fix compilation regression from JDK-8306983 on musl
 libc [v2]
In-Reply-To: <A5c-ALjAzzPPuiLfOuxUNm0Fi8xwUJC8YndS2g4CJP8=.794d207d-4677-42e1-adde-7547a3a958f4@github.com>
References: <A5c-ALjAzzPPuiLfOuxUNm0Fi8xwUJC8YndS2g4CJP8=.794d207d-4677-42e1-adde-7547a3a958f4@github.com>
Message-ID: <mEsnqmByOUXYgkq5Zr6fZclUhIxYWd9lav51ZwY2r88=.42ec7176-a2b2-4c59-9910-c487cc217320@github.com>

> Since [JDK-8306983](https://bugs.openjdk.org/browse/JDK-8306983) compilation on Alpine Linux using musl libc:
> 
> ../src/jdk.internal.le/linux/native/lible/CLibrary.cpp: In function 'void Java_jdk_internal_org_jline_terminal_impl_jna_linux_CLibraryImpl_tcgetattr(JNIEnv*, jobject, jint, jobject)':
> ../src/jdk.internal.le/linux/native/lible/CLibrary.cpp:116:45: error: 'struct termios' has no member named 'c_ispeed'; did you mean '__c_ispeed'?
>   116 | env->SetIntField(result, c_ispeed, data.c_ispeed);
>       | ^~~~~~~~
>       | __c_ispeed
> ../src/jdk.internal.le/linux/native/lible/CLibrary.cpp:117:45: error: 'struct termios' has no member named 'c_ospeed'; did you mean '__c_ospeed'?
>   117 | env->SetIntField(result, c_ospeed, data.c_ospeed);
>       | ^~~~~~~~
>       | __c_ospeed
> ../src/jdk.internal.le/linux/native/lible/CLibrary.cpp: In function 'void Java_jdk_internal_org_jline_terminal_impl_jna_linux_CLibraryImpl_tcsetattr(JNIEnv*, jobject, jint, jint, jobject)':
> ../src/jdk.internal.le/linux/native/lible/CLibrary.cpp:136:10: error: 'struct termios' has no member named 'c_ispeed'; did you mean '__c_ispeed'?
>   136 | data.c_ispeed = env->GetIntField(input, c_ispeed);
>       | ^~~~~~~~
>       | __c_ispeed
> ../src/jdk.internal.le/linux/native/lible/CLibrary.cpp:137:10: error: 'struct termios' has no member named 'c_ospeed'; did you mean '__c_ospeed'?
>    ... (rest of output omitted)

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

  Change author's e-mail.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14080/files
  - new: https://git.openjdk.org/jdk/pull/14080/files/8265af14..4c1b4ab0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14080&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14080&range=00-01

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14080.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14080/head:pull/14080

PR: https://git.openjdk.org/jdk/pull/14080

From stuefe at openjdk.org  Tue May 23 09:06:01 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 23 May 2023 09:06:01 GMT
Subject: RFR: JDK-8308627: JDK-8306983 breaks Alpine
Message-ID: <6pj_k-DpdXLUaVZQZ8pRlTZ4KtrwCRyt0BfY7rnNFMQ=.5e0c19d6-34e6-4321-89cc-5c3d7d36a044@github.com>

Trivial fix to get Alpine to build again after https://bugs.openjdk.org/browse/JDK-8306983

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

Commit messages:
 - JDK-8308627-JDK-8306983-breaks-Alpine

Changes: https://git.openjdk.org/jdk/pull/14097/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14097&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8308627
  Stats: 12 lines in 1 file changed: 11 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14097.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14097/head:pull/14097

PR: https://git.openjdk.org/jdk/pull/14097

From stuefe at openjdk.org  Tue May 23 15:19:08 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 23 May 2023 15:19:08 GMT
Subject: RFR: 8308544: Fix compilation regression from JDK-8306983 on musl
 libc [v2]
In-Reply-To: <mEsnqmByOUXYgkq5Zr6fZclUhIxYWd9lav51ZwY2r88=.42ec7176-a2b2-4c59-9910-c487cc217320@github.com>
References: <A5c-ALjAzzPPuiLfOuxUNm0Fi8xwUJC8YndS2g4CJP8=.794d207d-4677-42e1-adde-7547a3a958f4@github.com>
 <mEsnqmByOUXYgkq5Zr6fZclUhIxYWd9lav51ZwY2r88=.42ec7176-a2b2-4c59-9910-c487cc217320@github.com>
Message-ID: <NIq-HhfKnSrfhI4o8R-MKydvutRQkiPAzkbgBKGl2JQ=.71df8872-7a8a-421b-a1ec-fc544b8f3496@github.com>

On Tue, 23 May 2023 07:29:28 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

>> Since [JDK-8306983](https://bugs.openjdk.org/browse/JDK-8306983) compilation on Alpine Linux using musl libc:
>> 
>> ../src/jdk.internal.le/linux/native/lible/CLibrary.cpp: In function 'void Java_jdk_internal_org_jline_terminal_impl_jna_linux_CLibraryImpl_tcgetattr(JNIEnv*, jobject, jint, jobject)':
>> ../src/jdk.internal.le/linux/native/lible/CLibrary.cpp:116:45: error: 'struct termios' has no member named 'c_ispeed'; did you mean '__c_ispeed'?
>>   116 | env->SetIntField(result, c_ispeed, data.c_ispeed);
>>       | ^~~~~~~~
>>       | __c_ispeed
>> ../src/jdk.internal.le/linux/native/lible/CLibrary.cpp:117:45: error: 'struct termios' has no member named 'c_ospeed'; did you mean '__c_ospeed'?
>>   117 | env->SetIntField(result, c_ospeed, data.c_ospeed);
>>       | ^~~~~~~~
>>       | __c_ospeed
>> ../src/jdk.internal.le/linux/native/lible/CLibrary.cpp: In function 'void Java_jdk_internal_org_jline_terminal_impl_jna_linux_CLibraryImpl_tcsetattr(JNIEnv*, jobject, jint, jint, jobject)':
>> ../src/jdk.internal.le/linux/native/lible/CLibrary.cpp:136:10: error: 'struct termios' has no member named 'c_ispeed'; did you mean '__c_ispeed'?
>>   136 | data.c_ispeed = env->GetIntField(input, c_ispeed);
>>       | ^~~~~~~~
>>       | __c_ispeed
>> ../src/jdk.internal.le/linux/native/lible/CLibrary.cpp:137:10: error: 'struct termios' has no member named 'c_ospeed'; did you mean '__c_ospeed'?
>>    ... (rest of output omitted)
>
> Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change author's e-mail.

Okay. I had a slightly different fix, but I'll close that as duplicate: https://github.com/openjdk/jdk/pull/14097

Marked as reviewed by stuefe (Reviewer).

@jankratochvil can you please repeat the integrate? Thanks.

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

PR Review: https://git.openjdk.org/jdk/pull/14080#pullrequestreview-1439260947
PR Review: https://git.openjdk.org/jdk/pull/14080#pullrequestreview-1439261679
PR Comment: https://git.openjdk.org/jdk/pull/14080#issuecomment-1559093987

From jkratochvil at openjdk.org  Tue May 23 15:19:14 2023
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Tue, 23 May 2023 15:19:14 GMT
Subject: RFR: 8308544: Fix compilation regression from JDK-8306983 on musl
 libc [v2]
In-Reply-To: <NIq-HhfKnSrfhI4o8R-MKydvutRQkiPAzkbgBKGl2JQ=.71df8872-7a8a-421b-a1ec-fc544b8f3496@github.com>
References: <A5c-ALjAzzPPuiLfOuxUNm0Fi8xwUJC8YndS2g4CJP8=.794d207d-4677-42e1-adde-7547a3a958f4@github.com>
 <mEsnqmByOUXYgkq5Zr6fZclUhIxYWd9lav51ZwY2r88=.42ec7176-a2b2-4c59-9910-c487cc217320@github.com>
 <NIq-HhfKnSrfhI4o8R-MKydvutRQkiPAzkbgBKGl2JQ=.71df8872-7a8a-421b-a1ec-fc544b8f3496@github.com>
Message-ID: <qXro7wBoJQ5ZQoJhrouJm5vvpKeW33_RPYq_yOuRCSU=.17345faa-a851-4b84-9b86-7c4c9382ec00@github.com>

On Tue, 23 May 2023 11:18:44 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> @jankratochvil can you please repeat the integrate? Thanks.

I did not want to as I have realized my openjdk commits go with wrong e-mail address (not `@openjdk.org`). So I have filed now https://bugs.openjdk.org/browse/SKARA-1915 which should hopefully fix it but it has not been processed yet.

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

PR Comment: https://git.openjdk.org/jdk/pull/14080#issuecomment-1559161100

From stuefe at openjdk.org  Tue May 23 15:19:17 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 23 May 2023 15:19:17 GMT
Subject: RFR: 8308544: Fix compilation regression from JDK-8306983 on musl
 libc [v2]
In-Reply-To: <qXro7wBoJQ5ZQoJhrouJm5vvpKeW33_RPYq_yOuRCSU=.17345faa-a851-4b84-9b86-7c4c9382ec00@github.com>
References: <A5c-ALjAzzPPuiLfOuxUNm0Fi8xwUJC8YndS2g4CJP8=.794d207d-4677-42e1-adde-7547a3a958f4@github.com>
 <mEsnqmByOUXYgkq5Zr6fZclUhIxYWd9lav51ZwY2r88=.42ec7176-a2b2-4c59-9910-c487cc217320@github.com>
 <NIq-HhfKnSrfhI4o8R-MKydvutRQkiPAzkbgBKGl2JQ=.71df8872-7a8a-421b-a1ec-fc544b8f3496@github.com>
 <qXro7wBoJQ5ZQoJhrouJm5vvpKeW33_RPYq_yOuRCSU=.17345faa-a851-4b84-9b86-7c4c9382ec00@github.com>
Message-ID: <ehB4EuvsaMYccJRWBfYa2ABaf6K4irCywP80j2mIUEs=.0089b10f-dd47-4ca1-b7af-839c1b36f078@github.com>

On Tue, 23 May 2023 12:08:10 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

> > @jankratochvil can you please repeat the integrate? Thanks.
> 
> I did not want to as I have realized my openjdk commits go with wrong e-mail address (not `@openjdk.org`). So I have filed now https://bugs.openjdk.org/browse/SKARA-1915 which should hopefully fix it but it has not been processed yet.

Is this really important? Build fixes are time critical. Let's just hope this skara bug gets resolved quickly.

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

PR Comment: https://git.openjdk.org/jdk/pull/14080#issuecomment-1559184557

From jkratochvil at openjdk.org  Tue May 23 15:19:20 2023
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Tue, 23 May 2023 15:19:20 GMT
Subject: RFR: 8308544: Fix compilation regression from JDK-8306983 on musl
 libc [v2]
In-Reply-To: <ehB4EuvsaMYccJRWBfYa2ABaf6K4irCywP80j2mIUEs=.0089b10f-dd47-4ca1-b7af-839c1b36f078@github.com>
References: <A5c-ALjAzzPPuiLfOuxUNm0Fi8xwUJC8YndS2g4CJP8=.794d207d-4677-42e1-adde-7547a3a958f4@github.com>
 <mEsnqmByOUXYgkq5Zr6fZclUhIxYWd9lav51ZwY2r88=.42ec7176-a2b2-4c59-9910-c487cc217320@github.com>
 <NIq-HhfKnSrfhI4o8R-MKydvutRQkiPAzkbgBKGl2JQ=.71df8872-7a8a-421b-a1ec-fc544b8f3496@github.com>
 <qXro7wBoJQ5ZQoJhrouJm5vvpKeW33_RPYq_yOuRCSU=.17345faa-a851-4b84-9b86-7c4c9382ec00@github.com>
 <ehB4EuvsaMYccJRWBfYa2ABaf6K4irCywP80j2mIUEs=.0089b10f-dd47-4ca1-b7af-839c1b36f078@github.com>
Message-ID: <A4EwF1cyacW9Ozbd9AIaG-Ab2kwNGcGLFB1GsKlrSZY=.4554e53e-d49f-4f6a-8052-e543a3790143@github.com>

On Tue, 23 May 2023 12:18:53 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Is this really important? Build fixes are time critical.

It is not important. I rather have not found much urgent the Alpine Linux fix. So I have done the /integrate.

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

PR Comment: https://git.openjdk.org/jdk/pull/14080#issuecomment-1559195657

From jkratochvil at openjdk.org  Tue May 23 15:19:20 2023
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Tue, 23 May 2023 15:19:20 GMT
Subject: RFR: 8308544: Fix compilation regression from JDK-8306983 on musl
 libc [v2]
In-Reply-To: <mEsnqmByOUXYgkq5Zr6fZclUhIxYWd9lav51ZwY2r88=.42ec7176-a2b2-4c59-9910-c487cc217320@github.com>
References: <A5c-ALjAzzPPuiLfOuxUNm0Fi8xwUJC8YndS2g4CJP8=.794d207d-4677-42e1-adde-7547a3a958f4@github.com>
 <mEsnqmByOUXYgkq5Zr6fZclUhIxYWd9lav51ZwY2r88=.42ec7176-a2b2-4c59-9910-c487cc217320@github.com>
Message-ID: <d51Z42AJUOYM7pkxAF6UsogsQU8SDKck5eePNkuerIk=.8c83bfa5-d696-4627-833e-18425416433d@github.com>

On Tue, 23 May 2023 07:29:28 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

>> Since [JDK-8306983](https://bugs.openjdk.org/browse/JDK-8306983) compilation on Alpine Linux using musl libc:
>> 
>> ../src/jdk.internal.le/linux/native/lible/CLibrary.cpp: In function 'void Java_jdk_internal_org_jline_terminal_impl_jna_linux_CLibraryImpl_tcgetattr(JNIEnv*, jobject, jint, jobject)':
>> ../src/jdk.internal.le/linux/native/lible/CLibrary.cpp:116:45: error: 'struct termios' has no member named 'c_ispeed'; did you mean '__c_ispeed'?
>>   116 | env->SetIntField(result, c_ispeed, data.c_ispeed);
>>       | ^~~~~~~~
>>       | __c_ispeed
>> ../src/jdk.internal.le/linux/native/lible/CLibrary.cpp:117:45: error: 'struct termios' has no member named 'c_ospeed'; did you mean '__c_ospeed'?
>>   117 | env->SetIntField(result, c_ospeed, data.c_ospeed);
>>       | ^~~~~~~~
>>       | __c_ospeed
>> ../src/jdk.internal.le/linux/native/lible/CLibrary.cpp: In function 'void Java_jdk_internal_org_jline_terminal_impl_jna_linux_CLibraryImpl_tcsetattr(JNIEnv*, jobject, jint, jint, jobject)':
>> ../src/jdk.internal.le/linux/native/lible/CLibrary.cpp:136:10: error: 'struct termios' has no member named 'c_ispeed'; did you mean '__c_ispeed'?
>>   136 | data.c_ispeed = env->GetIntField(input, c_ispeed);
>>       | ^~~~~~~~
>>       | __c_ispeed
>> ../src/jdk.internal.le/linux/native/lible/CLibrary.cpp:137:10: error: 'struct termios' has no member named 'c_ospeed'; did you mean '__c_ospeed'?
>>    ... (rest of output omitted)
>
> Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change author's e-mail.

My e-mail address ticket https://bugs.openjdk.org/browse/SKARA-1915 is now even already resolved.

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

PR Comment: https://git.openjdk.org/jdk/pull/14080#issuecomment-1559361349

From stuefe at openjdk.org  Tue May 23 15:19:23 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 23 May 2023 15:19:23 GMT
Subject: RFR: 8308544: Fix compilation regression from JDK-8306983 on musl
 libc [v2]
In-Reply-To: <d51Z42AJUOYM7pkxAF6UsogsQU8SDKck5eePNkuerIk=.8c83bfa5-d696-4627-833e-18425416433d@github.com>
References: <A5c-ALjAzzPPuiLfOuxUNm0Fi8xwUJC8YndS2g4CJP8=.794d207d-4677-42e1-adde-7547a3a958f4@github.com>
 <mEsnqmByOUXYgkq5Zr6fZclUhIxYWd9lav51ZwY2r88=.42ec7176-a2b2-4c59-9910-c487cc217320@github.com>
 <d51Z42AJUOYM7pkxAF6UsogsQU8SDKck5eePNkuerIk=.8c83bfa5-d696-4627-833e-18425416433d@github.com>
Message-ID: <V00s0T5_Xh9ZtByj00_QJu_CTxi6qW7uKQjik48vuw4=.2ff34887-19b9-4b27-b27b-11cd5e5a4ce9@github.com>

On Tue, 23 May 2023 13:29:31 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

>> Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Change author's e-mail.
>
> My e-mail address ticket https://bugs.openjdk.org/browse/SKARA-1915 is now even already resolved.

@jankratochvil Great, thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/14080#issuecomment-1559402432

From jkratochvil at openjdk.org  Tue May 23 15:19:34 2023
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Tue, 23 May 2023 15:19:34 GMT
Subject: Integrated: 8308544: Fix compilation regression from JDK-8306983 on
 musl libc
In-Reply-To: <A5c-ALjAzzPPuiLfOuxUNm0Fi8xwUJC8YndS2g4CJP8=.794d207d-4677-42e1-adde-7547a3a958f4@github.com>
References: <A5c-ALjAzzPPuiLfOuxUNm0Fi8xwUJC8YndS2g4CJP8=.794d207d-4677-42e1-adde-7547a3a958f4@github.com>
Message-ID: <RW2dLhW7nWpJvwn41tpcHIo5oWNU8DCA6sBM0So2uYw=.3b58d1e9-d9e9-4623-a9c5-9929cd78cdf8@github.com>

On Mon, 22 May 2023 12:46:02 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

> Since [JDK-8306983](https://bugs.openjdk.org/browse/JDK-8306983) compilation on Alpine Linux using musl libc:
> 
> ../src/jdk.internal.le/linux/native/lible/CLibrary.cpp: In function 'void Java_jdk_internal_org_jline_terminal_impl_jna_linux_CLibraryImpl_tcgetattr(JNIEnv*, jobject, jint, jobject)':
> ../src/jdk.internal.le/linux/native/lible/CLibrary.cpp:116:45: error: 'struct termios' has no member named 'c_ispeed'; did you mean '__c_ispeed'?
>   116 | env->SetIntField(result, c_ispeed, data.c_ispeed);
>       | ^~~~~~~~
>       | __c_ispeed
> ../src/jdk.internal.le/linux/native/lible/CLibrary.cpp:117:45: error: 'struct termios' has no member named 'c_ospeed'; did you mean '__c_ospeed'?
>   117 | env->SetIntField(result, c_ospeed, data.c_ospeed);
>       | ^~~~~~~~
>       | __c_ospeed
> ../src/jdk.internal.le/linux/native/lible/CLibrary.cpp: In function 'void Java_jdk_internal_org_jline_terminal_impl_jna_linux_CLibraryImpl_tcsetattr(JNIEnv*, jobject, jint, jint, jobject)':
> ../src/jdk.internal.le/linux/native/lible/CLibrary.cpp:136:10: error: 'struct termios' has no member named 'c_ispeed'; did you mean '__c_ispeed'?
>   136 | data.c_ispeed = env->GetIntField(input, c_ispeed);
>       | ^~~~~~~~
>       | __c_ispeed
> ../src/jdk.internal.le/linux/native/lible/CLibrary.cpp:137:10: error: 'struct termios' has no member named 'c_ospeed'; did you mean '__c_ospeed'?
>    ... (rest of output omitted)

This pull request has now been integrated.

Changeset: c0c4d771
Author:    Jan Kratochvil <jkratochvil at openjdk.org>
Committer: Thomas Stuefe <stuefe at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c0c4d771922f8fce36f1014e57d7e7a213243891
Stats:     4 lines in 1 file changed: 0 ins; 0 del; 4 mod

8308544: Fix compilation regression from JDK-8306983 on musl libc

Reviewed-by: bpb, stuefe

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

PR: https://git.openjdk.org/jdk/pull/14080

From acobbs at openjdk.org  Tue May 23 20:26:39 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 23 May 2023 20:26:39 GMT
Subject: RFR: 8194743: Compiler implementation for Statements before
 super() [v5]
In-Reply-To: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>
References: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>
Message-ID: <w24poRstpvedWnFnH805ffHzCp0xhi_G3CzM91shl74=.9693d7c1-d4d4-4d21-81a0-6525fde01e39@github.com>

> This is a first draft of a patch for JEP 447.
> 
> Summary of changes:
> 
> 1. Track when we're within a constructor "prologue" via new flag `AttrContext.ctorPrologue`
> 1. Add checks for illegal early access to `this` in constructor prologues, and update existing checks to distinguish between static context vs. constructor prologue context
> 1. Verify allowed placement of `super()`/`this()` calls via new method `Check.checkSuperInitCalls()`
> 1. Remove/refactor assumptions in several places that `super()`/`this()` was always the first statement
> 
> The changes in `Flow.java` are an example of <span>#</span>4. `Flow.FlowAnalyzer` checks for uncaught checked exceptions. For initializer blocks, this was previously done by requiring that any checked exceptions thrown be declared as thrown by all constructors containing `super()`. This list of checked exceptions was being pre-calculated before recursing into the initial constructors. This worked because initializer blocks were executed at the beginning of each initial constructor right after `super()` is called.
> 
> Now initializer blocks are traversed as each `super()` invocation is encountered, reflecting what actually happens at runtime. Similarly, final fields are marked as DA after encountering `this()`, not automatically at the beginning of those  constructors. These changes produce equivalent checks, but are compatible with the new flexibility of placement of `super()`/`this()` as well as possible future changes that could occur along these same lines.

Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits:

 - Rename unit test to be consistent with other feature exampless.
 - Update unit test after merged-in commit eaa80ad08.
 - Add unit tests with local class decl's prior to super().
 - Merge branch 'master' into SuperInit
 - Use @enablePreview in tests in preference to explicit command line flags.
 - Make "statements before super()" support a preview feature.
   
   Thanks to Jim Laskey for help with preview logic.
 - Small refactoring to avoid redundant test.
 - Fix typo in comment.
 - Use for() loop instead of stream for efficiency.
 - Fix typo in comment.
 - ... and 12 more: https://git.openjdk.org/jdk/compare/bddf4838...543a596a

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

Changes: https://git.openjdk.org/jdk/pull/13656/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13656&range=04
  Stats: 1402 lines in 24 files changed: 1132 ins; 163 del; 107 mod
  Patch: https://git.openjdk.org/jdk/pull/13656.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13656/head:pull/13656

PR: https://git.openjdk.org/jdk/pull/13656

From jlahoda at openjdk.org  Fri May 26 07:47:55 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 26 May 2023 07:47:55 GMT
Subject: RFR: 8306560: Add TOOLING.jsh load file [v2]
In-Reply-To: <7RChGscBY8dup0BwH07KmqQqpKw5i7yE4FZD9U36938=.460372ec-111e-4f79-935c-db9d77579caf@github.com>
References: <D_Y5zRi3BVl6f2nknM9eXorEPdSK6NooGk4mf5j3e3U=.9f242609-33f7-4edf-b7d2-ea7e51ff238e@github.com>
 <7RChGscBY8dup0BwH07KmqQqpKw5i7yE4FZD9U36938=.460372ec-111e-4f79-935c-db9d77579caf@github.com>
Message-ID: <qyZpPb1hU5axi9tOgCs7dhUfJoFEtBXXGenp8VcINYk=.bc1bb249-68af-464f-be47-053029d56c89@github.com>

On Wed, 26 Apr 2023 15:55:00 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> This PR adds the `TOOLING.jsh` load file for being used in `jshell TOOLING` commands.
>> 
>> _Man page update is pending..._
>
> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve help text

Looks good to me.

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13609#pullrequestreview-1445470060

From jlahoda at openjdk.org  Fri May 26 11:57:32 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 26 May 2023 11:57:32 GMT
Subject: RFR: 8308943: jdk.internal.le build fails on AIX
Message-ID: <nLnpkThhJw5C7XiPK38jn_znrL56ngPxcYbQEN-AM6o=.bd421c59-ce1e-4fb1-b594-54aaa65ba13a@github.com>

Build of `jdk.internal.le` fails on AIX, because code in the `unix` directory expects `jdk.internal.org.jline.terminal.impl.jna.JDKNativePty` for each platform (unix-like), but it does not for AIX.

We could add a stub of this class into the `aix` directory (methods could throw an exception, which would automatically switch JLine into the "external executable" mode, if enabled). But, it might be better to use the `ServiceLoader`, and simply register a platform-specific provider as a service. This patch is attempting to do the latter.

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

Commit messages:
 - 8308943: jdk.internal.le build fails on AIX

Changes: https://git.openjdk.org/jdk/pull/14176/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14176&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8308943
  Stats: 323 lines in 8 files changed: 217 ins; 102 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/14176.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14176/head:pull/14176

PR: https://git.openjdk.org/jdk/pull/14176

From acobbs at openjdk.org  Fri May 26 21:32:20 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 26 May 2023 21:32:20 GMT
Subject: RFR: 8194743: Compiler implementation for Statements before
 super() [v6]
In-Reply-To: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>
References: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>
Message-ID: <cA2Ib1xUESlaN_rbKu0migmJCwnioAEuoakc6refeLQ=.49fe6bc9-91ef-4141-8df7-80e88f91359d@github.com>

> This is a first draft of a patch for JEP 447.
> 
> Summary of changes:
> 
> 1. Track when we're within a constructor "prologue" via new flag `AttrContext.ctorPrologue`
> 1. Add checks for illegal early access to `this` in constructor prologues, and update existing checks to distinguish between static context vs. constructor prologue context
> 1. Verify allowed placement of `super()`/`this()` calls via new method `Check.checkSuperInitCalls()`
> 1. Remove/refactor assumptions in several places that `super()`/`this()` was always the first statement
> 
> The changes in `Flow.java` are an example of <span>#</span>4. `Flow.FlowAnalyzer` checks for uncaught checked exceptions. For initializer blocks, this was previously done by requiring that any checked exceptions thrown be declared as thrown by all constructors containing `super()`. This list of checked exceptions was being pre-calculated before recursing into the initial constructors. This worked because initializer blocks were executed at the beginning of each initial constructor right after `super()` is called.
> 
> Now initializer blocks are traversed as each `super()` invocation is encountered, reflecting what actually happens at runtime. Similarly, final fields are marked as DA after encountering `this()`, not automatically at the beginning of those  constructors. These changes produce equivalent checks, but are compatible with the new flexibility of placement of `super()`/`this()` as well as possible future changes that could occur along these same lines.

Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 24 commits:

 - Fix mistake in previous merge commit 80ba6be4.
 - Merge branch 'master' into SuperInit
 - Rename unit test to be consistent with other feature exampless.
 - Update unit test after merged-in commit eaa80ad08.
 - Add unit tests with local class decl's prior to super().
 - Merge branch 'master' into SuperInit
 - Use @enablePreview in tests in preference to explicit command line flags.
 - Make "statements before super()" support a preview feature.
   
   Thanks to Jim Laskey for help with preview logic.
 - Small refactoring to avoid redundant test.
 - Fix typo in comment.
 - ... and 14 more: https://git.openjdk.org/jdk/compare/c72b5474...276e449d

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

Changes: https://git.openjdk.org/jdk/pull/13656/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13656&range=05
  Stats: 1400 lines in 24 files changed: 1132 ins; 163 del; 105 mod
  Patch: https://git.openjdk.org/jdk/pull/13656.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13656/head:pull/13656

PR: https://git.openjdk.org/jdk/pull/13656

From cstein at openjdk.org  Sun May 28 08:18:09 2023
From: cstein at openjdk.org (Christian Stein)
Date: Sun, 28 May 2023 08:18:09 GMT
Subject: Integrated: 8306560: Add TOOLING.jsh load file
In-Reply-To: <D_Y5zRi3BVl6f2nknM9eXorEPdSK6NooGk4mf5j3e3U=.9f242609-33f7-4edf-b7d2-ea7e51ff238e@github.com>
References: <D_Y5zRi3BVl6f2nknM9eXorEPdSK6NooGk4mf5j3e3U=.9f242609-33f7-4edf-b7d2-ea7e51ff238e@github.com>
Message-ID: <DVH217O_1p0kqcTEUGB1Q920gUZmCPuVPEycX6_9npk=.03ba1cdd-b25c-49cc-8d60-f4fad98f8cf2@github.com>

On Mon, 24 Apr 2023 10:35:43 GMT, Christian Stein <cstein at openjdk.org> wrote:

> This PR adds the `TOOLING.jsh` load file for being used in `jshell TOOLING` commands.
> 
> _Man page update is pending..._

This pull request has now been integrated.

Changeset: 547a8b40
Author:    Christian Stein <cstein at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/547a8b40b324917e66c71409b31421feacce79d7
Stats:     167 lines in 6 files changed: 153 ins; 0 del; 14 mod

8306560: Add TOOLING.jsh load file

Reviewed-by: jlahoda

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

PR: https://git.openjdk.org/jdk/pull/13609

From mbaesken at openjdk.org  Tue May 30 08:52:58 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 30 May 2023 08:52:58 GMT
Subject: RFR: 8308943: jdk.internal.le build fails on AIX
In-Reply-To: <nLnpkThhJw5C7XiPK38jn_znrL56ngPxcYbQEN-AM6o=.bd421c59-ce1e-4fb1-b594-54aaa65ba13a@github.com>
References: <nLnpkThhJw5C7XiPK38jn_znrL56ngPxcYbQEN-AM6o=.bd421c59-ce1e-4fb1-b594-54aaa65ba13a@github.com>
Message-ID: <wup7bkj7Od3xNqEWNo5oVRTXH7sZWcTh7oek92XlLdY=.f715102a-bc27-496c-abfb-85a56f20ab6d@github.com>

On Fri, 26 May 2023 11:49:34 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Build of `jdk.internal.le` fails on AIX, because code in the `unix` directory expects `jdk.internal.org.jline.terminal.impl.jna.JDKNativePty` for each platform (unix-like), but it does not for AIX.
> 
> We could add a stub of this class into the `aix` directory (methods could throw an exception, which would automatically switch JLine into the "external executable" mode, if enabled). But, it might be better to use the `ServiceLoader`, and simply register a platform-specific provider as a service. This patch is attempting to do the latter.

LGTM

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

Marked as reviewed by mbaesken (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14176#pullrequestreview-1450436363

From jlahoda at openjdk.org  Wed May 31 13:20:18 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 31 May 2023 13:20:18 GMT
Subject: RFR: 8308943: jdk.internal.le build fails on AIX
Message-ID: <JHSLDdbdlIvqLwaIj5e428Yq4fh3knM8dzNOTI9Ln28=.48ac0dff-d607-4c2d-a755-cd5e265bbe7e@github.com>

A simpler alternative to https://github.com/openjdk/jdk/pull/14176 - it only creates a stub of `JDKNativePty` for AIX, throwing `UnsupportedOperationException`. JLine will then either use the next provider (i.e. "exec", for JShell), or dumb terminal.

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

Commit messages:
 - 8308943: jdk.internal.le build fails on AIX

Changes: https://git.openjdk.org/jdk/pull/14247/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14247&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8308943
  Stats: 51 lines in 1 file changed: 51 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14247.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14247/head:pull/14247

PR: https://git.openjdk.org/jdk/pull/14247

From jlahoda at openjdk.org  Wed May 31 17:15:24 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 31 May 2023 17:15:24 GMT
Subject: RFR: 8308943: jdk.internal.le build fails on AIX [v2]
In-Reply-To: <JHSLDdbdlIvqLwaIj5e428Yq4fh3knM8dzNOTI9Ln28=.48ac0dff-d607-4c2d-a755-cd5e265bbe7e@github.com>
References: <JHSLDdbdlIvqLwaIj5e428Yq4fh3knM8dzNOTI9Ln28=.48ac0dff-d607-4c2d-a755-cd5e265bbe7e@github.com>
Message-ID: <JLZSQbv8DU9PP1qTPD8OHa1amO6tv4mti6YY1-yorEY=.30e7c130-8dd5-4ecd-9e99-2024ffc455a3@github.com>

> A simpler alternative to https://github.com/openjdk/jdk/pull/14176 - it only creates a stub of `JDKNativePty` for AIX, throwing `UnsupportedOperationException`. JLine will then either use the next provider (i.e. "exec", for JShell), or dumb terminal.

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

  Removing unnecessary import of a class that does not exist for this system.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14247/files
  - new: https://git.openjdk.org/jdk/pull/14247/files/01782019..cd0567db

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14247&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14247&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14247.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14247/head:pull/14247

PR: https://git.openjdk.org/jdk/pull/14247