From abimpoudis at openjdk.org  Fri Jul  1 09:26:21 2022
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Fri, 1 Jul 2022 09:26:21 GMT
Subject: RFR: 8269674: Improve testing of parenthesized patterns
Message-ID: <CKhyND9xcF1C457WSOvoxO6ne0PbX1Nb5v9s0rYivkM=.14ffb35a-db79-4272-bc36-fd6f9f924303@github.com>

Introduces a combo test (compile-time) for parenthesized patterns. Subsumes `test/langtools/tools/javac/patterns/Parenthesized.java`. 

Bugs addressed:
- `case (StringBox(String s1))` raised a parse error

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

Commit messages:
 - 8269674: Add combo test and fix parenthesized

Changes: https://git.openjdk.org/jdk/pull/9344/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9344&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8269674
  Stats: 174 lines in 2 files changed: 169 ins; 4 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9344.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9344/head:pull/9344

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

From vromero at openjdk.org  Fri Jul  1 16:30:54 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 1 Jul 2022 16:30:54 GMT
Subject: [jdk19] RFR: 8289196: Patttern domination not working property for
 record patterns
In-Reply-To: <SCvRtNylRkbz01mGAjf0YqXyzYz7txFSqZShcnEb118=.87da4559-1346-4d56-b4f0-984ef3732d58@github.com>
References: <SCvRtNylRkbz01mGAjf0YqXyzYz7txFSqZShcnEb118=.87da4559-1346-4d56-b4f0-984ef3732d58@github.com>
Message-ID: <Qunr2EpEHQyt_Bs5zWQGuZnRwdn6r4mKHd4h3B0nQsE=.ce755e7f-7c4b-45c3-93ba-deb6dcab2b4e@github.com>

On Tue, 28 Jun 2022 13:11:25 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> When checking that a pattern in a switch case is not dominated by a preceding pattern, handling for record pattern is mostly missing. This patch is attempting to fix that, and as it requires a bit more code, it moves the check into `Check`.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 4423:

> 4421:             }
> 4422:             if (existingPatternType.isPrimitive()) {
> 4423:                 if (!types.isSameType(existingPatternType, currentPatternType)) {

note: shouldn't we return true if both are primitive and they are the same type? I mean this method seems to returns the right thing in that case but it is doing some extra analysis that doesn't seem to be necessary IMO

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

PR: https://git.openjdk.org/jdk19/pull/84

From vromero at openjdk.org  Fri Jul  1 16:46:43 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 1 Jul 2022 16:46:43 GMT
Subject: [jdk19] RFR: 8289196: Patttern domination not working property for
 record patterns
In-Reply-To: <SCvRtNylRkbz01mGAjf0YqXyzYz7txFSqZShcnEb118=.87da4559-1346-4d56-b4f0-984ef3732d58@github.com>
References: <SCvRtNylRkbz01mGAjf0YqXyzYz7txFSqZShcnEb118=.87da4559-1346-4d56-b4f0-984ef3732d58@github.com>
Message-ID: <sWNHLlDUztBerHGINOUadFSu_bydtY49fxSzgBj__jg=.84d8f500-98bc-4b40-b8cb-3336ccc33efd@github.com>

On Tue, 28 Jun 2022 13:11:25 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> When checking that a pattern in a switch case is not dominated by a preceding pattern, handling for record pattern is mostly missing. This patch is attempting to fix that, and as it requires a bit more code, it moves the check into `Check`.

shouldn't this test case be rejected too:


class TestRecordPattern {
    int testRecordPatternsDominated2() {
        record R(int a) {}
        Object o = null;
        switch (o) {
            //case R(int a): return 1;
            case R(int a) when guard(): return -1;
            case R(int a): return 1;
            default: return 0;
        }
    }

    boolean guard() {
        return false;
    }
}


http://cr.openjdk.java.net/~gbierman/jep427+405/jep427+405-20220601/specs/patterns-switch-record-patterns-jls.html#jls-14.30.3 doesn't mention anything about guards if I understand correctly

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

PR: https://git.openjdk.org/jdk19/pull/84

From jlahoda at openjdk.org  Fri Jul  1 18:13:36 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 1 Jul 2022 18:13:36 GMT
Subject: [jdk19] RFR: 8289196: Patttern domination not working property for
 record patterns [v2]
In-Reply-To: <SCvRtNylRkbz01mGAjf0YqXyzYz7txFSqZShcnEb118=.87da4559-1346-4d56-b4f0-984ef3732d58@github.com>
References: <SCvRtNylRkbz01mGAjf0YqXyzYz7txFSqZShcnEb118=.87da4559-1346-4d56-b4f0-984ef3732d58@github.com>
Message-ID: <Io4XUQeBM4PPfPQ1GPg2dHOTkjrP-1NjSgZRfTPwlf4=.60ac825c-f241-4e97-8d3f-da6d3d292ac4@github.com>

> When checking that a pattern in a switch case is not dominated by a preceding pattern, handling for record pattern is mostly missing. This patch is attempting to fix that, and as it requires a bit more code, it moves the check into `Check`.

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

  Adding test, as suggested.

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

Changes:
  - all: https://git.openjdk.org/jdk19/pull/84/files
  - new: https://git.openjdk.org/jdk19/pull/84/files/9d22eaf0..220fcc12

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

  Stats: 21 lines in 2 files changed: 20 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk19/pull/84.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/84/head:pull/84

PR: https://git.openjdk.org/jdk19/pull/84

From jlahoda at openjdk.org  Fri Jul  1 18:13:37 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 1 Jul 2022 18:13:37 GMT
Subject: [jdk19] RFR: 8289196: Patttern domination not working property for
 record patterns
In-Reply-To: <sWNHLlDUztBerHGINOUadFSu_bydtY49fxSzgBj__jg=.84d8f500-98bc-4b40-b8cb-3336ccc33efd@github.com>
References: <SCvRtNylRkbz01mGAjf0YqXyzYz7txFSqZShcnEb118=.87da4559-1346-4d56-b4f0-984ef3732d58@github.com>
 <sWNHLlDUztBerHGINOUadFSu_bydtY49fxSzgBj__jg=.84d8f500-98bc-4b40-b8cb-3336ccc33efd@github.com>
Message-ID: <jDsura_H7Q1OjpBNPJXGaTwNX5BBX3cTSswRQycEanU=.b715cc18-81e8-477e-bc6b-08cbd4433ec3@github.com>

On Fri, 1 Jul 2022 16:43:29 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> nit: we could probably add this test case for completeness:
> 
> ```
> class Test {
>     int test() {
>         record R(int a) {}
>         Object o = null;
>         switch (o) {
>             case R(int a) when true: return -1;
>             case R(int a): return 1;
>         }
>     }
> }
> ```

Thanks, done.

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

PR: https://git.openjdk.org/jdk19/pull/84

From jlahoda at openjdk.org  Fri Jul  1 18:13:40 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 1 Jul 2022 18:13:40 GMT
Subject: [jdk19] RFR: 8289196: Patttern domination not working property for
 record patterns [v2]
In-Reply-To: <Qunr2EpEHQyt_Bs5zWQGuZnRwdn6r4mKHd4h3B0nQsE=.ce755e7f-7c4b-45c3-93ba-deb6dcab2b4e@github.com>
References: <SCvRtNylRkbz01mGAjf0YqXyzYz7txFSqZShcnEb118=.87da4559-1346-4d56-b4f0-984ef3732d58@github.com>
 <Qunr2EpEHQyt_Bs5zWQGuZnRwdn6r4mKHd4h3B0nQsE=.ce755e7f-7c4b-45c3-93ba-deb6dcab2b4e@github.com>
Message-ID: <3OsPYG07Ga2N4kRBQ5LexwPvRyt9N1COyUd8tXMbO_M=.612e587a-bdb7-4011-8ac7-879fbf94f62a@github.com>

On Fri, 1 Jul 2022 16:28:34 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adding test, as suggested.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 4423:
> 
>> 4421:             }
>> 4422:             if (existingPatternType.isPrimitive()) {
>> 4423:                 if (!types.isSameType(existingPatternType, currentPatternType)) {
> 
> note: shouldn't we return true if both have the same type? I mean this method seems to returns the right thing in that case but it is doing some extra analysis that doesn't seem to be necessary IMO

We could, but I am not sure if that's not "too clever". Returning `true` when the type is same is based on the fact that only binding patterns (type test patterns) can be of primitive types, so the tests below will always return `true`. I can do that if strongly preferred, but I somewhat like the separation of concerns, where we verify the types here, and then the structure is checked below, regardless of the pattern's type.

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

PR: https://git.openjdk.org/jdk19/pull/84

From vromero at openjdk.org  Fri Jul  1 19:23:23 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 1 Jul 2022 19:23:23 GMT
Subject: [jdk19] RFR: 8289196: Patttern domination not working property for
 record patterns [v2]
In-Reply-To: <Io4XUQeBM4PPfPQ1GPg2dHOTkjrP-1NjSgZRfTPwlf4=.60ac825c-f241-4e97-8d3f-da6d3d292ac4@github.com>
References: <SCvRtNylRkbz01mGAjf0YqXyzYz7txFSqZShcnEb118=.87da4559-1346-4d56-b4f0-984ef3732d58@github.com>
 <Io4XUQeBM4PPfPQ1GPg2dHOTkjrP-1NjSgZRfTPwlf4=.60ac825c-f241-4e97-8d3f-da6d3d292ac4@github.com>
Message-ID: <vl54-w_yCXu-rSFQ18daf1C38jc3oj6qPG1BxQyYHds=.1d5af21a-c2ca-4bce-a480-abdef620c749@github.com>

On Fri, 1 Jul 2022 18:13:36 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> When checking that a pattern in a switch case is not dominated by a preceding pattern, handling for record pattern is mostly missing. This patch is attempting to fix that, and as it requires a bit more code, it moves the check into `Check`.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding test, as suggested.

lgtm

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

Marked as reviewed by vromero (Reviewer).

PR: https://git.openjdk.org/jdk19/pull/84

From iveresov at openjdk.org  Sat Jul  2 01:13:01 2022
From: iveresov at openjdk.org (Igor Veresov)
Date: Sat, 2 Jul 2022 01:13:01 GMT
Subject: [jdk19] RFR: 8245268: -Xcomp is missing from java launcher
 documentation
Message-ID: <FVqMF2apRSRhYmOkhnI2ut8b6iz1BXA1meOfNzU5HQY=.f21b7123-395b-467d-9da0-154102f04398@github.com>

Updated man pages from markdown sources.

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

Commit messages:
 - Update man pages

Changes: https://git.openjdk.org/jdk19/pull/103/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=103&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8245268
  Stats: 495 lines in 8 files changed: 437 ins; 16 del; 42 mod
  Patch: https://git.openjdk.org/jdk19/pull/103.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/103/head:pull/103

PR: https://git.openjdk.org/jdk19/pull/103

From kvn at openjdk.org  Sat Jul  2 02:15:46 2022
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Sat, 2 Jul 2022 02:15:46 GMT
Subject: [jdk19] RFR: 8245268: -Xcomp is missing from java launcher
 documentation
In-Reply-To: <FVqMF2apRSRhYmOkhnI2ut8b6iz1BXA1meOfNzU5HQY=.f21b7123-395b-467d-9da0-154102f04398@github.com>
References: <FVqMF2apRSRhYmOkhnI2ut8b6iz1BXA1meOfNzU5HQY=.f21b7123-395b-467d-9da0-154102f04398@github.com>
Message-ID: <GTDdFln5SLvJgul7efyPR3N21byQWhR7frfN4T0J6sY=.5718188f-cf95-40cf-9675-786342527de5@github.com>

On Sat, 2 Jul 2022 01:04:19 GMT, Igor Veresov <iveresov at openjdk.org> wrote:

> Updated man pages from markdown sources.

I am not sure some words changes are correct?

May be we should cleanup and update all these man pages as separate issue. And apply only `-Xcomp` changes.

@iklam
 you recently pushed changes https://github.com/openjdk/jdk/pull/9024 which included only CDS related update.
Did you discuss this issue during your changes review?

src/java.base/share/man/java.1 line 3682:

> 3680: .RS
> 3681: .PP
> 3682: The following examples show how to set the mimimum size of allocated

`mimimum`?

src/java.base/share/man/java.1 line 5367:

> 5365: \f[CB];\f[R]
> 5366: .PP
> 5367: (The names "static" and "dyanmic" are used for historical reasons.

`dyanmic` ?

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

PR: https://git.openjdk.org/jdk19/pull/103

From iveresov at openjdk.org  Sat Jul  2 02:48:47 2022
From: iveresov at openjdk.org (Igor Veresov)
Date: Sat, 2 Jul 2022 02:48:47 GMT
Subject: [jdk19] RFR: 8245268: -Xcomp is missing from java launcher
 documentation
In-Reply-To: <GTDdFln5SLvJgul7efyPR3N21byQWhR7frfN4T0J6sY=.5718188f-cf95-40cf-9675-786342527de5@github.com>
References: <FVqMF2apRSRhYmOkhnI2ut8b6iz1BXA1meOfNzU5HQY=.f21b7123-395b-467d-9da0-154102f04398@github.com>
 <GTDdFln5SLvJgul7efyPR3N21byQWhR7frfN4T0J6sY=.5718188f-cf95-40cf-9675-786342527de5@github.com>
Message-ID: <V-SVt46nBKakekIk5Csju-hajRpTKc0QkpgN_iDuk9g=.cb88ce06-3ade-4f03-8c98-35a3712778a7@github.com>

On Sat, 2 Jul 2022 02:12:43 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> I am not sure some words changes are correct?
> 
> May be we should cleanup and update all these man pages as separate issue. And apply only `-Xcomp` changes.
> 

Then I'd have to manually craft a patch instead of actually generating them. It seems like it's all been out of sync for a long time.

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

PR: https://git.openjdk.org/jdk19/pull/103

From iveresov at openjdk.org  Sat Jul  2 02:48:48 2022
From: iveresov at openjdk.org (Igor Veresov)
Date: Sat, 2 Jul 2022 02:48:48 GMT
Subject: [jdk19] RFR: 8245268: -Xcomp is missing from java launcher
 documentation
In-Reply-To: <FVqMF2apRSRhYmOkhnI2ut8b6iz1BXA1meOfNzU5HQY=.f21b7123-395b-467d-9da0-154102f04398@github.com>
References: <FVqMF2apRSRhYmOkhnI2ut8b6iz1BXA1meOfNzU5HQY=.f21b7123-395b-467d-9da0-154102f04398@github.com>
Message-ID: <3n97bQQ4ib9ogDH_nIP-ivvywhufhTnQR49_SjlHmF4=.f0e23271-724e-404f-80fa-304ba27258a9@github.com>

On Sat, 2 Jul 2022 01:04:19 GMT, Igor Veresov <iveresov at openjdk.org> wrote:

> Updated man pages from markdown sources.

There is also a question of which version is actually correct. Yeah, may be I should manually craft a patch just for the Xcomp part.

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

PR: https://git.openjdk.org/jdk19/pull/103

From iklam at openjdk.org  Sat Jul  2 03:32:26 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Sat, 2 Jul 2022 03:32:26 GMT
Subject: [jdk19] RFR: 8245268: -Xcomp is missing from java launcher
 documentation
In-Reply-To: <3n97bQQ4ib9ogDH_nIP-ivvywhufhTnQR49_SjlHmF4=.f0e23271-724e-404f-80fa-304ba27258a9@github.com>
References: <FVqMF2apRSRhYmOkhnI2ut8b6iz1BXA1meOfNzU5HQY=.f21b7123-395b-467d-9da0-154102f04398@github.com>
 <3n97bQQ4ib9ogDH_nIP-ivvywhufhTnQR49_SjlHmF4=.f0e23271-724e-404f-80fa-304ba27258a9@github.com>
Message-ID: <WweobGTMI6puAW9cxCBHPbieCg3haM9wLj8SWOQfCJQ=.5aa6943f-f5cf-481c-989c-84d9ae2a85a7@github.com>

On Sat, 2 Jul 2022 02:45:43 GMT, Igor Veresov <iveresov at openjdk.org> wrote:

> There is also a question of which version is actually correct. Yeah, may be I should manually craft a patch just for the Xcomp part.

@veresov  please see the closed issue https://bugs.openjdk.org/browse/JDK-8287821

@vnkozlov when I did https://github.com/openjdk/jdk/pull/9024, I generated `java.1` from the `java.md` file. I then use the `meld` program on Linux to revert all changes in the `java.1` file that were unrelated to my changes in `java.md`. Yes, it was a pain.

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

PR: https://git.openjdk.org/jdk19/pull/103

From iveresov at openjdk.org  Sat Jul  2 03:48:27 2022
From: iveresov at openjdk.org (Igor Veresov)
Date: Sat, 2 Jul 2022 03:48:27 GMT
Subject: [jdk19] RFR: 8245268: -Xcomp is missing from java launcher
 documentation [v2]
In-Reply-To: <FVqMF2apRSRhYmOkhnI2ut8b6iz1BXA1meOfNzU5HQY=.f21b7123-395b-467d-9da0-154102f04398@github.com>
References: <FVqMF2apRSRhYmOkhnI2ut8b6iz1BXA1meOfNzU5HQY=.f21b7123-395b-467d-9da0-154102f04398@github.com>
Message-ID: <NCiOFzyET1RX2BY45y_L87Q5JLBwK16Asd9PVw71y2Y=.901afc8c-3c37-4565-9df8-1df67e679e91@github.com>

> Updated man pages from markdown sources.

Igor Veresov has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  Update java manpage

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

Changes:
  - all: https://git.openjdk.org/jdk19/pull/103/files
  - new: https://git.openjdk.org/jdk19/pull/103/files/37da94df..f3526e7b

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

  Stats: 485 lines in 8 files changed: 12 ins; 427 del; 46 mod
  Patch: https://git.openjdk.org/jdk19/pull/103.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/103/head:pull/103

PR: https://git.openjdk.org/jdk19/pull/103

From iveresov at openjdk.org  Sat Jul  2 03:48:27 2022
From: iveresov at openjdk.org (Igor Veresov)
Date: Sat, 2 Jul 2022 03:48:27 GMT
Subject: [jdk19] RFR: 8245268: -Xcomp is missing from java launcher
 documentation
In-Reply-To: <FVqMF2apRSRhYmOkhnI2ut8b6iz1BXA1meOfNzU5HQY=.f21b7123-395b-467d-9da0-154102f04398@github.com>
References: <FVqMF2apRSRhYmOkhnI2ut8b6iz1BXA1meOfNzU5HQY=.f21b7123-395b-467d-9da0-154102f04398@github.com>
Message-ID: <Fp5RB0VOEqsq8oNwxkvU-glRi49RN5Cv3muYPCExG9o=.8470a733-d97e-4db2-8457-26732abdefdf@github.com>

On Sat, 2 Jul 2022 01:04:19 GMT, Igor Veresov <iveresov at openjdk.org> wrote:

> Updated man pages from markdown sources.

Ok, I just hacked a patch file.

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

PR: https://git.openjdk.org/jdk19/pull/103

From vromero at openjdk.org  Wed Jul  6 02:15:15 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 6 Jul 2022 02:15:15 GMT
Subject: RFR: 8268312: Compilation error with nested generic functional
 interface [v3]
In-Reply-To: <DEIO0KG0-b3cxa0iS8U26nknAD4xeM40v_CY9c35rw8=.7c5720dc-1a07-4bee-afca-ade646e4e6cf@github.com>
References: <DEIO0KG0-b3cxa0iS8U26nknAD4xeM40v_CY9c35rw8=.7c5720dc-1a07-4bee-afca-ade646e4e6cf@github.com>
Message-ID: <VPf8jIQsYnBGmktNLkcfT-vqutiv4-h8j8K3Cse8yiY=.51a14f39-9038-41f8-ab76-c274968fc46c@github.com>

> Please review this PR, which is my proposal to fix an existing regression. This code:
> 
> 
> import java.util.Optional;
> 
> class App {
>     public static void main(String[] args) {
>         Optional.of("").map(outer -> {
>             Optional.of("")
>                 .map(inner -> returnGeneric(outer))
>                 .ifPresent(String::toString);
>             return "";
>         });
>     }
> 
>     private static <RG> RG returnGeneric(RG generic) {
>         return generic;
>     }
> }
> 
> is not accepted by javac but if the user passes the `-Xdiags:verbose` option then the code compiles. I tracked down the reason for this puzzling difference and I found that it is due to our diagnostic rewriters which can generate more detailed positions for error messages but in cases like the one above can trick the compiler to generate an error message too early. The code deciding if an error message should be deferred or not, depending on the position, is at `DeferredDiagnosticHandler::report`. We decide to do the rewriting if we are in diagnostics compact mode, this is why the error doesn't occur with the `-Xdiags:verbose` option. This fix will made some diagnostics to appear at a slightly different position, but won't make the compiler reject correct code. Comments?
> 
> TIA

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

  addressing another review iteration

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/5586/files
  - new: https://git.openjdk.org/jdk/pull/5586/files/95a0839a..0b38264e

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

  Stats: 164 lines in 73 files changed: 14 ins; 19 del; 131 mod
  Patch: https://git.openjdk.org/jdk/pull/5586.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/5586/head:pull/5586

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

From jjg at openjdk.org  Wed Jul  6 15:24:53 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 6 Jul 2022 15:24:53 GMT
Subject: RFR: JDK-8288699: cleanup HTML tree in
 HtmlDocletWriter.commentTagsToContent [v2]
In-Reply-To: <F8JJT617lYURezAXXnmWicQ6nvJ4J9zyfBQ8KgCvBY4=.25eb6f0b-5b79-4614-8a7e-383ecbac38b4@github.com>
References: <F8JJT617lYURezAXXnmWicQ6nvJ4J9zyfBQ8KgCvBY4=.25eb6f0b-5b79-4614-8a7e-383ecbac38b4@github.com>
Message-ID: <srXUq61qCFW6p4BrFmFOzmdgQ_k_8jyDjNxYOTBWb3U=.379d709c-43f0-49d5-a0b3-6362da1affd6@github.com>

> Please review a particularly satisfying review of a cleanup for
> `HtmlDocletWriter.commentTagsToContent`, and the use of `RawHtml`.
> 
> The background for this is a separate cleanup for `CommentHelper.getText`,
> during which it was observed that the code could be eliminated, with some
> uses being replaced by `HtmlDocletWriter.commentTagsToContent`. That led
> to more tags being processed, which in turn led to the observation that
> `Content.charCount` was often giving incorrect results.
> 
> The primary root cause of the problem with `Content.charCount` was the
> handling of `StartElementTree` in the visitor in `commentTagsToContent`.
> The problem is that code there creates a sequence of text nodes for the
> attributes, preceded by a `RawHtml` object containing `<TAGNAME` and followed
> by another separate `RawHtml` node containing just `>`.  The net result
> is that `charCount` is mistaken into including the size of the intervening
> text nodes in the total, because it does not recognize the "unbalanced" `<`
> and `>` in the surrounding nodes.
> 
> The general system fix for `commentTagsToContent` is to change the _visit..._
> methods to always append to the `Content` object supplied as a parameter, instead
> of to a fixed local variable (`result`) in the enclosing scope. This allows
> `visitStartElement` to accumulate the attributes in a temporary buffer,
> and then create a single `RawHtml` node as the translation of the
> `StartElementTree`.  Changing the methodology of the visitors also
> required disentangling the processing of `{@docRoot}`, which generally
> always appears inside the `href` attribute, typically followed by
> the rest of the URL. The complication there is that since forever there
> has been special handling of `{@docRoot}/..` which can be replaced by
> the value of the `--docrootparent` option. In reviewing that part of the code,
> it may help to just ignore the old code and just review the new replacement
> code.
> 
> Starting with the code in `commentTagsToContent`, it became worthwhile to
> use factory methods on `RawHtml` for stylized uses of the class, for _start
> element_, _end element_, and _comment_. These all have a `charCount` of zero,
> so it only becomes necessary to compute the character count when given
> arbitrary text.
> 
> Related, the `Text` and `TextBuilder` classes are changed so that they 
> contain unescaped content, and only escape the HTML characters when they
> are written out. This allows their `charCount` to simply return the `length()`
> of the string content, instead of having to parse the content to account
> of any entities that may be present.  This also means that newline characters
> will be counted; previously, they were not.
> 
> Another noteworthy change. Somewhat usually, some resource strings for the
> description of mandated methods, such as for enum and record classes, contain
> simple HTML (`<i>...</i>`), which is modelled in a single `TextTree` and
> subsequently converted to a non-standard use of `RawHtml`. To avoid
> significantly changing the resource strings, the solution is to parse the
> resources into a suitable `List<DocTree>`, using a relatively simple regular
> expression. The goal is to _not_ extend the support any further than that
> provided.
> 
> Finally, one more change/bug fix. We do not claim to support HTML CDATA
> sections, but there is one in the JDK API docs (in `coll-index.html`). 
> It "mostly worked" by accident, but dropped the leading `<`, which "broke"
> the section in the generated output. I've put code into `DocCommentParser`
> to handle CDATA sections, representing them (for now) as a `Text` node
> containing just the section itself. This is then handled specially up in
> `commentTagsToContent`, where it is translated to a new `RawHtml` node.
> 
> For reviewing, I suggest starting with `RawHtml` and then `HtmlDocletWriter`.
> Many of the other changes are derivative changes, such as changing
> `new RawHtml(...)` to `RawHtml.of(...)` and similar other changes.
> 
> All tests continue to pass without change.
> 
> There are minor changes to the generated docs, in two flavors.
> 
> 1. There is one instance, in `Collectors.html`, where the fixes to `charCount`
>    are enough to change the separator after the type parameters in a 
>    method summary table from `&nbsp;` to `<br>`. 
>    See `AbstractMemberWriter` line 207. The current threshold is 10, and
>    some of the methods in `Collectors.html` were less and are now more.
> 
> 2. A number of files use an unescaped `>` in doc comments. These are now
>    translated to `&gt;` in the output.  The change in behavior is because of
>    changing to use `html.Text` nodes instead of `html.RawHtml` nodes to represent
>    user-provided text in `TextTree` nodes.
>    Previously, the generated output was inconsistent in this area: most
>    instances used `&gt;`, but user-provided `>` was passed through.
>    Now, the output is consistent. 
>    FWIW, `tidy` prefers the use of `&gt;` as well.

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

 - Add missing resource and example of use
   Fix Text and TextBuilder for Windows newlines
 - Merge remote-tracking branch 'upstream/master' into 8288699.commentTagsToContent
 - JDK-8288699: cleanup HTML tree in HtmlDocletWriter.commentTagsToContent

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9210/files
  - new: https://git.openjdk.org/jdk/pull/9210/files/0dd59c3b..c3128804

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

  Stats: 62001 lines in 1171 files changed: 37626 ins; 11766 del; 12609 mod
  Patch: https://git.openjdk.org/jdk/pull/9210.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9210/head:pull/9210

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

From jjg at openjdk.org  Wed Jul  6 18:06:21 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 6 Jul 2022 18:06:21 GMT
Subject: RFR: JDK-6251738: Want a top-level summary page that itemizes all
 spec documents referenced from javadocs (OEM spec) [v11]
In-Reply-To: <PeZ8g98tWBwjtt6lW6Wy2BYbYPD_CvBRnZ5Onwv-FBM=.6a5b9416-4306-4df8-ad89-08424ff1dd08@github.com>
References: <PeZ8g98tWBwjtt6lW6Wy2BYbYPD_CvBRnZ5Onwv-FBM=.6a5b9416-4306-4df8-ad89-08424ff1dd08@github.com>
Message-ID: <nhjCupiP5v5Kz_SHSneeorwgyphaBDPl_SosPUN6_og=.30d2e83a-5649-4b0e-97fc-0d665ef98051@github.com>

> Please review the code and tests to add support for a new `@spec url title` tag to javadoc.  Note, this does not include any changes to API doc comments to use the new tag in JDK API documentation; that will come later.

Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:

 - Update @since tags
 - Merge remote-tracking branch 'upstream/master' into 6251738.spec-tag-2
 - Merge remote-tracking branch 'upstream/master' into 6251738.spec-tag-2
 - Updates for latest repo
 - Merge remote-tracking branch 'upstream/master' into 6251738.spec-tag-2
 - Merge remote-tracking branch 'upstream/master' into 6251738.spec-tag-2
 - Merge with upstream/master
 - fix copyright dates
   remove archaic obsolete build flags
 - more URI -> URL
 - address review feedback
 - ... and 7 more: https://git.openjdk.org/jdk/compare/9f37ba44...f0ce1937

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

Changes: https://git.openjdk.org/jdk/pull/8439/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=8439&range=10
  Stats: 1501 lines in 41 files changed: 1473 ins; 6 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/8439.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/8439/head:pull/8439

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

From vromero at openjdk.org  Wed Jul  6 02:53:36 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 6 Jul 2022 02:53:36 GMT
Subject: RFR: 8268312: Compilation error with nested generic functional
 interface [v4]
In-Reply-To: <DEIO0KG0-b3cxa0iS8U26nknAD4xeM40v_CY9c35rw8=.7c5720dc-1a07-4bee-afca-ade646e4e6cf@github.com>
References: <DEIO0KG0-b3cxa0iS8U26nknAD4xeM40v_CY9c35rw8=.7c5720dc-1a07-4bee-afca-ade646e4e6cf@github.com>
Message-ID: <V2M4K6czff1GAAofT4Q9m5LlDz8pJIYVKTorBSyDnHc=.2926fc7d-9333-4994-aa1b-455110594e3c@github.com>

> Please review this PR, which is my proposal to fix an existing regression. This code:
> 
> 
> import java.util.Optional;
> 
> class App {
>     public static void main(String[] args) {
>         Optional.of("").map(outer -> {
>             Optional.of("")
>                 .map(inner -> returnGeneric(outer))
>                 .ifPresent(String::toString);
>             return "";
>         });
>     }
> 
>     private static <RG> RG returnGeneric(RG generic) {
>         return generic;
>     }
> }
> 
> is not accepted by javac but if the user passes the `-Xdiags:verbose` option then the code compiles. I tracked down the reason for this puzzling difference and I found that it is due to our diagnostic rewriters which can generate more detailed positions for error messages but in cases like the one above can trick the compiler to generate an error message too early. The code deciding if an error message should be deferred or not, depending on the position, is at `DeferredDiagnosticHandler::report`. We decide to do the rewriting if we are in diagnostics compact mode, this is why the error doesn't occur with the `-Xdiags:verbose` option. This fix will made some diagnostics to appear at a slightly different position, but won't make the compiler reject correct code. Comments?
> 
> TIA

Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:

 - Merge master
 - addressing another review iteration
 - addressing review comments
 - 8268312: Compilation error with nested generic functional interface

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

Changes: https://git.openjdk.org/jdk/pull/5586/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=5586&range=03
  Stats: 327 lines in 81 files changed: 114 ins; 88 del; 125 mod
  Patch: https://git.openjdk.org/jdk/pull/5586.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/5586/head:pull/5586

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

From jlahoda at openjdk.org  Thu Jul  7 08:10:29 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 7 Jul 2022 08:10:29 GMT
Subject: RFR: 8269674: Improve testing of parenthesized patterns
In-Reply-To: <CKhyND9xcF1C457WSOvoxO6ne0PbX1Nb5v9s0rYivkM=.14ffb35a-db79-4272-bc36-fd6f9f924303@github.com>
References: <CKhyND9xcF1C457WSOvoxO6ne0PbX1Nb5v9s0rYivkM=.14ffb35a-db79-4272-bc36-fd6f9f924303@github.com>
Message-ID: <VcVMx6Fl5LP47yuhMPccF7JMjIvgStqX5F7zpw2JnDE=.4a1770b4-0620-4f85-b2ed-6c2269560add@github.com>

On Fri, 1 Jul 2022 08:46:58 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> Introduces a combo test (compile-time) for parenthesized patterns. Subsumes `test/langtools/tools/javac/patterns/Parenthesized.java` (can be safely deleted, if yes, I can port the comment section with the bug ids). 
> 
> Bugs addressed:
> - `case (StringBox(String s1))` raised a parse error

Looks good to me!

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

Marked as reviewed by jlahoda (Reviewer).

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

From jlahoda at openjdk.org  Thu Jul  7 07:58:29 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 7 Jul 2022 07:58:29 GMT
Subject: [jdk19] Integrated: 8289196: Pattern domination not working properly
 for record patterns
In-Reply-To: <SCvRtNylRkbz01mGAjf0YqXyzYz7txFSqZShcnEb118=.87da4559-1346-4d56-b4f0-984ef3732d58@github.com>
References: <SCvRtNylRkbz01mGAjf0YqXyzYz7txFSqZShcnEb118=.87da4559-1346-4d56-b4f0-984ef3732d58@github.com>
Message-ID: <7RnLSq8QZep4u9KViwnvV2a_pRWq0kb9llw3HZn_36k=.5711a641-c620-4d81-8e37-a3e0a8c9ddb5@github.com>

On Tue, 28 Jun 2022 13:11:25 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> When checking that a pattern in a switch case is not dominated by a preceding pattern, handling for record pattern is mostly missing. This patch is attempting to fix that, and as it requires a bit more code, it moves the check into `Check`.

This pull request has now been integrated.

Changeset: 8dd94a2c
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk19/commit/8dd94a2c14f7456b3eaf3e02f38d9e114eb8acc3
Stats:     197 lines in 5 files changed: 169 ins; 21 del; 7 mod

8289196: Pattern domination not working properly for record patterns

Reviewed-by: vromero

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

PR: https://git.openjdk.org/jdk19/pull/84

From jlahoda at openjdk.org  Thu Jul  7 07:28:49 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 7 Jul 2022 07:28:49 GMT
Subject: [jdk19] RFR: 8289196: Patttern domination not working property for
 record patterns [v3]
In-Reply-To: <SCvRtNylRkbz01mGAjf0YqXyzYz7txFSqZShcnEb118=.87da4559-1346-4d56-b4f0-984ef3732d58@github.com>
References: <SCvRtNylRkbz01mGAjf0YqXyzYz7txFSqZShcnEb118=.87da4559-1346-4d56-b4f0-984ef3732d58@github.com>
Message-ID: <JLCSw0EM6EBFD6VOe_q6Io9LELE4Sv_3oTb-LIosa64=.ab58c697-c69e-4322-801d-6daaeaad17ab@github.com>

> When checking that a pattern in a switch case is not dominated by a preceding pattern, handling for record pattern is mostly missing. This patch is attempting to fix that, and as it requires a bit more code, it moves the check into `Check`.

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

  Simplifying primitive pattern handling as suggested

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

Changes:
  - all: https://git.openjdk.org/jdk19/pull/84/files
  - new: https://git.openjdk.org/jdk19/pull/84/files/220fcc12..bf740ed1

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

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

PR: https://git.openjdk.org/jdk19/pull/84

From vromero at openjdk.org  Wed Jul  6 02:53:39 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 6 Jul 2022 02:53:39 GMT
Subject: RFR: 8268312: Compilation error with nested generic functional
 interface [v3]
In-Reply-To: <VPf8jIQsYnBGmktNLkcfT-vqutiv4-h8j8K3Cse8yiY=.51a14f39-9038-41f8-ab76-c274968fc46c@github.com>
References: <DEIO0KG0-b3cxa0iS8U26nknAD4xeM40v_CY9c35rw8=.7c5720dc-1a07-4bee-afca-ade646e4e6cf@github.com>
 <VPf8jIQsYnBGmktNLkcfT-vqutiv4-h8j8K3Cse8yiY=.51a14f39-9038-41f8-ab76-c274968fc46c@github.com>
Message-ID: <FOTIVbMJCM9hezPsGUPt1xYzt85nS06JcAKYoFiY_SE=.fed68359-55f9-40e8-b5b9-ad383888149b@github.com>

On Wed, 6 Jul 2022 02:15:15 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Please review this PR, which is my proposal to fix an existing regression. This code:
>> 
>> 
>> import java.util.Optional;
>> 
>> class App {
>>     public static void main(String[] args) {
>>         Optional.of("").map(outer -> {
>>             Optional.of("")
>>                 .map(inner -> returnGeneric(outer))
>>                 .ifPresent(String::toString);
>>             return "";
>>         });
>>     }
>> 
>>     private static <RG> RG returnGeneric(RG generic) {
>>         return generic;
>>     }
>> }
>> 
>> is not accepted by javac but if the user passes the `-Xdiags:verbose` option then the code compiles. I tracked down the reason for this puzzling difference and I found that it is due to our diagnostic rewriters which can generate more detailed positions for error messages but in cases like the one above can trick the compiler to generate an error message too early. The code deciding if an error message should be deferred or not, depending on the position, is at `DeferredDiagnosticHandler::report`. We decide to do the rewriting if we are in diagnostics compact mode, this is why the error doesn't occur with the `-Xdiags:verbose` option. This fix will made some diagnostics to appear at a slightly different position, but won't make the compiler reject correct code. Comments?
>> 
>> TIA
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   addressing another review iteration

another stab at this one

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

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

From mcimadamore at openjdk.org  Thu Jul  7 10:09:46 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 7 Jul 2022 10:09:46 GMT
Subject: RFR: 8268312: Compilation error with nested generic functional
 interface [v4]
In-Reply-To: <V2M4K6czff1GAAofT4Q9m5LlDz8pJIYVKTorBSyDnHc=.2926fc7d-9333-4994-aa1b-455110594e3c@github.com>
References: <DEIO0KG0-b3cxa0iS8U26nknAD4xeM40v_CY9c35rw8=.7c5720dc-1a07-4bee-afca-ade646e4e6cf@github.com>
 <V2M4K6czff1GAAofT4Q9m5LlDz8pJIYVKTorBSyDnHc=.2926fc7d-9333-4994-aa1b-455110594e3c@github.com>
Message-ID: <UfInB4YOlQ-cZyrihmjKjJTW4OUQ8K1y8nIFc5TVv8Q=.e208b866-bfdf-410a-87d1-620003b7066c@github.com>

On Wed, 6 Jul 2022 02:53:36 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Please review this PR, which is my proposal to fix an existing regression. This code:
>> 
>> 
>> import java.util.Optional;
>> 
>> class App {
>>     public static void main(String[] args) {
>>         Optional.of("").map(outer -> {
>>             Optional.of("")
>>                 .map(inner -> returnGeneric(outer))
>>                 .ifPresent(String::toString);
>>             return "";
>>         });
>>     }
>> 
>>     private static <RG> RG returnGeneric(RG generic) {
>>         return generic;
>>     }
>> }
>> 
>> is not accepted by javac but if the user passes the `-Xdiags:verbose` option then the code compiles. I tracked down the reason for this puzzling difference and I found that it is due to our diagnostic rewriters which can generate more detailed positions for error messages but in cases like the one above can trick the compiler to generate an error message too early. The code deciding if an error message should be deferred or not, depending on the position, is at `DeferredDiagnosticHandler::report`. We decide to do the rewriting if we are in diagnostics compact mode, this is why the error doesn't occur with the `-Xdiags:verbose` option. This fix will made some diagnostics to appear at a slightly different position, but won't make the compiler reject correct code. Comments?
>> 
>> TIA
>
> Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
> 
>  - Merge master
>  - addressing another review iteration
>  - addressing review comments
>  - 8268312: Compilation error with nested generic functional interface

A good step forward. I think the removal of the flag to optionally leave diagnostics uncompressed caused more changes than required - there's several changes to the raw diagnostic output that I was not expecting; ideally this patch should not change the behavior of compiler diagnostic, but should just make the current rewriting machinery work better with the speculative attribution machinery.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java line 4181:

> 4179:             return diags.create(dkind, log.currentSource(), pos,
> 4180:                       "cant.apply.symbol",
> 4181:                       d -> MethodResolutionDiagHelper.rewrite(diags, pos, log.currentSource(), dkind, c.snd),

This is a good step in the right direction - e.g. attaching a rewriting function to the diagnostic object itself. I wonder if a simpler solution is possible, as I note here that the call to `rewrite` is basically just passing info that are attached to the diagnostic being created _plus_ `c.snd` which is the real new bit of info.

E.g. in principle, we could just create the new diagnostic with a "cause" (e.g. `c.snd`) and then, when we're about to report the diagnostic, we check if there's a cause set and, if so, we try to late-rewrite the diagnostic. If we do this, perhaps we might be able to avoid the creation of a new instance in a very hot path.

src/jdk.compiler/share/classes/com/sun/tools/javac/util/Log.java line 220:

> 218:      * Set to true if a compressed diagnostic is reported
> 219:      */
> 220:     public boolean compressedOutput;

I see that this patch drops the option for compressing diagnostic - this seems to go a step too far, and I'm not sure this is what we want, at least in this patch. I believe there's an orthogonal discussion to be had there. I think the flag should stay as is for now (and  control  whether diagnostics should be rewritten at all in Log).

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

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

From mcimadamore at openjdk.org  Thu Jul  7 10:09:48 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 7 Jul 2022 10:09:48 GMT
Subject: RFR: 8268312: Compilation error with nested generic functional
 interface [v4]
In-Reply-To: <UfInB4YOlQ-cZyrihmjKjJTW4OUQ8K1y8nIFc5TVv8Q=.e208b866-bfdf-410a-87d1-620003b7066c@github.com>
References: <DEIO0KG0-b3cxa0iS8U26nknAD4xeM40v_CY9c35rw8=.7c5720dc-1a07-4bee-afca-ade646e4e6cf@github.com>
 <V2M4K6czff1GAAofT4Q9m5LlDz8pJIYVKTorBSyDnHc=.2926fc7d-9333-4994-aa1b-455110594e3c@github.com>
 <UfInB4YOlQ-cZyrihmjKjJTW4OUQ8K1y8nIFc5TVv8Q=.e208b866-bfdf-410a-87d1-620003b7066c@github.com>
Message-ID: <SA5cJYuXvumdmbqQLbqfzyHJc1YdP5DC9gWkMM8UwHY=.acb07776-9835-40f2-8e87-384fd5886bcd@github.com>

On Thu, 7 Jul 2022 09:56:58 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
>> 
>>  - Merge master
>>  - addressing another review iteration
>>  - addressing review comments
>>  - 8268312: Compilation error with nested generic functional interface
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java line 4181:
> 
>> 4179:             return diags.create(dkind, log.currentSource(), pos,
>> 4180:                       "cant.apply.symbol",
>> 4181:                       d -> MethodResolutionDiagHelper.rewrite(diags, pos, log.currentSource(), dkind, c.snd),
> 
> This is a good step in the right direction - e.g. attaching a rewriting function to the diagnostic object itself. I wonder if a simpler solution is possible, as I note here that the call to `rewrite` is basically just passing info that are attached to the diagnostic being created _plus_ `c.snd` which is the real new bit of info.
> 
> E.g. in principle, we could just create the new diagnostic with a "cause" (e.g. `c.snd`) and then, when we're about to report the diagnostic, we check if there's a cause set and, if so, we try to late-rewrite the diagnostic. If we do this, perhaps we might be able to avoid the creation of a new instance in a very hot path.

I would also check for other usages of the rewriter framework and make sure they follow the same pattern - right now we have some diagnostics using the late-bound reporting mechanism (such as this), and others (e.g. diamond, but possibly other inference ones as well) which rewrite the diagnostic eagerly. We should try to have only one way to do things. My feeling is that diagnostic rewriting should be a general mechanism, not something that belongs in Resolve (but perhaps closer to Log).

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

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

From vromero at openjdk.org  Thu Jul  7 19:56:22 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 7 Jul 2022 19:56:22 GMT
Subject: RFR: 8282714: synthetic arguments are being added to the constructors
 of static local classes
Message-ID: <Fn_Lx2J56RrcnFrWYqEoyrmE_nmq-cBdrKmdyFrsBak=.be72dbce-8598-4f6b-bad6-d8b534510bc6@github.com>

Constructors of local records and enums are being added free variables by the compiler same as it is done for local non-static classes. This is against the spec and should be fixed,

TIA

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

Commit messages:
 - removing whitespace
 - additional regression tests
 - Merge branch 'JDK-8282714' of https://github.com/vicente-romero-oracle/jdk into JDK-8282714
 - 8282714: synthetic arguments are being added to the constructors of static local classes
 - 8282714: synthetic arguments are being added to the constructors of static local classes

Changes: https://git.openjdk.org/jdk/pull/9412/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9412&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8282714
  Stats: 126 lines in 4 files changed: 107 ins; 1 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/9412.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9412/head:pull/9412

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

From jlahoda at openjdk.org  Thu Jul  7 14:55:13 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 7 Jul 2022 14:55:13 GMT
Subject: [jdk19] RFR: JDK-8289894: A NullPointerException thrown from guard
 expression
Message-ID: <vGZNqhAgf86RAmf0NBcambVLUCoqomYH3Nv_I6QViwE=.edf258f4-7af5-4184-82f1-5e63498f80c3@github.com>

Consider the following code:

public class SwitchGuard {
    public static void main(String... args) {
        test(null);
    }
    private static void test(Object o) {
        switch (o) {
            case null, String s when s.isEmpty() -> System.err.println("OK.");
            default -> {}
        }
    }
}


In the current specification, the guard should not be invoked when `o` is `null`, but javac will invoke it, for historical reasons.

Also, as opposed to JDK 18/JEP 420, `case null, <pattern>` is allowed for parenthesized pattern when the parenthesized pattern encloses (directly or via other parenthesized patterns) a type pattern.

The patch proposed here strives to fix both of these problems.

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

Commit messages:
 - JDK-8289894: A NullPointerException thrown from guard expression

Changes: https://git.openjdk.org/jdk19/pull/120/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=120&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8289894
  Stats: 69 lines in 6 files changed: 55 ins; 0 del; 14 mod
  Patch: https://git.openjdk.org/jdk19/pull/120.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/120/head:pull/120

PR: https://git.openjdk.org/jdk19/pull/120

From jjg at openjdk.org  Thu Jul  7 22:32:47 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 7 Jul 2022 22:32:47 GMT
Subject: RFR: JDK-8288699: cleanup HTML tree in
 HtmlDocletWriter.commentTagsToContent [v2]
In-Reply-To: <TLBJueclKnaayXDUMftTLt7oa4QJvzfaeDBVukXWwnI=.518c69f4-05a6-475b-ab31-4af22a821d5f@github.com>
References: <F8JJT617lYURezAXXnmWicQ6nvJ4J9zyfBQ8KgCvBY4=.25eb6f0b-5b79-4614-8a7e-383ecbac38b4@github.com>
 <TLBJueclKnaayXDUMftTLt7oa4QJvzfaeDBVukXWwnI=.518c69f4-05a6-475b-ab31-4af22a821d5f@github.com>
Message-ID: <Ykd2xglczR6lHpiCRbdD5LCw43aVNOIj51JSgH2fGXE=.35885fcf-f657-4a53-901d-c38499c0384e@github.com>

On Tue, 28 Jun 2022 16:11:10 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
>> 
>>  - Add missing resource and example of use
>>    Fix Text and TextBuilder for Windows newlines
>>  - Merge remote-tracking branch 'upstream/master' into 8288699.commentTagsToContent
>>  - JDK-8288699: cleanup HTML tree in HtmlDocletWriter.commentTagsToContent
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java line 1555:
> 
>> 1553:                             pendingDocRoot.accept(this, content);
>> 1554:                             pendingDocRoot = null;
>> 1555:                             first = false;
> 
> first is already false here and a few lines above since pendingDocRoot assignment below is followed by a `first = false` assignment.

Yes, I think I agree. `first` is only used if the first child of the attribute value is text, in which case we call `redirectRelativeLinks`.

`pendingDocRoot` is a separate flag for saying we have encountered but not yet fully processed `{@docRoot}` until we can see if it is followed by `/..`

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

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

From jwilhelm at openjdk.org  Thu Jul  7 22:27:22 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Thu, 7 Jul 2022 22:27:22 GMT
Subject: RFR: Merge jdk19 [v2]
In-Reply-To: <-KkCuVSAMiTg4BocRz3OwWxTQ7_0TIjXqqGQ4OicoOg=.c4255a3a-29b0-4fb5-9334-fe694249ad44@github.com>
References: <-KkCuVSAMiTg4BocRz3OwWxTQ7_0TIjXqqGQ4OicoOg=.c4255a3a-29b0-4fb5-9334-fe694249ad44@github.com>
Message-ID: <2HegrqiJuBLT64CHm3G3bNnBtYc0U07ECeoRV1pKbWA=.3c35644c-6a60-48fe-b0cc-d0e41c0c9ee1@github.com>

> Forwardport JDK 19 -> JDK 20

Jesper Wilhelmsson has updated the pull request incrementally with one additional commit since the last revision:

  Fix merge error

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9415/files
  - new: https://git.openjdk.org/jdk/pull/9415/files/0f86db4f..c6949b8f

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

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

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

From jwilhelm at openjdk.org  Fri Jul  8 02:11:29 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Fri, 8 Jul 2022 02:11:29 GMT
Subject: Integrated: Merge jdk19
In-Reply-To: <Qj_ooIea2dltOPOMHVXtoujGH_BkbT5wM9Nz64udrKw=.71974be9-0f2b-4f9c-8155-6622fde7735b@github.com>
References: <Qj_ooIea2dltOPOMHVXtoujGH_BkbT5wM9Nz64udrKw=.71974be9-0f2b-4f9c-8155-6622fde7735b@github.com>
Message-ID: <xTzueqoYMFmxnqfk055ZhkE-OLB1C_diEVhLpRvC7iY=.5bb68c91-e0d4-4ebe-8892-b38510511c22@github.com>

On Thu, 7 Jul 2022 22:31:27 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 19 -> JDK 20

This pull request has now been integrated.

Changeset: 01b9f95c
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/01b9f95c62953e7f9ca10eafd42d21c634413827
Stats:     807 lines in 28 files changed: 669 ins; 52 del; 86 mod

Merge

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

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

From jwilhelm at openjdk.org  Thu Jul  7 22:29:42 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Thu, 7 Jul 2022 22:29:42 GMT
Subject: Withdrawn: Merge jdk19
In-Reply-To: <-KkCuVSAMiTg4BocRz3OwWxTQ7_0TIjXqqGQ4OicoOg=.c4255a3a-29b0-4fb5-9334-fe694249ad44@github.com>
References: <-KkCuVSAMiTg4BocRz3OwWxTQ7_0TIjXqqGQ4OicoOg=.c4255a3a-29b0-4fb5-9334-fe694249ad44@github.com>
Message-ID: <FQIceUcG-7y5qjJZVLfhHOfx_x1QeZu2TwzQSzuNZWw=.adbba13e-adb1-4cf4-acee-d77ed37624cc@github.com>

On Thu, 7 Jul 2022 20:14:12 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 19 -> JDK 20

This pull request has been closed without being integrated.

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

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

From jwilhelm at openjdk.org  Thu Jul  7 22:40:28 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Thu, 7 Jul 2022 22:40:28 GMT
Subject: RFR: Merge jdk19
Message-ID: <Qj_ooIea2dltOPOMHVXtoujGH_BkbT5wM9Nz64udrKw=.71974be9-0f2b-4f9c-8155-6622fde7735b@github.com>

Forwardport JDK 19 -> JDK 20

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

Commit messages:
 - Merge
 - 8289486: Improve XSLT XPath operators count efficiency
 - 8289779: Map::replaceAll javadoc has redundant @throws clauses
 - 8289558: Need spec clarification of j.l.foreign.*Layout
 - 8289196: Pattern domination not working properly for record patterns
 - 6509045: {@inheritDoc} only copies one instance of the specified exception
 - 8288949: serviceability/jvmti/vthread/ContStackDepthTest/ContStackDepthTest.java failing
 - 8289857: ProblemList jdk/jfr/event/runtime/TestActiveSettingEvent.java
 - 8289840: ProblemList vmTestbase/nsk/jdwp/ThreadReference/ForceEarlyReturn/forceEarlyReturn002/forceEarlyReturn002.java when run with vthread wrapper
 - 8289841: ProblemList vmTestbase/gc/gctests/MemoryEaterMT/MemoryEaterMT.java with ZGC on windows

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.org/?repo=jdk&pr=9419&range=00.0
 - jdk19: https://webrevs.openjdk.org/?repo=jdk&pr=9419&range=00.1

Changes: https://git.openjdk.org/jdk/pull/9419/files
  Stats: 807 lines in 28 files changed: 669 ins; 52 del; 86 mod
  Patch: https://git.openjdk.org/jdk/pull/9419.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9419/head:pull/9419

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

From jjg at openjdk.org  Thu Jul  7 22:22:43 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 7 Jul 2022 22:22:43 GMT
Subject: RFR: JDK-8288699: cleanup HTML tree in
 HtmlDocletWriter.commentTagsToContent [v2]
In-Reply-To: <TLBJueclKnaayXDUMftTLt7oa4QJvzfaeDBVukXWwnI=.518c69f4-05a6-475b-ab31-4af22a821d5f@github.com>
References: <F8JJT617lYURezAXXnmWicQ6nvJ4J9zyfBQ8KgCvBY4=.25eb6f0b-5b79-4614-8a7e-383ecbac38b4@github.com>
 <TLBJueclKnaayXDUMftTLt7oa4QJvzfaeDBVukXWwnI=.518c69f4-05a6-475b-ab31-4af22a821d5f@github.com>
Message-ID: <qvwG2t90jUzz_qU6N7ZkQ8vqudr4zCsElgBnxUjdCa0=.2291320f-80e0-48fa-9141-c9892720bec6@github.com>

On Tue, 28 Jun 2022 16:04:30 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
>> 
>>  - Add missing resource and example of use
>>    Fix Text and TextBuilder for Windows newlines
>>  - Merge remote-tracking branch 'upstream/master' into 8288699.commentTagsToContent
>>  - JDK-8288699: cleanup HTML tree in HtmlDocletWriter.commentTagsToContent
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java line 1558:
> 
>> 1556:                         }
>> 1557: 
>> 1558:                         if (dt instanceof TextTree tt){
> 
> Missing space before curly bracket.

fixed

> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java line 1561:
> 
>> 1559:                             String text = tt.getBody();
>> 1560:                             if (first && isHRef) {
>> 1561:                                 text = redirectRelativeLinks(element, (TextTree) dt);
> 
> Could use tt instead of casting again.

definitely; done

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

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

From jwilhelm at openjdk.org  Thu Jul  7 20:22:53 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Thu, 7 Jul 2022 20:22:53 GMT
Subject: RFR: Merge jdk19
Message-ID: <-KkCuVSAMiTg4BocRz3OwWxTQ7_0TIjXqqGQ4OicoOg=.c4255a3a-29b0-4fb5-9334-fe694249ad44@github.com>

Forwardport JDK 19 -> JDK 20

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

Commit messages:
 - Merge
 - 8289486: Improve XSLT XPath operators count efficiency
 - 8289779: Map::replaceAll javadoc has redundant @throws clauses
 - 8289558: Need spec clarification of j.l.foreign.*Layout
 - 8289196: Pattern domination not working properly for record patterns
 - 6509045: {@inheritDoc} only copies one instance of the specified exception
 - 8288949: serviceability/jvmti/vthread/ContStackDepthTest/ContStackDepthTest.java failing
 - 8289857: ProblemList jdk/jfr/event/runtime/TestActiveSettingEvent.java
 - 8289840: ProblemList vmTestbase/nsk/jdwp/ThreadReference/ForceEarlyReturn/forceEarlyReturn002/forceEarlyReturn002.java when run with vthread wrapper
 - 8289841: ProblemList vmTestbase/gc/gctests/MemoryEaterMT/MemoryEaterMT.java with ZGC on windows

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.org/?repo=jdk&pr=9415&range=00.0
 - jdk19: https://webrevs.openjdk.org/?repo=jdk&pr=9415&range=00.1

Changes: https://git.openjdk.org/jdk/pull/9415/files
  Stats: 803 lines in 28 files changed: 669 ins; 48 del; 86 mod
  Patch: https://git.openjdk.org/jdk/pull/9415.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9415/head:pull/9415

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

From hannesw at openjdk.org  Fri Jul  8 09:56:49 2022
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Fri, 8 Jul 2022 09:56:49 GMT
Subject: RFR: JDK-8288699: cleanup HTML tree in
 HtmlDocletWriter.commentTagsToContent [v2]
In-Reply-To: <srXUq61qCFW6p4BrFmFOzmdgQ_k_8jyDjNxYOTBWb3U=.379d709c-43f0-49d5-a0b3-6362da1affd6@github.com>
References: <F8JJT617lYURezAXXnmWicQ6nvJ4J9zyfBQ8KgCvBY4=.25eb6f0b-5b79-4614-8a7e-383ecbac38b4@github.com>
 <srXUq61qCFW6p4BrFmFOzmdgQ_k_8jyDjNxYOTBWb3U=.379d709c-43f0-49d5-a0b3-6362da1affd6@github.com>
Message-ID: <LFcub4gLChZH6rNWCq7LQPzmQIVpk56NpQfP99X62Vs=.16d47217-1b2a-4af2-b0c5-f741f35b2d78@github.com>

On Wed, 6 Jul 2022 15:24:53 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a particularly satisfying review of a cleanup for
>> `HtmlDocletWriter.commentTagsToContent`, and the use of `RawHtml`.
>> 
>> The background for this is a separate cleanup for `CommentHelper.getText`,
>> during which it was observed that the code could be eliminated, with some
>> uses being replaced by `HtmlDocletWriter.commentTagsToContent`. That led
>> to more tags being processed, which in turn led to the observation that
>> `Content.charCount` was often giving incorrect results.
>> 
>> The primary root cause of the problem with `Content.charCount` was the
>> handling of `StartElementTree` in the visitor in `commentTagsToContent`.
>> The problem is that code there creates a sequence of text nodes for the
>> attributes, preceded by a `RawHtml` object containing `<TAGNAME` and followed
>> by another separate `RawHtml` node containing just `>`.  The net result
>> is that `charCount` is mistaken into including the size of the intervening
>> text nodes in the total, because it does not recognize the "unbalanced" `<`
>> and `>` in the surrounding nodes.
>> 
>> The general system fix for `commentTagsToContent` is to change the _visit..._
>> methods to always append to the `Content` object supplied as a parameter, instead
>> of to a fixed local variable (`result`) in the enclosing scope. This allows
>> `visitStartElement` to accumulate the attributes in a temporary buffer,
>> and then create a single `RawHtml` node as the translation of the
>> `StartElementTree`.  Changing the methodology of the visitors also
>> required disentangling the processing of `{@docRoot}`, which generally
>> always appears inside the `href` attribute, typically followed by
>> the rest of the URL. The complication there is that since forever there
>> has been special handling of `{@docRoot}/..` which can be replaced by
>> the value of the `--docrootparent` option. In reviewing that part of the code,
>> it may help to just ignore the old code and just review the new replacement
>> code.
>> 
>> Starting with the code in `commentTagsToContent`, it became worthwhile to
>> use factory methods on `RawHtml` for stylized uses of the class, for _start
>> element_, _end element_, and _comment_. These all have a `charCount` of zero,
>> so it only becomes necessary to compute the character count when given
>> arbitrary text.
>> 
>> Related, the `Text` and `TextBuilder` classes are changed so that they 
>> contain unescaped content, and only escape the HTML characters when they
>> are written out. This allows their `charCount` to simply return the `length()`
>> of the string content, instead of having to parse the content to account
>> of any entities that may be present.  This also means that newline characters
>> will be counted; previously, they were not.
>> 
>> Another noteworthy change. Somewhat usually, some resource strings for the
>> description of mandated methods, such as for enum and record classes, contain
>> simple HTML (`<i>...</i>`), which is modelled in a single `TextTree` and
>> subsequently converted to a non-standard use of `RawHtml`. To avoid
>> significantly changing the resource strings, the solution is to parse the
>> resources into a suitable `List<DocTree>`, using a relatively simple regular
>> expression. The goal is to _not_ extend the support any further than that
>> provided.
>> 
>> Finally, one more change/bug fix. We do not claim to support HTML CDATA
>> sections, but there is one in the JDK API docs (in `coll-index.html`). 
>> It "mostly worked" by accident, but dropped the leading `<`, which "broke"
>> the section in the generated output. I've put code into `DocCommentParser`
>> to handle CDATA sections, representing them (for now) as a `Text` node
>> containing just the section itself. This is then handled specially up in
>> `commentTagsToContent`, where it is translated to a new `RawHtml` node.
>> 
>> For reviewing, I suggest starting with `RawHtml` and then `HtmlDocletWriter`.
>> Many of the other changes are derivative changes, such as changing
>> `new RawHtml(...)` to `RawHtml.of(...)` and similar other changes.
>> 
>> All tests continue to pass without change.
>> 
>> There are minor changes to the generated docs, in two flavors.
>> 
>> 1. There is one instance, in `Collectors.html`, where the fixes to `charCount`
>>    are enough to change the separator after the type parameters in a 
>>    method summary table from `&nbsp;` to `<br>`. 
>>    See `AbstractMemberWriter` line 207. The current threshold is 10, and
>>    some of the methods in `Collectors.html` were less and are now more.
>> 
>> 2. A number of files use an unescaped `>` in doc comments. These are now
>>    translated to `&gt;` in the output.  The change in behavior is because of
>>    changing to use `html.Text` nodes instead of `html.RawHtml` nodes to represent
>>    user-provided text in `TextTree` nodes.
>>    Previously, the generated output was inconsistent in this area: most
>>    instances used `&gt;`, but user-provided `>` was passed through.
>>    Now, the output is consistent. 
>>    FWIW, `tidy` prefers the use of `&gt;` as well.
>
> Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Add missing resource and example of use
>    Fix Text and TextBuilder for Windows newlines
>  - Merge remote-tracking branch 'upstream/master' into 8288699.commentTagsToContent
>  - JDK-8288699: cleanup HTML tree in HtmlDocletWriter.commentTagsToContent

The changes in the additional commit c312880 look good to me.

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

Marked as reviewed by hannesw (Reviewer).

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

From abimpoudis at openjdk.org  Fri Jul  8 12:17:27 2022
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Fri, 8 Jul 2022 12:17:27 GMT
Subject: [jdk19] RFR: JDK-8289894: A NullPointerException thrown from guard
 expression
In-Reply-To: <vGZNqhAgf86RAmf0NBcambVLUCoqomYH3Nv_I6QViwE=.edf258f4-7af5-4184-82f1-5e63498f80c3@github.com>
References: <vGZNqhAgf86RAmf0NBcambVLUCoqomYH3Nv_I6QViwE=.edf258f4-7af5-4184-82f1-5e63498f80c3@github.com>
Message-ID: <xxaJ_4atSYnlfwNuMhBLJbkoXAv4Se_lk2zdB6FCL-o=.dab8f279-2662-4435-a038-22046da7ff7f@github.com>

On Thu, 7 Jul 2022 14:48:09 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider the following code:
> 
> public class SwitchGuard {
>     public static void main(String... args) {
>         test(null);
>     }
>     private static void test(Object o) {
>         switch (o) {
>             case null, String s when s.isEmpty() -> System.err.println("OK.");
>             default -> {}
>         }
>     }
> }
> 
> 
> In the current specification, the guard should not be invoked when `o` is `null`, but javac will invoke it, for historical reasons.
> 
> Also, as opposed to JDK 18/JEP 420, `case null, <pattern>` is allowed for parenthesized pattern when the parenthesized pattern encloses (directly or via other parenthesized patterns) a type pattern.
> 
> The patch proposed here strives to fix both of these problems.

LGTM ?

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

PR: https://git.openjdk.org/jdk19/pull/120

From vromero at openjdk.org  Fri Jul  8 16:27:27 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 8 Jul 2022 16:27:27 GMT
Subject: [jdk19] RFR: JDK-8289894: A NullPointerException thrown from guard
 expression
In-Reply-To: <vGZNqhAgf86RAmf0NBcambVLUCoqomYH3Nv_I6QViwE=.edf258f4-7af5-4184-82f1-5e63498f80c3@github.com>
References: <vGZNqhAgf86RAmf0NBcambVLUCoqomYH3Nv_I6QViwE=.edf258f4-7af5-4184-82f1-5e63498f80c3@github.com>
Message-ID: <n18JLOI3Y2Z_ay6DOQMgZqjMazKZfd7fpbCsQ0mVVd0=.07511d29-4d13-4d8f-a883-0a59069c480b@github.com>

On Thu, 7 Jul 2022 14:48:09 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider the following code:
> 
> public class SwitchGuard {
>     public static void main(String... args) {
>         test(null);
>     }
>     private static void test(Object o) {
>         switch (o) {
>             case null, String s when s.isEmpty() -> System.err.println("OK.");
>             default -> {}
>         }
>     }
> }
> 
> 
> In the current specification, the guard should not be invoked when `o` is `null`, but javac will invoke it, for historical reasons.
> 
> Also, as opposed to JDK 18/JEP 420, `case null, <pattern>` is allowed for parenthesized pattern when the parenthesized pattern encloses (directly or via other parenthesized patterns) a type pattern.
> 
> The patch proposed here strives to fix both of these problems.

looks sensible

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

Marked as reviewed by vromero (Reviewer).

PR: https://git.openjdk.org/jdk19/pull/120

From jlahoda at openjdk.org  Fri Jul  8 16:50:59 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 8 Jul 2022 16:50:59 GMT
Subject: RFR: 8282714: synthetic arguments are being added to the
 constructors of static local classes
In-Reply-To: <Fn_Lx2J56RrcnFrWYqEoyrmE_nmq-cBdrKmdyFrsBak=.be72dbce-8598-4f6b-bad6-d8b534510bc6@github.com>
References: <Fn_Lx2J56RrcnFrWYqEoyrmE_nmq-cBdrKmdyFrsBak=.be72dbce-8598-4f6b-bad6-d8b534510bc6@github.com>
Message-ID: <K4q1VZ1k8Ru0fmQknC_njY5X7Z_qsl95iLPPX5pNYmM=.57460333-6579-4729-bca8-63f65e25547f@github.com>

On Thu, 7 Jul 2022 17:09:03 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Constructors of local records and enums are being added synthetic parameters by the compiler same as it is done for local non-static classes. Also additional synthetic fields were being added to local records, basically free variables from the "enclosing" class. This is against the spec and should be fixed
> 
> TIA

Looks good to me!

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

Marked as reviewed by jlahoda (Reviewer).

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

From jjg at openjdk.org  Fri Jul  8 16:34:08 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 8 Jul 2022 16:34:08 GMT
Subject: RFR: JDK-8288699: cleanup HTML tree in
 HtmlDocletWriter.commentTagsToContent [v3]
In-Reply-To: <F8JJT617lYURezAXXnmWicQ6nvJ4J9zyfBQ8KgCvBY4=.25eb6f0b-5b79-4614-8a7e-383ecbac38b4@github.com>
References: <F8JJT617lYURezAXXnmWicQ6nvJ4J9zyfBQ8KgCvBY4=.25eb6f0b-5b79-4614-8a7e-383ecbac38b4@github.com>
Message-ID: <LFcihcrM0vd0Pf9bcq0-yV6zymq-UHHWoTssbb7JmqM=.bd116ec6-9c17-4053-bc5b-bc2c49442051@github.com>

> Please review a particularly satisfying review of a cleanup for
> `HtmlDocletWriter.commentTagsToContent`, and the use of `RawHtml`.
> 
> The background for this is a separate cleanup for `CommentHelper.getText`,
> during which it was observed that the code could be eliminated, with some
> uses being replaced by `HtmlDocletWriter.commentTagsToContent`. That led
> to more tags being processed, which in turn led to the observation that
> `Content.charCount` was often giving incorrect results.
> 
> The primary root cause of the problem with `Content.charCount` was the
> handling of `StartElementTree` in the visitor in `commentTagsToContent`.
> The problem is that code there creates a sequence of text nodes for the
> attributes, preceded by a `RawHtml` object containing `<TAGNAME` and followed
> by another separate `RawHtml` node containing just `>`.  The net result
> is that `charCount` is mistaken into including the size of the intervening
> text nodes in the total, because it does not recognize the "unbalanced" `<`
> and `>` in the surrounding nodes.
> 
> The general system fix for `commentTagsToContent` is to change the _visit..._
> methods to always append to the `Content` object supplied as a parameter, instead
> of to a fixed local variable (`result`) in the enclosing scope. This allows
> `visitStartElement` to accumulate the attributes in a temporary buffer,
> and then create a single `RawHtml` node as the translation of the
> `StartElementTree`.  Changing the methodology of the visitors also
> required disentangling the processing of `{@docRoot}`, which generally
> always appears inside the `href` attribute, typically followed by
> the rest of the URL. The complication there is that since forever there
> has been special handling of `{@docRoot}/..` which can be replaced by
> the value of the `--docrootparent` option. In reviewing that part of the code,
> it may help to just ignore the old code and just review the new replacement
> code.
> 
> Starting with the code in `commentTagsToContent`, it became worthwhile to
> use factory methods on `RawHtml` for stylized uses of the class, for _start
> element_, _end element_, and _comment_. These all have a `charCount` of zero,
> so it only becomes necessary to compute the character count when given
> arbitrary text.
> 
> Related, the `Text` and `TextBuilder` classes are changed so that they 
> contain unescaped content, and only escape the HTML characters when they
> are written out. This allows their `charCount` to simply return the `length()`
> of the string content, instead of having to parse the content to account
> of any entities that may be present.  This also means that newline characters
> will be counted; previously, they were not.
> 
> Another noteworthy change. Somewhat usually, some resource strings for the
> description of mandated methods, such as for enum and record classes, contain
> simple HTML (`<i>...</i>`), which is modelled in a single `TextTree` and
> subsequently converted to a non-standard use of `RawHtml`. To avoid
> significantly changing the resource strings, the solution is to parse the
> resources into a suitable `List<DocTree>`, using a relatively simple regular
> expression. The goal is to _not_ extend the support any further than that
> provided.
> 
> Finally, one more change/bug fix. We do not claim to support HTML CDATA
> sections, but there is one in the JDK API docs (in `coll-index.html`). 
> It "mostly worked" by accident, but dropped the leading `<`, which "broke"
> the section in the generated output. I've put code into `DocCommentParser`
> to handle CDATA sections, representing them (for now) as a `Text` node
> containing just the section itself. This is then handled specially up in
> `commentTagsToContent`, where it is translated to a new `RawHtml` node.
> 
> For reviewing, I suggest starting with `RawHtml` and then `HtmlDocletWriter`.
> Many of the other changes are derivative changes, such as changing
> `new RawHtml(...)` to `RawHtml.of(...)` and similar other changes.
> 
> All tests continue to pass without change.
> 
> There are minor changes to the generated docs, in two flavors.
> 
> 1. There is one instance, in `Collectors.html`, where the fixes to `charCount`
>    are enough to change the separator after the type parameters in a 
>    method summary table from `&nbsp;` to `<br>`. 
>    See `AbstractMemberWriter` line 207. The current threshold is 10, and
>    some of the methods in `Collectors.html` were less and are now more.
> 
> 2. A number of files use an unescaped `>` in doc comments. These are now
>    translated to `&gt;` in the output.  The change in behavior is because of
>    changing to use `html.Text` nodes instead of `html.RawHtml` nodes to represent
>    user-provided text in `TextTree` nodes.
>    Previously, the generated output was inconsistent in this area: most
>    instances used `&gt;`, but user-provided `>` was passed through.
>    Now, the output is consistent. 
>    FWIW, `tidy` prefers the use of `&gt;` as well.

Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:

 - Merge with upstream/master
 - Add missing resource and example of use
   Fix Text and TextBuilder for Windows newlines
 - Merge remote-tracking branch 'upstream/master' into 8288699.commentTagsToContent
 - JDK-8288699: cleanup HTML tree in HtmlDocletWriter.commentTagsToContent

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

Changes: https://git.openjdk.org/jdk/pull/9210/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9210&range=02
  Stats: 379 lines in 18 files changed: 209 ins; 66 del; 104 mod
  Patch: https://git.openjdk.org/jdk/pull/9210.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9210/head:pull/9210

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

From vromero at openjdk.org  Fri Jul  8 17:28:45 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 8 Jul 2022 17:28:45 GMT
Subject: Integrated: 8282714: synthetic arguments are being added to the
 constructors of static local classes
In-Reply-To: <Fn_Lx2J56RrcnFrWYqEoyrmE_nmq-cBdrKmdyFrsBak=.be72dbce-8598-4f6b-bad6-d8b534510bc6@github.com>
References: <Fn_Lx2J56RrcnFrWYqEoyrmE_nmq-cBdrKmdyFrsBak=.be72dbce-8598-4f6b-bad6-d8b534510bc6@github.com>
Message-ID: <-ZAmSe1KRFP-qR2RRpvElgz2jw-VSpZU7LKjNt-cx80=.600e2043-4a0b-4979-ae57-ebef4a6944b8@github.com>

On Thu, 7 Jul 2022 17:09:03 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Constructors of local records and enums are being added synthetic parameters by the compiler same as it is done for local non-static classes. Also additional synthetic fields were being added to local records, basically free variables from the "enclosing" class. This is against the spec and should be fixed
> 
> TIA

This pull request has now been integrated.

Changeset: 9c86c820
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9c86c82091827e781c3919b4b4410981ae322732
Stats:     126 lines in 4 files changed: 107 ins; 1 del; 18 mod

8282714: synthetic arguments are being added to the constructors of static local classes

Reviewed-by: jlahoda

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

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

From jjg at openjdk.org  Fri Jul  8 19:36:51 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 8 Jul 2022 19:36:51 GMT
Subject: Integrated: JDK-8288699: cleanup HTML tree in
 HtmlDocletWriter.commentTagsToContent
In-Reply-To: <F8JJT617lYURezAXXnmWicQ6nvJ4J9zyfBQ8KgCvBY4=.25eb6f0b-5b79-4614-8a7e-383ecbac38b4@github.com>
References: <F8JJT617lYURezAXXnmWicQ6nvJ4J9zyfBQ8KgCvBY4=.25eb6f0b-5b79-4614-8a7e-383ecbac38b4@github.com>
Message-ID: <IAb6mV0zarYObtYH45ML997VmCSMy-ctezr6SggE_gQ=.15ad0936-0259-449a-9ef6-f4bd167633ba@github.com>

On Sun, 19 Jun 2022 23:58:26 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a particularly satisfying review of a cleanup for
> `HtmlDocletWriter.commentTagsToContent`, and the use of `RawHtml`.
> 
> The background for this is a separate cleanup for `CommentHelper.getText`,
> during which it was observed that the code could be eliminated, with some
> uses being replaced by `HtmlDocletWriter.commentTagsToContent`. That led
> to more tags being processed, which in turn led to the observation that
> `Content.charCount` was often giving incorrect results.
> 
> The primary root cause of the problem with `Content.charCount` was the
> handling of `StartElementTree` in the visitor in `commentTagsToContent`.
> The problem is that code there creates a sequence of text nodes for the
> attributes, preceded by a `RawHtml` object containing `<TAGNAME` and followed
> by another separate `RawHtml` node containing just `>`.  The net result
> is that `charCount` is mistaken into including the size of the intervening
> text nodes in the total, because it does not recognize the "unbalanced" `<`
> and `>` in the surrounding nodes.
> 
> The general system fix for `commentTagsToContent` is to change the _visit..._
> methods to always append to the `Content` object supplied as a parameter, instead
> of to a fixed local variable (`result`) in the enclosing scope. This allows
> `visitStartElement` to accumulate the attributes in a temporary buffer,
> and then create a single `RawHtml` node as the translation of the
> `StartElementTree`.  Changing the methodology of the visitors also
> required disentangling the processing of `{@docRoot}`, which generally
> always appears inside the `href` attribute, typically followed by
> the rest of the URL. The complication there is that since forever there
> has been special handling of `{@docRoot}/..` which can be replaced by
> the value of the `--docrootparent` option. In reviewing that part of the code,
> it may help to just ignore the old code and just review the new replacement
> code.
> 
> Starting with the code in `commentTagsToContent`, it became worthwhile to
> use factory methods on `RawHtml` for stylized uses of the class, for _start
> element_, _end element_, and _comment_. These all have a `charCount` of zero,
> so it only becomes necessary to compute the character count when given
> arbitrary text.
> 
> Related, the `Text` and `TextBuilder` classes are changed so that they 
> contain unescaped content, and only escape the HTML characters when they
> are written out. This allows their `charCount` to simply return the `length()`
> of the string content, instead of having to parse the content to account
> of any entities that may be present.  This also means that newline characters
> will be counted; previously, they were not.
> 
> Another noteworthy change. Somewhat usually, some resource strings for the
> description of mandated methods, such as for enum and record classes, contain
> simple HTML (`<i>...</i>`), which is modelled in a single `TextTree` and
> subsequently converted to a non-standard use of `RawHtml`. To avoid
> significantly changing the resource strings, the solution is to parse the
> resources into a suitable `List<DocTree>`, using a relatively simple regular
> expression. The goal is to _not_ extend the support any further than that
> provided.
> 
> Finally, one more change/bug fix. We do not claim to support HTML CDATA
> sections, but there is one in the JDK API docs (in `coll-index.html`). 
> It "mostly worked" by accident, but dropped the leading `<`, which "broke"
> the section in the generated output. I've put code into `DocCommentParser`
> to handle CDATA sections, representing them (for now) as a `Text` node
> containing just the section itself. This is then handled specially up in
> `commentTagsToContent`, where it is translated to a new `RawHtml` node.
> 
> For reviewing, I suggest starting with `RawHtml` and then `HtmlDocletWriter`.
> Many of the other changes are derivative changes, such as changing
> `new RawHtml(...)` to `RawHtml.of(...)` and similar other changes.
> 
> All tests continue to pass without change.
> 
> There are minor changes to the generated docs, in two flavors.
> 
> 1. There is one instance, in `Collectors.html`, where the fixes to `charCount`
>    are enough to change the separator after the type parameters in a 
>    method summary table from `&nbsp;` to `<br>`. 
>    See `AbstractMemberWriter` line 207. The current threshold is 10, and
>    some of the methods in `Collectors.html` were less and are now more.
> 
> 2. A number of files use an unescaped `>` in doc comments. These are now
>    translated to `&gt;` in the output.  The change in behavior is because of
>    changing to use `html.Text` nodes instead of `html.RawHtml` nodes to represent
>    user-provided text in `TextTree` nodes.
>    Previously, the generated output was inconsistent in this area: most
>    instances used `&gt;`, but user-provided `>` was passed through.
>    Now, the output is consistent. 
>    FWIW, `tidy` prefers the use of `&gt;` as well.

This pull request has now been integrated.

Changeset: 54b4576f
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/54b4576f78277335e9b45d0b36d943a20cf40888
Stats:     379 lines in 18 files changed: 209 ins; 66 del; 104 mod

8288699: cleanup HTML tree in HtmlDocletWriter.commentTagsToContent

Reviewed-by: hannesw

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

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

From joe.darcy at oracle.com  Fri Jul  8 20:47:22 2022
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Fri, 8 Jul 2022 13:47:22 -0700
Subject: JSR 269 MR for Java SE 19 changes
Message-ID: <0b3ab976-0357-50e2-601d-8a3337fc529e@oracle.com>

FYI,

https://jcp.org/aboutJava/communityprocess/maintenance/jsr269/index13.html

-Joe


From jjg at openjdk.org  Sat Jul  9 02:09:06 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Sat, 9 Jul 2022 02:09:06 GMT
Subject: RFR: JDK-8288624: Cleanup CommentHelper.getText0
Message-ID: <9uN7bfC5s3czzTIv0_8KWn-xB2Cl6jbGayoMK4ro0Y0=.f9615fd9-d903-47bf-8a93-02129afd0209@github.com>

Please review a moderately simple fix to clean up (as in _remove_!) `CommentHelper.getText` and friends/overloads.

This is moderately simple, because most of the heavy lifting was done in 
[JDK-8288699](https://bugs.openjdk.org/browse/JDK-8288624), to clean up `commentTagsToContent`.

The uses of `CommentHelper.getText` can generally be replaced by either `commentTagsToContent` or just `DocTree.toString()`.

Two bugs were uncovered as a result of the cleanup.  These are described in detail in a comment with screenshots in the [bug report](https://bugs.openjdk.org/browse/JDK-8288624?focusedCommentId=14508488&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14508488)  

Fixing the `see-list-long` bug was a direct reason to cleanup `commentTagsToContent`. The fix here could maybe be further improved by writing a simple visitor or (preferably) a pattern-switch when that is a standard feature of the language.

Fixing the other bug was mostly an accidental side-effect of just using `commentTagsToContent` instead of `CommentHelper.getText`, since the tags now get interpreted instead of ignored.  However, one tweak was necessary.
The doc comments for serialization info end up in `serialized-form.html` and not in the primary file for the enclosing type.
This means they should not undergo the standard `redirectRelativeLinks` treatment. Links using `{@link...}` are not affected, but links using explicit `<a href="relative-link">...</a>` are affected. Ideally, we should not be using such relative links in the JDK API documentation, but there are too many to change/fix as part of this work. The fix, for now, is to add a new overload to `commentTagsToContent` that provides the ability to disable the call to `redirectRelativeLinks` when needed ... that is, when generating `serialized-form.html`.

Initially, the goal was just a cleanup fix with no change to tests. The work has been tested by comparing generated docs before and after this work. There are a number of instances of differences in the generated docs, but all are instances of the bugs described above ... either the `see-list-long` bug, or the change that inline doc comment tags are now interpretedin places where they were previously ignored.  All existing tests continue to work without modification; new tests have been added for the fixes for the bugs that were discovered in the course of this work.

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

Commit messages:
 - fix whitespace
 - fix whitespace
 - JDK-8288624: Cleanup CommentHelper.getText0

Changes: https://git.openjdk.org/jdk/pull/9438/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9438&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8288624
  Stats: 263 lines in 10 files changed: 227 ins; 12 del; 24 mod
  Patch: https://git.openjdk.org/jdk/pull/9438.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9438/head:pull/9438

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

From jjg at openjdk.org  Sat Jul  9 03:39:19 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Sat, 9 Jul 2022 03:39:19 GMT
Subject: RFR: JDK-8288624: Cleanup CommentHelper.getText0 [v2]
In-Reply-To: <9uN7bfC5s3czzTIv0_8KWn-xB2Cl6jbGayoMK4ro0Y0=.f9615fd9-d903-47bf-8a93-02129afd0209@github.com>
References: <9uN7bfC5s3czzTIv0_8KWn-xB2Cl6jbGayoMK4ro0Y0=.f9615fd9-d903-47bf-8a93-02129afd0209@github.com>
Message-ID: <lb1ST5ME6YoypHHSmWD-uWiROcEMiAhdn4yjwb2WMZ8=.e7220bea-bce8-46f5-ac96-0b9a56597a41@github.com>

> Please review a moderately simple fix to clean up (as in _remove_!) `CommentHelper.getText` and friends/overloads.
> 
> This is moderately simple, because most of the heavy lifting was done in 
> [JDK-8288699](https://bugs.openjdk.org/browse/JDK-8288624), to clean up `commentTagsToContent`.
> 
> The uses of `CommentHelper.getText` can generally be replaced by either `commentTagsToContent` or just `DocTree.toString()`.
> 
> Two bugs were uncovered as a result of the cleanup.  These are described in detail in a comment with screenshots in the [bug report](https://bugs.openjdk.org/browse/JDK-8288624?focusedCommentId=14508488&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14508488)  
> 
> Fixing the `see-list-long` bug was a direct reason to cleanup `commentTagsToContent`. The fix here could maybe be further improved by writing a simple visitor or (preferably) a pattern-switch when that is a standard feature of the language.
> 
> Fixing the other bug was mostly an accidental side-effect of just using `commentTagsToContent` instead of `CommentHelper.getText`, since the tags now get interpreted instead of ignored.  However, one tweak was necessary.
> The doc comments for serialization info end up in `serialized-form.html` and not in the primary file for the enclosing type.
> This means they should not undergo the standard `redirectRelativeLinks` treatment. Links using `{@link...}` are not affected, but links using explicit `<a href="relative-link">...</a>` are affected. Ideally, we should not be using such relative links in the JDK API documentation, but there are too many to change/fix as part of this work. The fix, for now, is to add a new overload to `commentTagsToContent` that provides the ability to disable the call to `redirectRelativeLinks` when needed ... that is, when generating `serialized-form.html`.
> 
> Initially, the goal was just a cleanup fix with no change to tests. The work has been tested by comparing generated docs before and after this work. There are a number of instances of differences in the generated docs, but all are instances of the bugs described above ... either the `see-list-long` bug, or the change that inline doc comment tags are now interpretedin places where they were previously ignored.  All existing tests continue to work without modification; new tests have been added for the fixes for the bugs that were discovered in the course of this work.

Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  tolerate Windows newlines

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9438/files
  - new: https://git.openjdk.org/jdk/pull/9438/files/81c02a81..e5b95523

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

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

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

From vromero at openjdk.org  Mon Jul 11 03:18:39 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 11 Jul 2022 03:18:39 GMT
Subject: RFR: 8268312: Compilation error with nested generic functional
 interface [v5]
In-Reply-To: <DEIO0KG0-b3cxa0iS8U26nknAD4xeM40v_CY9c35rw8=.7c5720dc-1a07-4bee-afca-ade646e4e6cf@github.com>
References: <DEIO0KG0-b3cxa0iS8U26nknAD4xeM40v_CY9c35rw8=.7c5720dc-1a07-4bee-afca-ade646e4e6cf@github.com>
Message-ID: <KYMjYeYl2fJH-0LOguP5V33-OZTMBTKX6xQTEULdFMU=.5732bebd-b261-46f8-81ed-0554756683e8@github.com>

> Please review this PR, which is my proposal to fix an existing regression. This code:
> 
> 
> import java.util.Optional;
> 
> class App {
>     public static void main(String[] args) {
>         Optional.of("").map(outer -> {
>             Optional.of("")
>                 .map(inner -> returnGeneric(outer))
>                 .ifPresent(String::toString);
>             return "";
>         });
>     }
> 
>     private static <RG> RG returnGeneric(RG generic) {
>         return generic;
>     }
> }
> 
> is not accepted by javac but if the user passes the `-Xdiags:verbose` option then the code compiles. I tracked down the reason for this puzzling difference and I found that it is due to our diagnostic rewriters which can generate more detailed positions for error messages but in cases like the one above can trick the compiler to generate an error message too early. The code deciding if an error message should be deferred or not, depending on the position, is at `DeferredDiagnosticHandler::report`. We decide to do the rewriting if we are in diagnostics compact mode, this is why the error doesn't occur with the `-Xdiags:verbose` option. This fix will made some diagnostics to appear at a slightly different position, but won't make the compiler reject correct code. Comments?
> 
> TIA

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

  restoring the option for compressing diagnostics

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/5586/files
  - new: https://git.openjdk.org/jdk/pull/5586/files/bf715178..5380d4c6

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

  Stats: 95 lines in 76 files changed: 94 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/5586.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/5586/head:pull/5586

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

From jlahoda at openjdk.org  Mon Jul 11 09:03:41 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 11 Jul 2022 09:03:41 GMT
Subject: [jdk19] Integrated: JDK-8289894: A NullPointerException thrown from
 guard expression
In-Reply-To: <vGZNqhAgf86RAmf0NBcambVLUCoqomYH3Nv_I6QViwE=.edf258f4-7af5-4184-82f1-5e63498f80c3@github.com>
References: <vGZNqhAgf86RAmf0NBcambVLUCoqomYH3Nv_I6QViwE=.edf258f4-7af5-4184-82f1-5e63498f80c3@github.com>
Message-ID: <eF3-ypnGZigxxeyZYkzkoeyRJWuULSm6Ky4K15jtyr0=.a124cf06-5370-418e-b510-320f15eeb6d7@github.com>

On Thu, 7 Jul 2022 14:48:09 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider the following code:
> 
> public class SwitchGuard {
>     public static void main(String... args) {
>         test(null);
>     }
>     private static void test(Object o) {
>         switch (o) {
>             case null, String s when s.isEmpty() -> System.err.println("OK.");
>             default -> {}
>         }
>     }
> }
> 
> 
> In the current specification, the guard should not be invoked when `o` is `null`, but javac will invoke it, for historical reasons.
> 
> Also, as opposed to JDK 18/JEP 420, `case null, <pattern>` is allowed for parenthesized pattern when the parenthesized pattern encloses (directly or via other parenthesized patterns) a type pattern.
> 
> The patch proposed here strives to fix both of these problems.

This pull request has now been integrated.

Changeset: 25f4b043
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk19/commit/25f4b04365e40a91ba7a06f6f9fe99e1785ce4f4
Stats:     69 lines in 6 files changed: 55 ins; 0 del; 14 mod

8289894: A NullPointerException thrown from guard expression

Reviewed-by: vromero

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

PR: https://git.openjdk.org/jdk19/pull/120

From mcimadamore at openjdk.org  Mon Jul 11 10:45:21 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 11 Jul 2022 10:45:21 GMT
Subject: RFR: 8268312: Compilation error with nested generic functional
 interface [v5]
In-Reply-To: <KYMjYeYl2fJH-0LOguP5V33-OZTMBTKX6xQTEULdFMU=.5732bebd-b261-46f8-81ed-0554756683e8@github.com>
References: <DEIO0KG0-b3cxa0iS8U26nknAD4xeM40v_CY9c35rw8=.7c5720dc-1a07-4bee-afca-ade646e4e6cf@github.com>
 <KYMjYeYl2fJH-0LOguP5V33-OZTMBTKX6xQTEULdFMU=.5732bebd-b261-46f8-81ed-0554756683e8@github.com>
Message-ID: <wmbN6zzpoBEcoQovqkOmoXYVNlanoA-oBAWCtqkGV3c=.2620854c-ae5e-45cf-b324-9bd34bcd7771@github.com>

On Mon, 11 Jul 2022 03:18:39 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Please review this PR, which is my proposal to fix an existing regression. This code:
>> 
>> 
>> import java.util.Optional;
>> 
>> class App {
>>     public static void main(String[] args) {
>>         Optional.of("").map(outer -> {
>>             Optional.of("")
>>                 .map(inner -> returnGeneric(outer))
>>                 .ifPresent(String::toString);
>>             return "";
>>         });
>>     }
>> 
>>     private static <RG> RG returnGeneric(RG generic) {
>>         return generic;
>>     }
>> }
>> 
>> is not accepted by javac but if the user passes the `-Xdiags:verbose` option then the code compiles. I tracked down the reason for this puzzling difference and I found that it is due to our diagnostic rewriters which can generate more detailed positions for error messages but in cases like the one above can trick the compiler to generate an error message too early. The code deciding if an error message should be deferred or not, depending on the position, is at `DeferredDiagnosticHandler::report`. We decide to do the rewriting if we are in diagnostics compact mode, this is why the error doesn't occur with the `-Xdiags:verbose` option. This fix will made some diagnostics to appear at a slightly different position, but won't make the compiler reject correct code. Comments?
>> 
>> TIA
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   restoring the option for compressing diagnostics

Looks good - there seems to be some change in functionality - in the sense that the raw diagnostics now show the note re. compressed diagnostic, while before that did not happen. It would be good to understand why that happens.

test/langtools/tools/javac/7132880/T7132880.out line 4:

> 2: T7132880.java:33:12: compiler.err.cant.apply.symbols: kindname.method, m1, java.lang.String,{(compiler.misc.inapplicable.method: kindname.method, Outer.Inner2, m1(java.lang.Integer), (compiler.misc.no.conforming.assignment.exists: (compiler.misc.inconvertible.types: java.lang.String, java.lang.Integer))),(compiler.misc.inapplicable.method: kindname.method, Outer.Inner2, m1(java.lang.Double), (compiler.misc.no.conforming.assignment.exists: (compiler.misc.inconvertible.types: java.lang.String, java.lang.Double)))}
> 3: T7132880.java:43:12: compiler.err.ref.ambiguous: m2, kindname.method, m2(java.lang.Object,int), Outer.Inner3, kindname.method, m2(int,java.lang.Object), Outer.Inner3
> 4: - compiler.note.compressed.diags

Why are these showing up now?

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

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

From mcimadamore at openjdk.org  Mon Jul 11 10:52:30 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 11 Jul 2022 10:52:30 GMT
Subject: RFR: 8268312: Compilation error with nested generic functional
 interface [v5]
In-Reply-To: <KYMjYeYl2fJH-0LOguP5V33-OZTMBTKX6xQTEULdFMU=.5732bebd-b261-46f8-81ed-0554756683e8@github.com>
References: <DEIO0KG0-b3cxa0iS8U26nknAD4xeM40v_CY9c35rw8=.7c5720dc-1a07-4bee-afca-ade646e4e6cf@github.com>
 <KYMjYeYl2fJH-0LOguP5V33-OZTMBTKX6xQTEULdFMU=.5732bebd-b261-46f8-81ed-0554756683e8@github.com>
Message-ID: <SXW0o5ZZbf1wfhhKHuYO3jESi5JJayuCYBLpR-wzCmc=.ecb78cff-a1f1-4a2f-8290-4b2a2bd29c47@github.com>

On Mon, 11 Jul 2022 03:18:39 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Please review this PR, which is my proposal to fix an existing regression. This code:
>> 
>> 
>> import java.util.Optional;
>> 
>> class App {
>>     public static void main(String[] args) {
>>         Optional.of("").map(outer -> {
>>             Optional.of("")
>>                 .map(inner -> returnGeneric(outer))
>>                 .ifPresent(String::toString);
>>             return "";
>>         });
>>     }
>> 
>>     private static <RG> RG returnGeneric(RG generic) {
>>         return generic;
>>     }
>> }
>> 
>> is not accepted by javac but if the user passes the `-Xdiags:verbose` option then the code compiles. I tracked down the reason for this puzzling difference and I found that it is due to our diagnostic rewriters which can generate more detailed positions for error messages but in cases like the one above can trick the compiler to generate an error message too early. The code deciding if an error message should be deferred or not, depending on the position, is at `DeferredDiagnosticHandler::report`. We decide to do the rewriting if we are in diagnostics compact mode, this is why the error doesn't occur with the `-Xdiags:verbose` option. This fix will made some diagnostics to appear at a slightly different position, but won't make the compiler reject correct code. Comments?
>> 
>> TIA
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   restoring the option for compressing diagnostics

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java line 4177:

> 4175: 
> 4176:             Pair<Symbol, JCDiagnostic> c = errCandidate();
> 4177:             if (compactMethodDiags) {

I believe the issue is here - the old code made the rewriting dependent on the value of `compactMethodDiags`, which in turns looked at which diagnostic formatter was installed. I think we should either move this check in `Log` (when we decide if we need to rewrite), or don't attach a rewriter if the `compactMethodDiags` is not set. I think it would be preferable to keep existing diagnostics as they are (and maybe cleanup the behavior of `compactMethodDiags` later, as an orthogonal fix).

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

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

From abimpoudis at openjdk.org  Mon Jul 11 11:16:36 2022
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 11 Jul 2022 11:16:36 GMT
Subject: Integrated: 8269674: Improve testing of parenthesized patterns
In-Reply-To: <CKhyND9xcF1C457WSOvoxO6ne0PbX1Nb5v9s0rYivkM=.14ffb35a-db79-4272-bc36-fd6f9f924303@github.com>
References: <CKhyND9xcF1C457WSOvoxO6ne0PbX1Nb5v9s0rYivkM=.14ffb35a-db79-4272-bc36-fd6f9f924303@github.com>
Message-ID: <kFo6XWKPB9tfgYUiUH1MKaAKMmjcFQGtFfIs18Vdazk=.0070dcc1-247c-493a-ab69-54add37776a9@github.com>

On Fri, 1 Jul 2022 08:46:58 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> Introduces a combo test (compile-time) for parenthesized patterns. Subsumes `test/langtools/tools/javac/patterns/Parenthesized.java` (can be safely deleted, if yes, I can port the comment section with the bug ids). 
> 
> Bugs addressed:
> - `case (StringBox(String s1))` raised a parse error

This pull request has now been integrated.

Changeset: bba6be79
Author:    Aggelos Biboudis <abimpoudis at openjdk.org>
Committer: Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bba6be79e06b2b83b97e6def7b6a520e93f5737c
Stats:     174 lines in 2 files changed: 169 ins; 4 del; 1 mod

8269674: Improve testing of parenthesized patterns

Reviewed-by: jlahoda

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

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

From jwilhelm at openjdk.org  Mon Jul 11 12:46:47 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Mon, 11 Jul 2022 12:46:47 GMT
Subject: RFR: Merge jdk19
Message-ID: <Byg8qQa5Z48pm6ayCSP76EBxkte-axHNj0jYI28nYYk=.3fba731e-bc51-4e42-a1e7-3129ceb2b0b3@github.com>

Forwardport JDK 19 -> JDK 20

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

Commit messages:
 - Merge
 - 8290004: [PPC64] JfrGetCallTrace: assert(_pc != nullptr) failed: must have PC
 - 8289692: JFR: Thread checkpoint no longer enforce mutual exclusion post Loom integration
 - 8289894: A NullPointerException thrown from guard expression
 - 8289729: G1: Incorrect verification logic in G1ConcurrentMark::clear_next_bitmap
 - 8282071: Update java.xml module-info
 - 8290033: ProblemList serviceability/jvmti/GetLocalVariable/GetLocalWithoutSuspendTest.java on windows-x64 in -Xcomp mode
 - 8289697: buffer overflow in MTLVertexCache.m: MTLVertexCache_AddGlyphQuad
 - 8289872: wrong wording in @param doc for HashMap.newHashMap et. al.
 - 8289601: SegmentAllocator::allocateUtf8String(String str) should be clarified for strings containing \0
 - ... and 5 more: https://git.openjdk.org/jdk/compare/46251bc6...0b0d186f

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.org/?repo=jdk&pr=9450&range=00.0
 - jdk19: https://webrevs.openjdk.org/?repo=jdk&pr=9450&range=00.1

Changes: https://git.openjdk.org/jdk/pull/9450/files
  Stats: 411 lines in 43 files changed: 284 ins; 26 del; 101 mod
  Patch: https://git.openjdk.org/jdk/pull/9450.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9450/head:pull/9450

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

From hannesw at openjdk.org  Mon Jul 11 13:04:27 2022
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Mon, 11 Jul 2022 13:04:27 GMT
Subject: RFR: JDK-8288624: Cleanup CommentHelper.getText0 [v2]
In-Reply-To: <lb1ST5ME6YoypHHSmWD-uWiROcEMiAhdn4yjwb2WMZ8=.e7220bea-bce8-46f5-ac96-0b9a56597a41@github.com>
References: <9uN7bfC5s3czzTIv0_8KWn-xB2Cl6jbGayoMK4ro0Y0=.f9615fd9-d903-47bf-8a93-02129afd0209@github.com>
 <lb1ST5ME6YoypHHSmWD-uWiROcEMiAhdn4yjwb2WMZ8=.e7220bea-bce8-46f5-ac96-0b9a56597a41@github.com>
Message-ID: <yg4K5wE4yIh-7dHFmnakoilXJIMB4ce59lMFhvksiKg=.dcdf3402-6f6c-4d50-8f3f-619b1d493b8c@github.com>

On Sat, 9 Jul 2022 03:39:19 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a moderately simple fix to clean up (as in _remove_!) `CommentHelper.getText` and friends/overloads.
>> 
>> This is moderately simple, because most of the heavy lifting was done in 
>> [JDK-8288699](https://bugs.openjdk.org/browse/JDK-8288624), to clean up `commentTagsToContent`.
>> 
>> The uses of `CommentHelper.getText` can generally be replaced by either `commentTagsToContent` or just `DocTree.toString()`.
>> 
>> Two bugs were uncovered as a result of the cleanup.  These are described in detail in a comment with screenshots in the [bug report](https://bugs.openjdk.org/browse/JDK-8288624?focusedCommentId=14508488&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14508488)  
>> 
>> Fixing the `see-list-long` bug was a direct reason to cleanup `commentTagsToContent`. The fix here could maybe be further improved by writing a simple visitor or (preferably) a pattern-switch when that is a standard feature of the language.
>> 
>> Fixing the other bug was mostly an accidental side-effect of just using `commentTagsToContent` instead of `CommentHelper.getText`, since the tags now get interpreted instead of ignored.  However, one tweak was necessary.
>> The doc comments for serialization info end up in `serialized-form.html` and not in the primary file for the enclosing type.
>> This means they should not undergo the standard `redirectRelativeLinks` treatment. Links using `{@link...}` are not affected, but links using explicit `<a href="relative-link">...</a>` are affected. Ideally, we should not be using such relative links in the JDK API documentation, but there are too many to change/fix as part of this work. The fix, for now, is to add a new overload to `commentTagsToContent` that provides the ability to disable the call to `redirectRelativeLinks` when needed ... that is, when generating `serialized-form.html`.
>> 
>> Initially, the goal was just a cleanup fix with no change to tests. The work has been tested by comparing generated docs before and after this work. There are a number of instances of differences in the generated docs, but all are instances of the bugs described above ... either the `see-list-long` bug, or the change that inline doc comment tags are now interpretedin places where they were previously ignored.  All existing tests continue to work without modification; new tests have been added for the fixes for the bugs that were discovered in the course of this work.
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   tolerate Windows newlines

I'm not convinced the added overload to commentTagsToContent is the best solution. The main reason is that there is already another mechanism to control handling of relative links, which is the `shouldRedirectRelativeLinks` method called by `redirectRelativeLinks`. 

It seems like it would be easier to adapt that method to handle the new case correctly. Otherwise, it would be more consistent to change everything to the explicit boolean argument, but I like that option less as there already is an overloaded method with 4 parameters with the last two of them of type `boolean`. 

Talking of `shouldRedirectRelativeLinks`, it seems that the policy implemented by that method is that redirection should occur in summary pages but not in the primary class documentation. However, the new code in `HtmlSerialFieldWriter` calls the new overload with `false` as last argument, which seems to implement the converse policy. I guess the best way to make sure is to add a relative link to the test.

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

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

From vromero at openjdk.org  Mon Jul 11 14:10:37 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 11 Jul 2022 14:10:37 GMT
Subject: RFR: 8268312: Compilation error with nested generic functional
 interface [v5]
In-Reply-To: <SXW0o5ZZbf1wfhhKHuYO3jESi5JJayuCYBLpR-wzCmc=.ecb78cff-a1f1-4a2f-8290-4b2a2bd29c47@github.com>
References: <DEIO0KG0-b3cxa0iS8U26nknAD4xeM40v_CY9c35rw8=.7c5720dc-1a07-4bee-afca-ade646e4e6cf@github.com>
 <KYMjYeYl2fJH-0LOguP5V33-OZTMBTKX6xQTEULdFMU=.5732bebd-b261-46f8-81ed-0554756683e8@github.com>
 <SXW0o5ZZbf1wfhhKHuYO3jESi5JJayuCYBLpR-wzCmc=.ecb78cff-a1f1-4a2f-8290-4b2a2bd29c47@github.com>
Message-ID: <ZfqODNuJDmy6hZbS6TRc65OWmbMtJ9YmaATbzNb8p0Q=.3a2f0df1-78b2-4073-a394-3fc31578328f@github.com>

On Mon, 11 Jul 2022 10:49:37 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   restoring the option for compressing diagnostics
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java line 4177:
> 
>> 4175: 
>> 4176:             Pair<Symbol, JCDiagnostic> c = errCandidate();
>> 4177:             if (compactMethodDiags) {
> 
> I believe the issue is here - the old code made the rewriting dependent on the value of `compactMethodDiags`, which in turns looked at which diagnostic formatter was installed. I think we should either move this check in `Log` (when we decide if we need to rewrite), or don't attach a rewriter if the `compactMethodDiags` is not set. I think it would be preferable to keep existing diagnostics as they are (and maybe cleanup the behavior of `compactMethodDiags` later, as an orthogonal fix).

yep I think this is the reason, will upload an updated iteration

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

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

From jjg at openjdk.org  Mon Jul 11 15:47:40 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 11 Jul 2022 15:47:40 GMT
Subject: RFR: JDK-8288624: Cleanup CommentHelper.getText0 [v2]
In-Reply-To: <yg4K5wE4yIh-7dHFmnakoilXJIMB4ce59lMFhvksiKg=.dcdf3402-6f6c-4d50-8f3f-619b1d493b8c@github.com>
References: <9uN7bfC5s3czzTIv0_8KWn-xB2Cl6jbGayoMK4ro0Y0=.f9615fd9-d903-47bf-8a93-02129afd0209@github.com>
 <lb1ST5ME6YoypHHSmWD-uWiROcEMiAhdn4yjwb2WMZ8=.e7220bea-bce8-46f5-ac96-0b9a56597a41@github.com>
 <yg4K5wE4yIh-7dHFmnakoilXJIMB4ce59lMFhvksiKg=.dcdf3402-6f6c-4d50-8f3f-619b1d493b8c@github.com>
Message-ID: <Af2GqtKS3rFKjgMfuUuQdr7CqGAjsHNxLkbhxY20oY0=.8fd17d39-aeff-4890-968b-e7029fa35c16@github.com>

On Mon, 11 Jul 2022 13:00:43 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> I'm not convinced the added overload to commentTagsToContent is the best solution. 

Thanks. I'll investigate your suggestions.  Avoiding new overloads would be good.

While `shouldredirectRelativeLinks` seems like a good policy, right now, yes, it is limited to "summary pages", e.g. for packages and modules.  The new case is for `serialized-form` which is a top-level singleton summary page.

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

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

From jwilhelm at openjdk.org  Mon Jul 11 16:19:55 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Mon, 11 Jul 2022 16:19:55 GMT
Subject: Integrated: Merge jdk19
In-Reply-To: <Byg8qQa5Z48pm6ayCSP76EBxkte-axHNj0jYI28nYYk=.3fba731e-bc51-4e42-a1e7-3129ceb2b0b3@github.com>
References: <Byg8qQa5Z48pm6ayCSP76EBxkte-axHNj0jYI28nYYk=.3fba731e-bc51-4e42-a1e7-3129ceb2b0b3@github.com>
Message-ID: <fjY4V5FNYuBqfDj7z2_ffBFWaO0RM9_vSWKnluFHlV8=.5c4d9cb3-4bd7-47ae-87d1-815f8617f974@github.com>

On Mon, 11 Jul 2022 12:38:11 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 19 -> JDK 20

This pull request has now been integrated.

Changeset: c79baaa8
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c79baaa811971c43fbdbc251482d0e40903588cc
Stats:     411 lines in 43 files changed: 284 ins; 26 del; 101 mod

Merge

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

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

From jjg at openjdk.org  Mon Jul 11 17:31:39 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 11 Jul 2022 17:31:39 GMT
Subject: RFR: JDK-8288624: Cleanup CommentHelper.getText0 [v2]
In-Reply-To: <Af2GqtKS3rFKjgMfuUuQdr7CqGAjsHNxLkbhxY20oY0=.8fd17d39-aeff-4890-968b-e7029fa35c16@github.com>
References: <9uN7bfC5s3czzTIv0_8KWn-xB2Cl6jbGayoMK4ro0Y0=.f9615fd9-d903-47bf-8a93-02129afd0209@github.com>
 <lb1ST5ME6YoypHHSmWD-uWiROcEMiAhdn4yjwb2WMZ8=.e7220bea-bce8-46f5-ac96-0b9a56597a41@github.com>
 <yg4K5wE4yIh-7dHFmnakoilXJIMB4ce59lMFhvksiKg=.dcdf3402-6f6c-4d50-8f3f-619b1d493b8c@github.com>
 <Af2GqtKS3rFKjgMfuUuQdr7CqGAjsHNxLkbhxY20oY0=.8fd17d39-aeff-4890-968b-e7029fa35c16@github.com>
Message-ID: <3pYhFTmQydeGLUrOpmSEuaMf6BskDhkOOlg9QnvG4iw=.10e0067f-c614-45e5-9ace-18c8108d445f@github.com>

On Mon, 11 Jul 2022 15:43:59 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> > I'm not convinced the added overload to commentTagsToContent is the best solution.
> 
> Thanks. I'll investigate your suggestions. Avoiding new overloads would be good.

After investigating, it seems the need for this only arises from 6 cases in 1 comment in 1 class. (`Locale#serialPersistentFields`) and those cases all seem like a workaround for the issue that before this work, `{@link}` did not work in `@serialField` comments (because of `CommentHelper.getText`). Now that `{@link}` should work as expected, we can update the comment for `Locale#serialPersistentFields` and thus get rid of the special case behavior that was added. And going forward, the rule can be no different from anywhere else: that relative links are updated depending on the file in which they will appear.

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

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

From vromero at openjdk.org  Mon Jul 11 18:03:40 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 11 Jul 2022 18:03:40 GMT
Subject: RFR: 8268312: Compilation error with nested generic functional
 interface [v6]
In-Reply-To: <DEIO0KG0-b3cxa0iS8U26nknAD4xeM40v_CY9c35rw8=.7c5720dc-1a07-4bee-afca-ade646e4e6cf@github.com>
References: <DEIO0KG0-b3cxa0iS8U26nknAD4xeM40v_CY9c35rw8=.7c5720dc-1a07-4bee-afca-ade646e4e6cf@github.com>
Message-ID: <jpj-iN8XVBI2pqlE1LNz2RMP7jlSUSmrmO43byt0dgM=.abd65e33-b5f3-4531-8645-9fe80958eebe@github.com>

> Please review this PR, which is my proposal to fix an existing regression. This code:
> 
> 
> import java.util.Optional;
> 
> class App {
>     public static void main(String[] args) {
>         Optional.of("").map(outer -> {
>             Optional.of("")
>                 .map(inner -> returnGeneric(outer))
>                 .ifPresent(String::toString);
>             return "";
>         });
>     }
> 
>     private static <RG> RG returnGeneric(RG generic) {
>         return generic;
>     }
> }
> 
> is not accepted by javac but if the user passes the `-Xdiags:verbose` option then the code compiles. I tracked down the reason for this puzzling difference and I found that it is due to our diagnostic rewriters which can generate more detailed positions for error messages but in cases like the one above can trick the compiler to generate an error message too early. The code deciding if an error message should be deferred or not, depending on the position, is at `DeferredDiagnosticHandler::report`. We decide to do the rewriting if we are in diagnostics compact mode, this is why the error doesn't occur with the `-Xdiags:verbose` option. This fix will made some diagnostics to appear at a slightly different position, but won't make the compiler reject correct code. Comments?
> 
> TIA

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

  another iteration, addressing review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/5586/files
  - new: https://git.openjdk.org/jdk/pull/5586/files/5380d4c6..6ccba3d5

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

  Stats: 190 lines in 68 files changed: 2 ins; 65 del; 123 mod
  Patch: https://git.openjdk.org/jdk/pull/5586.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/5586/head:pull/5586

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

From vromero at openjdk.org  Mon Jul 11 18:30:37 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 11 Jul 2022 18:30:37 GMT
Subject: RFR: 8268312: Compilation error with nested generic functional
 interface [v7]
In-Reply-To: <DEIO0KG0-b3cxa0iS8U26nknAD4xeM40v_CY9c35rw8=.7c5720dc-1a07-4bee-afca-ade646e4e6cf@github.com>
References: <DEIO0KG0-b3cxa0iS8U26nknAD4xeM40v_CY9c35rw8=.7c5720dc-1a07-4bee-afca-ade646e4e6cf@github.com>
Message-ID: <93xuKvo4ZE2QRXbt8psI6IBtfSp2zTKcEp9J3zgVSL0=.260b9cc3-97ba-4249-95cf-2dc7383b5e20@github.com>

> Please review this PR, which is my proposal to fix an existing regression. This code:
> 
> 
> import java.util.Optional;
> 
> class App {
>     public static void main(String[] args) {
>         Optional.of("").map(outer -> {
>             Optional.of("")
>                 .map(inner -> returnGeneric(outer))
>                 .ifPresent(String::toString);
>             return "";
>         });
>     }
> 
>     private static <RG> RG returnGeneric(RG generic) {
>         return generic;
>     }
> }
> 
> is not accepted by javac but if the user passes the `-Xdiags:verbose` option then the code compiles. I tracked down the reason for this puzzling difference and I found that it is due to our diagnostic rewriters which can generate more detailed positions for error messages but in cases like the one above can trick the compiler to generate an error message too early. The code deciding if an error message should be deferred or not, depending on the position, is at `DeferredDiagnosticHandler::report`. We decide to do the rewriting if we are in diagnostics compact mode, this is why the error doesn't occur with the `-Xdiags:verbose` option. This fix will made some diagnostics to appear at a slightly different position, but won't make the compiler reject correct code. Comments?
> 
> TIA

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

  some missed changes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/5586/files
  - new: https://git.openjdk.org/jdk/pull/5586/files/6ccba3d5..14f6e83a

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

  Stats: 58 lines in 11 files changed: 44 ins; 6 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/5586.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/5586/head:pull/5586

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

From mcimadamore at openjdk.org  Mon Jul 11 21:23:38 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 11 Jul 2022 21:23:38 GMT
Subject: RFR: 8268312: Compilation error with nested generic functional
 interface [v7]
In-Reply-To: <93xuKvo4ZE2QRXbt8psI6IBtfSp2zTKcEp9J3zgVSL0=.260b9cc3-97ba-4249-95cf-2dc7383b5e20@github.com>
References: <DEIO0KG0-b3cxa0iS8U26nknAD4xeM40v_CY9c35rw8=.7c5720dc-1a07-4bee-afca-ade646e4e6cf@github.com>
 <93xuKvo4ZE2QRXbt8psI6IBtfSp2zTKcEp9J3zgVSL0=.260b9cc3-97ba-4249-95cf-2dc7383b5e20@github.com>
Message-ID: <_0bvKYY1Wf9sdI5JXNELsk7L5q9ueNqcI3kbtJeGOY8=.5b66a64c-d24e-4013-8703-35803858e7fa@github.com>

On Mon, 11 Jul 2022 18:30:37 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Please review this PR, which is my proposal to fix an existing regression. This code:
>> 
>> 
>> import java.util.Optional;
>> 
>> class App {
>>     public static void main(String[] args) {
>>         Optional.of("").map(outer -> {
>>             Optional.of("")
>>                 .map(inner -> returnGeneric(outer))
>>                 .ifPresent(String::toString);
>>             return "";
>>         });
>>     }
>> 
>>     private static <RG> RG returnGeneric(RG generic) {
>>         return generic;
>>     }
>> }
>> 
>> is not accepted by javac but if the user passes the `-Xdiags:verbose` option then the code compiles. I tracked down the reason for this puzzling difference and I found that it is due to our diagnostic rewriters which can generate more detailed positions for error messages but in cases like the one above can trick the compiler to generate an error message too early. The code deciding if an error message should be deferred or not, depending on the position, is at `DeferredDiagnosticHandler::report`. We decide to do the rewriting if we are in diagnostics compact mode, this is why the error doesn't occur with the `-Xdiags:verbose` option. This fix will made some diagnostics to appear at a slightly different position, but won't make the compiler reject correct code. Comments?
>> 
>> TIA
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   some missed changes

test/langtools/tools/javac/Diagnostics/compressed/T8012003b.out line 4:

> 2: T8012003b.java:31:16: compiler.err.prob.found.req: (compiler.misc.stat.expr.expected)
> 3: T8012003b.java:32:22: compiler.err.prob.found.req: (compiler.misc.incompatible.ret.type.in.lambda: (compiler.misc.conditional.target.cant.be.void))
> 4: T8012003b.java:33:12: compiler.err.prob.found.req: (compiler.misc.invalid.mref: kindname.method, (compiler.misc.cant.apply.symbol: kindname.method, g, java.lang.String, java.lang.Integer, kindname.class, T8012003b, (compiler.misc.no.conforming.assignment.exists: (compiler.misc.inconvertible.types: java.lang.Integer, java.lang.String))))

Seems like this diagnostic is not getting compressed?

test/langtools/tools/javac/diags/examples/ProbFoundReqFragment.java line 25:

> 23: 
> 24: // key: compiler.err.prob.found.req
> 25: // key: compiler.misc.kindname.class

Uhm - this sample is meant to test `compiler.misc.prob.found.req` (e.g. the fragment version). Perhaps we might need to look at the test framework that runs these diagnostic test to understand what we have to change - or what has changed - for this to work as before?

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

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

From jjg at openjdk.org  Mon Jul 11 21:54:31 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 11 Jul 2022 21:54:31 GMT
Subject: RFR: JDK-8288624: Cleanup CommentHelper.getText0 [v3]
In-Reply-To: <9uN7bfC5s3czzTIv0_8KWn-xB2Cl6jbGayoMK4ro0Y0=.f9615fd9-d903-47bf-8a93-02129afd0209@github.com>
References: <9uN7bfC5s3czzTIv0_8KWn-xB2Cl6jbGayoMK4ro0Y0=.f9615fd9-d903-47bf-8a93-02129afd0209@github.com>
Message-ID: <cXCqq_aklYwfj0k67KYbKXmoVANlAotQ1hHuKHJmeOM=.a6d44dd8-dd45-4285-9ad4-b275c6770428@github.com>

> Please review a moderately simple fix to clean up (as in _remove_!) `CommentHelper.getText` and friends/overloads.
> 
> This is moderately simple, because most of the heavy lifting was done in 
> [JDK-8288699](https://bugs.openjdk.org/browse/JDK-8288624), to clean up `commentTagsToContent`.
> 
> The uses of `CommentHelper.getText` can generally be replaced by either `commentTagsToContent` or just `DocTree.toString()`.
> 
> Two bugs were uncovered as a result of the cleanup.  These are described in detail in a comment with screenshots in the [bug report](https://bugs.openjdk.org/browse/JDK-8288624?focusedCommentId=14508488&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14508488)  
> 
> Fixing the `see-list-long` bug was a direct reason to cleanup `commentTagsToContent`. The fix here could maybe be further improved by writing a simple visitor or (preferably) a pattern-switch when that is a standard feature of the language.
> 
> Fixing the other bug was mostly an accidental side-effect of just using `commentTagsToContent` instead of `CommentHelper.getText`, since the tags now get interpreted instead of ignored.  However, one tweak was necessary.
> The doc comments for serialization info end up in `serialized-form.html` and not in the primary file for the enclosing type.
> This means they should not undergo the standard `redirectRelativeLinks` treatment. Links using `{@link...}` are not affected, but links using explicit `<a href="relative-link">...</a>` are affected. Ideally, we should not be using such relative links in the JDK API documentation, but there are too many to change/fix as part of this work. The fix, for now, is to add a new overload to `commentTagsToContent` that provides the ability to disable the call to `redirectRelativeLinks` when needed ... that is, when generating `serialized-form.html`.
> 
> Initially, the goal was just a cleanup fix with no change to tests. The work has been tested by comparing generated docs before and after this work. There are a number of instances of differences in the generated docs, but all are instances of the bugs described above ... either the `see-list-long` bug, or the change that inline doc comment tags are now interpretedin places where they were previously ignored.  All existing tests continue to work without modification; new tests have been added for the fixes for the bugs that were discovered in the course of this work.

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

 - remove need to special-case old behavior
 - Merge remote-tracking branch 'upstream/master' into 8288624.commenthelper-gettext
 - tolerate Windows newlines
 - fix whitespace
 - fix whitespace
 - JDK-8288624: Cleanup CommentHelper.getText0

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9438/files
  - new: https://git.openjdk.org/jdk/pull/9438/files/e5b95523..9e881785

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

  Stats: 3389 lines in 207 files changed: 1179 ins; 1868 del; 342 mod
  Patch: https://git.openjdk.org/jdk/pull/9438.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9438/head:pull/9438

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

From jjg at openjdk.org  Mon Jul 11 21:59:52 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 11 Jul 2022 21:59:52 GMT
Subject: RFR: JDK-8288624: Cleanup CommentHelper.getText0 [v3]
In-Reply-To: <cXCqq_aklYwfj0k67KYbKXmoVANlAotQ1hHuKHJmeOM=.a6d44dd8-dd45-4285-9ad4-b275c6770428@github.com>
References: <9uN7bfC5s3czzTIv0_8KWn-xB2Cl6jbGayoMK4ro0Y0=.f9615fd9-d903-47bf-8a93-02129afd0209@github.com>
 <cXCqq_aklYwfj0k67KYbKXmoVANlAotQ1hHuKHJmeOM=.a6d44dd8-dd45-4285-9ad4-b275c6770428@github.com>
Message-ID: <s72x2FQiBzQIcYuDFRzxk1-gdD-bQpUi18NZhI3lN-A=.883688b5-fef0-4ab9-a0e3-1d19c1c6b4e3@github.com>

On Mon, 11 Jul 2022 21:54:31 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a moderately simple fix to clean up (as in _remove_!) `CommentHelper.getText` and friends/overloads.
>> 
>> This is moderately simple, because most of the heavy lifting was done in 
>> [JDK-8288699](https://bugs.openjdk.org/browse/JDK-8288624), to clean up `commentTagsToContent`.
>> 
>> The uses of `CommentHelper.getText` can generally be replaced by either `commentTagsToContent` or just `DocTree.toString()`.
>> 
>> Two bugs were uncovered as a result of the cleanup.  These are described in detail in a comment with screenshots in the [bug report](https://bugs.openjdk.org/browse/JDK-8288624?focusedCommentId=14508488&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14508488)  
>> 
>> Fixing the `see-list-long` bug was a direct reason to cleanup `commentTagsToContent`. The fix here could maybe be further improved by writing a simple visitor or (preferably) a pattern-switch when that is a standard feature of the language.
>> 
>> Fixing the other bug was mostly an accidental side-effect of just using `commentTagsToContent` instead of `CommentHelper.getText`, since the tags now get interpreted instead of ignored.  However, one tweak was necessary.
>> The doc comments for serialization info end up in `serialized-form.html` and not in the primary file for the enclosing type.
>> This means they should not undergo the standard `redirectRelativeLinks` treatment. Links using `{@link...}` are not affected, but links using explicit `<a href="relative-link">...</a>` are affected. Ideally, we should not be using such relative links in the JDK API documentation, but there are too many to change/fix as part of this work. The fix, for now, is to add a new overload to `commentTagsToContent` that provides the ability to disable the call to `redirectRelativeLinks` when needed ... that is, when generating `serialized-form.html`.
>> 
>> Initially, the goal was just a cleanup fix with no change to tests. The work has been tested by comparing generated docs before and after this work. There are a number of instances of differences in the generated docs, but all are instances of the bugs described above ... either the `see-list-long` bug, or the change that inline doc comment tags are now interpretedin places where they were previously ignored.  All existing tests continue to work without modification; new tests have been added for the fixes for the bugs that were discovered in the course of this work.
>
> Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - remove need to special-case old behavior
>  - Merge remote-tracking branch 'upstream/master' into 8288624.commenthelper-gettext
>  - tolerate Windows newlines
>  - fix whitespace
>  - fix whitespace
>  - JDK-8288624: Cleanup CommentHelper.getText0

I've updated `Locale.java` to change the `<a href...>` into equivalent `{@link...}`, which incidentally now display better because of the resulting added presence of `<code>...</code>` in the generated output.

Having updated `Locale.java` , there is no longer any need for the recently added new overload for `commentTagsToContent`, which has now been removed.

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

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

From vromero at openjdk.org  Tue Jul 12 02:36:13 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 12 Jul 2022 02:36:13 GMT
Subject: RFR: 8268312: Compilation error with nested generic functional
 interface [v7]
In-Reply-To: <_0bvKYY1Wf9sdI5JXNELsk7L5q9ueNqcI3kbtJeGOY8=.5b66a64c-d24e-4013-8703-35803858e7fa@github.com>
References: <DEIO0KG0-b3cxa0iS8U26nknAD4xeM40v_CY9c35rw8=.7c5720dc-1a07-4bee-afca-ade646e4e6cf@github.com>
 <93xuKvo4ZE2QRXbt8psI6IBtfSp2zTKcEp9J3zgVSL0=.260b9cc3-97ba-4249-95cf-2dc7383b5e20@github.com>
 <_0bvKYY1Wf9sdI5JXNELsk7L5q9ueNqcI3kbtJeGOY8=.5b66a64c-d24e-4013-8703-35803858e7fa@github.com>
Message-ID: <t6T-bNjwFUl4RmYx37wbgQxCRQnHOVptdFK7iwaD72E=.7e8e9bc1-1841-48d3-977e-190d97dbfb5b@github.com>

On Mon, 11 Jul 2022 21:21:28 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   some missed changes
>
> test/langtools/tools/javac/Diagnostics/compressed/T8012003b.out line 4:
> 
>> 2: T8012003b.java:31:16: compiler.err.prob.found.req: (compiler.misc.stat.expr.expected)
>> 3: T8012003b.java:32:22: compiler.err.prob.found.req: (compiler.misc.incompatible.ret.type.in.lambda: (compiler.misc.conditional.target.cant.be.void))
>> 4: T8012003b.java:33:12: compiler.err.prob.found.req: (compiler.misc.invalid.mref: kindname.method, (compiler.misc.cant.apply.symbol: kindname.method, g, java.lang.String, java.lang.Integer, kindname.class, T8012003b, (compiler.misc.no.conforming.assignment.exists: (compiler.misc.inconvertible.types: java.lang.Integer, java.lang.String))))
> 
> Seems like this diagnostic is not getting compressed?

yep good catch, checking what's going on

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

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

From hannesw at openjdk.org  Tue Jul 12 13:16:48 2022
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Tue, 12 Jul 2022 13:16:48 GMT
Subject: RFR: JDK-8288624: Cleanup CommentHelper.getText0 [v3]
In-Reply-To: <cXCqq_aklYwfj0k67KYbKXmoVANlAotQ1hHuKHJmeOM=.a6d44dd8-dd45-4285-9ad4-b275c6770428@github.com>
References: <9uN7bfC5s3czzTIv0_8KWn-xB2Cl6jbGayoMK4ro0Y0=.f9615fd9-d903-47bf-8a93-02129afd0209@github.com>
 <cXCqq_aklYwfj0k67KYbKXmoVANlAotQ1hHuKHJmeOM=.a6d44dd8-dd45-4285-9ad4-b275c6770428@github.com>
Message-ID: <S-JkGrt-d538mxeFbSNKX-feiLbzq4FwSGM1EIpZXwU=.5bd0aef4-a636-4a4f-bd05-526eb92e5c05@github.com>

On Mon, 11 Jul 2022 21:54:31 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a moderately simple fix to clean up (as in _remove_!) `CommentHelper.getText` and friends/overloads.
>> 
>> This is moderately simple, because most of the heavy lifting was done in 
>> [JDK-8288699](https://bugs.openjdk.org/browse/JDK-8288624), to clean up `commentTagsToContent`.
>> 
>> The uses of `CommentHelper.getText` can generally be replaced by either `commentTagsToContent` or just `DocTree.toString()`.
>> 
>> Two bugs were uncovered as a result of the cleanup.  These are described in detail in a comment with screenshots in the [bug report](https://bugs.openjdk.org/browse/JDK-8288624?focusedCommentId=14508488&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14508488)  
>> 
>> Fixing the `see-list-long` bug was a direct reason to cleanup `commentTagsToContent`. The fix here could maybe be further improved by writing a simple visitor or (preferably) a pattern-switch when that is a standard feature of the language.
>> 
>> Fixing the other bug was mostly an accidental side-effect of just using `commentTagsToContent` instead of `CommentHelper.getText`, since the tags now get interpreted instead of ignored.  However, one tweak was necessary.
>> The doc comments for serialization info end up in `serialized-form.html` and not in the primary file for the enclosing type.
>> This means they should not undergo the standard `redirectRelativeLinks` treatment. Links using `{@link...}` are not affected, but links using explicit `<a href="relative-link">...</a>` are affected. Ideally, we should not be using such relative links in the JDK API documentation, but there are too many to change/fix as part of this work. The fix, for now, is to add a new overload to `commentTagsToContent` that provides the ability to disable the call to `redirectRelativeLinks` when needed ... that is, when generating `serialized-form.html`.
>> 
>> Initially, the goal was just a cleanup fix with no change to tests. The work has been tested by comparing generated docs before and after this work. There are a number of instances of differences in the generated docs, but all are instances of the bugs described above ... either the `see-list-long` bug, or the change that inline doc comment tags are now interpretedin places where they were previously ignored.  All existing tests continue to work without modification; new tests have been added for the fixes for the bugs that were discovered in the course of this work.
>
> Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - remove need to special-case old behavior
>  - Merge remote-tracking branch 'upstream/master' into 8288624.commenthelper-gettext
>  - tolerate Windows newlines
>  - fix whitespace
>  - fix whitespace
>  - JDK-8288624: Cleanup CommentHelper.getText0

Thanks for looking into the issue concerning rewriting of relative links. The new solution is much nicer.

>From the main description of this PR it sounds like it was you intention to remove the `CommentHelper.getText` methods. However, I notice that the methods are not removed, and there is one use of `getText(DocTree)` remaining in `CommentHelper.getLabel(DocTree)`. Is guess this is an oversight or is it intentional?

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

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

From jjg at openjdk.org  Tue Jul 12 14:32:51 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 12 Jul 2022 14:32:51 GMT
Subject: RFR: JDK-8288624: Cleanup CommentHelper.getText0 [v3]
In-Reply-To: <S-JkGrt-d538mxeFbSNKX-feiLbzq4FwSGM1EIpZXwU=.5bd0aef4-a636-4a4f-bd05-526eb92e5c05@github.com>
References: <9uN7bfC5s3czzTIv0_8KWn-xB2Cl6jbGayoMK4ro0Y0=.f9615fd9-d903-47bf-8a93-02129afd0209@github.com>
 <cXCqq_aklYwfj0k67KYbKXmoVANlAotQ1hHuKHJmeOM=.a6d44dd8-dd45-4285-9ad4-b275c6770428@github.com>
 <S-JkGrt-d538mxeFbSNKX-feiLbzq4FwSGM1EIpZXwU=.5bd0aef4-a636-4a4f-bd05-526eb92e5c05@github.com>
Message-ID: <5g5mLHLxaQJ4BoC8quJERGnT2jf1OypgPeRbbma3Md8=.ee3f6d08-9d15-4fa7-9265-5ef92e2267c7@github.com>

On Tue, 12 Jul 2022 13:13:17 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Thanks for looking into the issue concerning rewriting of relative links. The new solution is much nicer.
> 
> From the main description of this PR it sounds like it was you intention to remove the `CommentHelper.getText` methods. However, I notice that the methods are not removed, and there is one use of `getText(DocTree)` remaining in `CommentHelper.getLabel(DocTree)`. Is guess this is an oversight or is it intentional?

Definite oversight. Will fix. Thanks.

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

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

From jjg at openjdk.org  Tue Jul 12 14:43:59 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 12 Jul 2022 14:43:59 GMT
Subject: RFR: JDK-8288624: Cleanup CommentHelper.getText0 [v4]
In-Reply-To: <9uN7bfC5s3czzTIv0_8KWn-xB2Cl6jbGayoMK4ro0Y0=.f9615fd9-d903-47bf-8a93-02129afd0209@github.com>
References: <9uN7bfC5s3czzTIv0_8KWn-xB2Cl6jbGayoMK4ro0Y0=.f9615fd9-d903-47bf-8a93-02129afd0209@github.com>
Message-ID: <8-D52H-yuWJZiWyOt8c5R178Nmn3hdE3ntuK1akXRdM=.0fa80a9f-b4d6-4cd9-ad97-20e930ef60e0@github.com>

> Please review a moderately simple fix to clean up (as in _remove_!) `CommentHelper.getText` and friends/overloads.
> 
> This is moderately simple, because most of the heavy lifting was done in 
> [JDK-8288699](https://bugs.openjdk.org/browse/JDK-8288624), to clean up `commentTagsToContent`.
> 
> The uses of `CommentHelper.getText` can generally be replaced by either `commentTagsToContent` or just `DocTree.toString()`.
> 
> Two bugs were uncovered as a result of the cleanup.  These are described in detail in a comment with screenshots in the [bug report](https://bugs.openjdk.org/browse/JDK-8288624?focusedCommentId=14508488&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14508488)  
> 
> Fixing the `see-list-long` bug was a direct reason to cleanup `commentTagsToContent`. The fix here could maybe be further improved by writing a simple visitor or (preferably) a pattern-switch when that is a standard feature of the language.
> 
> Fixing the other bug was mostly an accidental side-effect of just using `commentTagsToContent` instead of `CommentHelper.getText`, since the tags now get interpreted instead of ignored.  However, one tweak was necessary.
> The doc comments for serialization info end up in `serialized-form.html` and not in the primary file for the enclosing type.
> This means they should not undergo the standard `redirectRelativeLinks` treatment. Links using `{@link...}` are not affected, but links using explicit `<a href="relative-link">...</a>` are affected. Ideally, we should not be using such relative links in the JDK API documentation, but there are too many to change/fix as part of this work. The fix, for now, is to add a new overload to `commentTagsToContent` that provides the ability to disable the call to `redirectRelativeLinks` when needed ... that is, when generating `serialized-form.html`.
> 
> Initially, the goal was just a cleanup fix with no change to tests. The work has been tested by comparing generated docs before and after this work. There are a number of instances of differences in the generated docs, but all are instances of the bugs described above ... either the `see-list-long` bug, or the change that inline doc comment tags are now interpretedin places where they were previously ignored.  All existing tests continue to work without modification; new tests have been added for the fixes for the bugs that were discovered in the course of this work.

Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  remove dead code

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9438/files
  - new: https://git.openjdk.org/jdk/pull/9438/files/9e881785..09d03884

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

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

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

From hannesw at openjdk.org  Tue Jul 12 16:07:53 2022
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Tue, 12 Jul 2022 16:07:53 GMT
Subject: RFR: JDK-8288624: Cleanup CommentHelper.getText0 [v4]
In-Reply-To: <8-D52H-yuWJZiWyOt8c5R178Nmn3hdE3ntuK1akXRdM=.0fa80a9f-b4d6-4cd9-ad97-20e930ef60e0@github.com>
References: <9uN7bfC5s3czzTIv0_8KWn-xB2Cl6jbGayoMK4ro0Y0=.f9615fd9-d903-47bf-8a93-02129afd0209@github.com>
 <8-D52H-yuWJZiWyOt8c5R178Nmn3hdE3ntuK1akXRdM=.0fa80a9f-b4d6-4cd9-ad97-20e930ef60e0@github.com>
Message-ID: <5Rm_vhSJ16-pCApByL9tAzA2p1DZ_IuX0FVtg5a9-40=.c188abbc-ec7a-42d5-9116-a5af112be1ae@github.com>

On Tue, 12 Jul 2022 14:43:59 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a moderately simple fix to clean up (as in _remove_!) `CommentHelper.getText` and friends/overloads.
>> 
>> This is moderately simple, because most of the heavy lifting was done in 
>> [JDK-8288699](https://bugs.openjdk.org/browse/JDK-8288624), to clean up `commentTagsToContent`.
>> 
>> The uses of `CommentHelper.getText` can generally be replaced by either `commentTagsToContent` or just `DocTree.toString()`.
>> 
>> Two bugs were uncovered as a result of the cleanup.  These are described in detail in a comment with screenshots in the [bug report](https://bugs.openjdk.org/browse/JDK-8288624?focusedCommentId=14508488&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14508488)  
>> 
>> Fixing the `see-list-long` bug was a direct reason to cleanup `commentTagsToContent`. The fix here could maybe be further improved by writing a simple visitor or (preferably) a pattern-switch when that is a standard feature of the language.
>> 
>> Fixing the other bug was mostly an accidental side-effect of just using `commentTagsToContent` instead of `CommentHelper.getText`, since the tags now get interpreted instead of ignored.  However, one tweak was necessary.
>> The doc comments for serialization info end up in `serialized-form.html` and not in the primary file for the enclosing type.
>> This means they should not undergo the standard `redirectRelativeLinks` treatment. Links using `{@link...}` are not affected, but links using explicit `<a href="relative-link">...</a>` are affected. Ideally, we should not be using such relative links in the JDK API documentation, but there are too many to change/fix as part of this work. The fix, for now, is to add a new overload to `commentTagsToContent` that provides the ability to disable the call to `redirectRelativeLinks` when needed ... that is, when generating `serialized-form.html`.
>> 
>> Initially, the goal was just a cleanup fix with no change to tests. The work has been tested by comparing generated docs before and after this work. There are a number of instances of differences in the generated docs, but all are instances of the bugs described above ... either the `see-list-long` bug, or the change that inline doc comment tags are now interpretedin places where they were previously ignored.  All existing tests continue to work without modification; new tests have been added for the fixes for the bugs that were discovered in the course of this work.
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove dead code

Looks mostly good! The one thing I have doubts about is the regular expression for HTML entities.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/TagletWriterImpl.java line 361:

> 359:         String s = c.toString()
> 360:                 .replaceAll("<.*?>", "")            // ignore HTML
> 361:                 .replaceAll("\\&[a-z0-9]+;?", " ")  // entities count as a single character

I don't think the regex for entities is correct (or complete). Numeric entities contain a `#` (such as `&#197;`), entities can contain upper case characters (like `&Auml;`), and I don't think the semicolon is optional as this seems to suggest.

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

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

From hannesw at openjdk.org  Wed Jul 13 09:55:14 2022
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Wed, 13 Jul 2022 09:55:14 GMT
Subject: RFR: JDK-8288624: Cleanup CommentHelper.getText0 [v5]
In-Reply-To: <mR07Bg1VrAqlyVMW4NpeZ_9DT7pWZ8V2nt2aMwN4hJM=.bbc39253-9e29-43e9-a181-71b46d2e221f@github.com>
References: <9uN7bfC5s3czzTIv0_8KWn-xB2Cl6jbGayoMK4ro0Y0=.f9615fd9-d903-47bf-8a93-02129afd0209@github.com>
 <mR07Bg1VrAqlyVMW4NpeZ_9DT7pWZ8V2nt2aMwN4hJM=.bbc39253-9e29-43e9-a181-71b46d2e221f@github.com>
Message-ID: <7LAD-__aVhDd0t_4wpoMKw61flNmwCg0ebSLZrTsm1g=.275117e0-ff8d-4460-a93c-2a4779fc2ac3@github.com>

On Tue, 12 Jul 2022 17:04:40 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a moderately simple fix to clean up (as in _remove_!) `CommentHelper.getText` and friends/overloads.
>> 
>> This is moderately simple, because most of the heavy lifting was done in 
>> [JDK-8288699](https://bugs.openjdk.org/browse/JDK-8288624), to clean up `commentTagsToContent`.
>> 
>> The uses of `CommentHelper.getText` can generally be replaced by either `commentTagsToContent` or just `DocTree.toString()`.
>> 
>> Two bugs were uncovered as a result of the cleanup.  These are described in detail in a comment with screenshots in the [bug report](https://bugs.openjdk.org/browse/JDK-8288624?focusedCommentId=14508488&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14508488)  
>> 
>> Fixing the `see-list-long` bug was a direct reason to cleanup `commentTagsToContent`. The fix here could maybe be further improved by writing a simple visitor or (preferably) a pattern-switch when that is a standard feature of the language.
>> 
>> Fixing the other bug was mostly an accidental side-effect of just using `commentTagsToContent` instead of `CommentHelper.getText`, since the tags now get interpreted instead of ignored.  However, one tweak was necessary.
>> The doc comments for serialization info end up in `serialized-form.html` and not in the primary file for the enclosing type.
>> This means they should not undergo the standard `redirectRelativeLinks` treatment. Links using `{@link...}` are not affected, but links using explicit `<a href="relative-link">...</a>` are affected. Ideally, we should not be using such relative links in the JDK API documentation, but there are too many to change/fix as part of this work. The fix, for now, is to add a new overload to `commentTagsToContent` that provides the ability to disable the call to `redirectRelativeLinks` when needed ... that is, when generating `serialized-form.html`.
>> 
>> Initially, the goal was just a cleanup fix with no change to tests. The work has been tested by comparing generated docs before and after this work. There are a number of instances of differences in the generated docs, but all are instances of the bugs described above ... either the `see-list-long` bug, or the change that inline doc comment tags are now interpretedin places where they were previously ignored.  All existing tests continue to work without modification; new tests have been added for the fixes for the bugs that were discovered in the course of this work.
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix regex for entities

Looks good!

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

Marked as reviewed by hannesw (Reviewer).

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

From jjg at openjdk.org  Wed Jul 13 14:49:12 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 13 Jul 2022 14:49:12 GMT
Subject: Integrated: JDK-8288624: Cleanup CommentHelper.getText0
In-Reply-To: <9uN7bfC5s3czzTIv0_8KWn-xB2Cl6jbGayoMK4ro0Y0=.f9615fd9-d903-47bf-8a93-02129afd0209@github.com>
References: <9uN7bfC5s3czzTIv0_8KWn-xB2Cl6jbGayoMK4ro0Y0=.f9615fd9-d903-47bf-8a93-02129afd0209@github.com>
Message-ID: <twi6lxUN51ocONaI0bFAv_9aO268uAVrTvtybSyKIQg=.8208632e-79f0-4f23-a184-283530b09b9e@github.com>

On Sat, 9 Jul 2022 01:55:32 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a moderately simple fix to clean up (as in _remove_!) `CommentHelper.getText` and friends/overloads.
> 
> This is moderately simple, because most of the heavy lifting was done in 
> [JDK-8288699](https://bugs.openjdk.org/browse/JDK-8288624), to clean up `commentTagsToContent`.
> 
> The uses of `CommentHelper.getText` can generally be replaced by either `commentTagsToContent` or just `DocTree.toString()`.
> 
> Two bugs were uncovered as a result of the cleanup.  These are described in detail in a comment with screenshots in the [bug report](https://bugs.openjdk.org/browse/JDK-8288624?focusedCommentId=14508488&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14508488)  
> 
> Fixing the `see-list-long` bug was a direct reason to cleanup `commentTagsToContent`. The fix here could maybe be further improved by writing a simple visitor or (preferably) a pattern-switch when that is a standard feature of the language.
> 
> Fixing the other bug was mostly an accidental side-effect of just using `commentTagsToContent` instead of `CommentHelper.getText`, since the tags now get interpreted instead of ignored.  However, one tweak was necessary.
> The doc comments for serialization info end up in `serialized-form.html` and not in the primary file for the enclosing type.
> This means they should not undergo the standard `redirectRelativeLinks` treatment. Links using `{@link...}` are not affected, but links using explicit `<a href="relative-link">...</a>` are affected. Ideally, we should not be using such relative links in the JDK API documentation, but there are too many to change/fix as part of this work. The fix, for now, is to add a new overload to `commentTagsToContent` that provides the ability to disable the call to `redirectRelativeLinks` when needed ... that is, when generating `serialized-form.html`.
> 
> Initially, the goal was just a cleanup fix with no change to tests. The work has been tested by comparing generated docs before and after this work. There are a number of instances of differences in the generated docs, but all are instances of the bugs described above ... either the `see-list-long` bug, or the change that inline doc comment tags are now interpretedin places where they were previously ignored.  All existing tests continue to work without modification; new tests have been added for the fixes for the bugs that were discovered in the course of this work.

This pull request has now been integrated.

Changeset: 572c14ef
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/572c14efc67860e75edaa50608b4c61aec5997da
Stats:     406 lines in 12 files changed: 209 ins; 169 del; 28 mod

8288624: Cleanup CommentHelper.getText0

Reviewed-by: hannesw

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

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

From vromero at openjdk.org  Wed Jul 13 16:05:00 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 13 Jul 2022 16:05:00 GMT
Subject: RFR: 8268312: Compilation error with nested generic functional
 interface [v7]
In-Reply-To: <t6T-bNjwFUl4RmYx37wbgQxCRQnHOVptdFK7iwaD72E=.7e8e9bc1-1841-48d3-977e-190d97dbfb5b@github.com>
References: <DEIO0KG0-b3cxa0iS8U26nknAD4xeM40v_CY9c35rw8=.7c5720dc-1a07-4bee-afca-ade646e4e6cf@github.com>
 <93xuKvo4ZE2QRXbt8psI6IBtfSp2zTKcEp9J3zgVSL0=.260b9cc3-97ba-4249-95cf-2dc7383b5e20@github.com>
 <_0bvKYY1Wf9sdI5JXNELsk7L5q9ueNqcI3kbtJeGOY8=.5b66a64c-d24e-4013-8703-35803858e7fa@github.com>
 <t6T-bNjwFUl4RmYx37wbgQxCRQnHOVptdFK7iwaD72E=.7e8e9bc1-1841-48d3-977e-190d97dbfb5b@github.com>
Message-ID: <aA37m5xsGGV6-cKT17b1cx-JiUGbHGQk_3_PpUky1lc=.f4930052-25b7-46b8-a471-f9de5535e6a5@github.com>

On Tue, 12 Jul 2022 02:34:00 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> test/langtools/tools/javac/Diagnostics/compressed/T8012003b.out line 4:
>> 
>>> 2: T8012003b.java:31:16: compiler.err.prob.found.req: (compiler.misc.stat.expr.expected)
>>> 3: T8012003b.java:32:22: compiler.err.prob.found.req: (compiler.misc.incompatible.ret.type.in.lambda: (compiler.misc.conditional.target.cant.be.void))
>>> 4: T8012003b.java:33:12: compiler.err.prob.found.req: (compiler.misc.invalid.mref: kindname.method, (compiler.misc.cant.apply.symbol: kindname.method, g, java.lang.String, java.lang.Integer, kindname.class, T8012003b, (compiler.misc.no.conforming.assignment.exists: (compiler.misc.inconvertible.types: java.lang.Integer, java.lang.String))))
>> 
>> Seems like this diagnostic is not getting compressed?
>
> yep good catch, checking what's going on

I have been debugging and analyzing what is happening here, now we are creating more detailed diags compared to the previous code which was basically creating compact diags and they were making it to the corresponding `MethodResolutionContext::candidates` list, so we were selecting a compact diags from the `candidates` list and using a compact diags to issue the error message. Now we are always creating more detailed diags which sometimes link to a compact diags and sometimes don't as we create a lot of diags. This is the reason we are printing a detailed message in this case. One possible solution could be to try to propagate the compact diag, if a detailed diagnostic has one, and we create a new one but I think that if we do this then probably there is no reason to actually create a detailed diagnostic if a compact one is available, which is what the current code is doing.

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

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

From vromero at openjdk.org  Thu Jul 14 05:04:06 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 14 Jul 2022 05:04:06 GMT
Subject: RFR: 8268312: Compilation error with nested generic functional
 interface [v8]
In-Reply-To: <DEIO0KG0-b3cxa0iS8U26nknAD4xeM40v_CY9c35rw8=.7c5720dc-1a07-4bee-afca-ade646e4e6cf@github.com>
References: <DEIO0KG0-b3cxa0iS8U26nknAD4xeM40v_CY9c35rw8=.7c5720dc-1a07-4bee-afca-ade646e4e6cf@github.com>
Message-ID: <_R-R3C0IyDmRTs9h2RiWkHSSn74UhxTh813hkwHVkOU=.ffc4abef-aa22-40a3-b3da-13002e462e3e@github.com>

> Please review this PR, which is my proposal to fix an existing regression. This code:
> 
> 
> import java.util.Optional;
> 
> class App {
>     public static void main(String[] args) {
>         Optional.of("").map(outer -> {
>             Optional.of("")
>                 .map(inner -> returnGeneric(outer))
>                 .ifPresent(String::toString);
>             return "";
>         });
>     }
> 
>     private static <RG> RG returnGeneric(RG generic) {
>         return generic;
>     }
> }
> 
> is not accepted by javac but if the user passes the `-Xdiags:verbose` option then the code compiles. I tracked down the reason for this puzzling difference and I found that it is due to our diagnostic rewriters which can generate more detailed positions for error messages but in cases like the one above can trick the compiler to generate an error message too early. The code deciding if an error message should be deferred or not, depending on the position, is at `DeferredDiagnosticHandler::report`. We decide to do the rewriting if we are in diagnostics compact mode, this is why the error doesn't occur with the `-Xdiags:verbose` option. This fix will made some diagnostics to appear at a slightly different position, but won't make the compiler reject correct code. Comments?
> 
> TIA

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

  another iteration: addressing review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/5586/files
  - new: https://git.openjdk.org/jdk/pull/5586/files/14f6e83a..6c3fd35a

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

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

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

From vromero at openjdk.org  Thu Jul 14 05:08:49 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 14 Jul 2022 05:08:49 GMT
Subject: RFR: 8268312: Compilation error with nested generic functional
 interface [v9]
In-Reply-To: <DEIO0KG0-b3cxa0iS8U26nknAD4xeM40v_CY9c35rw8=.7c5720dc-1a07-4bee-afca-ade646e4e6cf@github.com>
References: <DEIO0KG0-b3cxa0iS8U26nknAD4xeM40v_CY9c35rw8=.7c5720dc-1a07-4bee-afca-ade646e4e6cf@github.com>
Message-ID: <CzJGERDTrvyLfNHRpYshxI3ezAFEAFUsMic20gVDgYM=.6931c0c2-0e30-4c85-8e17-f2c7994b0ace@github.com>

> Please review this PR, which is my proposal to fix an existing regression. This code:
> 
> 
> import java.util.Optional;
> 
> class App {
>     public static void main(String[] args) {
>         Optional.of("").map(outer -> {
>             Optional.of("")
>                 .map(inner -> returnGeneric(outer))
>                 .ifPresent(String::toString);
>             return "";
>         });
>     }
> 
>     private static <RG> RG returnGeneric(RG generic) {
>         return generic;
>     }
> }
> 
> is not accepted by javac but if the user passes the `-Xdiags:verbose` option then the code compiles. I tracked down the reason for this puzzling difference and I found that it is due to our diagnostic rewriters which can generate more detailed positions for error messages but in cases like the one above can trick the compiler to generate an error message too early. The code deciding if an error message should be deferred or not, depending on the position, is at `DeferredDiagnosticHandler::report`. We decide to do the rewriting if we are in diagnostics compact mode, this is why the error doesn't occur with the `-Xdiags:verbose` option. This fix will made some diagnostics to appear at a slightly different position, but won't make the compiler reject correct code. Comments?
> 
> TIA

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

  removing copyright year, no change to the file

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/5586/files
  - new: https://git.openjdk.org/jdk/pull/5586/files/6c3fd35a..a00c8dab

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

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

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

From vromero at openjdk.org  Thu Jul 14 05:08:50 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 14 Jul 2022 05:08:50 GMT
Subject: RFR: 8268312: Compilation error with nested generic functional
 interface [v7]
In-Reply-To: <t6T-bNjwFUl4RmYx37wbgQxCRQnHOVptdFK7iwaD72E=.7e8e9bc1-1841-48d3-977e-190d97dbfb5b@github.com>
References: <DEIO0KG0-b3cxa0iS8U26nknAD4xeM40v_CY9c35rw8=.7c5720dc-1a07-4bee-afca-ade646e4e6cf@github.com>
 <93xuKvo4ZE2QRXbt8psI6IBtfSp2zTKcEp9J3zgVSL0=.260b9cc3-97ba-4249-95cf-2dc7383b5e20@github.com>
 <_0bvKYY1Wf9sdI5JXNELsk7L5q9ueNqcI3kbtJeGOY8=.5b66a64c-d24e-4013-8703-35803858e7fa@github.com>
 <t6T-bNjwFUl4RmYx37wbgQxCRQnHOVptdFK7iwaD72E=.7e8e9bc1-1841-48d3-977e-190d97dbfb5b@github.com>
Message-ID: <ZBSLeAmx_OMoYe0Uti1y7zufSRkmciSb4A7HVa_p-Rg=.6bcdae6c-4475-420a-8def-443826d6d8ed@github.com>

On Tue, 12 Jul 2022 02:34:00 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> test/langtools/tools/javac/Diagnostics/compressed/T8012003b.out line 4:
>> 
>>> 2: T8012003b.java:31:16: compiler.err.prob.found.req: (compiler.misc.stat.expr.expected)
>>> 3: T8012003b.java:32:22: compiler.err.prob.found.req: (compiler.misc.incompatible.ret.type.in.lambda: (compiler.misc.conditional.target.cant.be.void))
>>> 4: T8012003b.java:33:12: compiler.err.prob.found.req: (compiler.misc.invalid.mref: kindname.method, (compiler.misc.cant.apply.symbol: kindname.method, g, java.lang.String, java.lang.Integer, kindname.class, T8012003b, (compiler.misc.no.conforming.assignment.exists: (compiler.misc.inconvertible.types: java.lang.Integer, java.lang.String))))
>> 
>> Seems like this diagnostic is not getting compressed?
>
> yep good catch, checking what's going on

uploaded another iteration as discussed offline, thanks

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

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

From mcimadamore at openjdk.org  Thu Jul 14 21:08:59 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 14 Jul 2022 21:08:59 GMT
Subject: RFR: 8268312: Compilation error with nested generic functional
 interface [v9]
In-Reply-To: <CzJGERDTrvyLfNHRpYshxI3ezAFEAFUsMic20gVDgYM=.6931c0c2-0e30-4c85-8e17-f2c7994b0ace@github.com>
References: <DEIO0KG0-b3cxa0iS8U26nknAD4xeM40v_CY9c35rw8=.7c5720dc-1a07-4bee-afca-ade646e4e6cf@github.com>
 <CzJGERDTrvyLfNHRpYshxI3ezAFEAFUsMic20gVDgYM=.6931c0c2-0e30-4c85-8e17-f2c7994b0ace@github.com>
Message-ID: <BdLANU8Jk6n1OVKF1fpGmznyK9h39PigKpTKl70YCS8=.a0c18e20-2e0c-4d7c-a70f-109b22ce5c41@github.com>

On Thu, 14 Jul 2022 05:08:49 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Please review this PR, which is my proposal to fix an existing regression. This code:
>> 
>> 
>> import java.util.Optional;
>> 
>> class App {
>>     public static void main(String[] args) {
>>         Optional.of("").map(outer -> {
>>             Optional.of("")
>>                 .map(inner -> returnGeneric(outer))
>>                 .ifPresent(String::toString);
>>             return "";
>>         });
>>     }
>> 
>>     private static <RG> RG returnGeneric(RG generic) {
>>         return generic;
>>     }
>> }
>> 
>> is not accepted by javac but if the user passes the `-Xdiags:verbose` option then the code compiles. I tracked down the reason for this puzzling difference and I found that it is due to our diagnostic rewriters which can generate more detailed positions for error messages but in cases like the one above can trick the compiler to generate an error message too early. The code deciding if an error message should be deferred or not, depending on the position, is at `DeferredDiagnosticHandler::report`. We decide to do the rewriting if we are in diagnostics compact mode, this is why the error doesn't occur with the `-Xdiags:verbose` option. This fix will made some diagnostics to appear at a slightly different position, but won't make the compiler reject correct code. Comments?
>> 
>> TIA
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removing copyright year, no change to the file

Looks good!

src/jdk.compiler/share/classes/com/sun/tools/javac/util/AbstractDiagnosticFormatter.java line 189:

> 187:                     rewrittenDiagnostic = diagnostic.rewrite();
> 188:                 }
> 189:                 s = formatMessage(rewrittenDiagnostic != null? rewrittenDiagnostic : diagnostic, l);

Suggestion:

                s = formatMessage(rewrittenDiagnostic != null ? rewrittenDiagnostic : diagnostic, l);

test/langtools/tools/javac/diags/DiagnosticRewriterTest3.java line 2:

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

Suggestion:

 * Copyright (c) 2022, Oracle and/or its affiliates. All rights reserved.

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

Marked as reviewed by mcimadamore (Reviewer).

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

From vromero at openjdk.org  Thu Jul 14 22:46:58 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 14 Jul 2022 22:46:58 GMT
Subject: RFR: 8268312: Compilation error with nested generic functional
 interface [v10]
In-Reply-To: <DEIO0KG0-b3cxa0iS8U26nknAD4xeM40v_CY9c35rw8=.7c5720dc-1a07-4bee-afca-ade646e4e6cf@github.com>
References: <DEIO0KG0-b3cxa0iS8U26nknAD4xeM40v_CY9c35rw8=.7c5720dc-1a07-4bee-afca-ade646e4e6cf@github.com>
Message-ID: <rj4PfhQM_xqn3NksFsFzCAvT8dFATu_kyDKUb_jXKGU=.142f90ea-a95e-49a2-ac2d-0fe7aa242ec1@github.com>

> Please review this PR, which is my proposal to fix an existing regression. This code:
> 
> 
> import java.util.Optional;
> 
> class App {
>     public static void main(String[] args) {
>         Optional.of("").map(outer -> {
>             Optional.of("")
>                 .map(inner -> returnGeneric(outer))
>                 .ifPresent(String::toString);
>             return "";
>         });
>     }
> 
>     private static <RG> RG returnGeneric(RG generic) {
>         return generic;
>     }
> }
> 
> is not accepted by javac but if the user passes the `-Xdiags:verbose` option then the code compiles. I tracked down the reason for this puzzling difference and I found that it is due to our diagnostic rewriters which can generate more detailed positions for error messages but in cases like the one above can trick the compiler to generate an error message too early. The code deciding if an error message should be deferred or not, depending on the position, is at `DeferredDiagnosticHandler::report`. We decide to do the rewriting if we are in diagnostics compact mode, this is why the error doesn't occur with the `-Xdiags:verbose` option. This fix will made some diagnostics to appear at a slightly different position, but won't make the compiler reject correct code. Comments?
> 
> TIA

Vicente Romero has updated the pull request incrementally with two additional commits since the last revision:

 - Update src/jdk.compiler/share/classes/com/sun/tools/javac/util/AbstractDiagnosticFormatter.java
   
   Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>
 - Update test/langtools/tools/javac/diags/DiagnosticRewriterTest3.java
   
   Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/5586/files
  - new: https://git.openjdk.org/jdk/pull/5586/files/a00c8dab..a913b305

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

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

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

From vromero at openjdk.org  Fri Jul 15 13:09:59 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 15 Jul 2022 13:09:59 GMT
Subject: Integrated: 8268312: Compilation error with nested generic functional
 interface
In-Reply-To: <DEIO0KG0-b3cxa0iS8U26nknAD4xeM40v_CY9c35rw8=.7c5720dc-1a07-4bee-afca-ade646e4e6cf@github.com>
References: <DEIO0KG0-b3cxa0iS8U26nknAD4xeM40v_CY9c35rw8=.7c5720dc-1a07-4bee-afca-ade646e4e6cf@github.com>
Message-ID: <b3V6Spiw-J6IZFbY_3vatYTzLZZzFy_9I2xe3-cz1pI=.27b57d35-f538-4ef7-a4f9-cf4a3126369d@github.com>

On Mon, 20 Sep 2021 19:00:29 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Please review this PR, which is my proposal to fix an existing regression. This code:
> 
> 
> import java.util.Optional;
> 
> class App {
>     public static void main(String[] args) {
>         Optional.of("").map(outer -> {
>             Optional.of("")
>                 .map(inner -> returnGeneric(outer))
>                 .ifPresent(String::toString);
>             return "";
>         });
>     }
> 
>     private static <RG> RG returnGeneric(RG generic) {
>         return generic;
>     }
> }
> 
> is not accepted by javac but if the user passes the `-Xdiags:verbose` option then the code compiles. I tracked down the reason for this puzzling difference and I found that it is due to our diagnostic rewriters which can generate more detailed positions for error messages but in cases like the one above can trick the compiler to generate an error message too early. The code deciding if an error message should be deferred or not, depending on the position, is at `DeferredDiagnosticHandler::report`. We decide to do the rewriting if we are in diagnostics compact mode, this is why the error doesn't occur with the `-Xdiags:verbose` option. This fix will made some diagnostics to appear at a slightly different position, but won't make the compiler reject correct code. Comments?
> 
> TIA

This pull request has now been integrated.

Changeset: f3abb829
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f3abb82989e79da97bcc0a837883be41d14703a3
Stats:     120 lines in 5 files changed: 109 ins; 8 del; 3 mod

8268312: Compilation error with nested generic functional interface

Reviewed-by: mcimadamore

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

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

From abimpoudis at openjdk.org  Fri Jul 15 16:25:27 2022
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Fri, 15 Jul 2022 16:25:27 GMT
Subject: RFR: 8290379: Parse error with parenthesized pattern and guard using
 an array
Message-ID: <Wmpv3eXCHkrAeOaEPafXTobTUyCjlfg6SzbLf9vKAdA=.42fe09c3-6eb3-44b9-82e6-52e8aacc6d72@github.com>

8290379: Parse error with parenthesized pattern and guard using an array

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

Commit messages:
 - 8290379: Parse error with parenthesized pattern and guard using an array

Changes: https://git.openjdk.org/jdk/pull/9519/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9519&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8290379
  Stats: 56 lines in 2 files changed: 55 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9519.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9519/head:pull/9519

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

From vromero at openjdk.org  Fri Jul 15 17:18:29 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 15 Jul 2022 17:18:29 GMT
Subject: RFR: 8285935: Spurious lint warning for static method accessed through
 instance qualifier
Message-ID: <qYH89lnOxAYYDxfbftLTopYv69Uf7l-w_KglLORzgeM=.33e96f4e-e9a9-4b9c-bea9-65665ede25df@github.com>

Please review this simple fix which is adding a more precise, I hope, warning for the case when a static method or field is being accessed using an anonymous class instance.

TIA

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

Commit messages:
 - 8285935: Spurious lint warning for static method accessed through instance qualifier

Changes: https://git.openjdk.org/jdk/pull/9521/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9521&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8285935
  Stats: 33 lines in 6 files changed: 29 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/9521.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9521/head:pull/9521

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

From dholmes at openjdk.org  Sun Jul 17 23:03:37 2022
From: dholmes at openjdk.org (David Holmes)
Date: Sun, 17 Jul 2022 23:03:37 GMT
Subject: [jdk19] RFR: 8278274: Update nroff pages in JDK 19 before RC
Message-ID: <d3yzjvTqRkMax-Aq0esRIjkMIZQizVgw_zuq41xVhw8=.bfd1fe45-9d79-4bda-bced-234a4f91a227@github.com>

Please review these changes to the nroff manpage files so that they match their markdown sources that Oracle maintains.

All pages at a minimum have 19-ea replaced with 19, and copyright set to 2022 if needed.  Additionally:

The Java manpage was missing updates from:
- [JDK-8282018](https://bugs.openjdk.org/browse/JDK-8282018): Add captions to tables on java man page.

The Java manpage has slight formatting differences from:
- [JDK-8262004](https://bugs.openjdk.org/browse/JDK-8262004): Classpath separator: Man page says semicolon; should be colon on Linux
- [JDK-8236569](https://bugs.openjdk.org/browse/JDK-8236569): -Xss not multiple of 4K does not work for the main thread on macOS

The Java manpage has a typo fixed in mainline by [JDK-8279047](https://bugs.openjdk.org/browse/JDK-8279047) (for JDK 20)


The keytool manpage was missing updates from:
- [JDK-8282014](https://bugs.openjdk.org/browse/JDK-8282014): Add captions to tables on keytool man page.
- [JDK-8267319](https://bugs.openjdk.org/browse/JDK-8267319): Use larger default key sizes and algorithms based on CNSA

The jar manpage was missing updates from:
- [JDK-8278764](https://bugs.openjdk.org/browse/JDK-8278764): jar and jmod man pages need the new --date documenting from CSR [JDK-8277755](https://bugs.openjdk.org/browse/JDK-8277755)

The jarsigner manpage was missing updates from:
- [JDK-8282015](https://bugs.openjdk.org/browse/JDK-8282015): Add captions to tables on jarsigner man page.
- [JDK-8267319](https://bugs.openjdk.org/browse/JDK-8267319): Use larger default key sizes and algorithms based on CNSA

The javadoc manpage was missing updates from:
- [JDK-8279034](https://bugs.openjdk.org/browse/JDK-8279034): Update man page for javadoc `--date` option

The jmod manpage was missing updates from:
- [JDK-8278764](https://bugs.openjdk.org/browse/JDK-8278764): jar and jmod man pages need the new --date documenting from CSR [JDK-8277755](https://bugs.openjdk.org/browse/JDK-8277755)

The jpackage manpage was missing updates from:
- [JDK-8285146](https://bugs.openjdk.org/browse/JDK-8285146): Document jpackage resource dir feature
- [JDK-8284695](https://bugs.openjdk.org/browse/JDK-8284695): Update jpackage man pages for JDK 19
- [JDK-8284209](https://bugs.openjdk.org/browse/JDK-8284209): Replace remaining usages of 'a the' in source code

The jshell manpage was missing updates from:
- [JDK-8282016](https://bugs.openjdk.org/browse/JDK-8282016): Add captions to tables on jshell man page.

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

Commit messages:
 - 8278274: Update nroff pages in JDK 19 before RC

Changes: https://git.openjdk.org/jdk19/pull/145/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=145&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8278274
  Stats: 515 lines in 28 files changed: 431 ins; 16 del; 68 mod
  Patch: https://git.openjdk.org/jdk19/pull/145.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/145/head:pull/145

PR: https://git.openjdk.org/jdk19/pull/145

From jlahoda at openjdk.org  Mon Jul 18 15:07:07 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 18 Jul 2022 15:07:07 GMT
Subject: RFR: 8290379: Parse error with parenthesized pattern and guard
 using an array
In-Reply-To: <Wmpv3eXCHkrAeOaEPafXTobTUyCjlfg6SzbLf9vKAdA=.42fe09c3-6eb3-44b9-82e6-52e8aacc6d72@github.com>
References: <Wmpv3eXCHkrAeOaEPafXTobTUyCjlfg6SzbLf9vKAdA=.42fe09c3-6eb3-44b9-82e6-52e8aacc6d72@github.com>
Message-ID: <mD2D3id_GXq105WX69X-fxHdp0-QyQdpdOJHTmDQuaQ=.0079c615-a586-453b-8a33-7cbae0e59ac4@github.com>

On Fri, 15 Jul 2022 16:15:52 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> Addresses the parsing error for the following case:
> 
> case (String s) when (arr[0] == 1) -> 0;

Seems reasonable, but the code may possibly be simpler.

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

> 3171:                     } else {
> 3172:                         // This is a potential guard, if we are already in a pattern
> 3173:                         return pendingResult == PatternResult.PATTERN

Why not simply `return pendingResult;`?

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

Marked as reviewed by jlahoda (Reviewer).

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

From jjg at openjdk.org  Mon Jul 18 15:24:06 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 18 Jul 2022 15:24:06 GMT
Subject: [jdk19] RFR: 8278274: Update nroff pages in JDK 19 before RC
In-Reply-To: <d3yzjvTqRkMax-Aq0esRIjkMIZQizVgw_zuq41xVhw8=.bfd1fe45-9d79-4bda-bced-234a4f91a227@github.com>
References: <d3yzjvTqRkMax-Aq0esRIjkMIZQizVgw_zuq41xVhw8=.bfd1fe45-9d79-4bda-bced-234a4f91a227@github.com>
Message-ID: <75mqpwhSuTfYsLguWkG0izRelatkAX7wOwsjC3crYFI=.2449d017-855e-4da9-b1b3-2fcee65cba2c@github.com>

On Sun, 17 Jul 2022 22:44:02 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Please review these changes to the nroff manpage files so that they match their markdown sources that Oracle maintains.
> 
> All pages at a minimum have 19-ea replaced with 19, and copyright set to 2022 if needed.  Additionally:
> 
> The Java manpage was missing updates from:
> - [JDK-8282018](https://bugs.openjdk.org/browse/JDK-8282018): Add captions to tables on java man page.
> 
> The Java manpage has slight formatting differences from:
> - [JDK-8262004](https://bugs.openjdk.org/browse/JDK-8262004): Classpath separator: Man page says semicolon; should be colon on Linux
> - [JDK-8236569](https://bugs.openjdk.org/browse/JDK-8236569): -Xss not multiple of 4K does not work for the main thread on macOS
> 
> The Java manpage has a typo fixed in mainline by [JDK-8279047](https://bugs.openjdk.org/browse/JDK-8279047) (for JDK 20)
> 
> 
> The keytool manpage was missing updates from:
> - [JDK-8282014](https://bugs.openjdk.org/browse/JDK-8282014): Add captions to tables on keytool man page.
> - [JDK-8267319](https://bugs.openjdk.org/browse/JDK-8267319): Use larger default key sizes and algorithms based on CNSA
> 
> The jar manpage was missing updates from:
> - [JDK-8278764](https://bugs.openjdk.org/browse/JDK-8278764): jar and jmod man pages need the new --date documenting from CSR [JDK-8277755](https://bugs.openjdk.org/browse/JDK-8277755)
> 
> The jarsigner manpage was missing updates from:
> - [JDK-8282015](https://bugs.openjdk.org/browse/JDK-8282015): Add captions to tables on jarsigner man page.
> - [JDK-8267319](https://bugs.openjdk.org/browse/JDK-8267319): Use larger default key sizes and algorithms based on CNSA
> 
> The javadoc manpage was missing updates from:
> - [JDK-8279034](https://bugs.openjdk.org/browse/JDK-8279034): Update man page for javadoc `--date` option
> 
> The jmod manpage was missing updates from:
> - [JDK-8278764](https://bugs.openjdk.org/browse/JDK-8278764): jar and jmod man pages need the new --date documenting from CSR [JDK-8277755](https://bugs.openjdk.org/browse/JDK-8277755)
> 
> The jpackage manpage was missing updates from:
> - [JDK-8285146](https://bugs.openjdk.org/browse/JDK-8285146): Document jpackage resource dir feature
> - [JDK-8284695](https://bugs.openjdk.org/browse/JDK-8284695): Update jpackage man pages for JDK 19
> - [JDK-8284209](https://bugs.openjdk.org/browse/JDK-8284209): Replace remaining usages of 'a the' in source code
> 
> The jshell manpage was missing updates from:
> - [JDK-8282016](https://bugs.openjdk.org/browse/JDK-8282016): Add captions to tables on jshell man page.

src/java.base/share/man/keytool.1 line 456:

> 454: \f[CB]PrivateKeyEntry\f[R] for the signer that already exists in the
> 455: keystore.
> 456: This option is used to sign the certificate with the signer?s private

Not a problem with this PR as such, but we still have a `?` character in the output.

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

PR: https://git.openjdk.org/jdk19/pull/145

From jjg at openjdk.org  Mon Jul 18 15:30:09 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 18 Jul 2022 15:30:09 GMT
Subject: [jdk19] RFR: 8278274: Update nroff pages in JDK 19 before RC
In-Reply-To: <d3yzjvTqRkMax-Aq0esRIjkMIZQizVgw_zuq41xVhw8=.bfd1fe45-9d79-4bda-bced-234a4f91a227@github.com>
References: <d3yzjvTqRkMax-Aq0esRIjkMIZQizVgw_zuq41xVhw8=.bfd1fe45-9d79-4bda-bced-234a4f91a227@github.com>
Message-ID: <UwyC1L1eTUZSFy6b2EYlgy4FkUS1laKFq-MMuFvZKw0=.40611a87-50c9-43b0-9d50-a3e24e6c359e@github.com>

On Sun, 17 Jul 2022 22:44:02 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Please review these changes to the nroff manpage files so that they match their markdown sources that Oracle maintains.
> 
> All pages at a minimum have 19-ea replaced with 19, and copyright set to 2022 if needed.  Additionally:
> 
> The Java manpage was missing updates from:
> - [JDK-8282018](https://bugs.openjdk.org/browse/JDK-8282018): Add captions to tables on java man page.
> 
> The Java manpage has slight formatting differences from:
> - [JDK-8262004](https://bugs.openjdk.org/browse/JDK-8262004): Classpath separator: Man page says semicolon; should be colon on Linux
> - [JDK-8236569](https://bugs.openjdk.org/browse/JDK-8236569): -Xss not multiple of 4K does not work for the main thread on macOS
> 
> The Java manpage has a typo fixed in mainline by [JDK-8279047](https://bugs.openjdk.org/browse/JDK-8279047) (for JDK 20)
> 
> 
> The keytool manpage was missing updates from:
> - [JDK-8282014](https://bugs.openjdk.org/browse/JDK-8282014): Add captions to tables on keytool man page.
> - [JDK-8267319](https://bugs.openjdk.org/browse/JDK-8267319): Use larger default key sizes and algorithms based on CNSA
> 
> The jar manpage was missing updates from:
> - [JDK-8278764](https://bugs.openjdk.org/browse/JDK-8278764): jar and jmod man pages need the new --date documenting from CSR [JDK-8277755](https://bugs.openjdk.org/browse/JDK-8277755)
> 
> The jarsigner manpage was missing updates from:
> - [JDK-8282015](https://bugs.openjdk.org/browse/JDK-8282015): Add captions to tables on jarsigner man page.
> - [JDK-8267319](https://bugs.openjdk.org/browse/JDK-8267319): Use larger default key sizes and algorithms based on CNSA
> 
> The javadoc manpage was missing updates from:
> - [JDK-8279034](https://bugs.openjdk.org/browse/JDK-8279034): Update man page for javadoc `--date` option
> 
> The jmod manpage was missing updates from:
> - [JDK-8278764](https://bugs.openjdk.org/browse/JDK-8278764): jar and jmod man pages need the new --date documenting from CSR [JDK-8277755](https://bugs.openjdk.org/browse/JDK-8277755)
> 
> The jpackage manpage was missing updates from:
> - [JDK-8285146](https://bugs.openjdk.org/browse/JDK-8285146): Document jpackage resource dir feature
> - [JDK-8284695](https://bugs.openjdk.org/browse/JDK-8284695): Update jpackage man pages for JDK 19
> - [JDK-8284209](https://bugs.openjdk.org/browse/JDK-8284209): Replace remaining usages of 'a the' in source code
> 
> The jshell manpage was missing updates from:
> - [JDK-8282016](https://bugs.openjdk.org/browse/JDK-8282016): Add captions to tables on jshell man page.

The version changes in each file look good (`19-ea` to `19`).
The changes for javadoc look good.

I looked over the other changes for other files, and while they look good, I cannot speak for their technical accuracy. That being said, this is an automated process deriving info from upstream, so is likely OK.

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

Marked as reviewed by jjg (Reviewer).

PR: https://git.openjdk.org/jdk19/pull/145

From abimpoudis at openjdk.org  Mon Jul 18 15:34:47 2022
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 18 Jul 2022 15:34:47 GMT
Subject: RFR: 8290379: Parse error with parenthesized pattern and guard
 using an array [v2]
In-Reply-To: <Wmpv3eXCHkrAeOaEPafXTobTUyCjlfg6SzbLf9vKAdA=.42fe09c3-6eb3-44b9-82e6-52e8aacc6d72@github.com>
References: <Wmpv3eXCHkrAeOaEPafXTobTUyCjlfg6SzbLf9vKAdA=.42fe09c3-6eb3-44b9-82e6-52e8aacc6d72@github.com>
Message-ID: <WbuAfYK9bZwPclAZ2SequBeUqNgziW31BRbEHcGCCfw=.87e22644-df72-426a-ae6b-dfed305cf74e@github.com>

> Addresses the parsing error for the following case:
> 
> case (String s) when (arr[0] == 1) -> 0;

Aggelos Biboudis has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  8290379: Parse error with parenthesized pattern and guard using an array

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9519/files
  - new: https://git.openjdk.org/jdk/pull/9519/files/32cd4677..0fb22ebe

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

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

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

From abimpoudis at openjdk.org  Mon Jul 18 15:34:48 2022
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 18 Jul 2022 15:34:48 GMT
Subject: RFR: 8290379: Parse error with parenthesized pattern and guard
 using an array [v2]
In-Reply-To: <mD2D3id_GXq105WX69X-fxHdp0-QyQdpdOJHTmDQuaQ=.0079c615-a586-453b-8a33-7cbae0e59ac4@github.com>
References: <Wmpv3eXCHkrAeOaEPafXTobTUyCjlfg6SzbLf9vKAdA=.42fe09c3-6eb3-44b9-82e6-52e8aacc6d72@github.com>
 <mD2D3id_GXq105WX69X-fxHdp0-QyQdpdOJHTmDQuaQ=.0079c615-a586-453b-8a33-7cbae0e59ac4@github.com>
Message-ID: <6b5RNusWXUtGbeH2wAMqJmMMAHeS9oKAs9eJ7gG9XQA=.9ca0ddd9-8cf3-445a-aee0-8f2edbff1e56@github.com>

On Mon, 18 Jul 2022 15:02:25 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Aggelos Biboudis has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
>> 
>>   8290379: Parse error with parenthesized pattern and guard using an array
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 3173:
> 
>> 3171:                     } else {
>> 3172:                         // This is a potential guard, if we are already in a pattern
>> 3173:                         return pendingResult == PatternResult.PATTERN
> 
> Why not simply `return pendingResult;`?

Good question! ?

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

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

From dholmes at openjdk.org  Mon Jul 18 23:32:04 2022
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 18 Jul 2022 23:32:04 GMT
Subject: [jdk19] RFR: 8278274: Update nroff pages in JDK 19 before RC
In-Reply-To: <UwyC1L1eTUZSFy6b2EYlgy4FkUS1laKFq-MMuFvZKw0=.40611a87-50c9-43b0-9d50-a3e24e6c359e@github.com>
References: <d3yzjvTqRkMax-Aq0esRIjkMIZQizVgw_zuq41xVhw8=.bfd1fe45-9d79-4bda-bced-234a4f91a227@github.com>
 <UwyC1L1eTUZSFy6b2EYlgy4FkUS1laKFq-MMuFvZKw0=.40611a87-50c9-43b0-9d50-a3e24e6c359e@github.com>
Message-ID: <Bx5KJ0K1oEDxEkvQf_xBVYiL1foF38AVFPy9tLp6YTg=.f851a628-86b6-4edf-89b1-c91f13728a51@github.com>

On Mon, 18 Jul 2022 15:26:23 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review these changes to the nroff manpage files so that they match their markdown sources that Oracle maintains.
>> 
>> All pages at a minimum have 19-ea replaced with 19, and copyright set to 2022 if needed.  Additionally:
>> 
>> The Java manpage was missing updates from:
>> - [JDK-8282018](https://bugs.openjdk.org/browse/JDK-8282018): Add captions to tables on java man page.
>> 
>> The Java manpage has slight formatting differences from:
>> - [JDK-8262004](https://bugs.openjdk.org/browse/JDK-8262004): Classpath separator: Man page says semicolon; should be colon on Linux
>> - [JDK-8236569](https://bugs.openjdk.org/browse/JDK-8236569): -Xss not multiple of 4K does not work for the main thread on macOS
>> 
>> The Java manpage has a typo fixed in mainline by [JDK-8279047](https://bugs.openjdk.org/browse/JDK-8279047) (for JDK 20)
>> 
>> 
>> The keytool manpage was missing updates from:
>> - [JDK-8282014](https://bugs.openjdk.org/browse/JDK-8282014): Add captions to tables on keytool man page.
>> - [JDK-8267319](https://bugs.openjdk.org/browse/JDK-8267319): Use larger default key sizes and algorithms based on CNSA
>> 
>> The jar manpage was missing updates from:
>> - [JDK-8278764](https://bugs.openjdk.org/browse/JDK-8278764): jar and jmod man pages need the new --date documenting from CSR [JDK-8277755](https://bugs.openjdk.org/browse/JDK-8277755)
>> 
>> The jarsigner manpage was missing updates from:
>> - [JDK-8282015](https://bugs.openjdk.org/browse/JDK-8282015): Add captions to tables on jarsigner man page.
>> - [JDK-8267319](https://bugs.openjdk.org/browse/JDK-8267319): Use larger default key sizes and algorithms based on CNSA
>> 
>> The javadoc manpage was missing updates from:
>> - [JDK-8279034](https://bugs.openjdk.org/browse/JDK-8279034): Update man page for javadoc `--date` option
>> 
>> The jmod manpage was missing updates from:
>> - [JDK-8278764](https://bugs.openjdk.org/browse/JDK-8278764): jar and jmod man pages need the new --date documenting from CSR [JDK-8277755](https://bugs.openjdk.org/browse/JDK-8277755)
>> 
>> The jpackage manpage was missing updates from:
>> - [JDK-8285146](https://bugs.openjdk.org/browse/JDK-8285146): Document jpackage resource dir feature
>> - [JDK-8284695](https://bugs.openjdk.org/browse/JDK-8284695): Update jpackage man pages for JDK 19
>> - [JDK-8284209](https://bugs.openjdk.org/browse/JDK-8284209): Replace remaining usages of 'a the' in source code
>> 
>> The jshell manpage was missing updates from:
>> - [JDK-8282016](https://bugs.openjdk.org/browse/JDK-8282016): Add captions to tables on jshell man page.
>
> The version changes in each file look good (`19-ea` to `19`).
> The changes for javadoc look good.
> 
> I looked over the other changes for other files, and while they look good, I cannot speak for their technical accuracy. That being said, this is an automated process deriving info from upstream, so is likely OK.

Thanks for the review @jonathan-gibbons ! I'll wait a day in case there are any further comments.

> src/java.base/share/man/keytool.1 line 456:
> 
>> 454: \f[CB]PrivateKeyEntry\f[R] for the signer that already exists in the
>> 455: keystore.
>> 456: This option is used to sign the certificate with the signer?s private
> 
> Not a problem with this PR as such, but we still have a `?` character in the output.

Yeah I spotted that too, but it would need to be fixed in source and nroff.  Must be some kind of "smart quote" from an editor. Do you think this needs to be fixed or just handle it in mainline?

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

PR: https://git.openjdk.org/jdk19/pull/145

From abimpoudis at openjdk.org  Tue Jul 19 09:06:59 2022
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Tue, 19 Jul 2022 09:06:59 GMT
Subject: Integrated: 8290379: Parse error with parenthesized pattern and guard
 using an array
In-Reply-To: <Wmpv3eXCHkrAeOaEPafXTobTUyCjlfg6SzbLf9vKAdA=.42fe09c3-6eb3-44b9-82e6-52e8aacc6d72@github.com>
References: <Wmpv3eXCHkrAeOaEPafXTobTUyCjlfg6SzbLf9vKAdA=.42fe09c3-6eb3-44b9-82e6-52e8aacc6d72@github.com>
Message-ID: <mfuprnuJFadbWJ8_1fzBnIaiogdXwDZPN5FIwgvqKCw=.a63804fe-f4f7-4a52-93cc-a090f9f14792@github.com>

On Fri, 15 Jul 2022 16:15:52 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> Addresses the parsing error for the following case:
> 
> case (String s) when (arr[0] == 1) -> 0;

This pull request has now been integrated.

Changeset: f5a7de86
Author:    Aggelos Biboudis <abimpoudis at openjdk.org>
Committer: Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f5a7de86278ce019ffe44a92921dbb4018451a73
Stats:     54 lines in 2 files changed: 53 ins; 0 del; 1 mod

8290379: Parse error with parenthesized pattern and guard using an array

Reviewed-by: jlahoda

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

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

From dholmes at openjdk.org  Wed Jul 20 04:44:05 2022
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 20 Jul 2022 04:44:05 GMT
Subject: [jdk19] Integrated: 8278274: Update nroff pages in JDK 19 before RC
In-Reply-To: <d3yzjvTqRkMax-Aq0esRIjkMIZQizVgw_zuq41xVhw8=.bfd1fe45-9d79-4bda-bced-234a4f91a227@github.com>
References: <d3yzjvTqRkMax-Aq0esRIjkMIZQizVgw_zuq41xVhw8=.bfd1fe45-9d79-4bda-bced-234a4f91a227@github.com>
Message-ID: <AMZ5T-Qky56FldFenzaRAnlaGG4Nxts3inu5GfIlS3c=.7e260c05-107b-48dd-b04b-48e791d0a7d6@github.com>

On Sun, 17 Jul 2022 22:44:02 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Please review these changes to the nroff manpage files so that they match their markdown sources that Oracle maintains.
> 
> All pages at a minimum have 19-ea replaced with 19, and copyright set to 2022 if needed.  Additionally:
> 
> The Java manpage was missing updates from:
> - [JDK-8282018](https://bugs.openjdk.org/browse/JDK-8282018): Add captions to tables on java man page.
> 
> The Java manpage has slight formatting differences from:
> - [JDK-8262004](https://bugs.openjdk.org/browse/JDK-8262004): Classpath separator: Man page says semicolon; should be colon on Linux
> - [JDK-8236569](https://bugs.openjdk.org/browse/JDK-8236569): -Xss not multiple of 4K does not work for the main thread on macOS
> 
> The Java manpage has a typo fixed in mainline by [JDK-8279047](https://bugs.openjdk.org/browse/JDK-8279047) (for JDK 20)
> 
> 
> The keytool manpage was missing updates from:
> - [JDK-8282014](https://bugs.openjdk.org/browse/JDK-8282014): Add captions to tables on keytool man page.
> - [JDK-8267319](https://bugs.openjdk.org/browse/JDK-8267319): Use larger default key sizes and algorithms based on CNSA
> 
> The jar manpage was missing updates from:
> - [JDK-8278764](https://bugs.openjdk.org/browse/JDK-8278764): jar and jmod man pages need the new --date documenting from CSR [JDK-8277755](https://bugs.openjdk.org/browse/JDK-8277755)
> 
> The jarsigner manpage was missing updates from:
> - [JDK-8282015](https://bugs.openjdk.org/browse/JDK-8282015): Add captions to tables on jarsigner man page.
> - [JDK-8267319](https://bugs.openjdk.org/browse/JDK-8267319): Use larger default key sizes and algorithms based on CNSA
> 
> The javadoc manpage was missing updates from:
> - [JDK-8279034](https://bugs.openjdk.org/browse/JDK-8279034): Update man page for javadoc `--date` option
> 
> The jmod manpage was missing updates from:
> - [JDK-8278764](https://bugs.openjdk.org/browse/JDK-8278764): jar and jmod man pages need the new --date documenting from CSR [JDK-8277755](https://bugs.openjdk.org/browse/JDK-8277755)
> 
> The jpackage manpage was missing updates from:
> - [JDK-8285146](https://bugs.openjdk.org/browse/JDK-8285146): Document jpackage resource dir feature
> - [JDK-8284695](https://bugs.openjdk.org/browse/JDK-8284695): Update jpackage man pages for JDK 19
> - [JDK-8284209](https://bugs.openjdk.org/browse/JDK-8284209): Replace remaining usages of 'a the' in source code
> 
> The jshell manpage was missing updates from:
> - [JDK-8282016](https://bugs.openjdk.org/browse/JDK-8282016): Add captions to tables on jshell man page.

This pull request has now been integrated.

Changeset: 618f3a82
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk19/commit/618f3a82a4d45cdb66b86259ae60dd1c322b987b
Stats:     515 lines in 28 files changed: 431 ins; 16 del; 68 mod

8278274: Update nroff pages in JDK 19 before RC

Reviewed-by: jjg

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

PR: https://git.openjdk.org/jdk19/pull/145

From dholmes at openjdk.org  Wed Jul 20 05:37:13 2022
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 20 Jul 2022 05:37:13 GMT
Subject: [jdk19] RFR: 8278274: Update nroff pages in JDK 19 before RC
In-Reply-To: <Bx5KJ0K1oEDxEkvQf_xBVYiL1foF38AVFPy9tLp6YTg=.f851a628-86b6-4edf-89b1-c91f13728a51@github.com>
References: <d3yzjvTqRkMax-Aq0esRIjkMIZQizVgw_zuq41xVhw8=.bfd1fe45-9d79-4bda-bced-234a4f91a227@github.com>
 <UwyC1L1eTUZSFy6b2EYlgy4FkUS1laKFq-MMuFvZKw0=.40611a87-50c9-43b0-9d50-a3e24e6c359e@github.com>
 <Bx5KJ0K1oEDxEkvQf_xBVYiL1foF38AVFPy9tLp6YTg=.f851a628-86b6-4edf-89b1-c91f13728a51@github.com>
Message-ID: <BhpRMQOoet5mjjrvmhiT1okUnn9PAbPuGa4PE3HNaAM=.2461be8a-096b-4e18-88f2-10b9e2dc519d@github.com>

On Mon, 18 Jul 2022 23:27:58 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/java.base/share/man/keytool.1 line 456:
>> 
>>> 454: \f[CB]PrivateKeyEntry\f[R] for the signer that already exists in the
>>> 455: keystore.
>>> 456: This option is used to sign the certificate with the signer?s private
>> 
>> Not a problem with this PR as such, but we still have a `?` character in the output.
>
> Yeah I spotted that too, but it would need to be fixed in source and nroff.  Must be some kind of "smart quote" from an editor. Do you think this needs to be fixed or just handle it in mainline?

Filed [JDK-8290626](https://bugs.openjdk.org/browse/JDK-8290626). It can easily be fixed before RDP2.

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

PR: https://git.openjdk.org/jdk19/pull/145

From abimpoudis at openjdk.org  Wed Jul 20 14:05:30 2022
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 20 Jul 2022 14:05:30 GMT
Subject: RFR: 8289647: AssertionError during annotation processing of record
 related tests
Message-ID: <oFQUtgja9NR52EAjFkHFh8gjyrj1zbf_XYsQLDNR6c0=.5f30ff04-e786-4206-bc05-9fd33e8abf29@github.com>

This PR fixes a situation where the same record component was entered *and* schedule for later annotation at the same time.

The test case of the original bug report was recreated as part of "RecordCompilationTests". I tested that it breaks with the expected assertion error mentioned on the original bug report, without the proposed changes.

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

Commit messages:
 - 8289647: AssertionError during annotation processing of record related tests

Changes: https://git.openjdk.org/jdk/pull/9570/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9570&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8289647
  Stats: 113 lines in 3 files changed: 76 ins; 30 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/9570.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9570/head:pull/9570

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

From abimpoudis at openjdk.org  Wed Jul 20 14:07:34 2022
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 20 Jul 2022 14:07:34 GMT
Subject: RFR: 8289647: AssertionError during annotation processing of
 record related tests [v2]
In-Reply-To: <oFQUtgja9NR52EAjFkHFh8gjyrj1zbf_XYsQLDNR6c0=.5f30ff04-e786-4206-bc05-9fd33e8abf29@github.com>
References: <oFQUtgja9NR52EAjFkHFh8gjyrj1zbf_XYsQLDNR6c0=.5f30ff04-e786-4206-bc05-9fd33e8abf29@github.com>
Message-ID: <q72jOzGu5fD6pJN_uG6ANoqyldoN3aopqHP1z3-PI6I=.b7fa7d66-b1f3-4a02-b41f-5c1f821fab53@github.com>

> This PR fixes a situation where the same record component was entered *and* schedule for later annotation at the same time.
> 
> The test case of the original bug report was recreated as part of "RecordCompilationTests". I tested that it breaks with the expected assertion error mentioned on the original bug report, without the proposed changes.

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

  Add bug id at existing test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9570/files
  - new: https://git.openjdk.org/jdk/pull/9570/files/83a3c52e..74fcc2a6

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

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

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

From dcubed at openjdk.org  Wed Jul 20 22:44:07 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 20 Jul 2022 22:44:07 GMT
Subject: RFR: Merge jdk19
Message-ID: <AEogMC6k_YZRhpfkn8Nu7DO26WE_lY5ATIWJEZLLC6s=.2c11afbd-30cf-43c2-af5f-3a923e209370@github.com>

Merge jdk19 -> jdk20.

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

Commit messages:
 - Merge
 - 8290625: Test jdk/javadoc/tool/CheckManPageOptions.java after manpage update
 - 8278274: Update nroff pages in JDK 19 before RC
 - 8287916: Address the inconsistency between the constant array and pool size
 - 8285407: Improve Xalan supports
 - 8282676: Improve subject handling
 - 8284370: Improve zlib usage
 - 8283190: Improve MIDI processing
 - 8281866: Enhance MethodHandle invocations
 - 8281859: Improve class compilation
 - ... and 3 more: https://git.openjdk.org/jdk/compare/b1817a30...aaca8b9d

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

Changes: https://git.openjdk.org/jdk/pull/9578/files
  Stats: 504 lines in 28 files changed: 428 ins; 16 del; 60 mod
  Patch: https://git.openjdk.org/jdk/pull/9578.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9578/head:pull/9578

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

From dcubed at openjdk.org  Wed Jul 20 22:59:25 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 20 Jul 2022 22:59:25 GMT
Subject: RFR: Merge jdk19
In-Reply-To: <AEogMC6k_YZRhpfkn8Nu7DO26WE_lY5ATIWJEZLLC6s=.2c11afbd-30cf-43c2-af5f-3a923e209370@github.com>
References: <AEogMC6k_YZRhpfkn8Nu7DO26WE_lY5ATIWJEZLLC6s=.2c11afbd-30cf-43c2-af5f-3a923e209370@github.com>
Message-ID: <ejPn-O0FlUDlzib8bV49EnPrKYeCQTWUAxRY9CayeqY=.76121730-cfaa-40f3-8be6-6c71897bbe0b@github.com>

On Wed, 20 Jul 2022 22:20:31 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> Merge jdk19 -> jdk20.

Mach5 Tier1 passed.

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

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

From dcubed at openjdk.org  Wed Jul 20 22:59:26 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 20 Jul 2022 22:59:26 GMT
Subject: Integrated: Merge jdk19
In-Reply-To: <AEogMC6k_YZRhpfkn8Nu7DO26WE_lY5ATIWJEZLLC6s=.2c11afbd-30cf-43c2-af5f-3a923e209370@github.com>
References: <AEogMC6k_YZRhpfkn8Nu7DO26WE_lY5ATIWJEZLLC6s=.2c11afbd-30cf-43c2-af5f-3a923e209370@github.com>
Message-ID: <NlbvRtErZWaBJsWsUjWLzQw8ZBrSn6f81MI1KQ_VE_k=.28531e99-8501-4f25-b621-52c51ef0b37c@github.com>

On Wed, 20 Jul 2022 22:20:31 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> Merge jdk19 -> jdk20.

This pull request has now been integrated.

Changeset: 9c19d89c
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9c19d89c9c564e436732c5f7851f4960fb5d783c
Stats:     504 lines in 28 files changed: 428 ins; 16 del; 60 mod

Merge

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

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

From dholmes at openjdk.org  Thu Jul 21 00:43:38 2022
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 21 Jul 2022 00:43:38 GMT
Subject: RFR: 8290489: Initial nroff manpage generation for JDK 20
Message-ID: <Oh3Bd-n_TP1kz1Ir2uR8dmgdQouSgZ24rzV1rhKVzLU=.ebb70241-1990-49a6-a47a-f56df55570de@github.com>

The version will be 20-ea and the copyright year 2023 (for March 2023 release date).

Thanks.

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

Commit messages:
 - 8290489: Initial nroff manpage generation for JDK 20

Changes: https://git.openjdk.org/jdk/pull/9581/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9581&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8290489
  Stats: 28 lines in 28 files changed: 0 ins; 0 del; 28 mod
  Patch: https://git.openjdk.org/jdk/pull/9581.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9581/head:pull/9581

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

From dcubed at openjdk.org  Thu Jul 21 01:07:02 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 21 Jul 2022 01:07:02 GMT
Subject: RFR: 8290489: Initial nroff manpage generation for JDK 20
In-Reply-To: <Oh3Bd-n_TP1kz1Ir2uR8dmgdQouSgZ24rzV1rhKVzLU=.ebb70241-1990-49a6-a47a-f56df55570de@github.com>
References: <Oh3Bd-n_TP1kz1Ir2uR8dmgdQouSgZ24rzV1rhKVzLU=.ebb70241-1990-49a6-a47a-f56df55570de@github.com>
Message-ID: <2chBf83EGB9f7D67rYVKNXRnOOWKUa0hLm7XNhCa5QU=.9bca77c8-36e8-4763-af9b-3d8c1df238c1@github.com>

On Thu, 21 Jul 2022 00:34:53 GMT, David Holmes <dholmes at openjdk.org> wrote:

> The version will be 20-ea and the copyright year 2023 (for March 2023 release date).
> 
> Thanks.

Thumbs up. This is a trivial change.

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

Marked as reviewed by dcubed (Reviewer).

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

From dholmes at openjdk.org  Thu Jul 21 05:49:57 2022
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 21 Jul 2022 05:49:57 GMT
Subject: RFR: 8290489: Initial nroff manpage generation for JDK 20
In-Reply-To: <2chBf83EGB9f7D67rYVKNXRnOOWKUa0hLm7XNhCa5QU=.9bca77c8-36e8-4763-af9b-3d8c1df238c1@github.com>
References: <Oh3Bd-n_TP1kz1Ir2uR8dmgdQouSgZ24rzV1rhKVzLU=.ebb70241-1990-49a6-a47a-f56df55570de@github.com>
 <2chBf83EGB9f7D67rYVKNXRnOOWKUa0hLm7XNhCa5QU=.9bca77c8-36e8-4763-af9b-3d8c1df238c1@github.com>
Message-ID: <gZuNsiJo3fWnsEb8TsdEbuKySkKHTvKtpP6T_zaRfuI=.04048e7d-88cf-43ba-959d-67a5b14eb833@github.com>

On Thu, 21 Jul 2022 01:03:46 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> The version will be 20-ea and the copyright year 2023 (for March 2023 release date).
>> 
>> Thanks.
>
> Thumbs up. This is a trivial change.

Thanks @dcubed-ojdk !

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

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

From dholmes at openjdk.org  Fri Jul 22 04:45:03 2022
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 22 Jul 2022 04:45:03 GMT
Subject: Integrated: 8290489: Initial nroff manpage generation for JDK 20
In-Reply-To: <Oh3Bd-n_TP1kz1Ir2uR8dmgdQouSgZ24rzV1rhKVzLU=.ebb70241-1990-49a6-a47a-f56df55570de@github.com>
References: <Oh3Bd-n_TP1kz1Ir2uR8dmgdQouSgZ24rzV1rhKVzLU=.ebb70241-1990-49a6-a47a-f56df55570de@github.com>
Message-ID: <2vnXOAQlpH9CGjFVkGkL4pWyCPxneNmWrxV8V6j5b_w=.c951b25d-e0cd-4902-ad79-200ca4238f91@github.com>

On Thu, 21 Jul 2022 00:34:53 GMT, David Holmes <dholmes at openjdk.org> wrote:

> The version will be 20-ea and the copyright year 2023 (for March 2023 release date).
> 
> Thanks.

This pull request has now been integrated.

Changeset: e9f97b2e
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e9f97b2e8cf301ba6b69101e5efc5c71d26bc87b
Stats:     28 lines in 28 files changed: 0 ins; 0 del; 28 mod

8290489: Initial nroff manpage generation for JDK 20

Reviewed-by: dcubed

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

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

From jlahoda at openjdk.org  Fri Jul 22 07:04:08 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 22 Jul 2022 07:04:08 GMT
Subject: RFR: 8290561: Coalesce incubator-module warnings for single-file
 source-code programs
Message-ID: <ZGC5hjaFFTPuZaiVWumsbXyNnLw5lL9BoewWEwlubvc=.23a364c2-ef92-43e9-88af-88a8f34624b3@github.com>

Consider a trivial code like:

public class Main {
     public static void main(String... args) {}
}


And an execution like:

$ java --add-modules jdk.incubator.concurrent Main.java 
WARNING: Using incubator modules: jdk.incubator.concurrent
warning: using incubating module(s): jdk.incubator.concurrent
1 warning


Having two warnings (one from runtime, one from javac) seems unnecessary. The patch proposed herein tries to avoid the javac warning, keeping only the runtime one. The conditions under which an incubator module is ignored w.r.t. this warning are:

 * the boot Module layer has the module (hence, presumably, the runtime already provided the warning)
 * the javac run is (likely) from the source launcher. This is being done using a custom javac option, `-XDsourceLauncher` (which can possibly be used in other cases).

This is to avoid cases where we would incorrectly suppress the incubator warning, e.g. when `-XDsourceLauncher` would be passed on the command line.

There are other ways to attempt to detect javac invocations from the source launcher - a distinct file manager is used by the source launcher (but detection of the specific file manager does not feel in line with general javac approach); or use of the `jdk.internal.javac.source` system property set by the native launcher (but this is only set when `--source` option is used, as far as I know, and javac also typically does not check system properties).

Note that there is JDK-8290563 to improve the text of the javac warning.

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

Commit messages:
 - 8290561: Coalesce incubator-module warnings for single-file source-code programs

Changes: https://git.openjdk.org/jdk/pull/9607/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9607&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8290561
  Stats: 102 lines in 3 files changed: 100 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/9607.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9607/head:pull/9607

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

From darcy at openjdk.org  Sat Jul 23 02:35:48 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Sat, 23 Jul 2022 02:35:48 GMT
Subject: RFR: JDK-8290901: Reduce use of -source in langtools tests
Message-ID: <qxKUaL0BtlAZGFMVfTWlZCQRPE3NidQYwUDg_smE6Hk=.f94d7d23-9264-4161-828b-6eaf2f101ff1@github.com>

To a first approximation, this change replaces use of "-source", where possible, with the preferable "--release" javac option. (There are cases where this swap is not desirable, such as when newer library features are being used in the test.)

A few unneeded uses of -source were removed entirely.

I'll update copyrights before any push.

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

Commit messages:
 - JDK-8290901: Reduce use of -source in langtools tests

Changes: https://git.openjdk.org/jdk/pull/9622/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9622&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8290901
  Stats: 116 lines in 81 files changed: 0 ins; 20 del; 96 mod
  Patch: https://git.openjdk.org/jdk/pull/9622.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9622/head:pull/9622

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

From achung at openjdk.org  Sat Jul 23 03:11:02 2022
From: achung at openjdk.org (Alisen Chung)
Date: Sat, 23 Jul 2022 03:11:02 GMT
Subject: [jdk19] RFR: 8290889: JDK 19 RDP2 L10n resource files update - msgdrop
 10
Message-ID: <sm_MskEXYa57rZRlnc_0Q3dW2_XZeT3hoMih9fjMkEk=.55bca83f-5bf7-4cae-8d1b-5e0b0f55b5bf@github.com>

open l10n msg drop
All tests passed.

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

Commit messages:
 - open l10n drop

Changes: https://git.openjdk.org/jdk19/pull/154/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=154&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8290889
  Stats: 3930 lines in 44 files changed: 3336 ins; 540 del; 54 mod
  Patch: https://git.openjdk.org/jdk19/pull/154.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/154/head:pull/154

PR: https://git.openjdk.org/jdk19/pull/154

From naoto at openjdk.org  Mon Jul 25 17:05:38 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 25 Jul 2022 17:05:38 GMT
Subject: [jdk19] RFR: 8290889: JDK 19 RDP2 L10n resource files update -
 msgdrop 10
In-Reply-To: <sm_MskEXYa57rZRlnc_0Q3dW2_XZeT3hoMih9fjMkEk=.55bca83f-5bf7-4cae-8d1b-5e0b0f55b5bf@github.com>
References: <sm_MskEXYa57rZRlnc_0Q3dW2_XZeT3hoMih9fjMkEk=.55bca83f-5bf7-4cae-8d1b-5e0b0f55b5bf@github.com>
Message-ID: <H6f17TB5GpzVnnzK7uUw7zQeqXFv4hr_-adfUI5D5D4=.a1cd4524-a11c-4749-b253-cb6c24303849@github.com>

On Sat, 23 Jul 2022 03:03:25 GMT, Alisen Chung <achung at openjdk.org> wrote:

> open l10n msg drop
> All tests passed.

Changes requested by naoto (Reviewer).

src/java.base/share/classes/sun/util/resources/CurrencyNames_de.properties line 63:

> 61: # written authorization of the copyright holder.
> 62: 
> 63: ADP=ADP

These currency symbols (`XXX=XXX`) are all in the base `CurrencyNames.properties`, so not needed in each localized resources (They are in the base in order to avoid throwing exceptions).

Also, the localized files should not reside in `java.base`, but to be merged with the ones in `jdk.localedata` module

These comments hold for all localized resources (de, ja, zh-CN). For furure reference, it may be good to add some comment in the base `CurrencyNames.properties` about this.

src/java.base/share/data/currency/CurrencyData_de.properties line 1:

> 1: #

`CurrencyData.properties` is not a localizable resource bundle, but a properties file containing currency data. No need to add these localized resources.

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

PR: https://git.openjdk.org/jdk19/pull/154

From darcy at openjdk.org  Mon Jul 25 17:32:38 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 25 Jul 2022 17:32:38 GMT
Subject: RFR: JDK-8290901: Reduce use of -source in langtools tests [v2]
In-Reply-To: <qxKUaL0BtlAZGFMVfTWlZCQRPE3NidQYwUDg_smE6Hk=.f94d7d23-9264-4161-828b-6eaf2f101ff1@github.com>
References: <qxKUaL0BtlAZGFMVfTWlZCQRPE3NidQYwUDg_smE6Hk=.f94d7d23-9264-4161-828b-6eaf2f101ff1@github.com>
Message-ID: <N9-ry_6BbZqZ-yUQOOB1w4gSgb7haFrMtsKOCoyPc8g=.d48e4d68-2aa2-463e-ba56-86af67cba394@github.com>

> To a first approximation, this change replaces use of "-source", where possible, with the preferable "--release" javac option. (There are cases where this swap is not desirable, such as when newer library features are being used in the test.)
> 
> A few unneeded uses of -source were removed entirely.
> 
> I'll update copyrights before any push.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Update copyrights.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9622/files
  - new: https://git.openjdk.org/jdk/pull/9622/files/63e95cfd..a375ff8b

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

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

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

From darcy at openjdk.org  Mon Jul 25 17:43:06 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 25 Jul 2022 17:43:06 GMT
Subject: RFR: JDK-8042981: Strip type annotations in Types' utility methods
 [v2]
In-Reply-To: <NXxHdBeoY6jAEeswG1eSyvX51SpllGufCa6_C-Dx41o=.142d5c64-6158-4d24-b98a-6834a6f7a204@github.com>
References: <ZJlqgOUvn3O38WxHRYb9AqOtE34HS1tWpINrbxjfi5I=.d914bc42-e221-4f93-a2a4-712c997fe23c@github.com>
 <NXxHdBeoY6jAEeswG1eSyvX51SpllGufCa6_C-Dx41o=.142d5c64-6158-4d24-b98a-6834a6f7a204@github.com>
Message-ID: <rtvJ9b-8rTCctjvyTuipibttVOFlXnpII7zLoyDoK9g=.17d1c3c3-07f0-48da-937f-36f9941380a8@github.com>

On Sun, 26 Jun 2022 22:52:43 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Early review for JDK-8042981: "Strip type annotations in Types' utility methods". I work more often in the Element world rather than the Type word of the annotation processing APIs.
>> 
>> The type annotations on primitive types are *not* cleared by the existing annotation clearing mechanisms. I suspect Type.Visitor is missing a case for primitive types. Someone with familiarity with javac's type modeling should take a look; thanks.
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Update visitor; all langtools regression tests pass.
>  - Merge branch 'master' into JDK-8042981
>  - JDK-8042981: Strip type annotations in Types' utility methods

Keep-alive.

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

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

From asemenyuk at openjdk.org  Mon Jul 25 18:52:15 2022
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 25 Jul 2022 18:52:15 GMT
Subject: [jdk19] RFR: 8290889: JDK 19 RDP2 L10n resource files update -
 msgdrop 10
In-Reply-To: <sm_MskEXYa57rZRlnc_0Q3dW2_XZeT3hoMih9fjMkEk=.55bca83f-5bf7-4cae-8d1b-5e0b0f55b5bf@github.com>
References: <sm_MskEXYa57rZRlnc_0Q3dW2_XZeT3hoMih9fjMkEk=.55bca83f-5bf7-4cae-8d1b-5e0b0f55b5bf@github.com>
Message-ID: <1Ziaq5GCAhIwzw1n5Vex22mK_sBGUknmSn_0xsxlysE=.87eb8ad1-7e05-458f-ba04-25fcfce81fc8@github.com>

On Sat, 23 Jul 2022 03:03:25 GMT, Alisen Chung <achung at openjdk.org> wrote:

> open l10n msg drop
> All tests passed.

Why `MSG_Help_mac_launcher` in [src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/HelpResources_de.properties](https://github.com/openjdk/jdk19/pull/154/files#diff-2e1b121e201e1040827d5b68ebdd852615e611904db783806a753dc6980e97fa) is left not localized? Is it intended to be localized in the next drop?

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

PR: https://git.openjdk.org/jdk19/pull/154

From asotona at openjdk.org  Tue Jul 26 08:32:00 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 26 Jul 2022 08:32:00 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments [v14]
In-Reply-To: <cg1cvzaYh2RZByrgkAI6sPvZ1J0B4JAOiqVe4ib_e34=.9ec074a6-f3c0-4226-8b8c-8064fefd393b@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
 <cg1cvzaYh2RZByrgkAI6sPvZ1J0B4JAOiqVe4ib_e34=.9ec074a6-f3c0-4226-8b8c-8064fefd393b@github.com>
Message-ID: <KXflC0s1JhTfM6RXbd-Cnord8y7OMmsLCcl4ixuWGE0=.f8327203-6dba-42d1-9563-e6fa563aa61d@github.com>

On Mon, 27 Jun 2022 09:25:58 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions.
>> 
>> The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable.
>> 
>> The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. 
>> 
>> Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments.
>> 
>> Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks.
>> 
>> Thanks for your review,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   re-enabled lossy conversions warnings for java.security.jgss, jdk.crypto.ec and jdk.internal.le

ping to keep the PR open

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

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

From achung at openjdk.org  Tue Jul 26 18:34:58 2022
From: achung at openjdk.org (Alisen Chung)
Date: Tue, 26 Jul 2022 18:34:58 GMT
Subject: [jdk19] RFR: 8290889: JDK 19 RDP2 L10n resource files update -
 msgdrop 10
In-Reply-To: <1Ziaq5GCAhIwzw1n5Vex22mK_sBGUknmSn_0xsxlysE=.87eb8ad1-7e05-458f-ba04-25fcfce81fc8@github.com>
References: <sm_MskEXYa57rZRlnc_0Q3dW2_XZeT3hoMih9fjMkEk=.55bca83f-5bf7-4cae-8d1b-5e0b0f55b5bf@github.com>
 <1Ziaq5GCAhIwzw1n5Vex22mK_sBGUknmSn_0xsxlysE=.87eb8ad1-7e05-458f-ba04-25fcfce81fc8@github.com>
Message-ID: <C1YU7iK0K6YjRCepyBlgesZDowUHqG11k9-7EuUwrlo=.fabcf888-a415-47c3-bdc2-2cf37684108b@github.com>

On Mon, 25 Jul 2022 18:48:25 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Why `MSG_Help_mac_launcher` in [src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/HelpResources_de.properties](https://github.com/openjdk/jdk19/pull/154/files#diff-2e1b121e201e1040827d5b68ebdd852615e611904db783806a753dc6980e97fa) is left not localized? Is it intended to be localized in the next drop?

Probably will be left for next drop

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

PR: https://git.openjdk.org/jdk19/pull/154

From achung at openjdk.org  Tue Jul 26 20:24:14 2022
From: achung at openjdk.org (Alisen Chung)
Date: Tue, 26 Jul 2022 20:24:14 GMT
Subject: [jdk19] RFR: 8290889: JDK 19 RDP2 L10n resource files update -
 msgdrop 10 [v2]
In-Reply-To: <sm_MskEXYa57rZRlnc_0Q3dW2_XZeT3hoMih9fjMkEk=.55bca83f-5bf7-4cae-8d1b-5e0b0f55b5bf@github.com>
References: <sm_MskEXYa57rZRlnc_0Q3dW2_XZeT3hoMih9fjMkEk=.55bca83f-5bf7-4cae-8d1b-5e0b0f55b5bf@github.com>
Message-ID: <dZ3e2I9I68fQ6AR4dLBeLnXlwgYejqstcByber6aIBs=.bae6a5fa-59be-4fea-b44d-1cdde31ee22b@github.com>

> open l10n msg drop
> All tests passed.

Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:

  merged currencyname property files into localedata

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

Changes:
  - all: https://git.openjdk.org/jdk19/pull/154/files
  - new: https://git.openjdk.org/jdk19/pull/154/files/334f4c76..7ab703ed

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

  Stats: 1540 lines in 7 files changed: 3 ins; 1534 del; 3 mod
  Patch: https://git.openjdk.org/jdk19/pull/154.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/154/head:pull/154

PR: https://git.openjdk.org/jdk19/pull/154

From achung at openjdk.org  Tue Jul 26 20:31:44 2022
From: achung at openjdk.org (Alisen Chung)
Date: Tue, 26 Jul 2022 20:31:44 GMT
Subject: [jdk19] RFR: 8290889: JDK 19 RDP2 L10n resource files update -
 msgdrop 10 [v3]
In-Reply-To: <sm_MskEXYa57rZRlnc_0Q3dW2_XZeT3hoMih9fjMkEk=.55bca83f-5bf7-4cae-8d1b-5e0b0f55b5bf@github.com>
References: <sm_MskEXYa57rZRlnc_0Q3dW2_XZeT3hoMih9fjMkEk=.55bca83f-5bf7-4cae-8d1b-5e0b0f55b5bf@github.com>
Message-ID: <kyU6nIIGoMX_otMTj_M8I7RVJwm85FOaTi05QHsi1nM=.2d4a5ec1-411f-4eaa-9def-b0b7239e632c@github.com>

> open l10n msg drop
> All tests passed.

Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:

  removed localized files from base

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

Changes:
  - all: https://git.openjdk.org/jdk19/pull/154/files
  - new: https://git.openjdk.org/jdk19/pull/154/files/7ab703ed..6776bd0f

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

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

PR: https://git.openjdk.org/jdk19/pull/154

From vromero at openjdk.org  Thu Jul 28 15:20:48 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 28 Jul 2022 15:20:48 GMT
Subject: RFR: 8289647: AssertionError during annotation processing of
 record related tests [v2]
In-Reply-To: <q72jOzGu5fD6pJN_uG6ANoqyldoN3aopqHP1z3-PI6I=.b7fa7d66-b1f3-4a02-b41f-5c1f821fab53@github.com>
References: <oFQUtgja9NR52EAjFkHFh8gjyrj1zbf_XYsQLDNR6c0=.5f30ff04-e786-4206-bc05-9fd33e8abf29@github.com>
 <q72jOzGu5fD6pJN_uG6ANoqyldoN3aopqHP1z3-PI6I=.b7fa7d66-b1f3-4a02-b41f-5c1f821fab53@github.com>
Message-ID: <LJOrmKCKwEZbo5oVzCMAOF7FNydtkJfAXtWPekrfNfg=.dc3e22f7-f1ee-4ed0-9090-3186db38b1ff@github.com>

On Wed, 20 Jul 2022 14:07:34 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This PR fixes a situation where the same record component was entered *and* schedule for later annotation at the same time.
>> 
>> The test case of the original bug report was recreated as part of "RecordCompilationTests". I tested that it breaks with the expected assertion error mentioned on the original bug report, without the proposed changes.
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add bug id at existing test

looks good, added some suggestions

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

> 1504:         }
> 1505: 
> 1506:         public RecordComponent findRecordComponentToRemove(JCVariableDecl var) {

given that this method has only one client and it is simple, consider inlining its code in the client code

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

> 1523:             RecordComponent rc = null;
> 1524:             if (existing != null) {
> 1525:                 // Found a record component with an erroneous type: remove it and create a new one

I don't think this comment is valid anymore as we are removing an existing record component regardless

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java line 1004:

> 1002:                      *  component.
> 1003:                      */
> 1004:                     RecordComponent rc = sym.findRecordComponentToRemove(field);

I would add an additional comment explaining why we are looking for the record component first and removing it later so that we remember the reason if we need to revisit this code in the future

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

Marked as reviewed by vromero (Reviewer).

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

From naoto at openjdk.org  Thu Jul 28 20:54:21 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 28 Jul 2022 20:54:21 GMT
Subject: [jdk19] RFR: 8290889: JDK 19 RDP2 L10n resource files update -
 msgdrop 10 [v3]
In-Reply-To: <kyU6nIIGoMX_otMTj_M8I7RVJwm85FOaTi05QHsi1nM=.2d4a5ec1-411f-4eaa-9def-b0b7239e632c@github.com>
References: <sm_MskEXYa57rZRlnc_0Q3dW2_XZeT3hoMih9fjMkEk=.55bca83f-5bf7-4cae-8d1b-5e0b0f55b5bf@github.com>
 <kyU6nIIGoMX_otMTj_M8I7RVJwm85FOaTi05QHsi1nM=.2d4a5ec1-411f-4eaa-9def-b0b7239e632c@github.com>
Message-ID: <bhXKuIFtr_FTB_j6ewaj0WeGlxOXZZVs4tdVq7odvoQ=.3ad74be2-d23d-4140-b706-35c454576231@github.com>

On Tue, 26 Jul 2022 20:31:44 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> open l10n msg drop
>> All tests passed.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed localized files from base

- src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_en_US.properties: this should not be moved from `java.base` module
- I still need some comments explaining `XXX=XXX` in the root bundle of `CurrencyNames`. Something like 

These currency symbol entries are for the root bundle only to avoid throwing a MissingResourceException. Should not be copied into each localized resource bundle.

src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_zh_CN.properties line 63:

> 61: # written authorization of the copyright holder.
> 62: 
> 63: CNY=\uffe5

Do not remove the original translation.

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

Changes requested by naoto (Reviewer).

PR: https://git.openjdk.org/jdk19/pull/154

From jjg at openjdk.org  Thu Jul 28 22:28:41 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 28 Jul 2022 22:28:41 GMT
Subject: RFR: JDK-8290901: Reduce use of -source in langtools tests [v2]
In-Reply-To: <N9-ry_6BbZqZ-yUQOOB1w4gSgb7haFrMtsKOCoyPc8g=.d48e4d68-2aa2-463e-ba56-86af67cba394@github.com>
References: <qxKUaL0BtlAZGFMVfTWlZCQRPE3NidQYwUDg_smE6Hk=.f94d7d23-9264-4161-828b-6eaf2f101ff1@github.com>
 <N9-ry_6BbZqZ-yUQOOB1w4gSgb7haFrMtsKOCoyPc8g=.d48e4d68-2aa2-463e-ba56-86af67cba394@github.com>
Message-ID: <cRW0NeLuY3WdaHBbCyMWfTOpBN2aruYT7mmZEhOD4Ks=.9fa2df0f-f7ad-44cd-b481-269e2cea214e@github.com>

On Mon, 25 Jul 2022 17:32:38 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> To a first approximation, this change replaces use of "-source", where possible, with the preferable "--release" javac option. (There are cases where this swap is not desirable, such as when newer library features are being used in the test.)
>> 
>> A few unneeded uses of -source were removed entirely.
>> 
>> I'll update copyrights before any push.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyrights.

I think you can probably simply and sometimes delete the `-Xlint` option ... specifically, to remove the `-options` sub-option.

test/langtools/tools/javac/generics/7015430/T7015430.java line 7:

> 5:  * @summary  Incorrect thrown type determined for unchecked invocations
> 6:  * @author Daniel Smith
> 7:  * @compile/fail/ref=T7015430_1.out --release 7 -Xlint:-options,unchecked -XDrawDiagnostics T7015430.java

You may be able to remove `-options` from `-Xlint` -- the value is probably there to suppress the warnings that you have deleted elsewhere

test/langtools/tools/javac/generics/diamond/neg/Neg09a.java line 7:

> 5:  * @summary  Check that diamond is not allowed with anonymous inner class expressions at source < 9
> 6:  * @author Maurizio Cimadamore
> 7:  * @compile/fail/ref=Neg09a.out Neg09a.java --release 8 -XDrawDiagnostics -Xlint:-options

another `-options`

test/langtools/tools/javac/generics/diamond/neg/Neg09b.java line 7:

> 5:  * @summary  Check that diamond is not allowed with anonymous inner class expressions at source < 9
> 6:  * @author Maurizio Cimadamore
> 7:  * @compile/fail/ref=Neg09b.out Neg09b.java --release 8 -XDrawDiagnostics -Xlint:-options

`-options`

test/langtools/tools/javac/generics/diamond/neg/Neg09c.java line 7:

> 5:  * @summary  Check that diamond is not allowed with anonymous inner class expressions at source < 9
> 6:  * @author Maurizio Cimadamore
> 7:  * @compile/fail/ref=Neg09c.out Neg09c.java --release 8 -XDrawDiagnostics -Xlint:-options

`-options`

test/langtools/tools/javac/generics/diamond/neg/Neg09d.java line 7:

> 5:  * @summary  Check that diamond is not allowed with anonymous inner class expressions at source < 9
> 6:  * @author Maurizio Cimadamore
> 7:  * @compile/fail/ref=Neg09d.out Neg09d.java --release 8 -XDrawDiagnostics -Xlint:-options

`-options`

test/langtools/tools/javac/generics/diamond/neg/Neg10.java line 7:

> 5:  * @summary  Check that 'complex' diamond can infer type that is too specific
> 6:  * @author mcimadamore
> 7:  * @compile/fail/ref=Neg10.out --release 7 -Xlint:-options Neg10.java -XDrawDiagnostics

`-options`

test/langtools/tools/javac/generics/inference/7154127/T7154127.java line 5:

> 3:  * @bug 7154127 8007464
> 4:  * @summary Inference cleanup: remove bound check analysis from visitors in Types.java
> 5:  * @compile/fail/ref=T7154127.out -Xlint:-options --release 7 -XDrawDiagnostics T7154127.java

`-options`

test/langtools/tools/javac/generics/inference/7177306/T7177306e.java line 5:

> 3:  * @bug 7177306 8007464
> 4:  * @summary Regression: unchecked method call does not erase return type
> 5:  * @compile/fail/ref=T7177306e_7.out -XDrawDiagnostics --release 7 -Xlint:-options -XDrawDiagnostics T7177306e.java

`-options`

test/langtools/tools/javac/generics/inference/8015505/T8015505.java line 5:

> 3:  * @bug 8015505
> 4:  * @summary Spurious inference error when return type of generic method requires unchecked conversion to target
> 5:  * @compile/fail/ref=T8015505.out -Xlint:-options --release 7 -XDrawDiagnostics T8015505.java

OK, I'll not bother with flagging more instances of `-options` ... `I suggest you use `grep` on the modified files in this PR.

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

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

From darcy at openjdk.org  Fri Jul 29 00:20:41 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 29 Jul 2022 00:20:41 GMT
Subject: RFR: JDK-8290901: Reduce use of -source in langtools tests [v3]
In-Reply-To: <qxKUaL0BtlAZGFMVfTWlZCQRPE3NidQYwUDg_smE6Hk=.f94d7d23-9264-4161-828b-6eaf2f101ff1@github.com>
References: <qxKUaL0BtlAZGFMVfTWlZCQRPE3NidQYwUDg_smE6Hk=.f94d7d23-9264-4161-828b-6eaf2f101ff1@github.com>
Message-ID: <Jvd3oFphLVHHPBKUDQAq0RcgOR61y7veI43XyhfVWhY=.d696db43-8415-4376-9396-4bc547c44c26@github.com>

> To a first approximation, this change replaces use of "-source", where possible, with the preferable "--release" javac option. (There are cases where this swap is not desirable, such as when newer library features are being used in the test.)
> 
> A few unneeded uses of -source were removed entirely.
> 
> I'll update copyrights before any push.

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

 - Remove unneeded -Xlint:-options flag
 - Merge branch 'master' into JDK-8290901
 - Update copyrights.
 - JDK-8290901: Reduce use of -source in langtools tests

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9622/files
  - new: https://git.openjdk.org/jdk/pull/9622/files/a375ff8b..3a6cb666

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

  Stats: 5738 lines in 278 files changed: 3270 ins; 1884 del; 584 mod
  Patch: https://git.openjdk.org/jdk/pull/9622.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9622/head:pull/9622

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

From darcy at openjdk.org  Fri Jul 29 00:27:49 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 29 Jul 2022 00:27:49 GMT
Subject: RFR: JDK-8290901: Reduce use of -source in langtools tests [v2]
In-Reply-To: <cRW0NeLuY3WdaHBbCyMWfTOpBN2aruYT7mmZEhOD4Ks=.9fa2df0f-f7ad-44cd-b481-269e2cea214e@github.com>
References: <qxKUaL0BtlAZGFMVfTWlZCQRPE3NidQYwUDg_smE6Hk=.f94d7d23-9264-4161-828b-6eaf2f101ff1@github.com>
 <N9-ry_6BbZqZ-yUQOOB1w4gSgb7haFrMtsKOCoyPc8g=.d48e4d68-2aa2-463e-ba56-86af67cba394@github.com>
 <cRW0NeLuY3WdaHBbCyMWfTOpBN2aruYT7mmZEhOD4Ks=.9fa2df0f-f7ad-44cd-b481-269e2cea214e@github.com>
Message-ID: <bpk3GX3LIvRlK4OdigU6DjBJoFoXscxS_Cv9M7OD5Ok=.13b5a194-6a6c-4943-95d3-cc2ce0195aee@github.com>

On Thu, 28 Jul 2022 22:11:28 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update copyrights.
>
> test/langtools/tools/javac/generics/7015430/T7015430.java line 7:
> 
>> 5:  * @summary  Incorrect thrown type determined for unchecked invocations
>> 6:  * @author Daniel Smith
>> 7:  * @compile/fail/ref=T7015430_1.out --release 7 -Xlint:-options,unchecked -XDrawDiagnostics T7015430.java
> 
> You may be able to remove `-options` from `-Xlint` -- the value is probably there to suppress the warnings that you have deleted elsewhere

There are warnings for using "--release 7" because of the age of 7, but otherwise I've updated the PR to remove unneeded uses of -Xlint:-options.

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

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

From darcy at openjdk.org  Fri Jul 29 00:53:44 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 29 Jul 2022 00:53:44 GMT
Subject: RFR: JDK-8290901: Reduce use of -source in langtools tests [v4]
In-Reply-To: <qxKUaL0BtlAZGFMVfTWlZCQRPE3NidQYwUDg_smE6Hk=.f94d7d23-9264-4161-828b-6eaf2f101ff1@github.com>
References: <qxKUaL0BtlAZGFMVfTWlZCQRPE3NidQYwUDg_smE6Hk=.f94d7d23-9264-4161-828b-6eaf2f101ff1@github.com>
Message-ID: <v69eDEcl51TvQ4SiVPH6GE89bFHQ0V4RLdwq9ciIwIs=.48d22146-b894-46e8-81d1-bc11eabba73a@github.com>

> To a first approximation, this change replaces use of "-source", where possible, with the preferable "--release" javac option. (There are cases where this swap is not desirable, such as when newer library features are being used in the test.)
> 
> A few unneeded uses of -source were removed entirely.
> 
> I'll update copyrights before any push.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Remove one more unneeded -Xlint:-options usage.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9622/files
  - new: https://git.openjdk.org/jdk/pull/9622/files/3a6cb666..f24c3f6c

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

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

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

From abimpoudis at openjdk.org  Fri Jul 29 13:58:26 2022
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Fri, 29 Jul 2022 13:58:26 GMT
Subject: RFR: 8289647: AssertionError during annotation processing of
 record related tests [v2]
In-Reply-To: <LJOrmKCKwEZbo5oVzCMAOF7FNydtkJfAXtWPekrfNfg=.dc3e22f7-f1ee-4ed0-9090-3186db38b1ff@github.com>
References: <oFQUtgja9NR52EAjFkHFh8gjyrj1zbf_XYsQLDNR6c0=.5f30ff04-e786-4206-bc05-9fd33e8abf29@github.com>
 <q72jOzGu5fD6pJN_uG6ANoqyldoN3aopqHP1z3-PI6I=.b7fa7d66-b1f3-4a02-b41f-5c1f821fab53@github.com>
 <LJOrmKCKwEZbo5oVzCMAOF7FNydtkJfAXtWPekrfNfg=.dc3e22f7-f1ee-4ed0-9090-3186db38b1ff@github.com>
Message-ID: <jsNjwJFaa396Mqwo58fVI3UoQzbPeetRNhx5pSf5sBU=.901fabaf-1012-47e1-b060-583d90c3c41e@github.com>

On Thu, 28 Jul 2022 15:14:54 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 bug id at existing test
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java line 1506:
> 
>> 1504:         }
>> 1505: 
>> 1506:         public RecordComponent findRecordComponentToRemove(JCVariableDecl var) {
> 
> given that this method has only one client and it is simple, consider inlining its code in the client code

`pos` has private access in `com.sun.tools.javac.code.Symbol.RecordComponent`. Is it ok if we bump it to `public` (it still hides the one from `VarSymbol`. WDYT?

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

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

From vromero at openjdk.org  Fri Jul 29 14:42:48 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 29 Jul 2022 14:42:48 GMT
Subject: RFR: 8289647: AssertionError during annotation processing of
 record related tests [v2]
In-Reply-To: <jsNjwJFaa396Mqwo58fVI3UoQzbPeetRNhx5pSf5sBU=.901fabaf-1012-47e1-b060-583d90c3c41e@github.com>
References: <oFQUtgja9NR52EAjFkHFh8gjyrj1zbf_XYsQLDNR6c0=.5f30ff04-e786-4206-bc05-9fd33e8abf29@github.com>
 <q72jOzGu5fD6pJN_uG6ANoqyldoN3aopqHP1z3-PI6I=.b7fa7d66-b1f3-4a02-b41f-5c1f821fab53@github.com>
 <LJOrmKCKwEZbo5oVzCMAOF7FNydtkJfAXtWPekrfNfg=.dc3e22f7-f1ee-4ed0-9090-3186db38b1ff@github.com>
 <jsNjwJFaa396Mqwo58fVI3UoQzbPeetRNhx5pSf5sBU=.901fabaf-1012-47e1-b060-583d90c3c41e@github.com>
Message-ID: <mI3aIqrAnVfbq8K_KtEZ2XFlTeJvUMpG6560QcA4tik=.b1b5a739-bb07-45a0-bebc-bbbb635c256a@github.com>

On Fri, 29 Jul 2022 13:55:00 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java line 1506:
>> 
>>> 1504:         }
>>> 1505: 
>>> 1506:         public RecordComponent findRecordComponentToRemove(JCVariableDecl var) {
>> 
>> given that this method has only one client and it is simple, consider inlining its code in the client code
>
> `pos` has private access in `com.sun.tools.javac.code.Symbol.RecordComponent`. Is it ok if we bump it to `public` (it still hides the one from `VarSymbol`. WDYT?

Oh I see then better to leave the code as it is now

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

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

From abimpoudis at openjdk.org  Fri Jul 29 14:58:48 2022
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Fri, 29 Jul 2022 14:58:48 GMT
Subject: RFR: 8289647: AssertionError during annotation processing of
 record related tests [v3]
In-Reply-To: <oFQUtgja9NR52EAjFkHFh8gjyrj1zbf_XYsQLDNR6c0=.5f30ff04-e786-4206-bc05-9fd33e8abf29@github.com>
References: <oFQUtgja9NR52EAjFkHFh8gjyrj1zbf_XYsQLDNR6c0=.5f30ff04-e786-4206-bc05-9fd33e8abf29@github.com>
Message-ID: <wONcN_4jBZabOKw4GkQ4ktCCGBO-IEf4jX8mjTr5oPM=.ecb4b937-30fe-4898-8696-9efd751cabda@github.com>

> This PR fixes a situation where the same record component was entered *and* schedule for later annotation at the same time.
> 
> The test case of the original bug report was recreated as part of "RecordCompilationTests". I tested that it breaks with the expected assertion error mentioned on the original bug report, without the proposed changes.

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

  Address review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9570/files
  - new: https://git.openjdk.org/jdk/pull/9570/files/74fcc2a6..166e2dfd

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

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

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

From abimpoudis at openjdk.org  Fri Jul 29 15:00:36 2022
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Fri, 29 Jul 2022 15:00:36 GMT
Subject: RFR: 8289647: AssertionError during annotation processing of
 record related tests [v2]
In-Reply-To: <LJOrmKCKwEZbo5oVzCMAOF7FNydtkJfAXtWPekrfNfg=.dc3e22f7-f1ee-4ed0-9090-3186db38b1ff@github.com>
References: <oFQUtgja9NR52EAjFkHFh8gjyrj1zbf_XYsQLDNR6c0=.5f30ff04-e786-4206-bc05-9fd33e8abf29@github.com>
 <q72jOzGu5fD6pJN_uG6ANoqyldoN3aopqHP1z3-PI6I=.b7fa7d66-b1f3-4a02-b41f-5c1f821fab53@github.com>
 <LJOrmKCKwEZbo5oVzCMAOF7FNydtkJfAXtWPekrfNfg=.dc3e22f7-f1ee-4ed0-9090-3186db38b1ff@github.com>
Message-ID: <eL_plWaxnBA6lxWciRwkBbiy8lT4KgqC4GaDLCHOFvQ=.1a460e97-7738-4c18-963e-2d0302847320@github.com>

On Thu, 28 Jul 2022 15:16:47 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 bug id at existing test
>
> looks good, added some suggestions

Thx for the review @vicente-romero-oracle ?

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

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

From abimpoudis at openjdk.org  Fri Jul 29 16:05:10 2022
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Fri, 29 Jul 2022 16:05:10 GMT
Subject: Integrated: 8289647: AssertionError during annotation processing of
 record related tests
In-Reply-To: <oFQUtgja9NR52EAjFkHFh8gjyrj1zbf_XYsQLDNR6c0=.5f30ff04-e786-4206-bc05-9fd33e8abf29@github.com>
References: <oFQUtgja9NR52EAjFkHFh8gjyrj1zbf_XYsQLDNR6c0=.5f30ff04-e786-4206-bc05-9fd33e8abf29@github.com>
Message-ID: <xByk3Y_H4WBvxCxAIh_bL2LTDRCYHxQuepYpf-uSl9Y=.76554b23-1bf3-49f8-b8ba-c2d70d13dd17@github.com>

On Wed, 20 Jul 2022 13:56:07 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> This PR fixes a situation where the same record component was entered *and* schedule for later annotation at the same time.
> 
> The test case of the original bug report was recreated as part of "RecordCompilationTests". I tested that it breaks with the expected assertion error mentioned on the original bug report, without the proposed changes.

This pull request has now been integrated.

Changeset: 64a1a08f
Author:    Aggelos Biboudis <abimpoudis at openjdk.org>
Committer: Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/64a1a08ff9f120648e466449f65750991cbf673c
Stats:     117 lines in 3 files changed: 78 ins; 31 del; 8 mod

8289647: AssertionError during annotation processing of record related tests

Reviewed-by: vromero

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

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

From jjg at openjdk.org  Fri Jul 29 16:21:00 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 29 Jul 2022 16:21:00 GMT
Subject: RFR: JDK-8290901: Reduce use of -source in langtools tests [v4]
In-Reply-To: <v69eDEcl51TvQ4SiVPH6GE89bFHQ0V4RLdwq9ciIwIs=.48d22146-b894-46e8-81d1-bc11eabba73a@github.com>
References: <qxKUaL0BtlAZGFMVfTWlZCQRPE3NidQYwUDg_smE6Hk=.f94d7d23-9264-4161-828b-6eaf2f101ff1@github.com>
 <v69eDEcl51TvQ4SiVPH6GE89bFHQ0V4RLdwq9ciIwIs=.48d22146-b894-46e8-81d1-bc11eabba73a@github.com>
Message-ID: <KIrwOH_MSf1Qqp7mvRmnt7dbty3snq4Geth-sPV240w=.e56234e2-e310-48a3-a359-11b3d45250c6@github.com>

On Fri, 29 Jul 2022 00:53:44 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> To a first approximation, this change replaces use of "-source", where possible, with the preferable "--release" javac option. (There are cases where this swap is not desirable, such as when newer library features are being used in the test.)
>> 
>> A few unneeded uses of -source were removed entirely.
>> 
>> I'll update copyrights before any push.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove one more unneeded -Xlint:-options usage.

generally, a nice cleanup, but check out `NestedCapture.java`

test/langtools/tools/javac/generics/inference/NestedCapture.java line 29:

> 27:  * @summary Capture variable passed through multiple levels of nested inference
> 28:  * @compile NestedCapture.java
> 29:  * @compile NestedCapture.java

Did too much get removed here?   Should there be a `--release 7`?

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

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

From darcy at openjdk.org  Fri Jul 29 17:24:51 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 29 Jul 2022 17:24:51 GMT
Subject: RFR: JDK-8290901: Reduce use of -source in langtools tests [v5]
In-Reply-To: <qxKUaL0BtlAZGFMVfTWlZCQRPE3NidQYwUDg_smE6Hk=.f94d7d23-9264-4161-828b-6eaf2f101ff1@github.com>
References: <qxKUaL0BtlAZGFMVfTWlZCQRPE3NidQYwUDg_smE6Hk=.f94d7d23-9264-4161-828b-6eaf2f101ff1@github.com>
Message-ID: <TbtafNpMzNi8zMAtxVQXGU9vJVZ3rTLXRtpArJWhjuQ=.7f8cb06a-738a-4c24-8c1a-2d930034978c@github.com>

> To a first approximation, this change replaces use of "-source", where possible, with the preferable "--release" javac option. (There are cases where this swap is not desirable, such as when newer library features are being used in the test.)
> 
> A few unneeded uses of -source were removed entirely.
> 
> I'll update copyrights before any push.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Fix bug found in code review.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9622/files
  - new: https://git.openjdk.org/jdk/pull/9622/files/f24c3f6c..54554767

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

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

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

From darcy at openjdk.org  Fri Jul 29 17:24:53 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 29 Jul 2022 17:24:53 GMT
Subject: RFR: JDK-8290901: Reduce use of -source in langtools tests [v4]
In-Reply-To: <KIrwOH_MSf1Qqp7mvRmnt7dbty3snq4Geth-sPV240w=.e56234e2-e310-48a3-a359-11b3d45250c6@github.com>
References: <qxKUaL0BtlAZGFMVfTWlZCQRPE3NidQYwUDg_smE6Hk=.f94d7d23-9264-4161-828b-6eaf2f101ff1@github.com>
 <v69eDEcl51TvQ4SiVPH6GE89bFHQ0V4RLdwq9ciIwIs=.48d22146-b894-46e8-81d1-bc11eabba73a@github.com>
 <KIrwOH_MSf1Qqp7mvRmnt7dbty3snq4Geth-sPV240w=.e56234e2-e310-48a3-a359-11b3d45250c6@github.com>
Message-ID: <tI35cPCNJrgqzYo6k-nJlad_IPRQRZrxeZkXFlGeuAI=.06beaefd-4e40-48ef-a56d-f3d3223e1242@github.com>

On Fri, 29 Jul 2022 16:15:01 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove one more unneeded -Xlint:-options usage.
>
> test/langtools/tools/javac/generics/inference/NestedCapture.java line 29:
> 
>> 27:  * @summary Capture variable passed through multiple levels of nested inference
>> 28:  * @compile NestedCapture.java
>> 29:  * @compile NestedCapture.java
> 
> Did too much get removed here?   Should there be a `--release 7`?

Good catch; fixed.

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

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

From jjg at openjdk.org  Fri Jul 29 17:29:56 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 29 Jul 2022 17:29:56 GMT
Subject: RFR: JDK-8290901: Reduce use of -source in langtools tests [v5]
In-Reply-To: <TbtafNpMzNi8zMAtxVQXGU9vJVZ3rTLXRtpArJWhjuQ=.7f8cb06a-738a-4c24-8c1a-2d930034978c@github.com>
References: <qxKUaL0BtlAZGFMVfTWlZCQRPE3NidQYwUDg_smE6Hk=.f94d7d23-9264-4161-828b-6eaf2f101ff1@github.com>
 <TbtafNpMzNi8zMAtxVQXGU9vJVZ3rTLXRtpArJWhjuQ=.7f8cb06a-738a-4c24-8c1a-2d930034978c@github.com>
Message-ID: <6U8p-oTXUM5ZZzLolqnG9OtpoDyyUD0CpwCOPBSHIPc=.3e76405e-8137-40fa-bc73-e821b66fd0db@github.com>

On Fri, 29 Jul 2022 17:24:51 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> To a first approximation, this change replaces use of "-source", where possible, with the preferable "--release" javac option. (There are cases where this swap is not desirable, such as when newer library features are being used in the test.)
>> 
>> A few unneeded uses of -source were removed entirely.
>> 
>> I'll update copyrights before any push.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix bug found in code review.

You probably don't need the `-Xlint:-options` in this case, because you are not checking the output with a reference output file, so the warning is mostly harmless.

I'll approve the review and leave it to you to decide whether to suppress the `-Xlint:-options`

Marked as reviewed by jjg (Reviewer).

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

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

From darcy at openjdk.org  Fri Jul 29 17:34:58 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 29 Jul 2022 17:34:58 GMT
Subject: RFR: JDK-8290901: Reduce use of -source in langtools tests [v5]
In-Reply-To: <6U8p-oTXUM5ZZzLolqnG9OtpoDyyUD0CpwCOPBSHIPc=.3e76405e-8137-40fa-bc73-e821b66fd0db@github.com>
References: <qxKUaL0BtlAZGFMVfTWlZCQRPE3NidQYwUDg_smE6Hk=.f94d7d23-9264-4161-828b-6eaf2f101ff1@github.com>
 <TbtafNpMzNi8zMAtxVQXGU9vJVZ3rTLXRtpArJWhjuQ=.7f8cb06a-738a-4c24-8c1a-2d930034978c@github.com>
 <6U8p-oTXUM5ZZzLolqnG9OtpoDyyUD0CpwCOPBSHIPc=.3e76405e-8137-40fa-bc73-e821b66fd0db@github.com>
Message-ID: <zxxnNI1awJ02__L6NPNjz2FMAR62i-YftCSbQln_rlo=.e9e9052c-4da9-4b35-9c87-fe554c02da5f@github.com>

On Fri, 29 Jul 2022 17:25:02 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> You probably don't need the `-Xlint:-options` in this case, because you are not checking the output with a reference output file, so the warning is mostly harmless.
> 
> I'll approve the review and leave it to you to decide whether to suppress the `-Xlint:-options`

Yes; the test passes with or without `-Xlint:-options`. I left `-options` in to avoid spurious messages in the test output and for consistency with the other uses of --release 7, many of which have `-options`.

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

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

From darcy at openjdk.org  Fri Jul 29 17:38:38 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 29 Jul 2022 17:38:38 GMT
Subject: Integrated: JDK-8290901: Reduce use of -source in langtools tests
In-Reply-To: <qxKUaL0BtlAZGFMVfTWlZCQRPE3NidQYwUDg_smE6Hk=.f94d7d23-9264-4161-828b-6eaf2f101ff1@github.com>
References: <qxKUaL0BtlAZGFMVfTWlZCQRPE3NidQYwUDg_smE6Hk=.f94d7d23-9264-4161-828b-6eaf2f101ff1@github.com>
Message-ID: <LqqozTGm1rGeDr4lRwQur1m0LtANmt6lByaf3bjvxqw=.21f5d7e8-a691-4f45-bb20-cf6f58a8c22b@github.com>

On Sat, 23 Jul 2022 02:29:56 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> To a first approximation, this change replaces use of "-source", where possible, with the preferable "--release" javac option. (There are cases where this swap is not desirable, such as when newer library features are being used in the test.)
> 
> A few unneeded uses of -source were removed entirely.
> 
> I'll update copyrights before any push.

This pull request has now been integrated.

Changeset: cc2861a9
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cc2861a993c5c9926e4e9708d5b229c2a0072ca9
Stats:     128 lines in 81 files changed: 0 ins; 20 del; 108 mod

8290901: Reduce use of -source in langtools tests

Reviewed-by: jjg

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

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

From achung at openjdk.org  Fri Jul 29 18:13:25 2022
From: achung at openjdk.org (Alisen Chung)
Date: Fri, 29 Jul 2022 18:13:25 GMT
Subject: [jdk19] RFR: 8290889: JDK 19 RDP2 L10n resource files update -
 msgdrop 10 [v4]
In-Reply-To: <sm_MskEXYa57rZRlnc_0Q3dW2_XZeT3hoMih9fjMkEk=.55bca83f-5bf7-4cae-8d1b-5e0b0f55b5bf@github.com>
References: <sm_MskEXYa57rZRlnc_0Q3dW2_XZeT3hoMih9fjMkEk=.55bca83f-5bf7-4cae-8d1b-5e0b0f55b5bf@github.com>
Message-ID: <vKXwAs-SGIVaskDopc7GE6LIGnafs2yZFLW3jG6q0zg=.1c432b6d-b66c-4419-8fb5-5d8863e6e51c@github.com>

> open l10n msg drop
> All tests passed.

Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:

  added comments in CurrencyNames root in base, moved US CurrencyNames back to base, readded original Chinese translation

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

Changes:
  - all: https://git.openjdk.org/jdk19/pull/154/files
  - new: https://git.openjdk.org/jdk19/pull/154/files/6776bd0f..737b253f

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

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

PR: https://git.openjdk.org/jdk19/pull/154

From jjg at openjdk.org  Fri Jul 29 18:19:37 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 29 Jul 2022 18:19:37 GMT
Subject: RFR: JDK-6251738: Want a top-level summary page that itemizes all
 spec documents referenced from javadocs (OEM spec) [v12]
In-Reply-To: <PeZ8g98tWBwjtt6lW6Wy2BYbYPD_CvBRnZ5Onwv-FBM=.6a5b9416-4306-4df8-ad89-08424ff1dd08@github.com>
References: <PeZ8g98tWBwjtt6lW6Wy2BYbYPD_CvBRnZ5Onwv-FBM=.6a5b9416-4306-4df8-ad89-08424ff1dd08@github.com>
Message-ID: <ljUSyLjTwk1xZrDdFujxiSFD3XzPOhGGKIHiXvdzs8g=.5443e389-c76c-4701-9a65-1bafbfc2c39c@github.com>

> Please review the code and tests to add support for a new `@spec url title` tag to javadoc.  Note, this does not include any changes to API doc comments to use the new tag in JDK API documentation; that will come later.

Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits:

 - Fix typo and merge error
 - Merge with upstream/master
 - Update @since tags
 - Merge remote-tracking branch 'upstream/master' into 6251738.spec-tag-2
 - Merge remote-tracking branch 'upstream/master' into 6251738.spec-tag-2
 - Updates for latest repo
 - Merge remote-tracking branch 'upstream/master' into 6251738.spec-tag-2
 - Merge remote-tracking branch 'upstream/master' into 6251738.spec-tag-2
 - Merge with upstream/master
 - fix copyright dates
   remove archaic obsolete build flags
 - ... and 9 more: https://git.openjdk.org/jdk/compare/eeac3da7...214b9244

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

Changes: https://git.openjdk.org/jdk/pull/8439/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=8439&range=11
  Stats: 1502 lines in 41 files changed: 1474 ins; 6 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/8439.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/8439/head:pull/8439

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