From darcy at openjdk.java.net  Mon Jan  3 18:33:35 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 3 Jan 2022 18:33:35 GMT
Subject: RFR: JDK-8277515: Update --release 18 symbol information for JDK 18
 build 29
Message-ID: <daMK3jGvo3fdSUym74f8uxJPtG5Xm6JfbMCA1iCSiVU=.20631e0d-4263-4846-be6b-5b89c32f2870@github.com>

Usual update to the JDK 19 symbol files for changes in JDK 18; this time JDK-8276660 in JDK 18 build 28.

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

Commit messages:
 - JDK-8277515: Update --release 18 symbol information for JDK 18 build 29

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

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

From iris at openjdk.java.net  Mon Jan  3 19:16:20 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Mon, 3 Jan 2022 19:16:20 GMT
Subject: RFR: JDK-8277515: Update --release 18 symbol information for JDK
 18 build 29
In-Reply-To: <daMK3jGvo3fdSUym74f8uxJPtG5Xm6JfbMCA1iCSiVU=.20631e0d-4263-4846-be6b-5b89c32f2870@github.com>
References: <daMK3jGvo3fdSUym74f8uxJPtG5Xm6JfbMCA1iCSiVU=.20631e0d-4263-4846-be6b-5b89c32f2870@github.com>
Message-ID: <pNvm2NdUTa4azcWT-i9YXkoeSH7LkJypNbGGXy5x68Y=.ce7f18d5-d97b-4081-a3cc-cb6df437b2e1@github.com>

On Mon, 3 Jan 2022 18:26:24 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Usual update to the JDK 19 symbol files for changes in JDK 18; this time JDK-8276660 in JDK 18 build 28.

Marked as reviewed by iris (Reviewer).

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

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

From jjg at openjdk.java.net  Mon Jan  3 21:50:18 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Mon, 3 Jan 2022 21:50:18 GMT
Subject: [jdk18] RFR: JDK-8273452: DocTrees.getDocCommentTree should be
 specified as idempotent
In-Reply-To: <GhovZDzU7t6WkQLekF1CwPanpuN0newHN5TMPz2FZTs=.984b4252-2fa7-4de7-a33c-bc717e1bd413@github.com>
References: <GhovZDzU7t6WkQLekF1CwPanpuN0newHN5TMPz2FZTs=.984b4252-2fa7-4de7-a33c-bc717e1bd413@github.com>
Message-ID: <tLX_71AwX3UKwCQ7FGZ1J2-11P7gjxCtzJmUpy2uPic=.bde9f730-7d2d-4ef4-a76e-b7fb99943d7b@github.com>

On Thu, 16 Dec 2021 11:05:01 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review a doc-only change to add implementation notes to the `DocTrees.getDocCommentTree` methods, some of which return the same `DocCommentTree` instance on repeated invocation and some don't. I decided to use `@implNote` instead of `@implSpec` as usually I wouldn't expect object identity to be part of a Java API specification.
> 
> I verified the described behavior using code analysis and enhancing existing tests. The latter are not included in the commit as this is a `noreg-doc` issue.

I guess it's a gray area whether it should be an `implSpec` or an `implNote`.

It is a relatively important aspect of the API, because the operations are expensive, and even cause some downstream caching. 

For now, it's enough that it is noted in some fashion.

As a general style note, I would suggest a blank line before each `implNote`, and change "The implementation of this method" to either "The default implementation of this method" or just "This implementation".

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

Marked as reviewed by jjg (Reviewer).

PR: https://git.openjdk.java.net/jdk18/pull/36

From jlahoda at openjdk.java.net  Tue Jan  4 17:27:28 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 4 Jan 2022 17:27:28 GMT
Subject: [jdk18] RFR: 8278373: JavacTypes.searchMethod finds incorrect match
Message-ID: <XbMsX_o0DPzcRmiLkhyD0uXxvEfHB8kXLGVoB9DWMFw=.9ccaedb0-4fab-44a1-ab68-8612a85d796e@github.com>

Currently, when javac encounters a javadoc reference, like `@see PrintStream#println(int)`, will first try to find a method `println` in `PrintStream` using subtyping on the argument types, which may find another overload of the method with an argument that is a subtype of `int` - like `println(double)`. Consequently, the link in the javadoc may be to a wrong method.

In this patch, the proposal is to use the subtype search only as a backup option, using the existing check based on `isSameType` first, and only doing an inexact match using subtyping if the more exact match fails to find a method. This fallback should help possible existing broken references to still work as before, while the preferred use of the more exact match should select the correct method in usual correct cases.

This patch fixes some instances of incorrect references in the JDK's javadoc, a diff of the generated javadocs for the JDK mainline is here:
http://cr.openjdk.java.net/~jlahoda/8278373/JDK-8278373.diff

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

Commit messages:
 - 8278373: JavacTypes.searchMethod finds incorrect match

Changes: https://git.openjdk.java.net/jdk18/pull/79/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk18&pr=79&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8278373
  Stats: 70 lines in 2 files changed: 52 ins; 2 del; 16 mod
  Patch: https://git.openjdk.java.net/jdk18/pull/79.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk18 pull/79/head:pull/79

PR: https://git.openjdk.java.net/jdk18/pull/79

From vromero at openjdk.java.net  Tue Jan  4 19:50:15 2022
From: vromero at openjdk.java.net (Vicente Romero)
Date: Tue, 4 Jan 2022 19:50:15 GMT
Subject: [jdk18] RFR: 8278373: JavacTypes.searchMethod finds incorrect
 match
In-Reply-To: <XbMsX_o0DPzcRmiLkhyD0uXxvEfHB8kXLGVoB9DWMFw=.9ccaedb0-4fab-44a1-ab68-8612a85d796e@github.com>
References: <XbMsX_o0DPzcRmiLkhyD0uXxvEfHB8kXLGVoB9DWMFw=.9ccaedb0-4fab-44a1-ab68-8612a85d796e@github.com>
Message-ID: <jcnglePx3UVQ48n-o6xwNJWHCoUU3nV8DNvf2d9Tuv0=.66a4148c-46f5-4f49-b93a-0e67d98a6993@github.com>

On Tue, 4 Jan 2022 17:19:44 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Currently, when javac encounters a javadoc reference, like `@see PrintStream#println(int)`, will first try to find a method `println` in `PrintStream` using subtyping on the argument types, which may find another overload of the method with an argument that is a subtype of `int` - like `println(double)`. Consequently, the link in the javadoc may be to a wrong method.
> 
> In this patch, the proposal is to use the subtype search only as a backup option, using the existing check based on `isSameType` first, and only doing an inexact match using subtyping if the more exact match fails to find a method. This fallback should help possible existing broken references to still work as before, while the preferred use of the more exact match should select the correct method in usual correct cases.
> 
> This patch fixes some instances of incorrect references in the JDK's javadoc, a diff of the generated javadocs for the JDK mainline is here:
> http://cr.openjdk.java.net/~jlahoda/8278373/JDK-8278373.diff

looks sensible

will we need a release note for this bug? it could be that some user's APIs could be affected by this change

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

Marked as reviewed by vromero (Reviewer).

PR: https://git.openjdk.java.net/jdk18/pull/79

From jjg at openjdk.java.net  Tue Jan  4 19:54:15 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Tue, 4 Jan 2022 19:54:15 GMT
Subject: [jdk18] RFR: 8278373: JavacTypes.searchMethod finds incorrect
 match
In-Reply-To: <XbMsX_o0DPzcRmiLkhyD0uXxvEfHB8kXLGVoB9DWMFw=.9ccaedb0-4fab-44a1-ab68-8612a85d796e@github.com>
References: <XbMsX_o0DPzcRmiLkhyD0uXxvEfHB8kXLGVoB9DWMFw=.9ccaedb0-4fab-44a1-ab68-8612a85d796e@github.com>
Message-ID: <3nXgEPemHZli72G96ehNbbHt5-Hc1WMc4UqP1wrP7z8=.84935fb2-c8d3-4906-8da6-72aab0dc9828@github.com>

On Tue, 4 Jan 2022 17:19:44 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Currently, when javac encounters a javadoc reference, like `@see PrintStream#println(int)`, will first try to find a method `println` in `PrintStream` using subtyping on the argument types, which may find another overload of the method with an argument that is a subtype of `int` - like `println(double)`. Consequently, the link in the javadoc may be to a wrong method.
> 
> In this patch, the proposal is to use the subtype search only as a backup option, using the existing check based on `isSameType` first, and only doing an inexact match using subtyping if the more exact match fails to find a method. This fallback should help possible existing broken references to still work as before, while the preferred use of the more exact match should select the correct method in usual correct cases.
> 
> This patch fixes some instances of incorrect references in the JDK's javadoc, a diff of the generated javadocs for the JDK mainline is here:
> http://cr.openjdk.java.net/~jlahoda/8278373/JDK-8278373.diff

Generally good; I think this is the right fix in the current situation and for potential back porting. It provides improved but compatible behavior.

The API diffs were an unexpected "bonus", if that is the right word.  It's better to know about and fix issues than to not know about them.  I've spot checked a few of them and all seem reasonable. The fix is especially obvious when the link and the clear-text are different and meant to be the same.  The one thing I would suggest is that because a lot of the api diffs are related to "subtyping" between primitive types, we might want to add some test cases for that into the test as well.   Here is a random example of the kind of diff I'm talking about:

```   
- as if by calling <a href="../java.base/java/lang/Math.html#max(double,double)"><code>Math.max</code></a>.</div>
+ as if by calling <a href="../java.base/java/lang/Math.html#max(float,float)"><code>Math.max</code></a>.</div>


Further out (JDK 19?) I think we should investigate the need for the `strict == false` case and/or give warnings (in javadoc) when the lookup is not exact.  We should fix any cases in the JDK docs where that is the case, and/or consider removing support for `strict == false` or else make it an opt-in behavior somehow.

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

Marked as reviewed by jjg (Reviewer).

PR: https://git.openjdk.java.net/jdk18/pull/79

From jjg at openjdk.java.net  Tue Jan  4 20:03:18 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Tue, 4 Jan 2022 20:03:18 GMT
Subject: [jdk18] RFR: 8278373: JavacTypes.searchMethod finds incorrect
 match
In-Reply-To: <XbMsX_o0DPzcRmiLkhyD0uXxvEfHB8kXLGVoB9DWMFw=.9ccaedb0-4fab-44a1-ab68-8612a85d796e@github.com>
References: <XbMsX_o0DPzcRmiLkhyD0uXxvEfHB8kXLGVoB9DWMFw=.9ccaedb0-4fab-44a1-ab68-8612a85d796e@github.com>
Message-ID: <AL3u3SOK8pIJOJ2BvmlWzWOO1mLNPtLICUXxPdmRR4k=.6510c08c-4262-4470-8b26-b7ee13dfa35e@github.com>

On Tue, 4 Jan 2022 17:19:44 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Currently, when javac encounters a javadoc reference, like `@see PrintStream#println(int)`, will first try to find a method `println` in `PrintStream` using subtyping on the argument types, which may find another overload of the method with an argument that is a subtype of `int` - like `println(double)`. Consequently, the link in the javadoc may be to a wrong method.
> 
> In this patch, the proposal is to use the subtype search only as a backup option, using the existing check based on `isSameType` first, and only doing an inexact match using subtyping if the more exact match fails to find a method. This fallback should help possible existing broken references to still work as before, while the preferred use of the more exact match should select the correct method in usual correct cases.
> 
> This patch fixes some instances of incorrect references in the JDK's javadoc, a diff of the generated javadocs for the JDK mainline is here:
> http://cr.openjdk.java.net/~jlahoda/8278373/JDK-8278373.diff

> [snip]
> 
> Further out (JDK 19?) I think we should investigate the need for the `strict == false` case and/or give warnings (in javadoc) when the lookup is not exact. We should fix any cases in the JDK docs where that is the case, and/or consider removing support for `strict == false` or else make it an opt-in behavior somehow.

Filed JDK-8279474

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

PR: https://git.openjdk.java.net/jdk18/pull/79

From vromero at openjdk.java.net  Tue Jan  4 21:12:17 2022
From: vromero at openjdk.java.net (Vicente Romero)
Date: Tue, 4 Jan 2022 21:12:17 GMT
Subject: RFR: 8211004: javac is complaining about non-denotable types and
 refusing to generate the class file
In-Reply-To: <kvzpIy2xq2MHhZNdRNT1hEOgcGaP6BjR0FEYBn2rLj0=.b989188c-f35f-46ac-8f54-f249f16b381e@github.com>
References: <kvzpIy2xq2MHhZNdRNT1hEOgcGaP6BjR0FEYBn2rLj0=.b989188c-f35f-46ac-8f54-f249f16b381e@github.com>
Message-ID: <fjnYVoMTLK813ebtV6fF2KXYwekpEyyyAOjwxXrWsd0=.1d489d4e-f54f-4b55-8a7a-2cb477647ee6@github.com>

On Fri, 17 Dec 2021 21:35:24 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Please review this fix which is checking if the enclosing class of an anonymous class is denotable or not. Currently javac is failing with an error at class writing time. All this fix is doing is failing during attribution and trying to issue a better error message so that the user knows better how to fix the issue and the position of the offending code,
> 
> TIA

ping

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

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

From jlahoda at openjdk.java.net  Wed Jan  5 14:37:02 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Wed, 5 Jan 2022 14:37:02 GMT
Subject: [jdk18] RFR: 8278373: JavacTrees.searchMethod finds incorrect
 match [v2]
In-Reply-To: <XbMsX_o0DPzcRmiLkhyD0uXxvEfHB8kXLGVoB9DWMFw=.9ccaedb0-4fab-44a1-ab68-8612a85d796e@github.com>
References: <XbMsX_o0DPzcRmiLkhyD0uXxvEfHB8kXLGVoB9DWMFw=.9ccaedb0-4fab-44a1-ab68-8612a85d796e@github.com>
Message-ID: <DIfaqsTcwwXliEiAXA4HKmK3kRsOgltc6Q3o6vIGnhc=.98e30e63-4544-44e5-be78-2064dd3eb5eb@github.com>

> Currently, when javac encounters a javadoc reference, like `@see PrintStream#println(int)`, will first try to find a method `println` in `PrintStream` using subtyping on the argument types, which may find another overload of the method with an argument that is a subtype of `int` - like `println(double)`. Consequently, the link in the javadoc may be to a wrong method.
> 
> In this patch, the proposal is to use the subtype search only as a backup option, using the existing check based on `isSameType` first, and only doing an inexact match using subtyping if the more exact match fails to find a method. This fallback should help possible existing broken references to still work as before, while the preferred use of the more exact match should select the correct method in usual correct cases.
> 
> This patch fixes some instances of incorrect references in the JDK's javadoc, a diff of the generated javadocs for the JDK mainline is here:
> http://cr.openjdk.java.net/~jlahoda/8278373/JDK-8278373.diff

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

 - Merge branch 'master' into JDK-8278373
 - Adding new test cases as suggested on the code review.
 - 8278373: JavacTypes.searchMethod finds incorrect match

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

Changes:
  - all: https://git.openjdk.java.net/jdk18/pull/79/files
  - new: https://git.openjdk.java.net/jdk18/pull/79/files/8c0ad7f0..0c88aa60

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

  Stats: 137 lines in 5 files changed: 116 ins; 8 del; 13 mod
  Patch: https://git.openjdk.java.net/jdk18/pull/79.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk18 pull/79/head:pull/79

PR: https://git.openjdk.java.net/jdk18/pull/79

From jlahoda at openjdk.java.net  Wed Jan  5 14:37:03 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Wed, 5 Jan 2022 14:37:03 GMT
Subject: [jdk18] RFR: 8278373: JavacTrees.searchMethod finds incorrect
 match
In-Reply-To: <XbMsX_o0DPzcRmiLkhyD0uXxvEfHB8kXLGVoB9DWMFw=.9ccaedb0-4fab-44a1-ab68-8612a85d796e@github.com>
References: <XbMsX_o0DPzcRmiLkhyD0uXxvEfHB8kXLGVoB9DWMFw=.9ccaedb0-4fab-44a1-ab68-8612a85d796e@github.com>
Message-ID: <sgFodMNmbdwDQsVQw3CbM8kM5XQGRuiqCw0zHq1ermE=.c65a6cfd-d369-40b9-a1b6-9710034987a4@github.com>

On Tue, 4 Jan 2022 17:19:44 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Currently, when javac encounters a javadoc reference, like `@see PrintStream#println(int)`, will first try to find a method `println` in `PrintStream` using subtyping on the argument types, which may find another overload of the method with an argument that is a subtype of `int` - like `println(double)`. Consequently, the link in the javadoc may be to a wrong method.
> 
> In this patch, the proposal is to use the subtype search only as a backup option, using the existing check based on `isSameType` first, and only doing an inexact match using subtyping if the more exact match fails to find a method. This fallback should help possible existing broken references to still work as before, while the preferred use of the more exact match should select the correct method in usual correct cases.
> 
> This patch fixes some instances of incorrect references in the JDK's javadoc, a diff of the generated javadocs for the JDK mainline is here:
> http://cr.openjdk.java.net/~jlahoda/8278373/JDK-8278373.diff

I've filled a release note here:
https://bugs.openjdk.java.net/browse/JDK-8279503

And updated the patch to include primitive types and methods with multiple parameters: https://github.com/openjdk/jdk18/pull/79/commits/34e421b96fa7f4e7e20aec16bb758056191b8773

Feedback is welcome!

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

PR: https://git.openjdk.java.net/jdk18/pull/79

From vromero at openjdk.java.net  Wed Jan  5 16:48:23 2022
From: vromero at openjdk.java.net (Vicente Romero)
Date: Wed, 5 Jan 2022 16:48:23 GMT
Subject: [jdk18] RFR: 8278373: JavacTrees.searchMethod finds incorrect
 match [v2]
In-Reply-To: <DIfaqsTcwwXliEiAXA4HKmK3kRsOgltc6Q3o6vIGnhc=.98e30e63-4544-44e5-be78-2064dd3eb5eb@github.com>
References: <XbMsX_o0DPzcRmiLkhyD0uXxvEfHB8kXLGVoB9DWMFw=.9ccaedb0-4fab-44a1-ab68-8612a85d796e@github.com>
 <DIfaqsTcwwXliEiAXA4HKmK3kRsOgltc6Q3o6vIGnhc=.98e30e63-4544-44e5-be78-2064dd3eb5eb@github.com>
Message-ID: <rfaIKB7JBQmTiz3RJQlQwu_ZBxv8kGp_b9-E7_Cy_tI=.b681c97c-fcba-4905-a450-3f0d56d5844f@github.com>

On Wed, 5 Jan 2022 14:37:02 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Currently, when javac encounters a javadoc reference, like `@see PrintStream#println(int)`, will first try to find a method `println` in `PrintStream` using subtyping on the argument types, which may find another overload of the method with an argument that is a subtype of `int` - like `println(double)`. Consequently, the link in the javadoc may be to a wrong method.
>> 
>> In this patch, the proposal is to use the subtype search only as a backup option, using the existing check based on `isSameType` first, and only doing an inexact match using subtyping if the more exact match fails to find a method. This fallback should help possible existing broken references to still work as before, while the preferred use of the more exact match should select the correct method in usual correct cases.
>> 
>> This patch fixes some instances of incorrect references in the JDK's javadoc, a diff of the generated javadocs for the JDK mainline is here:
>> http://cr.openjdk.java.net/~jlahoda/8278373/JDK-8278373.diff
>
> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8278373
>  - Adding new test cases as suggested on the code review.
>  - 8278373: JavacTypes.searchMethod finds incorrect match

latest change looks good to me

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

PR: https://git.openjdk.java.net/jdk18/pull/79

From shade at openjdk.java.net  Wed Jan  5 17:06:38 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 5 Jan 2022 17:06:38 GMT
Subject: RFR: 8279528: Unused TypeEnter.diag after JDK-8205187
Message-ID: <-mtpP2t1Aa-d47dM58ZTVpX2XHZt_D-oOfAfhjQz9t0=.ea87413b-22fb-4ebb-a41e-271b93bc9de9@github.com>

SonarCloud reports that `TypeEnter.diag` is not used. The last use was removed by [JDK-8205187](https://bugs.openjdk.java.net/browse/JDK-8205187). We can probably save a few bytes/cycles by not retaining it.

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

Commit messages:
 - 8279528: Unused TypeEnter.diag after JDK-8205187

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

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

From vromero at openjdk.java.net  Wed Jan  5 18:55:15 2022
From: vromero at openjdk.java.net (Vicente Romero)
Date: Wed, 5 Jan 2022 18:55:15 GMT
Subject: RFR: 8279528: Unused TypeEnter.diag after JDK-8205187
In-Reply-To: <-mtpP2t1Aa-d47dM58ZTVpX2XHZt_D-oOfAfhjQz9t0=.ea87413b-22fb-4ebb-a41e-271b93bc9de9@github.com>
References: <-mtpP2t1Aa-d47dM58ZTVpX2XHZt_D-oOfAfhjQz9t0=.ea87413b-22fb-4ebb-a41e-271b93bc9de9@github.com>
Message-ID: <Yq37hDGGmjgq3Kw92M-jRS0KjGSWfRk7GIoV1Xo2Dm4=.acf2c95e-273b-47d6-a07c-2ea6c2a91676@github.com>

On Wed, 5 Jan 2022 16:58:33 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> SonarCloud reports that `TypeEnter.diag` is not used. The last use was removed by [JDK-8205187](https://bugs.openjdk.java.net/browse/JDK-8205187). We can probably save a few bytes/cycles by not retaining it.

looks good

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

Marked as reviewed by vromero (Reviewer).

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

From darcy at openjdk.java.net  Wed Jan  5 18:59:16 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 5 Jan 2022 18:59:16 GMT
Subject: Integrated: JDK-8277515: Update --release 18 symbol information for
 JDK 18 build 29
In-Reply-To: <daMK3jGvo3fdSUym74f8uxJPtG5Xm6JfbMCA1iCSiVU=.20631e0d-4263-4846-be6b-5b89c32f2870@github.com>
References: <daMK3jGvo3fdSUym74f8uxJPtG5Xm6JfbMCA1iCSiVU=.20631e0d-4263-4846-be6b-5b89c32f2870@github.com>
Message-ID: <BnQmjkOjkHHzWJlWkhYV6tTtKQ49659A9036Uq_yFco=.354f2114-928f-4cdb-a704-bf11011baf54@github.com>

On Mon, 3 Jan 2022 18:26:24 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Usual update to the JDK 19 symbol files for changes in JDK 18; this time JDK-8276660 in JDK 18 build 28.

This pull request has now been integrated.

Changeset: 9a0e8900
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/9a0e890056fb8ae4e28e656118e73fae33ba5e2a
Stats:     5 lines in 1 file changed: 4 ins; 0 del; 1 mod

8277515: Update --release 18 symbol information for JDK 18 build 29

Reviewed-by: iris

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

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

From jlahoda at openjdk.java.net  Wed Jan  5 20:29:10 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Wed, 5 Jan 2022 20:29:10 GMT
Subject: RFR: 8211004: javac is complaining about non-denotable types and
 refusing to generate the class file
In-Reply-To: <kvzpIy2xq2MHhZNdRNT1hEOgcGaP6BjR0FEYBn2rLj0=.b989188c-f35f-46ac-8f54-f249f16b381e@github.com>
References: <kvzpIy2xq2MHhZNdRNT1hEOgcGaP6BjR0FEYBn2rLj0=.b989188c-f35f-46ac-8f54-f249f16b381e@github.com>
Message-ID: <OUfOb9i3EhCmq4CL3n3Cn1ceRs_97Y8bRAfSPGwcjM8=.9eda49cd-3660-40f3-b46a-dbe3cb5ad843@github.com>

On Fri, 17 Dec 2021 21:35:24 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Please review this fix which is checking if the enclosing class of an anonymous class is denotable or not. Currently javac is failing with an error at class writing time. All this fix is doing is failing during attribution and trying to issue a better error message so that the user knows better how to fix the issue and the position of the offending code,
> 
> TIA

Looks reasonable.

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

Marked as reviewed by jlahoda (Reviewer).

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

From vromero at openjdk.java.net  Wed Jan  5 20:57:16 2022
From: vromero at openjdk.java.net (Vicente Romero)
Date: Wed, 5 Jan 2022 20:57:16 GMT
Subject: RFR: 8211004: javac is complaining about non-denotable types and
 refusing to generate the class file
In-Reply-To: <kvzpIy2xq2MHhZNdRNT1hEOgcGaP6BjR0FEYBn2rLj0=.b989188c-f35f-46ac-8f54-f249f16b381e@github.com>
References: <kvzpIy2xq2MHhZNdRNT1hEOgcGaP6BjR0FEYBn2rLj0=.b989188c-f35f-46ac-8f54-f249f16b381e@github.com>
Message-ID: <3k3decu-1toNuG1Q0uN-3euSdjIQtzsSKWb2UrRyYjQ=.dc6f8e55-12cf-4a19-99cc-73d2766bb334@github.com>

On Fri, 17 Dec 2021 21:35:24 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Please review this fix which is checking if the enclosing class of an anonymous class is denotable or not. Currently javac is failing with an error at class writing time. All this fix is doing is failing during attribution and trying to issue a better error message so that the user knows better how to fix the issue and the position of the offending code,
> 
> TIA

thanks!

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

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

From vromero at openjdk.java.net  Wed Jan  5 21:02:50 2022
From: vromero at openjdk.java.net (Vicente Romero)
Date: Wed, 5 Jan 2022 21:02:50 GMT
Subject: RFR: 8211004: javac is complaining about non-denotable types and
 refusing to generate the class file [v2]
In-Reply-To: <kvzpIy2xq2MHhZNdRNT1hEOgcGaP6BjR0FEYBn2rLj0=.b989188c-f35f-46ac-8f54-f249f16b381e@github.com>
References: <kvzpIy2xq2MHhZNdRNT1hEOgcGaP6BjR0FEYBn2rLj0=.b989188c-f35f-46ac-8f54-f249f16b381e@github.com>
Message-ID: <_WdYX7Q-jQ-oy8yPI9oMPc6NtEx5X3Alj1HGnmXCXO4=.85e3d29f-7ce4-446a-bde8-8dbef9650239@github.com>

> Please review this fix which is checking if the enclosing class of an anonymous class is denotable or not. Currently javac is failing with an error at class writing time. All this fix is doing is failing during attribution and trying to issue a better error message so that the user knows better how to fix the issue and the position of the offending code,
> 
> TIA

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

 - Merge branch 'master' into JDK-8211004
 - 8211004: javac is complaining about non-denotable types and refusing to generate the class file

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6886/files
  - new: https://git.openjdk.java.net/jdk/pull/6886/files/ed719136..a50d57b7

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

  Stats: 13046 lines in 494 files changed: 7907 ins; 3309 del; 1830 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6886.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6886/head:pull/6886

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

From vromero at openjdk.java.net  Thu Jan  6 05:57:41 2022
From: vromero at openjdk.java.net (Vicente Romero)
Date: Thu, 6 Jan 2022 05:57:41 GMT
Subject: RFR: 8279290: symbol not found error,
 implicit lambdas and diamond constructor invocations
Message-ID: <FqpZkwB3s1HYMA2r86PGnFSZP4x6jswxxGN8pHVL5ag=.c48a15bf-daaf-433c-9def-fe9c36c3c9f4@github.com>

Please review this PR which is fixing a bug caused by scope sharing. In particular for code like:

class Test {
    static class B<T>{}

    static class A1 {
        <T> A1(Consumer<T> cons) {}
    }

    void foo() {
        new A1(findMe ->
                new B<>() {{
                    System.out.println(findMe); // javac is failing here with symbol not found for findMe
                }});
    }
}

the reason for the error is that when attributing the diamond constructor invocation, a listener is registered in the current inference context. But the scope inside the environment passed to the listener is shared with the implicit lambda and once the lambda has been attributed, the argument `findMe` is removed from the shared scope. See the `localEnv.info.scope.leave()` at the end of `Attr::visitLambda`. This is why it is necessary to duplicate the scope as proposed in this patch.

TIA

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

Commit messages:
 - 8279290: symbol not found error, implicit lambdas and diamond constructor invocations

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

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

From vromero at openjdk.java.net  Thu Jan  6 06:02:13 2022
From: vromero at openjdk.java.net (Vicente Romero)
Date: Thu, 6 Jan 2022 06:02:13 GMT
Subject: Integrated: 8211004: javac is complaining about non-denotable types
 and refusing to generate the class file
In-Reply-To: <kvzpIy2xq2MHhZNdRNT1hEOgcGaP6BjR0FEYBn2rLj0=.b989188c-f35f-46ac-8f54-f249f16b381e@github.com>
References: <kvzpIy2xq2MHhZNdRNT1hEOgcGaP6BjR0FEYBn2rLj0=.b989188c-f35f-46ac-8f54-f249f16b381e@github.com>
Message-ID: <DyLZcaNMloePo-xj6bzjF4gndTy4jb5k9vtfup3hewY=.1fdab8d1-93eb-44cd-b891-487577f46868@github.com>

On Fri, 17 Dec 2021 21:35:24 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Please review this fix which is checking if the enclosing class of an anonymous class is denotable or not. Currently javac is failing with an error at class writing time. All this fix is doing is failing during attribution and trying to issue a better error message so that the user knows better how to fix the issue and the position of the offending code,
> 
> TIA

This pull request has now been integrated.

Changeset: 456bd1ed
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/456bd1ed1cbfedc225194e9afb917b913e5bc9d5
Stats:     21 lines in 8 files changed: 15 ins; 1 del; 5 mod

8211004: javac is complaining about non-denotable types and refusing to generate the class file

Reviewed-by: jlahoda

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

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

From jlahoda at openjdk.java.net  Thu Jan  6 13:57:54 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Thu, 6 Jan 2022 13:57:54 GMT
Subject: [jdk18] RFR: 8278930: javac tries to compile a file twice via
 PackageElement.getEnclosedElements
Message-ID: <79N27LyKBfILLvA9ewVCZic1F5YY6bLWMcZdw3Scgtw=.4dbf47a8-1056-4781-97e2-f066eb1b2f45@github.com>

When using the Elements API, it may happen that an inner class is being completed before its enclosing class. The code is generally prepared for that, and will complete the enclosing class before filling in the content of the inner class.

An issue happens if the enclosing class is completed from source. Then, since [JDK-8224922](https://bugs.openjdk.java.net/browse/JDK-8224922), the innerclass' `ClassSymbol.classfile` will be set to the source file as well, and then javac will try to fill the innerclass from the source code again, leading to duplicate class error. (Before JDK-8224922, the innerclass was, as far as I can tell, completed from the classfile, which didn't lead to this specific problem, but is unlikely to be completely correct either.)

The proposal in this fix is to detect the situation where the nested class was already filled after the enclosing class has been completed, and skip further processing.

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

Commit messages:
 - 8278930: javac tries to compile a file twice via PackageElement.getEnclosedElements

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

PR: https://git.openjdk.java.net/jdk18/pull/85

From vromero at openjdk.java.net  Thu Jan  6 18:05:15 2022
From: vromero at openjdk.java.net (Vicente Romero)
Date: Thu, 6 Jan 2022 18:05:15 GMT
Subject: [jdk18] RFR: 8278930: javac tries to compile a file twice via
 PackageElement.getEnclosedElements
In-Reply-To: <79N27LyKBfILLvA9ewVCZic1F5YY6bLWMcZdw3Scgtw=.4dbf47a8-1056-4781-97e2-f066eb1b2f45@github.com>
References: <79N27LyKBfILLvA9ewVCZic1F5YY6bLWMcZdw3Scgtw=.4dbf47a8-1056-4781-97e2-f066eb1b2f45@github.com>
Message-ID: <ohQP1BDpdT9KTGWZAyOyYAVnyFz1EihNbRYUopybdRc=.9a319c2a-f9da-4a33-99c7-0f1d87ec8256@github.com>

On Thu, 6 Jan 2022 13:48:40 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> When using the Elements API, it may happen that an inner class is being completed before its enclosing class. The code is generally prepared for that, and will complete the enclosing class before filling in the content of the inner class.
> 
> An issue happens if the enclosing class is completed from source. Then, since [JDK-8224922](https://bugs.openjdk.java.net/browse/JDK-8224922), the innerclass' `ClassSymbol.classfile` will be set to the source file as well, and then javac will try to fill the innerclass from the source code again, leading to duplicate class error. (Before JDK-8224922, the innerclass was, as far as I can tell, completed from the classfile, which didn't lead to this specific problem, but is unlikely to be completely correct either.)
> 
> The proposal in this fix is to detect the situation where the nested class was already filled after the enclosing class has been completed, and skip further processing.

looks sensible

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

Marked as reviewed by vromero (Reviewer).

PR: https://git.openjdk.java.net/jdk18/pull/85

From jjg at openjdk.java.net  Fri Jan  7 00:04:30 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Fri, 7 Jan 2022 00:04:30 GMT
Subject: [jdk18] RFR: 8278930: javac tries to compile a file twice via
 PackageElement.getEnclosedElements
In-Reply-To: <79N27LyKBfILLvA9ewVCZic1F5YY6bLWMcZdw3Scgtw=.4dbf47a8-1056-4781-97e2-f066eb1b2f45@github.com>
References: <79N27LyKBfILLvA9ewVCZic1F5YY6bLWMcZdw3Scgtw=.4dbf47a8-1056-4781-97e2-f066eb1b2f45@github.com>
Message-ID: <41Z2LFC6BkhV7HGN69D8LrcU4iYdlUlHY3hZy_jiuSk=.d9e5b807-4ccf-474f-b755-04fe70c4bcf6@github.com>

On Thu, 6 Jan 2022 13:48:40 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> When using the Elements API, it may happen that an inner class is being completed before its enclosing class. The code is generally prepared for that, and will complete the enclosing class before filling in the content of the inner class.
> 
> An issue happens if the enclosing class is completed from source. Then, since [JDK-8224922](https://bugs.openjdk.java.net/browse/JDK-8224922), the innerclass' `ClassSymbol.classfile` will be set to the source file as well, and then javac will try to fill the innerclass from the source code again, leading to duplicate class error. (Before JDK-8224922, the innerclass was, as far as I can tell, completed from the classfile, which didn't lead to this specific problem, but is unlikely to be completely correct either.)
> 
> The proposal in this fix is to detect the situation where the nested class was already filled after the enclosing class has been completed, and skip further processing.

The change to the code looks plausible, but I'm not expert enough to approve it.

Check copyright years on modified files.

test/langtools/tools/javac/processing/model/element/TestListPackageFromAPI.java line 2:

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

Copyright year?

test/langtools/tools/javac/processing/model/element/TestListPackageFromAPI.java line 70:

> 68:         Files.newOutputStream(classes.resolve("Test.class")).close();
> 69: 
> 70:         Thread.sleep(2000);

Mild ugh

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

PR: https://git.openjdk.java.net/jdk18/pull/85

From shade at openjdk.java.net  Fri Jan  7 07:07:16 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 7 Jan 2022 07:07:16 GMT
Subject: RFR: 8279528: Unused TypeEnter.diag after JDK-8205187
In-Reply-To: <-mtpP2t1Aa-d47dM58ZTVpX2XHZt_D-oOfAfhjQz9t0=.ea87413b-22fb-4ebb-a41e-271b93bc9de9@github.com>
References: <-mtpP2t1Aa-d47dM58ZTVpX2XHZt_D-oOfAfhjQz9t0=.ea87413b-22fb-4ebb-a41e-271b93bc9de9@github.com>
Message-ID: <79Ue7vVCiMqu6aprAVwkJpBF2C7ZV89MzBByd8HKZIg=.6da5dca7-5767-4a1f-81ff-ac8775258963@github.com>

On Wed, 5 Jan 2022 16:58:33 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> SonarCloud reports that `TypeEnter.diag` is not used. The last use was removed by [JDK-8205187](https://bugs.openjdk.java.net/browse/JDK-8205187). We can probably save a few bytes/cycles by not retaining it.

Thanks, more reviewers needed, or is this change simple enough?

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

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

From cushon at openjdk.java.net  Fri Jan  7 11:32:16 2022
From: cushon at openjdk.java.net (Liam Miller-Cushon)
Date: Fri, 7 Jan 2022 11:32:16 GMT
Subject: RFR: JDK-8273914: Indy string concat changes order of operations
 [v3]
In-Reply-To: <iz96gKt6sVKRwfWbCQ-s8Z0WUb7Xvy08CqfliZns9I4=.f0e5a0c0-842e-4956-b4c5-c8c5d4baf86d@github.com>
References: <iM42rUgZ1oVRCQTQ5-HcSSSxq8WPmNzMwLEivYMOjys=.9e5a2ed6-4877-4bb0-a250-75f4ae373c49@github.com>
 <rgiR7fXVguKEdzQPLXphCNrAy-cHiOB5jGbo2ubKXRk=.20723bde-1088-45c5-a73a-d22489590694@github.com>
 <iz96gKt6sVKRwfWbCQ-s8Z0WUb7Xvy08CqfliZns9I4=.f0e5a0c0-842e-4956-b4c5-c8c5d4baf86d@github.com>
Message-ID: <72IPi3oS8KX5xaCsQWGxR09xzHMNpFK3PySyQv8g8TA=.c273cd54-1473-40e0-95fe-311d595c02e7@github.com>

On Tue, 12 Oct 2021 07:23:32 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Document the rationale for the jasm changes
>
> How about code like:
> 
>         StringBuilder builder2 = new StringBuilder("foo");
>         Object oo = builder2;
>         oo += "" + builder2.append("bar"); 
> 
> 
> Should that be covered as well? From looking at the patch (not really trying it), it does not seem to be covered?

@lahodaj would you be willing to review for the compiler group?

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

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

From jlahoda at openjdk.java.net  Fri Jan  7 12:41:07 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Fri, 7 Jan 2022 12:41:07 GMT
Subject: [jdk18] RFR: 8278930: javac tries to compile a file twice via
 PackageElement.getEnclosedElements [v2]
In-Reply-To: <79N27LyKBfILLvA9ewVCZic1F5YY6bLWMcZdw3Scgtw=.4dbf47a8-1056-4781-97e2-f066eb1b2f45@github.com>
References: <79N27LyKBfILLvA9ewVCZic1F5YY6bLWMcZdw3Scgtw=.4dbf47a8-1056-4781-97e2-f066eb1b2f45@github.com>
Message-ID: <LGGZcLqGePL6HqpnWvhhaYyVfUEXHR2Iatu9ak5JLoI=.ab62c925-e765-4fbd-87fc-75b01c07d609@github.com>

> When using the Elements API, it may happen that an inner class is being completed before its enclosing class. The code is generally prepared for that, and will complete the enclosing class before filling in the content of the inner class.
> 
> An issue happens if the enclosing class is completed from source. Then, since [JDK-8224922](https://bugs.openjdk.java.net/browse/JDK-8224922), the innerclass' `ClassSymbol.classfile` will be set to the source file as well, and then javac will try to fill the innerclass from the source code again, leading to duplicate class error. (Before JDK-8224922, the innerclass was, as far as I can tell, completed from the classfile, which didn't lead to this specific problem, but is unlikely to be completely correct either.)
> 
> The proposal in this fix is to detect the situation where the nested class was already filled after the enclosing class has been completed, and skip further processing.

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

  Test cleanup.

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

Changes:
  - all: https://git.openjdk.java.net/jdk18/pull/85/files
  - new: https://git.openjdk.java.net/jdk18/pull/85/files/c3473de4..6bef38f5

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

  Stats: 41 lines in 1 file changed: 7 ins; 26 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk18/pull/85.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk18 pull/85/head:pull/85

PR: https://git.openjdk.java.net/jdk18/pull/85

From jlahoda at openjdk.java.net  Fri Jan  7 12:47:05 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Fri, 7 Jan 2022 12:47:05 GMT
Subject: [jdk18] RFR: 8278930: javac tries to compile a file twice via
 PackageElement.getEnclosedElements [v3]
In-Reply-To: <41Z2LFC6BkhV7HGN69D8LrcU4iYdlUlHY3hZy_jiuSk=.d9e5b807-4ccf-474f-b755-04fe70c4bcf6@github.com>
References: <79N27LyKBfILLvA9ewVCZic1F5YY6bLWMcZdw3Scgtw=.4dbf47a8-1056-4781-97e2-f066eb1b2f45@github.com>
 <41Z2LFC6BkhV7HGN69D8LrcU4iYdlUlHY3hZy_jiuSk=.d9e5b807-4ccf-474f-b755-04fe70c4bcf6@github.com>
Message-ID: <UoLewVgtMyO5PgRs-2SeNapNuCEzc8eqD3wDSAj1J3s=.c8d554c5-05b6-4800-b8ef-8877386c7d54@github.com>

On Thu, 6 Jan 2022 23:58:29 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updating year.
>
> test/langtools/tools/javac/processing/model/element/TestListPackageFromAPI.java line 70:
> 
>> 68:         Files.newOutputStream(classes.resolve("Test.class")).close();
>> 69: 
>> 70:         Thread.sleep(2000);
> 
> Mild ugh.  What condition are you waiting for?  Are you waiting for file timestamps to be newer, or something like that?  Can you "poll" looking for the desired change instead?

Thanks for the comment!

It was waiting to reliably make the timestamps different, but I've cleaned up the test here to avoid that:
https://github.com/openjdk/jdk18/pull/85/commits/6bef38f54e791092eb88843c766d8f5d064ac9c5

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

PR: https://git.openjdk.java.net/jdk18/pull/85

From jlahoda at openjdk.java.net  Fri Jan  7 12:47:04 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Fri, 7 Jan 2022 12:47:04 GMT
Subject: [jdk18] RFR: 8278930: javac tries to compile a file twice via
 PackageElement.getEnclosedElements [v3]
In-Reply-To: <79N27LyKBfILLvA9ewVCZic1F5YY6bLWMcZdw3Scgtw=.4dbf47a8-1056-4781-97e2-f066eb1b2f45@github.com>
References: <79N27LyKBfILLvA9ewVCZic1F5YY6bLWMcZdw3Scgtw=.4dbf47a8-1056-4781-97e2-f066eb1b2f45@github.com>
Message-ID: <OiEsVEYHCI4FbRnq1GjIIE6DkZv2vRha9BPwbzpd0do=.d8a7fced-3118-423c-9cb3-7f96a6416d10@github.com>

> When using the Elements API, it may happen that an inner class is being completed before its enclosing class. The code is generally prepared for that, and will complete the enclosing class before filling in the content of the inner class.
> 
> An issue happens if the enclosing class is completed from source. Then, since [JDK-8224922](https://bugs.openjdk.java.net/browse/JDK-8224922), the innerclass' `ClassSymbol.classfile` will be set to the source file as well, and then javac will try to fill the innerclass from the source code again, leading to duplicate class error. (Before JDK-8224922, the innerclass was, as far as I can tell, completed from the classfile, which didn't lead to this specific problem, but is unlikely to be completely correct either.)
> 
> The proposal in this fix is to detect the situation where the nested class was already filled after the enclosing class has been completed, and skip further processing.

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

  Updating year.

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

Changes:
  - all: https://git.openjdk.java.net/jdk18/pull/85/files
  - new: https://git.openjdk.java.net/jdk18/pull/85/files/6bef38f5..b051fdc4

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

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk18/pull/85.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk18 pull/85/head:pull/85

PR: https://git.openjdk.java.net/jdk18/pull/85

From vromero at openjdk.java.net  Fri Jan  7 14:26:16 2022
From: vromero at openjdk.java.net (Vicente Romero)
Date: Fri, 7 Jan 2022 14:26:16 GMT
Subject: RFR: 8279528: Unused TypeEnter.diag after JDK-8205187
In-Reply-To: <-mtpP2t1Aa-d47dM58ZTVpX2XHZt_D-oOfAfhjQz9t0=.ea87413b-22fb-4ebb-a41e-271b93bc9de9@github.com>
References: <-mtpP2t1Aa-d47dM58ZTVpX2XHZt_D-oOfAfhjQz9t0=.ea87413b-22fb-4ebb-a41e-271b93bc9de9@github.com>
Message-ID: <lAqqHP4Rd5150-iit9DqPP7k3Ii64XQrhyCPTtmq2tk=.31b1de8f-31cb-47c0-baf7-6c961b3487a5@github.com>

On Wed, 5 Jan 2022 16:58:33 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> SonarCloud reports that `TypeEnter.diag` is not used. The last use was removed by [JDK-8205187](https://bugs.openjdk.java.net/browse/JDK-8205187). We can probably save a few bytes/cycles by not retaining it.

usually one reviewer is enough, unless it is a big change

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

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

From vromero at openjdk.java.net  Fri Jan  7 17:22:30 2022
From: vromero at openjdk.java.net (Vicente Romero)
Date: Fri, 7 Jan 2022 17:22:30 GMT
Subject: RFR: JDK-8273914: Indy string concat changes order of operations
 [v5]
In-Reply-To: <mPchjrPQ83plRRl3Jbg_aG9WM3eAJiGCxun3P_B5IpU=.32a2242e-703a-45b3-90c4-8ee517719b15@github.com>
References: <iM42rUgZ1oVRCQTQ5-HcSSSxq8WPmNzMwLEivYMOjys=.9e5a2ed6-4877-4bb0-a250-75f4ae373c49@github.com>
 <mPchjrPQ83plRRl3Jbg_aG9WM3eAJiGCxun3P_B5IpU=.32a2242e-703a-45b3-90c4-8ee517719b15@github.com>
Message-ID: <OCSMiwH2ui1LZ_-ikM2W0KtqS0ZvwE65HOpCCCVgGS4=.db0bc455-fc3f-445d-9d05-a7d5b3a00420@github.com>

On Thu, 14 Oct 2021 17:14:42 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> This change makes string concatenation call `toString` on the arguments eagerly, to preserve the correct evaluation order of the arguments and the calls to `toString`.
>
> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename WellKnownTypes to WellKnownTypeSignatures
>   
>   and add more functional test coverage for string concat of well-known
>   types, covering all strategies.

the compiler changes look good to me

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

Marked as reviewed by vromero (Reviewer).

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

From jlahoda at openjdk.java.net  Fri Jan  7 18:18:29 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Fri, 7 Jan 2022 18:18:29 GMT
Subject: RFR: JDK-8273914: Indy string concat changes order of operations
 [v5]
In-Reply-To: <mPchjrPQ83plRRl3Jbg_aG9WM3eAJiGCxun3P_B5IpU=.32a2242e-703a-45b3-90c4-8ee517719b15@github.com>
References: <iM42rUgZ1oVRCQTQ5-HcSSSxq8WPmNzMwLEivYMOjys=.9e5a2ed6-4877-4bb0-a250-75f4ae373c49@github.com>
 <mPchjrPQ83plRRl3Jbg_aG9WM3eAJiGCxun3P_B5IpU=.32a2242e-703a-45b3-90c4-8ee517719b15@github.com>
Message-ID: <ryJadYLI_lfUaImg7lUdO2C_Rfl-MT2ghJ6yrrFZjEE=.c9bff76b-279d-42a0-8f04-9a73a2815287@github.com>

On Thu, 14 Oct 2021 17:14:42 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> This change makes string concatenation call `toString` on the arguments eagerly, to preserve the correct evaluation order of the arguments and the calls to `toString`.
>
> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename WellKnownTypes to WellKnownTypeSignatures
>   
>   and add more functional test coverage for string concat of well-known
>   types, covering all strategies.

Looks reasonable.

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

Marked as reviewed by jlahoda (Reviewer).

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

From shade at openjdk.java.net  Mon Jan 10 08:34:32 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 10 Jan 2022 08:34:32 GMT
Subject: RFR: 8279528: Unused TypeEnter.diag after JDK-8205187
In-Reply-To: <-mtpP2t1Aa-d47dM58ZTVpX2XHZt_D-oOfAfhjQz9t0=.ea87413b-22fb-4ebb-a41e-271b93bc9de9@github.com>
References: <-mtpP2t1Aa-d47dM58ZTVpX2XHZt_D-oOfAfhjQz9t0=.ea87413b-22fb-4ebb-a41e-271b93bc9de9@github.com>
Message-ID: <jvEy8jMdzg2OOY5gyzBCNF5upv75r2mhvPEuLXBiN6c=.0f764ead-ab08-430c-be1b-3befecd04e7f@github.com>

On Wed, 5 Jan 2022 16:58:33 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> SonarCloud reports that `TypeEnter.diag` is not used. The last use was removed by [JDK-8205187](https://bugs.openjdk.java.net/browse/JDK-8205187). We can probably save a few bytes/cycles by not retaining it.

All right then, thanks!

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

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

From shade at openjdk.java.net  Mon Jan 10 08:34:33 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 10 Jan 2022 08:34:33 GMT
Subject: Integrated: 8279528: Unused TypeEnter.diag after JDK-8205187
In-Reply-To: <-mtpP2t1Aa-d47dM58ZTVpX2XHZt_D-oOfAfhjQz9t0=.ea87413b-22fb-4ebb-a41e-271b93bc9de9@github.com>
References: <-mtpP2t1Aa-d47dM58ZTVpX2XHZt_D-oOfAfhjQz9t0=.ea87413b-22fb-4ebb-a41e-271b93bc9de9@github.com>
Message-ID: <tzZwaZbBXUfDhIAZVOcJhP2HCFbh9odhsnfB8by4DFs=.923ed8b6-c8a1-4922-853f-bc933e03f2b1@github.com>

On Wed, 5 Jan 2022 16:58:33 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> SonarCloud reports that `TypeEnter.diag` is not used. The last use was removed by [JDK-8205187](https://bugs.openjdk.java.net/browse/JDK-8205187). We can probably save a few bytes/cycles by not retaining it.

This pull request has now been integrated.

Changeset: 4aefd8b8
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/4aefd8b8b6cd76137e3bc51a84d1182fde22ba02
Stats:     2 lines in 1 file changed: 0 ins; 2 del; 0 mod

8279528: Unused TypeEnter.diag after JDK-8205187

Reviewed-by: vromero

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

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

From jlahoda at openjdk.java.net  Mon Jan 10 08:38:39 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Mon, 10 Jan 2022 08:38:39 GMT
Subject: [jdk18] Integrated: 8278373: JavacTrees.searchMethod finds incorrect
 match
In-Reply-To: <XbMsX_o0DPzcRmiLkhyD0uXxvEfHB8kXLGVoB9DWMFw=.9ccaedb0-4fab-44a1-ab68-8612a85d796e@github.com>
References: <XbMsX_o0DPzcRmiLkhyD0uXxvEfHB8kXLGVoB9DWMFw=.9ccaedb0-4fab-44a1-ab68-8612a85d796e@github.com>
Message-ID: <TMCccJsSpO3nRBTDF56Lh_DwuoUDvuXujXhvqt05Nd4=.f0b7bd98-380d-4040-948a-8f2fcff5b44e@github.com>

On Tue, 4 Jan 2022 17:19:44 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Currently, when javac encounters a javadoc reference, like `@see PrintStream#println(int)`, will first try to find a method `println` in `PrintStream` using subtyping on the argument types, which may find another overload of the method with an argument that is a subtype of `int` - like `println(double)`. Consequently, the link in the javadoc may be to a wrong method.
> 
> In this patch, the proposal is to use the subtype search only as a backup option, using the existing check based on `isSameType` first, and only doing an inexact match using subtyping if the more exact match fails to find a method. This fallback should help possible existing broken references to still work as before, while the preferred use of the more exact match should select the correct method in usual correct cases.
> 
> This patch fixes some instances of incorrect references in the JDK's javadoc, a diff of the generated javadocs for the JDK mainline is here:
> http://cr.openjdk.java.net/~jlahoda/8278373/JDK-8278373.diff

This pull request has now been integrated.

Changeset: 642ab34a
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.java.net/jdk18/commit/642ab34a60172f4b629f953e146b54b9c7269033
Stats:     89 lines in 2 files changed: 71 ins; 2 del; 16 mod

8278373: JavacTrees.searchMethod finds incorrect match

Reviewed-by: vromero, jjg

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

PR: https://git.openjdk.java.net/jdk18/pull/79

From jlahoda at openjdk.java.net  Mon Jan 10 09:34:43 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Mon, 10 Jan 2022 09:34:43 GMT
Subject: [jdk18] Integrated: 8278930: javac tries to compile a file twice via
 PackageElement.getEnclosedElements
In-Reply-To: <79N27LyKBfILLvA9ewVCZic1F5YY6bLWMcZdw3Scgtw=.4dbf47a8-1056-4781-97e2-f066eb1b2f45@github.com>
References: <79N27LyKBfILLvA9ewVCZic1F5YY6bLWMcZdw3Scgtw=.4dbf47a8-1056-4781-97e2-f066eb1b2f45@github.com>
Message-ID: <NcGAmUNsIjLb5N6UFQCvAFMtX6yrjunBwr4d5WEAFiw=.537a8fe3-1d74-4a59-ac7d-f95cd2278134@github.com>

On Thu, 6 Jan 2022 13:48:40 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> When using the Elements API, it may happen that an inner class is being completed before its enclosing class. The code is generally prepared for that, and will complete the enclosing class before filling in the content of the inner class.
> 
> An issue happens if the enclosing class is completed from source. Then, since [JDK-8224922](https://bugs.openjdk.java.net/browse/JDK-8224922), the innerclass' `ClassSymbol.classfile` will be set to the source file as well, and then javac will try to fill the innerclass from the source code again, leading to duplicate class error. (Before JDK-8224922, the innerclass was, as far as I can tell, completed from the classfile, which didn't lead to this specific problem, but is unlikely to be completely correct either.)
> 
> The proposal in this fix is to detect the situation where the nested class was already filled after the enclosing class has been completed, and skip further processing.

This pull request has now been integrated.

Changeset: 8f969a13
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.java.net/jdk18/commit/8f969a1362343df8592046a838436f41894ee471
Stats:     158 lines in 2 files changed: 155 ins; 0 del; 3 mod

8278930: javac tries to compile a file twice via PackageElement.getEnclosedElements

Reviewed-by: vromero

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

PR: https://git.openjdk.java.net/jdk18/pull/85

From duke at openjdk.java.net  Mon Jan 10 11:08:52 2022
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Mon, 10 Jan 2022 11:08:52 GMT
Subject: RFR: 8274425: Remove unused Modules.extraLimitMods [v2]
In-Reply-To: <3XU4OpaQ6kW3DXLru4uScWtbIQBiYgHyoUPBdkkoo-g=.bd1ac042-fb54-4b37-9433-d4c0c5990e6f@github.com>
References: <3XU4OpaQ6kW3DXLru4uScWtbIQBiYgHyoUPBdkkoo-g=.bd1ac042-fb54-4b37-9433-d4c0c5990e6f@github.com>
Message-ID: <_VSeie5GC-sPX0apREmPYJCW__5cwX-EdClVUMJMlls=.84b4e3eb-7f53-438a-b180-588e67d9f3df@github.com>

> HashSet `com.sun.tools.javac.comp.Modules.extraLimitMods` is always empty. Code only check its content, but no content added.
> There was a method `addExtraLimitModules`, but it was removed under [JDK-8175191](https://bugs.openjdk.java.net/browse/JDK-8175191) 253fdcd0b26
> Method `addExtraLimitModules` itself was added in ec9ca2997f4, but was never actually used .

Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:

  8274425: Remove unused Modules.extraLimitMods
  
  update copyright year

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5628/files
  - new: https://git.openjdk.java.net/jdk/pull/5628/files/72bf4ca3..54113676

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

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

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

From hannesw at openjdk.java.net  Mon Jan 10 11:46:06 2022
From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Mon, 10 Jan 2022 11:46:06 GMT
Subject: [jdk18] RFR: JDK-8273452: DocTrees.getDocCommentTree should be
 specified as idempotent [v2]
In-Reply-To: <GhovZDzU7t6WkQLekF1CwPanpuN0newHN5TMPz2FZTs=.984b4252-2fa7-4de7-a33c-bc717e1bd413@github.com>
References: <GhovZDzU7t6WkQLekF1CwPanpuN0newHN5TMPz2FZTs=.984b4252-2fa7-4de7-a33c-bc717e1bd413@github.com>
Message-ID: <wHzzfXBgln7FpdvfWDceIFUHKt_GnMDW0Pja_p3vJVI=.42a09d9c-652e-42da-858a-d6c3aea84d1a@github.com>

> Please review a doc-only change to add implementation notes to the `DocTrees.getDocCommentTree` methods, some of which return the same `DocCommentTree` instance on repeated invocation and some don't. I decided to use `@implNote` instead of `@implSpec` as usually I wouldn't expect object identity to be part of a Java API specification.
> 
> I verified the described behavior using code analysis and enhancing existing tests. The latter are not included in the commit as this is a `noreg-doc` issue.

Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:

  JDK-8273452: review feedback

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

Changes:
  - all: https://git.openjdk.java.net/jdk18/pull/36/files
  - new: https://git.openjdk.java.net/jdk18/pull/36/files/f69a1052..66cbd42b

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

  Stats: 8 lines in 1 file changed: 4 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk18/pull/36.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk18 pull/36/head:pull/36

PR: https://git.openjdk.java.net/jdk18/pull/36

From hannesw at openjdk.java.net  Mon Jan 10 12:07:29 2022
From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Mon, 10 Jan 2022 12:07:29 GMT
Subject: [jdk18] Integrated: JDK-8273452: DocTrees.getDocCommentTree should be
 specified as idempotent
In-Reply-To: <GhovZDzU7t6WkQLekF1CwPanpuN0newHN5TMPz2FZTs=.984b4252-2fa7-4de7-a33c-bc717e1bd413@github.com>
References: <GhovZDzU7t6WkQLekF1CwPanpuN0newHN5TMPz2FZTs=.984b4252-2fa7-4de7-a33c-bc717e1bd413@github.com>
Message-ID: <lb2tIXx4Zk0lpGhYdBQyVCeJhS5Uki6epHNAlFrJ5uA=.1674789c-446f-4b01-8de5-fd343a68ad3a@github.com>

On Thu, 16 Dec 2021 11:05:01 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review a doc-only change to add implementation notes to the `DocTrees.getDocCommentTree` methods, some of which return the same `DocCommentTree` instance on repeated invocation and some don't. I decided to use `@implNote` instead of `@implSpec` as usually I wouldn't expect object identity to be part of a Java API specification.
> 
> I verified the described behavior using code analysis and enhancing existing tests. The latter are not included in the commit as this is a `noreg-doc` issue.

This pull request has now been integrated.

Changeset: 354c9047
Author:    Hannes Walln?fer <hannesw at openjdk.org>
URL:       https://git.openjdk.java.net/jdk18/commit/354c9047987c0837d95440780993a0aa84551ea1
Stats:     16 lines in 1 file changed: 16 ins; 0 del; 0 mod

8273452: DocTrees.getDocCommentTree should be specified as idempotent

Reviewed-by: jjg

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

PR: https://git.openjdk.java.net/jdk18/pull/36

From jwilhelm at openjdk.java.net  Mon Jan 10 17:10:40 2022
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Mon, 10 Jan 2022 17:10:40 GMT
Subject: Integrated: Merge jdk18
Message-ID: <5hMMnbP2laUfEjb0svduDuzGgdUJckDDcCxaj-7QZg0=.1fd54c99-b81e-41e1-b3d7-bbdbedf161c9@github.com>

Forwardport JDK 18 -> JDK 19

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

Commit messages:
 - Merge
 - 8274679: Remove unnecessary conversion to String in security code in java.base
 - 8142362: Lots of code duplication in Copy class
 - 8218857: Confusing overloads for os::open
 - 8183227: read/write APIs in class os shall return ssize_t
 - 8279300: [arm32] SIGILL when running GetObjectSizeIntrinsicsTest
 - 8278329: some TraceDeoptimization code not included in PRODUCT build
 - 8279523: Parallel: Remove unnecessary PSScavenge::_to_space_top_before_gc
 - 8279522: Serial: Remove unused Generation::clear_remembered_set
 - 8279528: Unused TypeEnter.diag after JDK-8205187
 - ... and 163 more: https://git.openjdk.java.net/jdk/compare/40df5df9...6ff1c607

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

Changes: https://git.openjdk.java.net/jdk/pull/7017/files
  Stats: 27994 lines in 750 files changed: 20678 ins; 5315 del; 2001 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7017.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7017/head:pull/7017

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

From jwilhelm at openjdk.java.net  Mon Jan 10 17:10:41 2022
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Mon, 10 Jan 2022 17:10:41 GMT
Subject: Integrated: Merge jdk18
In-Reply-To: <5hMMnbP2laUfEjb0svduDuzGgdUJckDDcCxaj-7QZg0=.1fd54c99-b81e-41e1-b3d7-bbdbedf161c9@github.com>
References: <5hMMnbP2laUfEjb0svduDuzGgdUJckDDcCxaj-7QZg0=.1fd54c99-b81e-41e1-b3d7-bbdbedf161c9@github.com>
Message-ID: <LWy6sTkBpk83budJQIqgEjCdEgq62d3JuxhZCubMyR0=.49c56cd4-a4b8-49f8-9bf0-00ebb2c874cf@github.com>

On Mon, 10 Jan 2022 17:00:05 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 18 -> JDK 19

This pull request has now been integrated.

Changeset: d9b1bb58
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d9b1bb58600c03cee43387864d1530d4dd5f1422
Stats:     615 lines in 24 files changed: 478 ins; 77 del; 60 mod

Merge

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

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

From cushon at openjdk.java.net  Tue Jan 11 15:48:34 2022
From: cushon at openjdk.java.net (Liam Miller-Cushon)
Date: Tue, 11 Jan 2022 15:48:34 GMT
Subject: Integrated: JDK-8273914: Indy string concat changes order of
 operations
In-Reply-To: <iM42rUgZ1oVRCQTQ5-HcSSSxq8WPmNzMwLEivYMOjys=.9e5a2ed6-4877-4bb0-a250-75f4ae373c49@github.com>
References: <iM42rUgZ1oVRCQTQ5-HcSSSxq8WPmNzMwLEivYMOjys=.9e5a2ed6-4877-4bb0-a250-75f4ae373c49@github.com>
Message-ID: <Ser_8OTvApl0O7PCXpxxqPbJFbS4r3vVWg5DnqSiNWo=.cbd8b912-27c4-4ca8-9378-57e20277cf25@github.com>

On Wed, 6 Oct 2021 21:00:04 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

> This change makes string concatenation call `toString` on the arguments eagerly, to preserve the correct evaluation order of the arguments and the calls to `toString`.

This pull request has now been integrated.

Changeset: cfee4512
Author:    Liam Miller-Cushon <cushon at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/cfee4512f7048e9cf440078e9eb87d37c7ebcdd9
Stats:     532 lines in 8 files changed: 473 ins; 20 del; 39 mod

8273914: Indy string concat changes order of operations

Reviewed-by: vromero, jlahoda

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

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

From vromero at openjdk.java.net  Wed Jan 12 16:51:28 2022
From: vromero at openjdk.java.net (Vicente Romero)
Date: Wed, 12 Jan 2022 16:51:28 GMT
Subject: RFR: 8279290: symbol not found error,
 implicit lambdas and diamond constructor invocations
In-Reply-To: <FqpZkwB3s1HYMA2r86PGnFSZP4x6jswxxGN8pHVL5ag=.c48a15bf-daaf-433c-9def-fe9c36c3c9f4@github.com>
References: <FqpZkwB3s1HYMA2r86PGnFSZP4x6jswxxGN8pHVL5ag=.c48a15bf-daaf-433c-9def-fe9c36c3c9f4@github.com>
Message-ID: <ppZdku4yUm_xJQ3jLDsDJENfqnNrlE19XCeFPJRAfSw=.32fd2eb6-569d-4be6-8eee-d80449ce1033@github.com>

On Thu, 6 Jan 2022 05:42:49 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Please review this PR which is fixing a bug caused by scope sharing. In particular for code like:
> 
> class Test {
>     static class B<T>{}
> 
>     static class A1 {
>         <T> A1(Consumer<T> cons) {}
>     }
> 
>     void foo() {
>         new A1(findMe ->
>                 new B<>() {{
>                     System.out.println(findMe); // javac is failing here with symbol not found for findMe
>                 }});
>     }
> }
> 
> the reason for the error is that when attributing the diamond constructor invocation, a listener is registered in the current inference context. But the scope inside the environment passed to the listener is shared with the implicit lambda and once the lambda has been attributed, the argument `findMe` is removed from the shared scope. See the `localEnv.info.scope.leave()` at the end of `Attr::visitLambda`. This is why it is necessary to duplicate the scope as proposed in this patch.
> 
> TIA

ping

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

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

From prappo at openjdk.java.net  Thu Jan 13 10:35:39 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Thu, 13 Jan 2022 10:35:39 GMT
Subject: RFR: 8279918: Fix various doc typos
Message-ID: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>

- Most of the typos are of a trivial kind: missing whitespace.
- If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch.
- As I understand it,   in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed.
- &#39; is an apostrophe, which does not require to be encoded.

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

Commit messages:
 - Initial commit

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

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

From kevinw at openjdk.java.net  Thu Jan 13 10:49:28 2022
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Thu, 13 Jan 2022 10:49:28 GMT
Subject: RFR: 8279918: Fix various doc typos
In-Reply-To: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
Message-ID: <c7q1emDrYxQ4prMys2ORMJdDTpjyFAeNZLUwAv_mvLo=.b551f39b-e81b-448d-a53a-db93036debff@github.com>

On Thu, 13 Jan 2022 10:30:07 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> - Most of the typos are of a trivial kind: missing whitespace.
> - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch.
> - As I understand it,   in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed.
> - &#39; is an apostrophe, which does not require to be encoded.

src/java.base/share/classes/sun/text/RuleBasedBreakIterator.java line 73:

> 71:  * will be transparent to the BreakIterator.&nbsp; A sequence of characters will break the
> 72:  * same way it would if any ignore characters it contains are taken out.&nbsp; Break
> 73:  * positions never occur before ignore characters.</p>

"before ignored characters"

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

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

From prappo at openjdk.java.net  Thu Jan 13 11:04:28 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Thu, 13 Jan 2022 11:04:28 GMT
Subject: RFR: 8279918: Fix various doc typos
In-Reply-To: <c7q1emDrYxQ4prMys2ORMJdDTpjyFAeNZLUwAv_mvLo=.b551f39b-e81b-448d-a53a-db93036debff@github.com>
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
 <c7q1emDrYxQ4prMys2ORMJdDTpjyFAeNZLUwAv_mvLo=.b551f39b-e81b-448d-a53a-db93036debff@github.com>
Message-ID: <4f89A8T4GDZajnNMg-tT5qWaN5OCrH04Vwh9HZ6uTvg=.f2af94ec-43b4-4521-8158-aef4137b400b@github.com>

On Thu, 13 Jan 2022 10:46:11 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> - Most of the typos are of a trivial kind: missing whitespace.
>> - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch.
>> - As I understand it,   in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed.
>> - &#39; is an apostrophe, which does not require to be encoded.
>
> src/java.base/share/classes/sun/text/RuleBasedBreakIterator.java line 73:
> 
>> 71:  * will be transparent to the BreakIterator.&nbsp; A sequence of characters will break the
>> 72:  * same way it would if any ignore characters it contains are taken out.&nbsp; Break
>> 73:  * positions never occur before ignore characters.</p>
> 
> "before ignored characters"

I believe it's the name of a concept, so I will leave it as is:

> There is one special substitution.  If the description defines a substitution called "<ignore>", the expression must be a [] expression, and the expression defines a set of characters (the "ignore characters") that will be transparent to the BreakIterator.

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

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

From kevinw at openjdk.java.net  Thu Jan 13 11:04:28 2022
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Thu, 13 Jan 2022 11:04:28 GMT
Subject: RFR: 8279918: Fix various doc typos
In-Reply-To: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
Message-ID: <2bsQg-3igmY6_fAT_OD9jIuJ7ziQBgvB7oF1CiZN_Zo=.51e0dd63-d489-4996-8fb9-b2e8c385cbb8@github.com>

On Thu, 13 Jan 2022 10:30:07 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> - Most of the typos are of a trivial kind: missing whitespace.
> - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch.
> - As I understand it,   in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed.
> - &#39; is an apostrophe, which does not require to be encoded.

src/java.sql/share/classes/java/sql/BatchUpdateException.java line 58:

> 56:  * A JDBC driver implementation should use
> 57:  * the constructor {@code BatchUpdateException(String reason, String SQLState,
> 58:  * int vendorCode, long []updateCounts, Throwable cause) } instead of

While we are here, is it more normal to say "long[] updateCounts", not separating the [] from the type.
Similarly at line 81, 118, 151, 247, 277, 318, 354.

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

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

From prappo at openjdk.java.net  Thu Jan 13 11:07:28 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Thu, 13 Jan 2022 11:07:28 GMT
Subject: RFR: 8279918: Fix various doc typos
In-Reply-To: <2bsQg-3igmY6_fAT_OD9jIuJ7ziQBgvB7oF1CiZN_Zo=.51e0dd63-d489-4996-8fb9-b2e8c385cbb8@github.com>
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
 <2bsQg-3igmY6_fAT_OD9jIuJ7ziQBgvB7oF1CiZN_Zo=.51e0dd63-d489-4996-8fb9-b2e8c385cbb8@github.com>
Message-ID: <VCF8_RsgzIZEi2Hls0T3tX08pg3RfYbTtQKrU0WsO6g=.e49acac0-a7d5-4a35-9a27-4bc1e8b39d1a@github.com>

On Thu, 13 Jan 2022 11:00:55 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> - Most of the typos are of a trivial kind: missing whitespace.
>> - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch.
>> - As I understand it,   in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed.
>> - &#39; is an apostrophe, which does not require to be encoded.
>
> src/java.sql/share/classes/java/sql/BatchUpdateException.java line 58:
> 
>> 56:  * A JDBC driver implementation should use
>> 57:  * the constructor {@code BatchUpdateException(String reason, String SQLState,
>> 58:  * int vendorCode, long []updateCounts, Throwable cause) } instead of
> 
> While we are here, is it more normal to say "long[] updateCounts", not separating the [] from the type.
> Similarly at line 81, 118, 151, 247, 277, 318, 354.

I thought about it too, but then noticed how the position of `[]` mimics that of the respective method signatures in code.

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

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

From kevinw at openjdk.java.net  Thu Jan 13 11:21:27 2022
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Thu, 13 Jan 2022 11:21:27 GMT
Subject: RFR: 8279918: Fix various doc typos
In-Reply-To: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
Message-ID: <zVeD6RgS6UVZkMAhRSuyKSbTi7PESs6zNDZ6lYXRnW4=.fbc4d00e-2dd4-43e5-8115-7e308b725d17@github.com>

On Thu, 13 Jan 2022 10:30:07 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> - Most of the typos are of a trivial kind: missing whitespace.
> - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch.
> - As I understand it, ` ` in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed.
> - `&#39;` is an apostrophe, which does not require to be encoded.

src/java.sql/share/classes/java/sql/Statement.java line 784:

> 782:      * statement returns a {@code ResultSet} object, the second argument
> 783:      * supplied to this method is not an
> 784:      * {@code int} array whose elements are valid column indexes, the method is called on a

Should it be "or the method is called on...", i.e. add the "or", otherwise it's a list of problems but we don't know if they are all required, or are alternatives.  It probably does not mean that all these have to be true to throw the exception, but it doesn't say that.  We are nitpicking of course.

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

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

From kevinw at openjdk.java.net  Thu Jan 13 11:33:27 2022
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Thu, 13 Jan 2022 11:33:27 GMT
Subject: RFR: 8279918: Fix various doc typos
In-Reply-To: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
Message-ID: <pjHWjVnBclRVnojpj7BEIAYuSdlwTLMEkAYhI3iPovw=.6e4cd7fe-f085-4572-856d-44d6ecace75c@github.com>

On Thu, 13 Jan 2022 10:30:07 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> - Most of the typos are of a trivial kind: missing whitespace.
> - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch.
> - As I understand it, ` ` in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed.
> - `&#39;` is an apostrophe, which does not require to be encoded.

Marked as reviewed by kevinw (Committer).

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

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

From kevinw at openjdk.java.net  Thu Jan 13 11:33:27 2022
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Thu, 13 Jan 2022 11:33:27 GMT
Subject: RFR: 8279918: Fix various doc typos
In-Reply-To: <VCF8_RsgzIZEi2Hls0T3tX08pg3RfYbTtQKrU0WsO6g=.e49acac0-a7d5-4a35-9a27-4bc1e8b39d1a@github.com>
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
 <2bsQg-3igmY6_fAT_OD9jIuJ7ziQBgvB7oF1CiZN_Zo=.51e0dd63-d489-4996-8fb9-b2e8c385cbb8@github.com>
 <VCF8_RsgzIZEi2Hls0T3tX08pg3RfYbTtQKrU0WsO6g=.e49acac0-a7d5-4a35-9a27-4bc1e8b39d1a@github.com>
Message-ID: <KEQBfIPtqMR39DeUDsPXb3Tqaow0Q487Gne-nJSp5hI=.bf96f113-80dc-48ba-a280-6cd13bb979da@github.com>

On Thu, 13 Jan 2022 11:04:43 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> src/java.sql/share/classes/java/sql/BatchUpdateException.java line 58:
>> 
>>> 56:  * A JDBC driver implementation should use
>>> 57:  * the constructor {@code BatchUpdateException(String reason, String SQLState,
>>> 58:  * int vendorCode, long []updateCounts, Throwable cause) } instead of
>> 
>> While we are here, is it more normal to say "long[] updateCounts", not separating the [] from the type.
>> Similarly at line 81, 118, 151, 247, 277, 318, 354.
>
> I thought about it too, but then noticed how the position of `[]` mimics that of the respective method signatures in code.

OK, so lines 264,  295, 329, 364, 431 are arguably wrong as well?  Separating the [] completely looks quite rare.
I'll leave it up to you. 8-)

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

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

From prappo at openjdk.java.net  Thu Jan 13 11:33:28 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Thu, 13 Jan 2022 11:33:28 GMT
Subject: RFR: 8279918: Fix various doc typos
In-Reply-To: <zVeD6RgS6UVZkMAhRSuyKSbTi7PESs6zNDZ6lYXRnW4=.fbc4d00e-2dd4-43e5-8115-7e308b725d17@github.com>
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
 <zVeD6RgS6UVZkMAhRSuyKSbTi7PESs6zNDZ6lYXRnW4=.fbc4d00e-2dd4-43e5-8115-7e308b725d17@github.com>
Message-ID: <90v_XM2RzHUik7EfePw8m-79pscrcKUAb10T6FMJHYA=.3577ceee-012b-45f7-af57-64f0a8172dfa@github.com>

On Thu, 13 Jan 2022 11:18:42 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> - Most of the typos are of a trivial kind: missing whitespace.
>> - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch.
>> - As I understand it, ` ` in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed.
>> - `&#39;` is an apostrophe, which does not require to be encoded.
>
> src/java.sql/share/classes/java/sql/Statement.java line 784:
> 
>> 782:      * statement returns a {@code ResultSet} object, the second argument
>> 783:      * supplied to this method is not an
>> 784:      * {@code int} array whose elements are valid column indexes, the method is called on a
> 
> Should it be "or the method is called on...", i.e. add the "or", otherwise it's a list of problems but we don't know if they are all required, or are alternatives.  It probably does not mean that all these have to be true to throw the exception, but it doesn't say that.  We are nitpicking of course.

You are right in that this `@throws` description reads a bit weird in its current form. That said, I wouldn't touch it in this PR for two reasons. Firstly, this wording seems to be consistent with other locations in that file. Secondly, this is a spec territory.

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

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

From lancea at openjdk.java.net  Thu Jan 13 11:46:27 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Thu, 13 Jan 2022 11:46:27 GMT
Subject: RFR: 8279918: Fix various doc typos
In-Reply-To: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
Message-ID: <N93S_4q_0Hb8J6Wqm_8Cur4pRu-cKsGRDYtkT1rj-Qk=.42f89bd3-876e-4017-af48-65fcadfcf62f@github.com>

On Thu, 13 Jan 2022 10:30:07 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> - Most of the typos are of a trivial kind: missing whitespace.
> - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch.
> - As I understand it, ` ` in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed.
> - `&#39;` is an apostrophe, which does not require to be encoded.

Overall this looks good, thanks for the clean up :-)

A few comments below

src/java.base/share/classes/java/io/DataInput.java line 496:

> 494:      * ceases. If the character {@code '\r'}
> 495:      * is encountered, it is discarded and, if
> 496:      * the following byte converts to the

The above is a bit confusing as it reads(same in ImageInputStream.java).  I think that that can be looked at later.

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

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

From lancea at openjdk.java.net  Thu Jan 13 11:46:27 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Thu, 13 Jan 2022 11:46:27 GMT
Subject: RFR: 8279918: Fix various doc typos
In-Reply-To: <KEQBfIPtqMR39DeUDsPXb3Tqaow0Q487Gne-nJSp5hI=.bf96f113-80dc-48ba-a280-6cd13bb979da@github.com>
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
 <2bsQg-3igmY6_fAT_OD9jIuJ7ziQBgvB7oF1CiZN_Zo=.51e0dd63-d489-4996-8fb9-b2e8c385cbb8@github.com>
 <VCF8_RsgzIZEi2Hls0T3tX08pg3RfYbTtQKrU0WsO6g=.e49acac0-a7d5-4a35-9a27-4bc1e8b39d1a@github.com>
 <KEQBfIPtqMR39DeUDsPXb3Tqaow0Q487Gne-nJSp5hI=.bf96f113-80dc-48ba-a280-6cd13bb979da@github.com>
Message-ID: <zYl0PN2cKub3zwtGJr9wKdC7oq0BrHa6v2TG2esnlZM=.9936d444-caae-47af-916a-d2847c64bcd5@github.com>

On Thu, 13 Jan 2022 11:28:34 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> I thought about it too, but then noticed how the position of `[]` mimics that of the respective method signatures in code.
>
> OK, so lines 264,  295, 329, 364, 431 are arguably wrong as well?  Separating the [] completely looks quite rare.
> I'll leave it up to you. 8-)

I think that can be a follow on clean up.

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

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

From lancea at openjdk.java.net  Thu Jan 13 11:46:28 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Thu, 13 Jan 2022 11:46:28 GMT
Subject: RFR: 8279918: Fix various doc typos
In-Reply-To: <90v_XM2RzHUik7EfePw8m-79pscrcKUAb10T6FMJHYA=.3577ceee-012b-45f7-af57-64f0a8172dfa@github.com>
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
 <zVeD6RgS6UVZkMAhRSuyKSbTi7PESs6zNDZ6lYXRnW4=.fbc4d00e-2dd4-43e5-8115-7e308b725d17@github.com>
 <90v_XM2RzHUik7EfePw8m-79pscrcKUAb10T6FMJHYA=.3577ceee-012b-45f7-af57-64f0a8172dfa@github.com>
Message-ID: <siJYLuQdiSxsrufNvzgVR1V3olYqps5ZA0NMBzqBmOY=.1884295a-8707-4e4b-bd7b-a54a1e0b54a2@github.com>

On Thu, 13 Jan 2022 11:29:35 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> src/java.sql/share/classes/java/sql/Statement.java line 784:
>> 
>>> 782:      * statement returns a {@code ResultSet} object, the second argument
>>> 783:      * supplied to this method is not an
>>> 784:      * {@code int} array whose elements are valid column indexes, the method is called on a
>> 
>> Should it be "or the method is called on...", i.e. add the "or", otherwise it's a list of problems but we don't know if they are all required, or are alternatives.  It probably does not mean that all these have to be true to throw the exception, but it doesn't say that.  We are nitpicking of course.
>
> You are right in that this `@throws` description reads a bit weird in its current form. That said, I wouldn't touch it in this PR for two reasons. Firstly, this wording seems to be consistent with other locations in that file. Secondly, this is a spec territory.

Yes an "or" is probably worthwhile to add.

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

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

From prappo at openjdk.java.net  Thu Jan 13 12:40:45 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Thu, 13 Jan 2022 12:40:45 GMT
Subject: RFR: 8279918: Fix various doc typos
In-Reply-To: <N93S_4q_0Hb8J6Wqm_8Cur4pRu-cKsGRDYtkT1rj-Qk=.42f89bd3-876e-4017-af48-65fcadfcf62f@github.com>
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
 <N93S_4q_0Hb8J6Wqm_8Cur4pRu-cKsGRDYtkT1rj-Qk=.42f89bd3-876e-4017-af48-65fcadfcf62f@github.com>
Message-ID: <KaZIJRgmte5WexU8y71mFOZ_dLKcoWf8DXvkY5ty59Y=.74f2053d-1dc4-44f0-b499-54caa6d84c7b@github.com>

On Thu, 13 Jan 2022 11:42:48 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> The above is a bit confusing as it reads(same in ImageInputStream.java). I think that that can be looked at later.

Just to clarify: you are okay with removing the ` ` entity, right? As for ImageInputStream, some doc comments should probably use `@inheritDoc`. But this is a much bigger clean-up.

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

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

From mullan at openjdk.java.net  Thu Jan 13 13:45:30 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Thu, 13 Jan 2022 13:45:30 GMT
Subject: RFR: 8279918: Fix various doc typos
In-Reply-To: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
Message-ID: <GoTfQ0njQABWrD7SFvPbmOPuKBIMNKsS3jJHnHMZfDY=.b11b8d73-4c8b-4eb1-8078-33dcd70b013c@github.com>

On Thu, 13 Jan 2022 10:30:07 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> - Most of the typos are of a trivial kind: missing whitespace.
> - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch.
> - As I understand it, ` ` in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed.
> - `&#39;` is an apostrophe, which does not require to be encoded.

The change in the one security class (KeyStoreLoginModule) looks fine.

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

Marked as reviewed by mullan (Reviewer).

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

From prappo at openjdk.java.net  Thu Jan 13 13:51:34 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Thu, 13 Jan 2022 13:51:34 GMT
Subject: RFR: 8279918: Fix various doc typos
In-Reply-To: <siJYLuQdiSxsrufNvzgVR1V3olYqps5ZA0NMBzqBmOY=.1884295a-8707-4e4b-bd7b-a54a1e0b54a2@github.com>
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
 <zVeD6RgS6UVZkMAhRSuyKSbTi7PESs6zNDZ6lYXRnW4=.fbc4d00e-2dd4-43e5-8115-7e308b725d17@github.com>
 <90v_XM2RzHUik7EfePw8m-79pscrcKUAb10T6FMJHYA=.3577ceee-012b-45f7-af57-64f0a8172dfa@github.com>
 <siJYLuQdiSxsrufNvzgVR1V3olYqps5ZA0NMBzqBmOY=.1884295a-8707-4e4b-bd7b-a54a1e0b54a2@github.com>
Message-ID: <9HH1T6jnf2bbBhD0h9sZZGoBWqEAoYen5Ymr52wVyDA=.7afbde78-363f-4e51-b0ad-a7e0cf2c0d6d@github.com>

On Thu, 13 Jan 2022 11:38:13 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Yes an "or" is probably worthwhile to add.

I would prefer to leave it for the follow-up cleanup if only because adding "or" here would make it inconsistent with other `@throws SQLException` descriptions in that file and perhaps elsewhere in java.sql:

* java/sql/Statement.java:59
* java/sql/Statement.java:85
* java/sql/Statement.java:346
* java/sql/Statement.java:524
* java/sql/Statement.java:745
* java/sql/Statement.java:814
* java/sql/Statement.java:860
* java/sql/Statement.java:913
* java/sql/Statement.java:962
* java/sql/Statement.java:1225
* java/sql/Statement.java:1269
* java/sql/Statement.java:1314

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

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

From prappo at openjdk.java.net  Thu Jan 13 14:01:04 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Thu, 13 Jan 2022 14:01:04 GMT
Subject: RFR: 8279918: Fix various doc typos [v2]
In-Reply-To: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
Message-ID: <xjtKpoXjmab0GcY8CsWz8yZAReei4r9VUhOisV2zmPY=.cb5ffea8-3ba3-4cfd-bd6c-4d8555c87fcb@github.com>

> - Most of the typos are of a trivial kind: missing whitespace.
> - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch.
> - As I understand it, ` ` in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed.
> - `&#39;` is an apostrophe, which does not require to be encoded.

Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:

  Additional typos

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7063/files
  - new: https://git.openjdk.java.net/jdk/pull/7063/files/fe81eeca..b256a13f

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

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

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

From sspitsyn at openjdk.java.net  Thu Jan 13 16:53:27 2022
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Thu, 13 Jan 2022 16:53:27 GMT
Subject: RFR: 8279918: Fix various doc typos [v2]
In-Reply-To: <xjtKpoXjmab0GcY8CsWz8yZAReei4r9VUhOisV2zmPY=.cb5ffea8-3ba3-4cfd-bd6c-4d8555c87fcb@github.com>
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
 <xjtKpoXjmab0GcY8CsWz8yZAReei4r9VUhOisV2zmPY=.cb5ffea8-3ba3-4cfd-bd6c-4d8555c87fcb@github.com>
Message-ID: <Ibur44h4Co3CBFiirsNKloOUVl2G0KUC1pCEbFz5DII=.80447fd1-effd-4cba-9d5c-572ebcf12e72@github.com>

On Thu, 13 Jan 2022 14:01:04 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> - Most of the typos are of a trivial kind: missing whitespace.
>> - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch.
>> - As I understand it, ` ` in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed.
>> - `&#39;` is an apostrophe, which does not require to be encoded.
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Additional typos

Hi Pavel,
Looks good.
Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

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

From lancea at openjdk.java.net  Thu Jan 13 17:18:23 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Thu, 13 Jan 2022 17:18:23 GMT
Subject: RFR: 8279918: Fix various doc typos [v2]
In-Reply-To: <KaZIJRgmte5WexU8y71mFOZ_dLKcoWf8DXvkY5ty59Y=.74f2053d-1dc4-44f0-b499-54caa6d84c7b@github.com>
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
 <N93S_4q_0Hb8J6Wqm_8Cur4pRu-cKsGRDYtkT1rj-Qk=.42f89bd3-876e-4017-af48-65fcadfcf62f@github.com>
 <KaZIJRgmte5WexU8y71mFOZ_dLKcoWf8DXvkY5ty59Y=.74f2053d-1dc4-44f0-b499-54caa6d84c7b@github.com>
Message-ID: <irVQg_VsXH7St95vPZp8vVD3oaWCefUdqLxDETFhN5I=.ebbbb6d8-eba8-4e17-996d-32ffb15716f3@github.com>

On Thu, 13 Jan 2022 12:37:46 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> > The above is a bit confusing as it reads(same in ImageInputStream.java). I think that that can be looked at later.
> 
> Just to clarify: you are okay with removing the ` ` entity, right? As for ImageInputStream, some doc comments should probably use `@inheritDoc`. But this is a much bigger clean-up.

Yes I am.  It just does not flow as well as it could IMHO

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

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

From naoto at openjdk.java.net  Thu Jan 13 17:25:30 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 13 Jan 2022 17:25:30 GMT
Subject: RFR: 8279918: Fix various doc typos [v2]
In-Reply-To: <xjtKpoXjmab0GcY8CsWz8yZAReei4r9VUhOisV2zmPY=.cb5ffea8-3ba3-4cfd-bd6c-4d8555c87fcb@github.com>
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
 <xjtKpoXjmab0GcY8CsWz8yZAReei4r9VUhOisV2zmPY=.cb5ffea8-3ba3-4cfd-bd6c-4d8555c87fcb@github.com>
Message-ID: <CmrsmcEGepottkt6pPurYZ3cPdM7oK7v1DInHe5jqbQ=.d9dd81e5-18b2-4e2c-9881-97d586442a35@github.com>

On Thu, 13 Jan 2022 14:01:04 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> - Most of the typos are of a trivial kind: missing whitespace.
>> - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch.
>> - As I understand it, ` ` in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed.
>> - `&#39;` is an apostrophe, which does not require to be encoded.
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Additional typos

Marked as reviewed by naoto (Reviewer).

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

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

From naoto at openjdk.java.net  Thu Jan 13 17:25:31 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 13 Jan 2022 17:25:31 GMT
Subject: RFR: 8279918: Fix various doc typos [v2]
In-Reply-To: <4f89A8T4GDZajnNMg-tT5qWaN5OCrH04Vwh9HZ6uTvg=.f2af94ec-43b4-4521-8158-aef4137b400b@github.com>
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
 <c7q1emDrYxQ4prMys2ORMJdDTpjyFAeNZLUwAv_mvLo=.b551f39b-e81b-448d-a53a-db93036debff@github.com>
 <4f89A8T4GDZajnNMg-tT5qWaN5OCrH04Vwh9HZ6uTvg=.f2af94ec-43b4-4521-8158-aef4137b400b@github.com>
Message-ID: <4-d5YVHaRmPcyMlFYm2fxtIaRq6Z5PVooC8yd0OIbag=.cbd015b1-b2bd-43ba-b12f-8727087364b5@github.com>

On Thu, 13 Jan 2022 10:59:13 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> src/java.base/share/classes/sun/text/RuleBasedBreakIterator.java line 73:
>> 
>>> 71:  * will be transparent to the BreakIterator.&nbsp; A sequence of characters will break the
>>> 72:  * same way it would if any ignore characters it contains are taken out.&nbsp; Break
>>> 73:  * positions never occur before ignore characters.</p>
>> 
>> "before ignored characters"
>
> I believe it's the name of a concept, so I will leave it as is:
> 
>> There is one special substitution.  If the description defines a substitution called "<ignore>", the expression must be a [] expression, and the expression defines a set of characters (the "ignore characters") that will be transparent to the BreakIterator.

Yes, that is correct.

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

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

From lancea at openjdk.java.net  Thu Jan 13 17:25:31 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Thu, 13 Jan 2022 17:25:31 GMT
Subject: RFR: 8279918: Fix various doc typos [v2]
In-Reply-To: <9HH1T6jnf2bbBhD0h9sZZGoBWqEAoYen5Ymr52wVyDA=.7afbde78-363f-4e51-b0ad-a7e0cf2c0d6d@github.com>
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
 <zVeD6RgS6UVZkMAhRSuyKSbTi7PESs6zNDZ6lYXRnW4=.fbc4d00e-2dd4-43e5-8115-7e308b725d17@github.com>
 <90v_XM2RzHUik7EfePw8m-79pscrcKUAb10T6FMJHYA=.3577ceee-012b-45f7-af57-64f0a8172dfa@github.com>
 <siJYLuQdiSxsrufNvzgVR1V3olYqps5ZA0NMBzqBmOY=.1884295a-8707-4e4b-bd7b-a54a1e0b54a2@github.com>
 <9HH1T6jnf2bbBhD0h9sZZGoBWqEAoYen5Ymr52wVyDA=.7afbde78-363f-4e51-b0ad-a7e0cf2c0d6d@github.com>
Message-ID: <-4rLp_8_PwigKKpD1gGONCS8QMfDkNNNP4uZU1k9u9M=.9119e3bf-b879-42eb-a3a7-af6442a0551e@github.com>

On Thu, 13 Jan 2022 13:48:02 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> > Yes an "or" is probably worthwhile to add.
> 
> I would prefer to leave it for the follow-up cleanup if only because adding "or" here would make it inconsistent with other `@throws SQLException` descriptions in that file and perhaps elsewhere in java.sql:
> 
> * java/sql/Statement.java:59
> * java/sql/Statement.java:85
> * java/sql/Statement.java:346
> * java/sql/Statement.java:524
> * java/sql/Statement.java:745
> * java/sql/Statement.java:814
> * java/sql/Statement.java:860
> * java/sql/Statement.java:913
> * java/sql/Statement.java:962
> * java/sql/Statement.java:1225
> * java/sql/Statement.java:1269
> * java/sql/Statement.java:1314

I am fine with that.  I guess a semi-colon could also be used vs. a comma to divide the Exception scenarios listed

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

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

From lancea at openjdk.java.net  Thu Jan 13 17:35:25 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Thu, 13 Jan 2022 17:35:25 GMT
Subject: RFR: 8279918: Fix various doc typos [v2]
In-Reply-To: <xjtKpoXjmab0GcY8CsWz8yZAReei4r9VUhOisV2zmPY=.cb5ffea8-3ba3-4cfd-bd6c-4d8555c87fcb@github.com>
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
 <xjtKpoXjmab0GcY8CsWz8yZAReei4r9VUhOisV2zmPY=.cb5ffea8-3ba3-4cfd-bd6c-4d8555c87fcb@github.com>
Message-ID: <wFh5PNvl7A_Oui3iDHyjFGEYyurAzJmGjVKD2bEF1tg=.e962af55-7886-4678-8a7b-39d1a695ae22@github.com>

On Thu, 13 Jan 2022 14:01:04 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> - Most of the typos are of a trivial kind: missing whitespace.
>> - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch.
>> - As I understand it, ` ` in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed.
>> - `&#39;` is an apostrophe, which does not require to be encoded.
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Additional typos

Marked as reviewed by lancea (Reviewer).

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

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

From jjg at openjdk.java.net  Thu Jan 13 23:01:28 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Thu, 13 Jan 2022 23:01:28 GMT
Subject: RFR: 8279918: Fix various doc typos [v2]
In-Reply-To: <zYl0PN2cKub3zwtGJr9wKdC7oq0BrHa6v2TG2esnlZM=.9936d444-caae-47af-916a-d2847c64bcd5@github.com>
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
 <2bsQg-3igmY6_fAT_OD9jIuJ7ziQBgvB7oF1CiZN_Zo=.51e0dd63-d489-4996-8fb9-b2e8c385cbb8@github.com>
 <VCF8_RsgzIZEi2Hls0T3tX08pg3RfYbTtQKrU0WsO6g=.e49acac0-a7d5-4a35-9a27-4bc1e8b39d1a@github.com>
 <KEQBfIPtqMR39DeUDsPXb3Tqaow0Q487Gne-nJSp5hI=.bf96f113-80dc-48ba-a280-6cd13bb979da@github.com>
 <zYl0PN2cKub3zwtGJr9wKdC7oq0BrHa6v2TG2esnlZM=.9936d444-caae-47af-916a-d2847c64bcd5@github.com>
Message-ID: <euQ2BZTUg-jsd4LJYaF9nTXRLsnozIsFNI3en-iH6a0=.1fb0785a-886c-41e7-870f-87b941bb82f6@github.com>

On Thu, 13 Jan 2022 11:40:20 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> OK, so lines 264,  295, 329, 364, 431 are arguably wrong as well?  Separating the [] completely looks quite rare.
>> I'll leave it up to you. 8-)
>
> I think that can be a follow on clean up.

The strange formatting of `long []updateCounts` looks very unusual and well worth a followup cleanup.

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

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

From duke at openjdk.java.net  Fri Jan 14 02:31:56 2022
From: duke at openjdk.java.net (Aggelos Biboudis)
Date: Fri, 14 Jan 2022 02:31:56 GMT
Subject: RFR: 8036019: Insufficient alternatives listed in some errors produced
 by the parser
Message-ID: <kuaNYEc0tS3MIFqSPbkMztyboEwJwR8MHbe32P80Ca4=.21cd16f8-7e2d-48b2-9593-9c8668a9c648@github.com>

Adjusts the corresponding "expected-" errors for `argumentOpt`,  `typeArgumentsOpt` and `annotationValue`.

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

Commit messages:
 - 8036019: Improve alternatives listed in some errors

Changes: https://git.openjdk.java.net/jdk/pull/7019/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7019&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8036019
  Stats: 94 lines in 9 files changed: 87 ins; 0 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7019.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7019/head:pull/7019

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

From jlahoda at openjdk.java.net  Fri Jan 14 11:22:36 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Fri, 14 Jan 2022 11:22:36 GMT
Subject: RFR: 8279918: Fix various doc typos [v2]
In-Reply-To: <xjtKpoXjmab0GcY8CsWz8yZAReei4r9VUhOisV2zmPY=.cb5ffea8-3ba3-4cfd-bd6c-4d8555c87fcb@github.com>
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
 <xjtKpoXjmab0GcY8CsWz8yZAReei4r9VUhOisV2zmPY=.cb5ffea8-3ba3-4cfd-bd6c-4d8555c87fcb@github.com>
Message-ID: <mHTQhslPgaefsXLYiV_SvYHyzjK_ugDhBIpWzkdua3o=.d6cc09e9-9eb6-4dbb-9b9a-64b743d7eb37@github.com>

On Thu, 13 Jan 2022 14:01:04 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> - Most of the typos are of a trivial kind: missing whitespace.
>> - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch.
>> - As I understand it, ` ` in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed.
>> - `&#39;` is an apostrophe, which does not require to be encoded.
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Additional typos

javac changes look good to me.

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

Marked as reviewed by jlahoda (Reviewer).

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

From azvegint at openjdk.java.net  Fri Jan 14 12:19:28 2022
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Fri, 14 Jan 2022 12:19:28 GMT
Subject: RFR: 8279918: Fix various doc typos [v2]
In-Reply-To: <xjtKpoXjmab0GcY8CsWz8yZAReei4r9VUhOisV2zmPY=.cb5ffea8-3ba3-4cfd-bd6c-4d8555c87fcb@github.com>
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
 <xjtKpoXjmab0GcY8CsWz8yZAReei4r9VUhOisV2zmPY=.cb5ffea8-3ba3-4cfd-bd6c-4d8555c87fcb@github.com>
Message-ID: <2NHrJp-0YZuLsk1to7auM4-WbJ0BxxfUImHMBAYHxs8=.012a0e0c-a9e7-4bb9-b822-21334744d4ed@github.com>

On Thu, 13 Jan 2022 14:01:04 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> - Most of the typos are of a trivial kind: missing whitespace.
>> - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch.
>> - As I understand it, ` ` in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed.
>> - `&#39;` is an apostrophe, which does not require to be encoded.
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Additional typos

Client changes looks good to me.

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

Marked as reviewed by azvegint (Reviewer).

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

From egahlin at openjdk.java.net  Fri Jan 14 12:42:32 2022
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Fri, 14 Jan 2022 12:42:32 GMT
Subject: RFR: 8279918: Fix various doc typos [v2]
In-Reply-To: <xjtKpoXjmab0GcY8CsWz8yZAReei4r9VUhOisV2zmPY=.cb5ffea8-3ba3-4cfd-bd6c-4d8555c87fcb@github.com>
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
 <xjtKpoXjmab0GcY8CsWz8yZAReei4r9VUhOisV2zmPY=.cb5ffea8-3ba3-4cfd-bd6c-4d8555c87fcb@github.com>
Message-ID: <V_tZ6iUCrtIDCAbwbWr8Pnj-hACcC7UbdEStP17e3BA=.5c64f1d4-9df7-4d9f-8bbc-f59b2748505f@github.com>

On Thu, 13 Jan 2022 14:01:04 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> - Most of the typos are of a trivial kind: missing whitespace.
>> - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch.
>> - As I understand it, ` ` in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed.
>> - `&#39;` is an apostrophe, which does not require to be encoded.
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Additional typos

Marked as reviewed by egahlin (Reviewer).

The JFR related changes looks OK.

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

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

From jjg at openjdk.java.net  Fri Jan 14 16:08:31 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Fri, 14 Jan 2022 16:08:31 GMT
Subject: RFR: 8279918: Fix various doc typos [v2]
In-Reply-To: <xjtKpoXjmab0GcY8CsWz8yZAReei4r9VUhOisV2zmPY=.cb5ffea8-3ba3-4cfd-bd6c-4d8555c87fcb@github.com>
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
 <xjtKpoXjmab0GcY8CsWz8yZAReei4r9VUhOisV2zmPY=.cb5ffea8-3ba3-4cfd-bd6c-4d8555c87fcb@github.com>
Message-ID: <96bxwtnI-_Z67Udh4acEGwA2xzIy6dAV6CxOe9HLkRo=.dd8643aa-f3be-42e2-ad72-4a00d90363d9@github.com>

On Thu, 13 Jan 2022 14:01:04 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> - Most of the typos are of a trivial kind: missing whitespace.
>> - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch.
>> - As I understand it, ` ` in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed.
>> - `&#39;` is an apostrophe, which does not require to be encoded.
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Additional typos

jdk.compiler and jdk.javadoc look good

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

Marked as reviewed by jjg (Reviewer).

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

From prappo at openjdk.java.net  Fri Jan 14 16:13:34 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Fri, 14 Jan 2022 16:13:34 GMT
Subject: Integrated: 8279918: Fix various doc typos
In-Reply-To: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
Message-ID: <iRT0-D_kHCqoTOO_tqTh0WH4UU1j-7Ju2SV6oLUBLhU=.73b73e8f-5608-4fc1-a147-bc569d647428@github.com>

On Thu, 13 Jan 2022 10:30:07 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> - Most of the typos are of a trivial kind: missing whitespace.
> - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch.
> - As I understand it, ` ` in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed.
> - `&#39;` is an apostrophe, which does not require to be encoded.

This pull request has now been integrated.

Changeset: f1805309
Author:    Pavel Rappo <prappo at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f1805309352a22119ae2edf8bfbb596f00936224
Stats:     88 lines in 35 files changed: 0 ins; 0 del; 88 mod

8279918: Fix various doc typos

Reviewed-by: kevinw, lancea, mullan, sspitsyn, naoto, jlahoda, azvegint, egahlin, jjg

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

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

From jlahoda at openjdk.java.net  Fri Jan 14 18:29:26 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Fri, 14 Jan 2022 18:29:26 GMT
Subject: RFR: 8279290: symbol not found error,
 implicit lambdas and diamond constructor invocations
In-Reply-To: <FqpZkwB3s1HYMA2r86PGnFSZP4x6jswxxGN8pHVL5ag=.c48a15bf-daaf-433c-9def-fe9c36c3c9f4@github.com>
References: <FqpZkwB3s1HYMA2r86PGnFSZP4x6jswxxGN8pHVL5ag=.c48a15bf-daaf-433c-9def-fe9c36c3c9f4@github.com>
Message-ID: <0bY9C4NCWVpte54wjajAtM1eZACxPXUr3sgnijSCPJk=.72d7d436-99be-415c-91bc-3dbc3d0f3288@github.com>

On Thu, 6 Jan 2022 05:42:49 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Please review this PR which is fixing a bug caused by scope sharing. In particular for code like:
> 
> class Test {
>     static class B<T>{}
> 
>     static class A1 {
>         <T> A1(Consumer<T> cons) {}
>     }
> 
>     void foo() {
>         new A1(findMe ->
>                 new B<>() {{
>                     System.out.println(findMe); // javac is failing here with symbol not found for findMe
>                 }});
>     }
> }
> 
> the reason for the error is that when attributing the diamond constructor invocation, a listener is registered in the current inference context. But the scope inside the environment passed to the listener is shared with the implicit lambda and once the lambda has been attributed, the argument `findMe` is removed from the shared scope. See the `localEnv.info.scope.leave()` at the end of `Attr::visitLambda`. This is why it is necessary to duplicate the scope as proposed in this patch.
> 
> TIA

Looks good to me.

Please note that `jdk/javadoc/doclet/testLinkPlatform/TestLinkPlatform.java` failed in the GitHub checks under `Linux x86 (langtools/tier1)`. Quite possibly an unrelated random failure, but please be sure to run tests before integrating to double-check.

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

Marked as reviewed by jlahoda (Reviewer).

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

From vromero at openjdk.java.net  Fri Jan 14 21:41:07 2022
From: vromero at openjdk.java.net (Vicente Romero)
Date: Fri, 14 Jan 2022 21:41:07 GMT
Subject: RFR: 8279290: symbol not found error,
 implicit lambdas and diamond constructor invocations
In-Reply-To: <FqpZkwB3s1HYMA2r86PGnFSZP4x6jswxxGN8pHVL5ag=.c48a15bf-daaf-433c-9def-fe9c36c3c9f4@github.com>
References: <FqpZkwB3s1HYMA2r86PGnFSZP4x6jswxxGN8pHVL5ag=.c48a15bf-daaf-433c-9def-fe9c36c3c9f4@github.com>
Message-ID: <QNtI1yjnuPam1VCeOHngeut2Pj4A8w7Xwm9YuD3wypM=.1465bb85-ff8a-4191-9a5c-d1e3918fbab2@github.com>

On Thu, 6 Jan 2022 05:42:49 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Please review this PR which is fixing a bug caused by scope sharing. In particular for code like:
> 
> class Test {
>     static class B<T>{}
> 
>     static class A1 {
>         <T> A1(Consumer<T> cons) {}
>     }
> 
>     void foo() {
>         new A1(findMe ->
>                 new B<>() {{
>                     System.out.println(findMe); // javac is failing here with symbol not found for findMe
>                 }});
>     }
> }
> 
> the reason for the error is that when attributing the diamond constructor invocation, a listener is registered in the current inference context. But the scope inside the environment passed to the listener is shared with the implicit lambda and once the lambda has been attributed, the argument `findMe` is removed from the shared scope. See the `localEnv.info.scope.leave()` at the end of `Attr::visitLambda`. This is why it is necessary to duplicate the scope as proposed in this patch.
> 
> TIA

thanks for the review

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

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

From vromero at openjdk.java.net  Tue Jan 18 15:54:00 2022
From: vromero at openjdk.java.net (Vicente Romero)
Date: Tue, 18 Jan 2022 15:54:00 GMT
Subject: Integrated: 8279290: symbol not found error,
 implicit lambdas and diamond constructor invocations
In-Reply-To: <FqpZkwB3s1HYMA2r86PGnFSZP4x6jswxxGN8pHVL5ag=.c48a15bf-daaf-433c-9def-fe9c36c3c9f4@github.com>
References: <FqpZkwB3s1HYMA2r86PGnFSZP4x6jswxxGN8pHVL5ag=.c48a15bf-daaf-433c-9def-fe9c36c3c9f4@github.com>
Message-ID: <tBai7NYCvNLBdc2DL4nL-ZpheI6-ZNZoc0S8rDH_p5U=.cdb24f3f-6ca5-4bb7-be4b-d3c3ba03b312@github.com>

On Thu, 6 Jan 2022 05:42:49 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Please review this PR which is fixing a bug caused by scope sharing. In particular for code like:
> 
> class Test {
>     static class B<T>{}
> 
>     static class A1 {
>         <T> A1(Consumer<T> cons) {}
>     }
> 
>     void foo() {
>         new A1(findMe ->
>                 new B<>() {{
>                     System.out.println(findMe); // javac is failing here with symbol not found for findMe
>                 }});
>     }
> }
> 
> the reason for the error is that when attributing the diamond constructor invocation, a listener is registered in the current inference context. But the scope inside the environment passed to the listener is shared with the implicit lambda and once the lambda has been attributed, the argument `findMe` is removed from the shared scope. See the `localEnv.info.scope.leave()` at the end of `Attr::visitLambda`. This is why it is necessary to duplicate the scope as proposed in this patch.
> 
> TIA

This pull request has now been integrated.

Changeset: 9e3f68d8
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/9e3f68d8f41ff632ebf28a6f488f6a06754a088f
Stats:     56 lines in 2 files changed: 55 ins; 0 del; 1 mod

8279290: symbol not found error, implicit lambdas and diamond constructor invocations

Reviewed-by: jlahoda

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

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

From vromero at openjdk.java.net  Tue Jan 18 17:31:30 2022
From: vromero at openjdk.java.net (Vicente Romero)
Date: Tue, 18 Jan 2022 17:31:30 GMT
Subject: RFR: 8036019: Insufficient alternatives listed in some errors
 produced by the parser
In-Reply-To: <kuaNYEc0tS3MIFqSPbkMztyboEwJwR8MHbe32P80Ca4=.21cd16f8-7e2d-48b2-9593-9c8668a9c648@github.com>
References: <kuaNYEc0tS3MIFqSPbkMztyboEwJwR8MHbe32P80Ca4=.21cd16f8-7e2d-48b2-9593-9c8668a9c648@github.com>
Message-ID: <w9a7a2TKHe-c5XP7PTzbCeHHWMdstB6fiqgMeFqqhd0=.55ca12ce-e680-429f-8351-eac441a12194@github.com>

On Mon, 10 Jan 2022 18:53:35 GMT, Aggelos Biboudis <duke at openjdk.java.net> wrote:

> Adjusts the corresponding "expected-" errors for `argumentOpt`,  `typeArgumentsOpt` and `annotationValue`.

Changes requested by vromero (Reviewer).

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

> 3380:                 }
> 3381:             }
> 3382:             accept(RBRACE, tk -> Errors.AnnotationMissingElementValue);

I think that this method needs some more massage, annotations like this one are being accepted:


@SuppressWarnings({,})

even previous to your patch, if my reading of the spec is correct, there should be at least one `ElementValue`

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

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

From jlahoda at openjdk.java.net  Wed Jan 19 13:40:00 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Wed, 19 Jan 2022 13:40:00 GMT
Subject: [jdk18] RFR: 8278834: Error
 "Cannot read field "sym" because "this.lvar[od]" is null" when compiling
Message-ID: <rBvuTgHDH7kHgdYaAg0e2aRIfnco-oSp3alUHpAv5Tg=.87fb0c5a-abdd-4322-bf35-e80eecdf8ecf@github.com>

For code like:

public class TestInstanceOf {

    public static void main(String[] args) {
        Number abc = 1;
        new Object() {
            {
                if (abc instanceof Integer integer) {
                    System.out.println(integer.intValue());
                }
            }
        };
    }

}


`javac` crashes with:

An exception has occurred in the compiler (17-internal). Please file a bug against the Java compiler via the Java bug reporting page (http://bugreport.java.com) after checking the Bug Database (http://bugs.java.com) for duplicates. Include your program, the following diagnostic, and the parameters passed to the Java compiler in your report. Thank you.
java.lang.NullPointerException: Cannot read field "sym" because "this.lvar[3]" is null
        at jdk.compiler/com.sun.tools.javac.jvm.Code.emitop0(Code.java:577)
        at jdk.compiler/com.sun.tools.javac.jvm.Items$LocalItem.load(Items.java:399)
        at jdk.compiler/com.sun.tools.javac.jvm.Gen.genArgs(Gen.java:902)
        at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitNewClass(Gen.java:1961)
        at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCNewClass.accept(JCTree.java:1852)
        at jdk.compiler/com.sun.tools.javac.jvm.Gen.genExpr(Gen.java:877)
        at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitExec(Gen.java:1742)
        at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCExpressionStatement.accept(JCTree.java:1584)
        at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:610)
        at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:645)
        at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:631)
        at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStats(Gen.java:682)
        at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitBlock(Gen.java:1097)
        at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:1091)
        at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:610)
        at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:645)
        at jdk.compiler/com.sun.tools.javac.jvm.Gen.genMethod(Gen.java:967)
        at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitMethodDef(Gen.java:930)
        at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:921)
        at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:610)
        at jdk.compiler/com.sun.tools.javac.jvm.Gen.genClass(Gen.java:2414)
        at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.genCode(JavaCompiler.java:737)
        at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1617)
        at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1585)
        at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:946)
        at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:317)
        at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:176)
        at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:64)
        at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:50)


The cause is in `TransPatterns` - it tracks the current class and method, so that it can define correct owners for temporary variables. But if there's a class nested in a method, the current method field is not cleared, and consequently the temporary variables get a wrong owner (the method enclosing the class, not a method inside the current class), which then crashes subsequent phases, like Gen.

The proposed fix is to clear `currentMethod` when entering a class AST node.

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

Commit messages:
 - 8278834: Error "Cannot read field "sym" because "this.lvar[od]" is null" when compiling

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

PR: https://git.openjdk.java.net/jdk18/pull/110

From vromero at openjdk.java.net  Wed Jan 19 16:52:39 2022
From: vromero at openjdk.java.net (Vicente Romero)
Date: Wed, 19 Jan 2022 16:52:39 GMT
Subject: [jdk18] RFR: 8278834: Error
 "Cannot read field "sym" because "this.lvar[od]" is null" when compiling
In-Reply-To: <rBvuTgHDH7kHgdYaAg0e2aRIfnco-oSp3alUHpAv5Tg=.87fb0c5a-abdd-4322-bf35-e80eecdf8ecf@github.com>
References: <rBvuTgHDH7kHgdYaAg0e2aRIfnco-oSp3alUHpAv5Tg=.87fb0c5a-abdd-4322-bf35-e80eecdf8ecf@github.com>
Message-ID: <3EPPI3r9GgEwc_7xtIGXHYOAfjrlhmeVjOLjJw9i-io=.5a73b5bb-64b1-4693-a5a0-81839daba2e8@github.com>

On Wed, 19 Jan 2022 13:29:44 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> For code like:
> 
> public class TestInstanceOf {
> 
>     public static void main(String[] args) {
>         Number abc = 1;
>         new Object() {
>             {
>                 if (abc instanceof Integer integer) {
>                     System.out.println(integer.intValue());
>                 }
>             }
>         };
>     }
> 
> }
> 
> 
> `javac` crashes with:
> 
> An exception has occurred in the compiler (17-internal). Please file a bug against the Java compiler via the Java bug reporting page (http://bugreport.java.com) after checking the Bug Database (http://bugs.java.com) for duplicates. Include your program, the following diagnostic, and the parameters passed to the Java compiler in your report. Thank you.
> java.lang.NullPointerException: Cannot read field "sym" because "this.lvar[3]" is null
>         at jdk.compiler/com.sun.tools.javac.jvm.Code.emitop0(Code.java:577)
>         at jdk.compiler/com.sun.tools.javac.jvm.Items$LocalItem.load(Items.java:399)
>         at jdk.compiler/com.sun.tools.javac.jvm.Gen.genArgs(Gen.java:902)
>         at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitNewClass(Gen.java:1961)
>         at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCNewClass.accept(JCTree.java:1852)
>         at jdk.compiler/com.sun.tools.javac.jvm.Gen.genExpr(Gen.java:877)
>         at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitExec(Gen.java:1742)
>         at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCExpressionStatement.accept(JCTree.java:1584)
>         at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:610)
>         at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:645)
>         at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:631)
>         at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStats(Gen.java:682)
>         at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitBlock(Gen.java:1097)
>         at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:1091)
>         at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:610)
>         at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:645)
>         at jdk.compiler/com.sun.tools.javac.jvm.Gen.genMethod(Gen.java:967)
>         at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitMethodDef(Gen.java:930)
>         at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:921)
>         at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:610)
>         at jdk.compiler/com.sun.tools.javac.jvm.Gen.genClass(Gen.java:2414)
>         at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.genCode(JavaCompiler.java:737)
>         at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1617)
>         at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1585)
>         at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:946)
>         at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:317)
>         at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:176)
>         at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:64)
>         at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:50)
> 
> 
> The cause is in `TransPatterns` - it tracks the current class and method, so that it can define correct owners for temporary variables. But if there's a class nested in a method, the current method field is not cleared, and consequently the temporary variables get a wrong owner (the method enclosing the class, not a method inside the current class), which then crashes subsequent phases, like Gen.
> 
> The proposed fix is to clear `currentMethod` when entering a class AST node.

looks sensible

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

Marked as reviewed by vromero (Reviewer).

PR: https://git.openjdk.java.net/jdk18/pull/110

From duke at openjdk.java.net  Wed Jan 19 17:11:27 2022
From: duke at openjdk.java.net (Aggelos Biboudis)
Date: Wed, 19 Jan 2022 17:11:27 GMT
Subject: RFR: 8036019: Insufficient alternatives listed in some errors
 produced by the parser
In-Reply-To: <w9a7a2TKHe-c5XP7PTzbCeHHWMdstB6fiqgMeFqqhd0=.55ca12ce-e680-429f-8351-eac441a12194@github.com>
References: <kuaNYEc0tS3MIFqSPbkMztyboEwJwR8MHbe32P80Ca4=.21cd16f8-7e2d-48b2-9593-9c8668a9c648@github.com>
 <w9a7a2TKHe-c5XP7PTzbCeHHWMdstB6fiqgMeFqqhd0=.55ca12ce-e680-429f-8351-eac441a12194@github.com>
Message-ID: <WBytTNwI_Mt_a_g4ItXIQeo2vHNsJtKYsBK3oyGHzWE=.2c095c78-0e67-44bc-a34d-dbe4702d8fef@github.com>

On Tue, 18 Jan 2022 17:27:29 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Adjusts the corresponding "expected-" errors for `argumentOpt`,  `typeArgumentsOpt` and `annotationValue`.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 3382:
> 
>> 3380:                 }
>> 3381:             }
>> 3382:             accept(RBRACE, tk -> Errors.AnnotationMissingElementValue);
> 
> I think that this method needs some more massage, annotations like this one are being accepted:
> 
> 
> @SuppressWarnings({,})
> 
> even previous to your patch, if my reading of the spec is correct, there should be at least one `ElementValue`

Indeed, that was my observation as well but then I noticed this: 

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

This is among the positive tests of that contribution:


public class SingleCommaAnnotationValue {
    @Foo({}) void a() { }
    @Foo({,}) void b() { }
    @Foo({0}) void c() { }
    @Foo({0,}) void d() { }
    @Foo({0,0}) void e() { }
    @Foo({0,0,}) void f() { }
}
@interface Foo { int[] value(); }


What do you think?

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

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

From duke at openjdk.java.net  Wed Jan 19 17:31:31 2022
From: duke at openjdk.java.net (Aggelos Biboudis)
Date: Wed, 19 Jan 2022 17:31:31 GMT
Subject: RFR: 8036019: Insufficient alternatives listed in some errors
 produced by the parser
In-Reply-To: <WBytTNwI_Mt_a_g4ItXIQeo2vHNsJtKYsBK3oyGHzWE=.2c095c78-0e67-44bc-a34d-dbe4702d8fef@github.com>
References: <kuaNYEc0tS3MIFqSPbkMztyboEwJwR8MHbe32P80Ca4=.21cd16f8-7e2d-48b2-9593-9c8668a9c648@github.com>
 <w9a7a2TKHe-c5XP7PTzbCeHHWMdstB6fiqgMeFqqhd0=.55ca12ce-e680-429f-8351-eac441a12194@github.com>
 <WBytTNwI_Mt_a_g4ItXIQeo2vHNsJtKYsBK3oyGHzWE=.2c095c78-0e67-44bc-a34d-dbe4702d8fef@github.com>
Message-ID: <GnPQbGpPQ5KW0ZGnzVZOV7_MQhnYLQzTT191InMu9Lo=.a4bea498-3c21-4b98-a389-f0363cdd3804@github.com>

On Wed, 19 Jan 2022 17:08:07 GMT, Aggelos Biboudis <duke at openjdk.java.net> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 3382:
>> 
>>> 3380:                 }
>>> 3381:             }
>>> 3382:             accept(RBRACE, tk -> Errors.AnnotationMissingElementValue);
>> 
>> I think that this method needs some more massage, annotations like this one are being accepted:
>> 
>> 
>> @SuppressWarnings({,})
>> 
>> even previous to your patch, if my reading of the spec is correct, there should be at least one `ElementValue`
>
> Indeed, that was my observation as well but then I noticed this: 
> 
> https://bugs.openjdk.java.net/browse/JDK-8012722
> 
> This is among the positive tests of that contribution, which exists on master:
> 
> 
> public class SingleCommaAnnotationValue {
>     @Foo({}) void a() { }
>     @Foo({,}) void b() { }
>     @Foo({0}) void c() { }
>     @Foo({0,}) void d() { }
>     @Foo({0,0}) void e() { }
>     @Foo({0,0,}) void f() { }
> }
> @interface Foo { int[] value(); }
> 
> 
> What do you think?

To my understanding the following rule permits `{,}`:


ElementValueArrayInitializer:
   { [ElementValueList] [,] }
ElementValueList:
   ElementValue {, ElementValue}

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

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

From vromero at openjdk.java.net  Wed Jan 19 18:02:56 2022
From: vromero at openjdk.java.net (Vicente Romero)
Date: Wed, 19 Jan 2022 18:02:56 GMT
Subject: RFR: 8036019: Insufficient alternatives listed in some errors
 produced by the parser
In-Reply-To: <kuaNYEc0tS3MIFqSPbkMztyboEwJwR8MHbe32P80Ca4=.21cd16f8-7e2d-48b2-9593-9c8668a9c648@github.com>
References: <kuaNYEc0tS3MIFqSPbkMztyboEwJwR8MHbe32P80Ca4=.21cd16f8-7e2d-48b2-9593-9c8668a9c648@github.com>
Message-ID: <qvMIJr0Q18V6kcSHJCFgzscQzN15wtLqUFwGZbhQDfU=.cb1a45a3-e4ff-4af6-8ff4-e1ba00248205@github.com>

On Mon, 10 Jan 2022 18:53:35 GMT, Aggelos Biboudis <duke at openjdk.java.net> wrote:

> Adjusts the corresponding "expected-" errors for `argumentOpt`,  `typeArgumentsOpt` and `annotationValue`.

looks good

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

Marked as reviewed by vromero (Reviewer).

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

From vromero at openjdk.java.net  Wed Jan 19 18:02:57 2022
From: vromero at openjdk.java.net (Vicente Romero)
Date: Wed, 19 Jan 2022 18:02:57 GMT
Subject: RFR: 8036019: Insufficient alternatives listed in some errors
 produced by the parser
In-Reply-To: <GnPQbGpPQ5KW0ZGnzVZOV7_MQhnYLQzTT191InMu9Lo=.a4bea498-3c21-4b98-a389-f0363cdd3804@github.com>
References: <kuaNYEc0tS3MIFqSPbkMztyboEwJwR8MHbe32P80Ca4=.21cd16f8-7e2d-48b2-9593-9c8668a9c648@github.com>
 <w9a7a2TKHe-c5XP7PTzbCeHHWMdstB6fiqgMeFqqhd0=.55ca12ce-e680-429f-8351-eac441a12194@github.com>
 <WBytTNwI_Mt_a_g4ItXIQeo2vHNsJtKYsBK3oyGHzWE=.2c095c78-0e67-44bc-a34d-dbe4702d8fef@github.com>
 <GnPQbGpPQ5KW0ZGnzVZOV7_MQhnYLQzTT191InMu9Lo=.a4bea498-3c21-4b98-a389-f0363cdd3804@github.com>
Message-ID: <BrbWIJp8xmE9lrL3htwByWtptb-7yskSkcrBJcrQCsg=.0ee6b742-2145-476d-9c47-86b00ff5308c@github.com>

On Wed, 19 Jan 2022 17:28:29 GMT, Aggelos Biboudis <duke at openjdk.java.net> wrote:

>> Indeed, that was my observation as well but then I noticed this: 
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8012722
>> 
>> This is among the positive tests of that contribution, which exists on master:
>> 
>> 
>> public class SingleCommaAnnotationValue {
>>     @Foo({}) void a() { }
>>     @Foo({,}) void b() { }
>>     @Foo({0}) void c() { }
>>     @Foo({0,}) void d() { }
>>     @Foo({0,0}) void e() { }
>>     @Foo({0,0,}) void f() { }
>> }
>> @interface Foo { int[] value(); }
>> 
>> 
>> What do you think?
>
> To my understanding the following rule permits `{,}`:
> 
> 
> ElementValueArrayInitializer:
>    { [ElementValueList] [,] }
> ElementValueList:
>    ElementValue {, ElementValue}

I see, thanks for the clarification

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

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

From jlahoda at openjdk.java.net  Wed Jan 19 19:06:29 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Wed, 19 Jan 2022 19:06:29 GMT
Subject: [jdk18] Integrated: 8278834: Error
 "Cannot read field "sym" because "this.lvar[od]" is null" when compiling
In-Reply-To: <rBvuTgHDH7kHgdYaAg0e2aRIfnco-oSp3alUHpAv5Tg=.87fb0c5a-abdd-4322-bf35-e80eecdf8ecf@github.com>
References: <rBvuTgHDH7kHgdYaAg0e2aRIfnco-oSp3alUHpAv5Tg=.87fb0c5a-abdd-4322-bf35-e80eecdf8ecf@github.com>
Message-ID: <2VNlFS3HtUObZzn8C-6USYDO4TVlUK4Z2j5VVC7Nxys=.4895316b-cc18-4b6f-8a56-514051e721f5@github.com>

On Wed, 19 Jan 2022 13:29:44 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> For code like:
> 
> public class TestInstanceOf {
> 
>     public static void main(String[] args) {
>         Number abc = 1;
>         new Object() {
>             {
>                 if (abc instanceof Integer integer) {
>                     System.out.println(integer.intValue());
>                 }
>             }
>         };
>     }
> 
> }
> 
> 
> `javac` crashes with:
> 
> An exception has occurred in the compiler (17-internal). Please file a bug against the Java compiler via the Java bug reporting page (http://bugreport.java.com) after checking the Bug Database (http://bugs.java.com) for duplicates. Include your program, the following diagnostic, and the parameters passed to the Java compiler in your report. Thank you.
> java.lang.NullPointerException: Cannot read field "sym" because "this.lvar[3]" is null
>         at jdk.compiler/com.sun.tools.javac.jvm.Code.emitop0(Code.java:577)
>         at jdk.compiler/com.sun.tools.javac.jvm.Items$LocalItem.load(Items.java:399)
>         at jdk.compiler/com.sun.tools.javac.jvm.Gen.genArgs(Gen.java:902)
>         at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitNewClass(Gen.java:1961)
>         at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCNewClass.accept(JCTree.java:1852)
>         at jdk.compiler/com.sun.tools.javac.jvm.Gen.genExpr(Gen.java:877)
>         at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitExec(Gen.java:1742)
>         at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCExpressionStatement.accept(JCTree.java:1584)
>         at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:610)
>         at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:645)
>         at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:631)
>         at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStats(Gen.java:682)
>         at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitBlock(Gen.java:1097)
>         at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:1091)
>         at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:610)
>         at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:645)
>         at jdk.compiler/com.sun.tools.javac.jvm.Gen.genMethod(Gen.java:967)
>         at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitMethodDef(Gen.java:930)
>         at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:921)
>         at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:610)
>         at jdk.compiler/com.sun.tools.javac.jvm.Gen.genClass(Gen.java:2414)
>         at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.genCode(JavaCompiler.java:737)
>         at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1617)
>         at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1585)
>         at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:946)
>         at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:317)
>         at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:176)
>         at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:64)
>         at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:50)
> 
> 
> The cause is in `TransPatterns` - it tracks the current class and method, so that it can define correct owners for temporary variables. But if there's a class nested in a method, the current method field is not cleared, and consequently the temporary variables get a wrong owner (the method enclosing the class, not a method inside the current class), which then crashes subsequent phases, like Gen.
> 
> The proposed fix is to clear `currentMethod` when entering a class AST node.

This pull request has now been integrated.

Changeset: be0538d7
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.java.net/jdk18/commit/be0538d7c8e2cbfa599dbcb4c5c69533678a8421
Stats:     167 lines in 2 files changed: 167 ins; 0 del; 0 mod

8278834: Error "Cannot read field "sym" because "this.lvar[od]" is null" when compiling

Reviewed-by: vromero

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

PR: https://git.openjdk.java.net/jdk18/pull/110

From joe.darcy at oracle.com  Wed Jan 19 23:35:36 2022
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Wed, 19 Jan 2022 15:35:36 -0800
Subject: JSR 269 MR for Java SE 18 changes
Message-ID: <11c8e416-70b9-96b1-9494-9e54d22020dd@oracle.com>

FYI,

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

-Joe


From jwilhelm at openjdk.java.net  Thu Jan 20 00:40:42 2022
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Thu, 20 Jan 2022 00:40:42 GMT
Subject: RFR: Merge jdk18
Message-ID: <EKvhDNv6ltbdyXkGEi0nLmNGrcDYV4LwVLRrf193G8Q=.e8f88c82-a430-4608-8ea9-e79b427231c8@github.com>

Forwardport JDK 18 -> JDK 19

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

Commit messages:
 - Merge
 - 8280233: Temporarily disable Unix domain sockets in Windows PipeImpl
 - 8278834: Error "Cannot read field "sym" because "this.lvar[od]" is null" when compiling
 - 8272058: 25 Null pointer dereference defect groups in 4 files
 - 8280234: AArch64 "core" variant does not build after JDK-8270947
 - 8280155: [PPC64, s390] frame size checks are not yet correct
 - 8273383: vmTestbase/vm/gc/containers/Combination05/TestDescription.java crashes verifying length of DCQS
 - 8279654: jdk/incubator/vector/Vector256ConversionTests.java crashes randomly with SVE
 - 8278417: Closed test fails after JDK-8276108 on aarch64
 - 8274096: Improve decoding of image files
 - ... and 30 more: https://git.openjdk.java.net/jdk/compare/98d96a77...e0d83a07

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

Changes: https://git.openjdk.java.net/jdk/pull/7151/files
  Stats: 1732 lines in 67 files changed: 933 ins; 606 del; 193 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7151.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7151/head:pull/7151

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

From jwilhelm at openjdk.java.net  Thu Jan 20 01:21:56 2022
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Thu, 20 Jan 2022 01:21:56 GMT
Subject: Integrated: Merge jdk18
In-Reply-To: <EKvhDNv6ltbdyXkGEi0nLmNGrcDYV4LwVLRrf193G8Q=.e8f88c82-a430-4608-8ea9-e79b427231c8@github.com>
References: <EKvhDNv6ltbdyXkGEi0nLmNGrcDYV4LwVLRrf193G8Q=.e8f88c82-a430-4608-8ea9-e79b427231c8@github.com>
Message-ID: <y0iAccUwe8WmPHsAzm9zEpWgdTLEzKLHEmBgkiWWrzc=.4fca1b0a-3f93-4ee9-9fc6-6835ebd6d041@github.com>

On Thu, 20 Jan 2022 00:28:55 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 18 -> JDK 19

This pull request has now been integrated.

Changeset: 4616c13c
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/4616c13c2f1ced8a8bdeed81f0469523932e91b5
Stats:     1732 lines in 67 files changed: 933 ins; 606 del; 193 mod

Merge

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

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

From jlahoda at openjdk.java.net  Thu Jan 20 12:42:14 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Thu, 20 Jan 2022 12:42:14 GMT
Subject: RFR: 8280067: Incorrect code generated for unary - on char operand
Message-ID: <LgddRspgRss295gmlRAPxPkrU_yXWE_FgRS1gloj8_I=.47fd2389-6dee-4f62-8ef8-c054091463ef@github.com>

Consider the following snippet of code:

Character var = (char) -(false ? (char) param : (char) 2);


The `javac` frontend will not put a constant type on `false ? (char) param : (char) 2` (i.e. it will not constant-fold `(char) 2` to the whole conditional expression). This seems correct, as this is not (I think) a constant expression. But then, in the code generator:
-`Gen.visitUnary` is called, which requests to evaluate the argument, specifying the type should be `int`.
-when the argument (i.e. `false ? (char) param : (char) 2`) is evaluted, it produces an `ImmediateItem` with the constant, of type `char`, skipping the "then" expression, as that is never reached
-then the type of the `Item` is converted using `coerce` to the desired type (`int`). But in `ImmediateItem.coerce`, `char` is considered to be "equivalent" to `int`, and no conversion happens, and the same (`char`) `ImmediateItem` is returned
-`Gen.visitUnary` will push the constant  the stack and will produce the `ineg` instruction, but will (effectively) use the type of the parameter's `Item` for its result
-so the outermost `char` cast is a no-op, because the stack's top is considered to be `char` - but that is not correct, because `char` is unsigned, and the actual value at the top of the stack is `-2`.

This can then lead to various wrong behavior, including an exception from `Character.valueOf(char)`.

The proposal is to produce an `Item` with the correct type (i.e. `int`) in `ImmediateItem.coerce` for `char`-typed `ImmediateItem`s. `Item`s of type `byte`/`short` are kept as they are, even though it is not clear to me if simply producing an `int`-typed `Item` would not work equally well. But returning an `Item` with type `char` when `int` is requested seems wrong due to the unsigned property of `char`.

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

Commit messages:
 - 8280067: Incorrect code generated for unary - on char operand

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

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

From jlaskey at openjdk.java.net  Thu Jan 20 12:53:49 2022
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Thu, 20 Jan 2022 12:53:49 GMT
Subject: RFR: 8280067: Incorrect code generated for unary - on char operand
In-Reply-To: <LgddRspgRss295gmlRAPxPkrU_yXWE_FgRS1gloj8_I=.47fd2389-6dee-4f62-8ef8-c054091463ef@github.com>
References: <LgddRspgRss295gmlRAPxPkrU_yXWE_FgRS1gloj8_I=.47fd2389-6dee-4f62-8ef8-c054091463ef@github.com>
Message-ID: <b4UhZHNqCzPx9_MBagxx5WX8wcPQQxcPwdLXb-Kt1C0=.0db4e345-aaf8-489f-96b9-6d00e1506d6a@github.com>

On Thu, 20 Jan 2022 12:31:57 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider the following snippet of code:
> 
> Character var = (char) -(false ? (char) param : (char) 2);
> 
> 
> The `javac` frontend will not put a constant type on `false ? (char) param : (char) 2` (i.e. it will not constant-fold `(char) 2` to the whole conditional expression). This seems correct, as this is not (I think) a constant expression. But then, in the code generator:
> -`Gen.visitUnary` is called, which requests to evaluate the argument, specifying the type should be `int`.
> -when the argument (i.e. `false ? (char) param : (char) 2`) is evaluted, it produces an `ImmediateItem` with the constant, of type `char`, skipping the "then" expression, as that is never reached
> -then the type of the `Item` is converted using `coerce` to the desired type (`int`). But in `ImmediateItem.coerce`, `char` is considered to be "equivalent" to `int`, and no conversion happens, and the same (`char`) `ImmediateItem` is returned
> -`Gen.visitUnary` will push the constant  the stack and will produce the `ineg` instruction, but will (effectively) use the type of the parameter's `Item` for its result
> -so the outermost `char` cast is a no-op, because the stack's top is considered to be `char` - but that is not correct, because `char` is unsigned, and the actual value at the top of the stack is `-2`.
> 
> This can then lead to various wrong behavior, including an exception from `Character.valueOf(char)`.
> 
> The proposal is to produce an `Item` with the correct type (i.e. `int`) in `ImmediateItem.coerce` for `char`-typed `ImmediateItem`s. `Item`s of type `byte`/`short` are kept as they are, even though it is not clear to me if simply producing an `int`-typed `Item` would not work equally well. But returning an `Item` with type `char` when `int` is requested seems wrong due to the unsigned property of `char`.

LGTM

test/langtools/tools/javac/code/CharImmediateValue.java line 78:

> 76:     void runSourceTest() throws Exception {
> 77:         int param = 0;
> 78:         Character var = (char) -(false ? (char) param : (char) 2);

"var"? - syntax highlighting misreads.

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

Marked as reviewed by jlaskey (Reviewer).

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

From vromero at openjdk.java.net  Thu Jan 20 17:12:48 2022
From: vromero at openjdk.java.net (Vicente Romero)
Date: Thu, 20 Jan 2022 17:12:48 GMT
Subject: RFR: 8280067: Incorrect code generated for unary - on char operand
In-Reply-To: <LgddRspgRss295gmlRAPxPkrU_yXWE_FgRS1gloj8_I=.47fd2389-6dee-4f62-8ef8-c054091463ef@github.com>
References: <LgddRspgRss295gmlRAPxPkrU_yXWE_FgRS1gloj8_I=.47fd2389-6dee-4f62-8ef8-c054091463ef@github.com>
Message-ID: <N5WDRaeYfMHXZDFeiq7mhSydt-ucB8tJyurDto0zSjg=.06c953ce-e5a5-4446-821f-7bd60184ac0b@github.com>

On Thu, 20 Jan 2022 12:31:57 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider the following snippet of code:
> 
> Character var = (char) -(false ? (char) param : (char) 2);
> 
> 
> The `javac` frontend will not put a constant type on `false ? (char) param : (char) 2` (i.e. it will not constant-fold `(char) 2` to the whole conditional expression). This seems correct, as this is not (I think) a constant expression. But then, in the code generator:
> -`Gen.visitUnary` is called, which requests to evaluate the argument, specifying the type should be `int`.
> -when the argument (i.e. `false ? (char) param : (char) 2`) is evaluted, it produces an `ImmediateItem` with the constant, of type `char`, skipping the "then" expression, as that is never reached
> -then the type of the `Item` is converted using `coerce` to the desired type (`int`). But in `ImmediateItem.coerce`, `char` is considered to be "equivalent" to `int`, and no conversion happens, and the same (`char`) `ImmediateItem` is returned
> -`Gen.visitUnary` will push the constant  the stack and will produce the `ineg` instruction, but will (effectively) use the type of the parameter's `Item` for its result
> -so the outermost `char` cast is a no-op, because the stack's top is considered to be `char` - but that is not correct, because `char` is unsigned, and the actual value at the top of the stack is `-2`.
> 
> This can then lead to various wrong behavior, including an exception from `Character.valueOf(char)`.
> 
> The proposal is to produce an `Item` with the correct type (i.e. `int`) in `ImmediateItem.coerce` for `char`-typed `ImmediateItem`s. `Item`s of type `byte`/`short` are kept as they are, even though it is not clear to me if simply producing an `int`-typed `Item` would not work equally well. But returning an `Item` with type `char` when `int` is requested seems wrong due to the unsigned property of `char`.

I'm seeing that Lower is reducing the conditional to `(char)(char)2` at `Lower::visitConditional` could it be that the type is wrongly set to `int` somewhere before reaching to `Gen`?

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

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

From jlahoda at openjdk.java.net  Thu Jan 20 18:57:50 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Thu, 20 Jan 2022 18:57:50 GMT
Subject: RFR: 8280067: Incorrect code generated for unary - on char operand
In-Reply-To: <N5WDRaeYfMHXZDFeiq7mhSydt-ucB8tJyurDto0zSjg=.06c953ce-e5a5-4446-821f-7bd60184ac0b@github.com>
References: <LgddRspgRss295gmlRAPxPkrU_yXWE_FgRS1gloj8_I=.47fd2389-6dee-4f62-8ef8-c054091463ef@github.com>
 <N5WDRaeYfMHXZDFeiq7mhSydt-ucB8tJyurDto0zSjg=.06c953ce-e5a5-4446-821f-7bd60184ac0b@github.com>
Message-ID: <0plXWWkjfjYcoezypBLRbru9MUv-keJjcCHeYyFa8Fo=.dd56ee52-0eda-43d2-8fa7-388ccde3e960@github.com>

On Thu, 20 Jan 2022 17:09:26 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> I'm seeing that Lower is reducing the conditional to `(char)(char)2` at `Lower::visitConditional` could it be that the type is wrongly set to `int` somewhere before reaching to `Gen`?

I believe the types of `(char)(char) 2` is correctly `char`, and the type of `-(char)(char)2` is correctly `int` in the AST. But then, when generating the code, the actual value on the stack for `-(char)(char)2` is `-2`, but then for the outermost cast, the codegen thinks the type of the value on the stack is `char`, so does it does not need the cast (`i2c`), which is wrong.

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

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

From darcy at openjdk.java.net  Thu Jan 20 19:09:06 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 20 Jan 2022 19:09:06 GMT
Subject: RFR: JDK-8279397: Update --release 18 symbol information for JDK 18
 build 32
Message-ID: <LjJxtqwfm_EzJV5kWl1ku2DxI0DqYuma2QPyBY2hNn4=.60f9eb6b-5a2e-46e7-8d1e-58ef05780cf8@github.com>

Update of JDK 18 symbol information for build 32.

@lahodaj , can you take a look at the diff? Given the code changes for JDK-8270416: "Enhance construction of Identity maps" (https://github.com/openjdk/jdk/commit/5832a3440489d0967dc3b0542c1ace51eed292d6), I didn't see why the symbol update was triggered.

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

Commit messages:
 - JDK-8279397: Update --release 18 symbol information for JDK 18 build 32

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

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

From iris at openjdk.java.net  Thu Jan 20 19:26:49 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Thu, 20 Jan 2022 19:26:49 GMT
Subject: RFR: JDK-8279397: Update --release 18 symbol information for JDK
 18 build 32
In-Reply-To: <LjJxtqwfm_EzJV5kWl1ku2DxI0DqYuma2QPyBY2hNn4=.60f9eb6b-5a2e-46e7-8d1e-58ef05780cf8@github.com>
References: <LjJxtqwfm_EzJV5kWl1ku2DxI0DqYuma2QPyBY2hNn4=.60f9eb6b-5a2e-46e7-8d1e-58ef05780cf8@github.com>
Message-ID: <zoL9S51sK0TKua1LS-svxjwINdfalZ72Z6UiGJSphIM=.12035ad0-3d93-4f63-b0d8-4c76f7a0986b@github.com>

On Thu, 20 Jan 2022 19:03:36 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Update of JDK 18 symbol information for build 32.
> 
> @lahodaj , can you take a look at the diff? Given the code changes for JDK-8270416: "Enhance construction of Identity maps" (https://github.com/openjdk/jdk/commit/5832a3440489d0967dc3b0542c1ace51eed292d6), I didn't see why the symbol update was triggered.

Marked as reviewed by iris (Reviewer).

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

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

From vromero at openjdk.java.net  Thu Jan 20 20:49:49 2022
From: vromero at openjdk.java.net (Vicente Romero)
Date: Thu, 20 Jan 2022 20:49:49 GMT
Subject: RFR: 8280067: Incorrect code generated for unary - on char operand
In-Reply-To: <LgddRspgRss295gmlRAPxPkrU_yXWE_FgRS1gloj8_I=.47fd2389-6dee-4f62-8ef8-c054091463ef@github.com>
References: <LgddRspgRss295gmlRAPxPkrU_yXWE_FgRS1gloj8_I=.47fd2389-6dee-4f62-8ef8-c054091463ef@github.com>
Message-ID: <hof_3t8PN_FeTZF-k9aRa2fcKRlOIc-u2JBThnhG1jU=.9e34680d-a137-453a-aeff-d8ade816ea6c@github.com>

On Thu, 20 Jan 2022 12:31:57 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider the following snippet of code:
> 
> Character var = (char) -(false ? (char) param : (char) 2);
> 
> 
> The `javac` frontend will not put a constant type on `false ? (char) param : (char) 2` (i.e. it will not constant-fold `(char) 2` to the whole conditional expression). This seems correct, as this is not (I think) a constant expression. But then, in the code generator:
> -`Gen.visitUnary` is called, which requests to evaluate the argument, specifying the type should be `int`.
> -when the argument (i.e. `false ? (char) param : (char) 2`) is evaluted, it produces an `ImmediateItem` with the constant, of type `char`, skipping the "then" expression, as that is never reached
> -then the type of the `Item` is converted using `coerce` to the desired type (`int`). But in `ImmediateItem.coerce`, `char` is considered to be "equivalent" to `int`, and no conversion happens, and the same (`char`) `ImmediateItem` is returned
> -`Gen.visitUnary` will push the constant  the stack and will produce the `ineg` instruction, but will (effectively) use the type of the parameter's `Item` for its result
> -so the outermost `char` cast is a no-op, because the stack's top is considered to be `char` - but that is not correct, because `char` is unsigned, and the actual value at the top of the stack is `-2`.
> 
> This can then lead to various wrong behavior, including an exception from `Character.valueOf(char)`.
> 
> The proposal is to produce an `Item` with the correct type (i.e. `int`) in `ImmediateItem.coerce` for `char`-typed `ImmediateItem`s. `Item`s of type `byte`/`short` are kept as they are, even though it is not clear to me if simply producing an `int`-typed `Item` would not work equally well. But returning an `Item` with type `char` when `int` is requested seems wrong due to the unsigned property of `char`.

looks good

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

Marked as reviewed by vromero (Reviewer).

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

From simone.bordet at gmail.com  Fri Jan 21 10:46:04 2022
From: simone.bordet at gmail.com (Simone Bordet)
Date: Fri, 21 Jan 2022 11:46:04 +0100
Subject: Compilation issue with requires static
Message-ID: <CAFWmRJ2XOxnLxX6X+2woBSGSxeVdt8J+UBx=Rm1eKkqDg4ok7A@mail.gmail.com>

Hi,

the issue is described in detail here:
https://issues.apache.org/jira/browse/MCOMPILER-481.

To summarize, we have module A with: requires static X.
Then we have module B with: requires A.
Module B has test classes (that are patched into module B), and to
compile the test classes X is added to the class-path, and --add-reads
B=ALL-UNNAMED is also added.

My understanding is that a test class in module B should be able to
read classes from module X, due to the --add-reads directive.

However, the compiler (triggered by Maven, but you can see the full
command line in the issue linked above) reports:

[ERROR] /home/simon/tmp/compiler-bug/app/src/test/java/org/test/app/MainTest.java:[12,38]
cannot access org.eclipse.jetty.util.ajax.JSON
[ERROR]   class file for org.eclipse.jetty.util.ajax.JSON not found

where MainTest is a test class in module B, and JSON is a class in module X.

The workaround is to put the jar of module X in the module-path, but
that seems unnecessary given the --add-reads directive.

Is the error expected behavior, or a javac bug?

Thanks!

-- 
Simone Bordet
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless.   Victoria Livschitz

From jan.lahoda at oracle.com  Fri Jan 21 18:25:33 2022
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Fri, 21 Jan 2022 19:25:33 +0100
Subject: Compilation issue with requires static
In-Reply-To: <CAFWmRJ2XOxnLxX6X+2woBSGSxeVdt8J+UBx=Rm1eKkqDg4ok7A@mail.gmail.com>
References: <CAFWmRJ2XOxnLxX6X+2woBSGSxeVdt8J+UBx=Rm1eKkqDg4ok7A@mail.gmail.com>
Message-ID: <81cf11e6-638f-5084-778e-94c9e62b1570@oracle.com>

Hi Simone,


The full error is:

.../MainTest.java:12: error: cannot access JSON
 ??????? JSON json = new JSONService().json;
 ???????????????????????????????????? ^
 ? class file for org.eclipse.jetty.util.ajax.JSON not found
1 error


The JSON class is available to the 'compiler.bug.app' module, and can be 
used there (there is no error for the variable's type, for example). But 
JSONService is from module 'compiler.bug.service', and its return type 
is JSON, and JSON is not available in the context of the 
'compiler.bug.service' module, leading to the error.


So I don't currently see a bug in javac for this.


In principle, one could specify '--add-reads 
compiler.bug.service=ALL-UNNAMED' (then the JSON class from the unnamed 
module would be available to 'compiler.bug.service'), but it is not 
clear to me why the dependent module is not simply put on the module path.


Jan


On 21. 01. 22 11:46, Simone Bordet wrote:
> Hi,
>
> the issue is described in detail here:
> https://issues.apache.org/jira/browse/MCOMPILER-481.
>
> To summarize, we have module A with: requires static X.
> Then we have module B with: requires A.
> Module B has test classes (that are patched into module B), and to
> compile the test classes X is added to the class-path, and --add-reads
> B=ALL-UNNAMED is also added.
>
> My understanding is that a test class in module B should be able to
> read classes from module X, due to the --add-reads directive.
>
> However, the compiler (triggered by Maven, but you can see the full
> command line in the issue linked above) reports:
>
> [ERROR] /home/simon/tmp/compiler-bug/app/src/test/java/org/test/app/MainTest.java:[12,38]
> cannot access org.eclipse.jetty.util.ajax.JSON
> [ERROR]   class file for org.eclipse.jetty.util.ajax.JSON not found
>
> where MainTest is a test class in module B, and JSON is a class in module X.
>
> The workaround is to put the jar of module X in the module-path, but
> that seems unnecessary given the --add-reads directive.
>
> Is the error expected behavior, or a javac bug?
>
> Thanks!
>

From jlahoda at openjdk.java.net  Fri Jan 21 18:42:51 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Fri, 21 Jan 2022 18:42:51 GMT
Subject: RFR: JDK-8279397: Update --release 18 symbol information for JDK
 18 build 32
In-Reply-To: <LjJxtqwfm_EzJV5kWl1ku2DxI0DqYuma2QPyBY2hNn4=.60f9eb6b-5a2e-46e7-8d1e-58ef05780cf8@github.com>
References: <LjJxtqwfm_EzJV5kWl1ku2DxI0DqYuma2QPyBY2hNn4=.60f9eb6b-5a2e-46e7-8d1e-58ef05780cf8@github.com>
Message-ID: <0vhdXH6xMp15rkFrpxZ3YrfPpke3Ox7YEbUO2wFuccQ=.0460eb20-1bd2-437e-9276-a1d56fc604bb@github.com>

On Thu, 20 Jan 2022 19:03:36 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Update of JDK 18 symbol information for build 32.
> 
> @lahodaj , can you take a look at the diff? Given the code changes for JDK-8270416: "Enhance construction of Identity maps" (https://github.com/openjdk/jdk/commit/5832a3440489d0967dc3b0542c1ace51eed292d6), I didn't see why the symbol update was triggered.

I believe this is an artifact of limited optimization of the InnerClasses attribute: if the InnerClasses attribute refers to a class that is not part of `ct.sym`, then it is stripped, but if the class is part of ct.sym, the code does not check if it is used from the headers. So some InnerClass entries may sadly be produced for classes that were only used inside method bodies. Possibly an improvement for the future to do more aggressive cleaning. (In general, recording more/unnecessary classes in the InnerClasses shouldn't be harmful besides wasting space, I believe.)

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

Marked as reviewed by jlahoda (Reviewer).

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

From jjg at openjdk.java.net  Fri Jan 21 18:45:58 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Fri, 21 Jan 2022 18:45:58 GMT
Subject: [jdk18] RFR: JDK-8279179: Update nroff pages in JDK 18 before RC
Message-ID: <1nrbA42viloBlDxMIjy9Qb_fcgwUNb_6sAcG2sPTaCY=.2ea6a544-03b6-4a49-88bd-77db90f426fb@github.com>

Please review this semi-automated update to the nroff man pages from the upstream repo.

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

Commit messages:
 - JDK-8279179: Update nroff pages in JDK 18 before RC

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

PR: https://git.openjdk.java.net/jdk18/pull/112

From darcy at openjdk.java.net  Fri Jan 21 18:58:45 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Fri, 21 Jan 2022 18:58:45 GMT
Subject: RFR: JDK-8279397: Update --release 18 symbol information for JDK
 18 build 32
In-Reply-To: <0vhdXH6xMp15rkFrpxZ3YrfPpke3Ox7YEbUO2wFuccQ=.0460eb20-1bd2-437e-9276-a1d56fc604bb@github.com>
References: <LjJxtqwfm_EzJV5kWl1ku2DxI0DqYuma2QPyBY2hNn4=.60f9eb6b-5a2e-46e7-8d1e-58ef05780cf8@github.com>
 <0vhdXH6xMp15rkFrpxZ3YrfPpke3Ox7YEbUO2wFuccQ=.0460eb20-1bd2-437e-9276-a1d56fc604bb@github.com>
Message-ID: <UuFTXYG7DMKucBvAgRIQCEJ3Hq3cwDqxa9az8RielAA=.64c580af-e712-4a89-beef-221182ef2fdb@github.com>

On Fri, 21 Jan 2022 18:39:02 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> I believe this is an artifact of limited optimization of the InnerClasses attribute: if the InnerClasses attribute refers to a class that is not part of `ct.sym`, then it is stripped, but if the class is part of ct.sym, the code does not check if it is used from the headers. So some InnerClass entries may sadly be produced for classes that were only used inside method bodies. Possibly an improvement for the future to do more aggressive cleaning. (In general, recording more/unnecessary classes in the InnerClasses shouldn't be harmful besides wasting space, I believe.)

Good to know; thanks Jan.

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

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

From darcy at openjdk.java.net  Fri Jan 21 18:58:45 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Fri, 21 Jan 2022 18:58:45 GMT
Subject: Integrated: JDK-8279397: Update --release 18 symbol information for
 JDK 18 build 32
In-Reply-To: <LjJxtqwfm_EzJV5kWl1ku2DxI0DqYuma2QPyBY2hNn4=.60f9eb6b-5a2e-46e7-8d1e-58ef05780cf8@github.com>
References: <LjJxtqwfm_EzJV5kWl1ku2DxI0DqYuma2QPyBY2hNn4=.60f9eb6b-5a2e-46e7-8d1e-58ef05780cf8@github.com>
Message-ID: <krv5rV5lwUo7FacFscZIHLj1nJtJbOhp_l4uqM1hSPM=.6fda74f6-d658-4953-b9fe-afca814e1a2f@github.com>

On Thu, 20 Jan 2022 19:03:36 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Update of JDK 18 symbol information for build 32.
> 
> @lahodaj , can you take a look at the diff? Given the code changes for JDK-8270416: "Enhance construction of Identity maps" (https://github.com/openjdk/jdk/commit/5832a3440489d0967dc3b0542c1ace51eed292d6), I didn't see why the symbol update was triggered.

This pull request has now been integrated.

Changeset: c1e4f3dd
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c1e4f3dd1b42474c9abc22c7b981a98f9c36e0d5
Stats:     10 lines in 1 file changed: 10 ins; 0 del; 0 mod

8279397: Update --release 18 symbol information for JDK 18 build 32

Reviewed-by: iris, jlahoda

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

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

From alex.buckley at oracle.com  Fri Jan 21 19:12:23 2022
From: alex.buckley at oracle.com (Alex Buckley)
Date: Fri, 21 Jan 2022 11:12:23 -0800
Subject: Compilation issue with requires static
In-Reply-To: <CAFWmRJ2XOxnLxX6X+2woBSGSxeVdt8J+UBx=Rm1eKkqDg4ok7A@mail.gmail.com>
References: <CAFWmRJ2XOxnLxX6X+2woBSGSxeVdt8J+UBx=Rm1eKkqDg4ok7A@mail.gmail.com>
Message-ID: <5a73d3be-303c-3e45-4e73-042d05cd6310@oracle.com>

On 1/21/2022 2:46 AM, Simone Bordet wrote:
> the issue is described in detail here:
> https://issues.apache.org/jira/browse/MCOMPILER-481.
> 
> To summarize, we have module A with: requires static X.
> Then we have module B with: requires A.
> Module B has test classes (that are patched into module B), and to
> compile the test classes X is added to the class-path, and --add-reads
> B=ALL-UNNAMED is also added.
> 
> My understanding is that a test class in module B should be able to
> read classes from module X, due to the --add-reads directive.
> 
> However, the compiler (triggered by Maven, but you can see the full
> command line in the issue linked above) reports:
> 
> [ERROR] /home/simon/tmp/compiler-bug/app/src/test/java/org/test/app/MainTest.java:[12,38]
> cannot access org.eclipse.jetty.util.ajax.JSON
> [ERROR]   class file for org.eclipse.jetty.util.ajax.JSON not found
> 
> where MainTest is a test class in module B, and JSON is a class in module X.
> 
> The workaround is to put the jar of module X in the module-path, but
> that seems unnecessary given the --add-reads directive.
> 
> Is the error expected behavior, or a javac bug?

I agree with Jan that javac is unlikely to be at fault here.

The intent of module A is that module X be on the modulepath at 
compile-time. I realize you are not compiling module A, but rather 
module B (or at least the test classes patched into B), but it would 
still be simpler to put X on the modulepath instead of messing around 
with the classpath.

Then, you should do `--add-modules X --add-reads B=X` to ensure that X 
is, first, resolved (A's `requires static X;` is moot as you're not 
compiling/resolving A), and second, readable by B.

Alex

From iris at openjdk.java.net  Fri Jan 21 21:09:09 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Fri, 21 Jan 2022 21:09:09 GMT
Subject: [jdk18] RFR: JDK-8279179: Update nroff pages in JDK 18 before RC
In-Reply-To: <1nrbA42viloBlDxMIjy9Qb_fcgwUNb_6sAcG2sPTaCY=.2ea6a544-03b6-4a49-88bd-77db90f426fb@github.com>
References: <1nrbA42viloBlDxMIjy9Qb_fcgwUNb_6sAcG2sPTaCY=.2ea6a544-03b6-4a49-88bd-77db90f426fb@github.com>
Message-ID: <g5jr7NCLRDp-3vt8RqNzip0G09ieklDZvQ4wFvdbjwM=.42ff30b4-dbb8-4250-8d72-4fc942aa928f@github.com>

On Fri, 21 Jan 2022 18:37:50 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review this semi-automated update to the nroff man pages from the upstream repo.

Marked as reviewed by iris (Reviewer).

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

PR: https://git.openjdk.java.net/jdk18/pull/112

From mchung at openjdk.java.net  Fri Jan 21 21:30:14 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Fri, 21 Jan 2022 21:30:14 GMT
Subject: [jdk18] RFR: JDK-8279179: Update nroff pages in JDK 18 before RC
In-Reply-To: <1nrbA42viloBlDxMIjy9Qb_fcgwUNb_6sAcG2sPTaCY=.2ea6a544-03b6-4a49-88bd-77db90f426fb@github.com>
References: <1nrbA42viloBlDxMIjy9Qb_fcgwUNb_6sAcG2sPTaCY=.2ea6a544-03b6-4a49-88bd-77db90f426fb@github.com>
Message-ID: <x8Pjqqan34HlYD9ddr6Ml9pgp8NOkGJczzsUC9FBK8Y=.b0c520b1-812c-4d7d-bb97-908d25411a09@github.com>

On Fri, 21 Jan 2022 18:37:50 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review this semi-automated update to the nroff man pages from the upstream repo.

Marked as reviewed by mchung (Reviewer).

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

PR: https://git.openjdk.java.net/jdk18/pull/112

From jjg at openjdk.java.net  Fri Jan 21 23:22:13 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Fri, 21 Jan 2022 23:22:13 GMT
Subject: [jdk18] Integrated: JDK-8279179: Update nroff pages in JDK 18 before
 RC
In-Reply-To: <1nrbA42viloBlDxMIjy9Qb_fcgwUNb_6sAcG2sPTaCY=.2ea6a544-03b6-4a49-88bd-77db90f426fb@github.com>
References: <1nrbA42viloBlDxMIjy9Qb_fcgwUNb_6sAcG2sPTaCY=.2ea6a544-03b6-4a49-88bd-77db90f426fb@github.com>
Message-ID: <Q-BUs1KzbxnK5fv3i0jI_DhLXZMRu6TeREF7T7zM4a0=.3d650bfc-6ce9-4f48-87bf-65b5ddd22828@github.com>

On Fri, 21 Jan 2022 18:37:50 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review this semi-automated update to the nroff man pages from the upstream repo.

This pull request has now been integrated.

Changeset: 7d2ef9d9
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.java.net/jdk18/commit/7d2ef9d984f96cd260dc233c4acf58669615227f
Stats:     34 lines in 3 files changed: 32 ins; 0 del; 2 mod

8279179: Update nroff pages in JDK 18 before RC

Reviewed-by: iris, mchung

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

PR: https://git.openjdk.java.net/jdk18/pull/112

From simone.bordet at gmail.com  Mon Jan 24 09:50:32 2022
From: simone.bordet at gmail.com (Simone Bordet)
Date: Mon, 24 Jan 2022 10:50:32 +0100
Subject: Compilation issue with requires static
In-Reply-To: <5a73d3be-303c-3e45-4e73-042d05cd6310@oracle.com>
References: <CAFWmRJ2XOxnLxX6X+2woBSGSxeVdt8J+UBx=Rm1eKkqDg4ok7A@mail.gmail.com>
 <5a73d3be-303c-3e45-4e73-042d05cd6310@oracle.com>
Message-ID: <CAFWmRJ2ookGZxyzVh015ivkjcwL+t+O2Ap8rEeYSTYwHWt7==Q@mail.gmail.com>

Jan, Alex,

On Fri, Jan 21, 2022 at 8:12 PM Alex Buckley <alex.buckley at oracle.com> wrote:
> I agree with Jan that javac is unlikely to be at fault here.

Thanks for the help!
We understand the problem better now, and we'll continue on the Maven
Compiler Plugin side to support the use-case I reported here, which
was supported in previous versions of the Maven Compiler Plugin but
there was a regression.
The insights you provided about javac were key to understanding the issue.

Thanks!
-- 
Simone Bordet
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless.   Victoria Livschitz

From jlahoda at openjdk.java.net  Mon Jan 24 13:56:12 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Mon, 24 Jan 2022 13:56:12 GMT
Subject: Integrated: 8280067: Incorrect code generated for unary - on char
 operand
In-Reply-To: <LgddRspgRss295gmlRAPxPkrU_yXWE_FgRS1gloj8_I=.47fd2389-6dee-4f62-8ef8-c054091463ef@github.com>
References: <LgddRspgRss295gmlRAPxPkrU_yXWE_FgRS1gloj8_I=.47fd2389-6dee-4f62-8ef8-c054091463ef@github.com>
Message-ID: <YN9DVSNGF6SX5FRC7xQjoeSV_iJxsuF2w1vi76allBM=.1d93333c-2e2f-407a-83cd-515959300cab@github.com>

On Thu, 20 Jan 2022 12:31:57 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider the following snippet of code:
> 
> Character var = (char) -(false ? (char) param : (char) 2);
> 
> 
> The `javac` frontend will not put a constant type on `false ? (char) param : (char) 2` (i.e. it will not constant-fold `(char) 2` to the whole conditional expression). This seems correct, as this is not (I think) a constant expression. But then, in the code generator:
> -`Gen.visitUnary` is called, which requests to evaluate the argument, specifying the type should be `int`.
> -when the argument (i.e. `false ? (char) param : (char) 2`) is evaluted, it produces an `ImmediateItem` with the constant, of type `char`, skipping the "then" expression, as that is never reached
> -then the type of the `Item` is converted using `coerce` to the desired type (`int`). But in `ImmediateItem.coerce`, `char` is considered to be "equivalent" to `int`, and no conversion happens, and the same (`char`) `ImmediateItem` is returned
> -`Gen.visitUnary` will push the constant  the stack and will produce the `ineg` instruction, but will (effectively) use the type of the parameter's `Item` for its result
> -so the outermost `char` cast is a no-op, because the stack's top is considered to be `char` - but that is not correct, because `char` is unsigned, and the actual value at the top of the stack is `-2`.
> 
> This can then lead to various wrong behavior, including an exception from `Character.valueOf(char)`.
> 
> The proposal is to produce an `Item` with the correct type (i.e. `int`) in `ImmediateItem.coerce` for `char`-typed `ImmediateItem`s. `Item`s of type `byte`/`short` are kept as they are, even though it is not clear to me if simply producing an `int`-typed `Item` would not work equally well. But returning an `Item` with type `char` when `int` is requested seems wrong due to the unsigned property of `char`.

This pull request has now been integrated.

Changeset: 18c9cb07
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/18c9cb07891cdd68c06385a28af16e3931b84317
Stats:     187 lines in 2 files changed: 185 ins; 0 del; 2 mod

8280067: Incorrect code generated for unary - on char operand

Reviewed-by: jlaskey, vromero

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

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

From duke at openjdk.java.net  Mon Jan 24 15:13:12 2022
From: duke at openjdk.java.net (Aggelos Biboudis)
Date: Mon, 24 Jan 2022 15:13:12 GMT
Subject: Integrated: 8036019: Insufficient alternatives listed in some errors
 produced by the parser
In-Reply-To: <kuaNYEc0tS3MIFqSPbkMztyboEwJwR8MHbe32P80Ca4=.21cd16f8-7e2d-48b2-9593-9c8668a9c648@github.com>
References: <kuaNYEc0tS3MIFqSPbkMztyboEwJwR8MHbe32P80Ca4=.21cd16f8-7e2d-48b2-9593-9c8668a9c648@github.com>
Message-ID: <Sc_6pAuW4TeVQczvcADFAcY5011eFXieuwP3l6Sr_EM=.d31cd843-aef9-4725-9ea9-5f3bdcfe9a99@github.com>

On Mon, 10 Jan 2022 18:53:35 GMT, Aggelos Biboudis <duke at openjdk.java.net> wrote:

> Adjusts the corresponding "expected-" errors for `argumentOpt`,  `typeArgumentsOpt` and `annotationValue`.

This pull request has now been integrated.

Changeset: 2b133415
Author:    Angelos Bimpoudis <angelos.bimpoudis at oracle.com>
Committer: Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/2b13341500cb9474f5fd6375b97d102ffb635b13
Stats:     94 lines in 9 files changed: 87 ins; 0 del; 7 mod

8036019: Insufficient alternatives listed in some errors produced by the parser

Reviewed-by: vromero

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

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

From jwilhelm at openjdk.java.net  Mon Jan 24 20:00:50 2022
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Mon, 24 Jan 2022 20:00:50 GMT
Subject: RFR: Merge jdk18
Message-ID: <DEF_B2Es3fA4SlsR8LFXeOn-RZhaKozYwU3VgPlu9eY=.912a62d3-fda5-4659-a5d1-e3475f91c0d0@github.com>

Forwardport JDK 18 -> JDK 19

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

Commit messages:
 - Merge remote-tracking branch 'jdk18/master' into Merge_jdk18
 - 8280441: Missing "classpath exception" in several files from jdk.httpserver
 - 8279179: Update nroff pages in JDK 18 before RC

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

Changes: https://git.openjdk.java.net/jdk/pull/7203/files
  Stats: 62 lines in 10 files changed: 46 ins; 0 del; 16 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7203.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7203/head:pull/7203

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

From jwilhelm at openjdk.java.net  Mon Jan 24 21:57:13 2022
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Mon, 24 Jan 2022 21:57:13 GMT
Subject: Integrated: Merge jdk18
In-Reply-To: <DEF_B2Es3fA4SlsR8LFXeOn-RZhaKozYwU3VgPlu9eY=.912a62d3-fda5-4659-a5d1-e3475f91c0d0@github.com>
References: <DEF_B2Es3fA4SlsR8LFXeOn-RZhaKozYwU3VgPlu9eY=.912a62d3-fda5-4659-a5d1-e3475f91c0d0@github.com>
Message-ID: <qFIRt21XPHhw6XPq9ZMQ6ktA6GQfjtDvpecsx7fZ4yY=.3106095d-779b-4f21-b781-24dc80a4d344@github.com>

On Mon, 24 Jan 2022 19:51:08 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 18 -> JDK 19

This pull request has now been integrated.

Changeset: 52ddbe2d
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/52ddbe2dcdb2fa52d85c987443ffa14522ace729
Stats:     62 lines in 10 files changed: 46 ins; 0 del; 16 mod

Merge

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

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

From duke at openjdk.java.net  Wed Jan 26 22:13:38 2022
From: duke at openjdk.java.net (duke)
Date: Wed, 26 Jan 2022 22:13:38 GMT
Subject: Withdrawn: 8276836: Error in javac caused by switch expression without
 result expressions: Internal error: stack sim error
In-Reply-To: <QTTZWDHD_kM74NPEGEwAHUFVxXl4xQT-_sArJiODBlI=.62b1a747-eb1b-4271-b409-fa0a24330042@github.com>
References: <QTTZWDHD_kM74NPEGEwAHUFVxXl4xQT-_sArJiODBlI=.62b1a747-eb1b-4271-b409-fa0a24330042@github.com>
Message-ID: <nFLrDDVBDTfE0J5qUALYwTawnLTGGDaKJdttYqhzVv0=.2172c76d-c49b-4838-ad36-5ba42054a75a@github.com>

On Thu, 11 Nov 2021 13:47:17 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> The method `Gen#visitSwitchExpression` will switch code generation off by using the method `Code#markDead` when it meets the code like `throw new RuntimeException()`. Then the method `Gen#completeBinop` won't generate the expected code and wiil let the left operand stay in the stack without handling it.
> 
> This patch pops the left operand from the stack to solve this issue. And the corresponding test is added.
> 
> Thanks for taking the time to review.
> 
> Best Regards,
> -- Guoxiong

This pull request has been closed without being integrated.

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

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

From joe.darcy at oracle.com  Fri Jan 28 02:32:50 2022
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Thu, 27 Jan 2022 18:32:50 -0800
Subject: FYI, in Java SE 19 SuppressedWarnings annotations will be applicable
 in all declaration contexts
Message-ID: <afddd3b4-fcd1-1cef-c772-a5700028cf07@oracle.com>

FYI, with the fix to

 ??? JDK-8280744: Allow SuppressWarnings to be used in all declaration 
contexts

in 19, SuppressedWarnings annotations will be applicable in all 
declaration contexts, which include several where they are not currently 
allowed, such as package-info files.

-Joe


From jlahoda at openjdk.java.net  Fri Jan 28 11:04:36 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Fri, 28 Jan 2022 11:04:36 GMT
Subject: RFR: 8280866: SuppressWarnings does not work properly in package-info
 and module-info
Message-ID: <seVJWKBGW5-VNijGS76vF7lnNzHgjc7wSCsLFV40n48=.9acbcfde-b72d-4b81-96b1-f491ed276dd8@github.com>

`@SuppressWarnings` is not handled properly in `module-info` and, after https://bugs.openjdk.java.net/browse/JDK-8280744, also not in `package-info`. This patch attempts to fix that, by correctly deferring the warnings, and the printing them at an appropriate point.

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

Commit messages:
 - Cleanup.
 - 8280866: SuppressWarnings does not work properly in package-info and module-info

Changes: https://git.openjdk.java.net/jdk/pull/7266/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7266&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8280866
  Stats: 247 lines in 4 files changed: 234 ins; 0 del; 13 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7266.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7266/head:pull/7266

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

From darcy at openjdk.java.net  Fri Jan 28 17:50:09 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Fri, 28 Jan 2022 17:50:09 GMT
Subject: RFR: 8280866: SuppressWarnings does not work properly in
 package-info and module-info
In-Reply-To: <seVJWKBGW5-VNijGS76vF7lnNzHgjc7wSCsLFV40n48=.9acbcfde-b72d-4b81-96b1-f491ed276dd8@github.com>
References: <seVJWKBGW5-VNijGS76vF7lnNzHgjc7wSCsLFV40n48=.9acbcfde-b72d-4b81-96b1-f491ed276dd8@github.com>
Message-ID: <Z2v86xXu9hnXrGnXCJ_0f0Tqlrvbp6ZZseOvgaWBARo=.79c11254-abd7-4f15-8e84-82a7b28a7959@github.com>

On Fri, 28 Jan 2022 10:57:50 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> `@SuppressWarnings` is not handled properly in `module-info` and, after https://bugs.openjdk.java.net/browse/JDK-8280744, also not in `package-info`. This patch attempts to fix that, by correctly deferring the warnings, and the printing them at an appropriate point.

Test case looks good; thanks for fixing this.

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

Marked as reviewed by darcy (Reviewer).

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

From duke at openjdk.java.net  Sun Jan 30 04:01:16 2022
From: duke at openjdk.java.net (duke)
Date: Sun, 30 Jan 2022 04:01:16 GMT
Subject: Withdrawn: 8274881: Update jdk.compiler classes to use
 try-with-resources
In-Reply-To: <KZ7glwO6LNrfX3h2zys05htd7bn80cc51Th9xAG7AlY=.187e2e56-fb8c-4d7d-8a6d-682f12622b8d@github.com>
References: <KZ7glwO6LNrfX3h2zys05htd7bn80cc51Th9xAG7AlY=.187e2e56-fb8c-4d7d-8a6d-682f12622b8d@github.com>
Message-ID: <LoYPeyu8NYSlLySEwIYsD87vksv2_9k0p5a3PuZoieM=.e560b4a0-a267-4abb-86fb-b1ec58022975@github.com>

On Tue, 5 Oct 2021 07:52:40 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> 8274881: Update jdk.compiler classes to use try-with-resources

This pull request has been closed without being integrated.

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

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