From jjg at openjdk.org  Wed Feb  1 00:01:17 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 1 Feb 2023 00:01:17 GMT
Subject: RFR: JDK-8301201: Allow \n@ inside inline tags using inlineContent
 [v2]
In-Reply-To: <Aq9OARRHdHjmBiM2c8c3spmH58wp1l-pAOXk6-7tp7U=.0bb7925e-1ce2-49e5-875e-c336b6c79275@github.com>
References: <Aq9OARRHdHjmBiM2c8c3spmH58wp1l-pAOXk6-7tp7U=.0bb7925e-1ce2-49e5-875e-c336b6c79275@github.com>
Message-ID: <2ywtOGpJGOOjYvNWp3xLX9jwK-bgaTnZAamZicv34Jw=.748a2509-f127-49cb-83df-939353b9ccf9@github.com>

> Please review a simple change to allow the use of _newline_ _whitespace_ `@` inside inline tags that allow rich content (that is, those parsed with `inlineContent`) as compared to those that only allow plain text (that is, those parsed with `inlineText`).
> 
> The fix is to delete the code which recognizes `@` as the beginning of a block tag. Compare to the similar fix in [JDK-8241780](https://bugs.openjdk.org/browse/JDK-8241780)
> 
> The general `TagTest.java` is updated for the new feature.

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

  fix broken tests

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12264/files
  - new: https://git.openjdk.org/jdk/pull/12264/files/a27b09b1..6b22d92f

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

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

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

From jjg at openjdk.org  Wed Feb  1 00:08:51 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 1 Feb 2023 00:08:51 GMT
Subject: RFR: JDK-8301201: Allow \n@ inside inline tags using inlineContent
 [v2]
In-Reply-To: <q_9FfzeL4ex7BPIHiaHr8CvCO9rn73HGSO7-EZg2BPM=.27193380-3989-4303-a1cd-6e278a129ae2@github.com>
References: <Aq9OARRHdHjmBiM2c8c3spmH58wp1l-pAOXk6-7tp7U=.0bb7925e-1ce2-49e5-875e-c336b6c79275@github.com>
 <q_9FfzeL4ex7BPIHiaHr8CvCO9rn73HGSO7-EZg2BPM=.27193380-3989-4303-a1cd-6e278a129ae2@github.com>
Message-ID: <DiAdYmZ6Yw7WxTtY65r7qko2BTzQfuwBePKR-O_r78Q=.a2134c12-09bf-4188-8988-9788b29c53ed@github.com>

On Tue, 31 Jan 2023 14:55:34 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix broken tests
>
> test/langtools/tools/javac/doctree/DocCommentTester.java line 922:
> 
>> 920:             String s2 = s.trim().replaceFirst("\\.\\s*\\n *@", ".\n@");
>> 921:             StringBuilder sb = new StringBuilder();
>> 922:             Pattern p = Pattern.compile("(?i)\\{@([a-z][a-z0-9.:-]*)( )?");
> 
> Why is this change necessary? I see it is intended to impact the unknown inline tag in `TagTest.java`, but couldn't the test be written without this change?

Previously, the only tags in which `newline at` was supported were `{@code}` `{@literal}` and  `{@snippet}` ... and this tag predated `{@snippet}` which is the main reason it's not included here.

Now `newline at` is supported in all inline tags, so the scope of this check is broadened accordingly.

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

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

From jjg at openjdk.org  Wed Feb  1 00:17:49 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 1 Feb 2023 00:17:49 GMT
Subject: RFR: JDK-8301201: Allow \n@ inside inline tags using inlineContent
In-Reply-To: <pk8esqauMGhdk2h9hAMySmRYIJv_Kyd5I7CeowC4mc0=.6e82f86b-f2d6-41c0-88ec-ff2066565215@github.com>
References: <Aq9OARRHdHjmBiM2c8c3spmH58wp1l-pAOXk6-7tp7U=.0bb7925e-1ce2-49e5-875e-c336b6c79275@github.com>
 <pk8esqauMGhdk2h9hAMySmRYIJv_Kyd5I7CeowC4mc0=.6e82f86b-f2d6-41c0-88ec-ff2066565215@github.com>
Message-ID: <DNd-sWf_ImsPabedtJAKducmUTKd5Xzg-_Ynv8fLJnw=.28078266-c943-45d5-a0db-a84f0278031d@github.com>

On Tue, 31 Jan 2023 15:28:42 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> There's something wrong with this, several `javac/doctree` tests are failing.

Yes, now fixed. The breakage was obviously due to the change you mentioned above (for `code|literal` tags). The fix in most cases (one exception) was to make the `PrettyChecker` more robust. The one difficult case was a syntactically invalid tag (which was in most ways a reasonable test case) but which led to false positive matches in the `normalize` code. For that case, I created a "backdoor" to pass a boolean flag to the `normalize` code by means of an annotation on the test case.  Note that because the test case is only _parsed_ and never _analyzed_, the annotation does not need a declaration, it's enough to have an annotation show up in the AST, where it can be accessed by the `PrettyChecker` code.

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

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

From jjg at openjdk.org  Wed Feb  1 00:39:27 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 1 Feb 2023 00:39:27 GMT
Subject: RFR: JDK-8298405: Support Markdown in the standard doclet [v4]
In-Reply-To: <ltVVuz_1JTacO6uHQATm0UPq7e0PmZpqDkVUepejnDY=.2650c47e-737f-46f6-936b-47cab371b848@github.com>
References: <ltVVuz_1JTacO6uHQATm0UPq7e0PmZpqDkVUepejnDY=.2650c47e-737f-46f6-936b-47cab371b848@github.com>
Message-ID: <TdE4xK_J9cb_9Rqz3CydKgmfxkPA6uAhlpQ8V5hB040=.05143b19-158c-4ba6-b0b6-5584234f01d8@github.com>

> Support for Markdown comments in the standard doclet.
> 
> To enable Markdown in a comment, start the comment with `/**md` followed by whitespace.  The syntax is as defined for CommonMark.
> 
> The work is in 3 parts:
> 
> 1. Update the Compiler Tree API to support Markdown tree nodes, containing strings of (uninterpreted) Markdown source code.
> 2. Import commonmark-java into the `jdk.javadoc` module, to be able to convert Markdown strings to HTML.
> 3. Update the standard doclet, to leverage the preceding two parts, to translate Markdown in documentation comments to `Content` nodes.
> 
> There are new tests both for the low level work in the Compiler Tree API, and for the overall high-level work in the doclet.
> 
> Background info: https://mail.openjdk.org/pipermail/javadoc-dev/2023-January/005563.html

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

  Rename MarkdownTree to RawTextTree

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11701/files
  - new: https://git.openjdk.org/jdk/pull/11701/files/3f45c988..432ae0b9

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

  Stats: 408 lines in 17 files changed: 172 ins; 144 del; 92 mod
  Patch: https://git.openjdk.org/jdk/pull/11701.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11701/head:pull/11701

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

From vromero at openjdk.org  Wed Feb  1 05:40:11 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 1 Feb 2023 05:40:11 GMT
Subject: RFR: 8296010: AssertionError in annotationTargetType [v3]
In-Reply-To: <DvQdjvJhItRaHF_AkTkzwM7yvZ4DUvuahgM2a9C1LHQ=.c23bb346-eed7-4d54-99b5-42969bc55ccf@github.com>
References: <DvQdjvJhItRaHF_AkTkzwM7yvZ4DUvuahgM2a9C1LHQ=.c23bb346-eed7-4d54-99b5-42969bc55ccf@github.com>
Message-ID: <Q5JyElu1FpGCoeJfnt5h8q9y9SwGMZnehfk9F9H5D-I=.75eab984-b851-4c81-b724-6bfd01e0d9ef@github.com>

> javac is crashing if a class file is forged so that an annotation can be applicable to an unknown target. It would be equivalent to the following declaration:
> 
> 
> @Target({ElementType.FIELD, ElementType.NO_SUCH})
> @interface A {}
> 
> if the compiler process this source it would issue a compiler error, indicating that symbol `NO_SUCH` cant be found. Currently our class reader just issues a warning and move on. This is OK as it could be that the loaded class won't be used anyway but if this annotation is actually applied to symbol as in:
> 
> 
> class B {
>     @A Object o;
> }
> 
> then this to my understanding should be a compilation error. Currently javac is crashing and this is not acceptable, so this PR is fixing this issue so that a compilation error is issued instead.

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

 - Merge branch 'JDK-8296010' of https://github.com/vicente-romero-oracle/jdk into JDK-8296010
 - updating parameter name

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12241/files
  - new: https://git.openjdk.org/jdk/pull/12241/files/59a6f3c1..e2f234bd

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

  Stats: 142 lines in 6 files changed: 102 ins; 1 del; 39 mod
  Patch: https://git.openjdk.org/jdk/pull/12241.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12241/head:pull/12241

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

From duke at openjdk.org  Wed Feb  1 06:44:54 2023
From: duke at openjdk.org (Wim Deblauwe)
Date: Wed, 1 Feb 2023 06:44:54 GMT
Subject: RFR: JDK-8298405: Support Markdown in the standard doclet [v2]
In-Reply-To: <2bFoIv0Kj1LGy3YGyZGQNQVJ0Ue8Y-26B7oyZoqnjH8=.4e68efb1-f6d8-42c3-abf0-881b872886e2@github.com>
References: <ltVVuz_1JTacO6uHQATm0UPq7e0PmZpqDkVUepejnDY=.2650c47e-737f-46f6-936b-47cab371b848@github.com>
 <2bFoIv0Kj1LGy3YGyZGQNQVJ0Ue8Y-26B7oyZoqnjH8=.4e68efb1-f6d8-42c3-abf0-881b872886e2@github.com>
Message-ID: <ojc28C8ocX8-Bl8G9YpkuaD2el00tjBhWEaShMd6bbk=.946fbab2-e895-4237-808a-9b5fb26d21ee@github.com>

On Mon, 9 Jan 2023 17:44:35 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Support for Markdown comments in the standard doclet.
>> 
>> To enable Markdown in a comment, start the comment with `/**md` followed by whitespace.  The syntax is as defined for CommonMark.
>> 
>> The work is in 3 parts:
>> 
>> 1. Update the Compiler Tree API to support Markdown tree nodes, containing strings of (uninterpreted) Markdown source code.
>> 2. Import commonmark-java into the `jdk.javadoc` module, to be able to convert Markdown strings to HTML.
>> 3. Update the standard doclet, to leverage the preceding two parts, to translate Markdown in documentation comments to `Content` nodes.
>> 
>> There are new tests both for the low level work in the Compiler Tree API, and for the overall high-level work in the doclet.
>> 
>> Background info: https://mail.openjdk.org/pipermail/javadoc-dev/2023-January/005563.html
>
> Jonathan Gibbons has updated the pull request incrementally with five additional commits since the last revision:
> 
>  - Update copyright years
>  - Rename FFFC variable
>    Share Markdown parser and renderer in instance of MarkdownHandler
>  - Move CommonMark to new internal module.
>    Add legal header to imported CommonMark source files
>    Always use Text nodes inside AttributeTree values
>    Unwrap <p> from "simple" paragraphs
>  - Always use Text nodes inside AttributeTree values
>  - Update to CommonMark 0.21.

Is the work here done in a way that asciidoc ( https://docs.asciidoctor.org/ ) support is also possible?

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

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

From duke at openjdk.org  Wed Feb  1 06:44:54 2023
From: duke at openjdk.org (Wim Deblauwe)
Date: Wed, 1 Feb 2023 06:44:54 GMT
Subject: RFR: JDK-8298405: Support Markdown in the standard doclet [v2]
In-Reply-To: <ojc28C8ocX8-Bl8G9YpkuaD2el00tjBhWEaShMd6bbk=.946fbab2-e895-4237-808a-9b5fb26d21ee@github.com>
References: <ltVVuz_1JTacO6uHQATm0UPq7e0PmZpqDkVUepejnDY=.2650c47e-737f-46f6-936b-47cab371b848@github.com>
 <2bFoIv0Kj1LGy3YGyZGQNQVJ0Ue8Y-26B7oyZoqnjH8=.4e68efb1-f6d8-42c3-abf0-881b872886e2@github.com>
 <ojc28C8ocX8-Bl8G9YpkuaD2el00tjBhWEaShMd6bbk=.946fbab2-e895-4237-808a-9b5fb26d21ee@github.com>
Message-ID: <NRMUji12tuTuW7bc64PjIqT9ddxOaHPUE_iumPXq0Tc=.450fa62c-5ad2-4c22-b1f8-7f3dcd0e51d4@github.com>

On Sat, 21 Jan 2023 11:55:15 GMT, Wim Deblauwe <duke at openjdk.org> wrote:

>> Jonathan Gibbons has updated the pull request incrementally with five additional commits since the last revision:
>> 
>>  - Update copyright years
>>  - Rename FFFC variable
>>    Share Markdown parser and renderer in instance of MarkdownHandler
>>  - Move CommonMark to new internal module.
>>    Add legal header to imported CommonMark source files
>>    Always use Text nodes inside AttributeTree values
>>    Unwrap <p> from "simple" paragraphs
>>  - Always use Text nodes inside AttributeTree values
>>  - Update to CommonMark 0.21.
>
> Is the work here done in a way that asciidoc ( https://docs.asciidoctor.org/ ) support is also possible?

> @wimdeblauwe, not sure if you've noticed it, but your comment was hidden: [#11701 (comment)](https://github.com/openjdk/jdk/pull/11701#issuecomment-1399237029). To make the comment visible and response possible, consider accepting TOU suggested by the bot. Thanks.

Thanks for letting me know! Should be ok now.

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

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

From jlahoda at openjdk.org  Wed Feb  1 12:07:39 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 1 Feb 2023 12:07:39 GMT
Subject: RFR: 8301580: Error recovery does not clear returnResult
Message-ID: <5pitppiKIdloYWKA9MOQpJWhSlMuKYbMOU4h1sJ-eqQ=.2b7c84f4-227c-4608-b60f-ac0d11a1ed1b@github.com>

Considering code like:

class C {
    void m
    {
        return;
    }
}


`void m` is wrapped in an erroneous tree (which is good), and if/when `Attr` is processing it in `visitErroneous`, it will create a new `Env` to attribute the erroneous part.

But, `Attr` will set a `returnResult` into the `Env`'s info - and that info is shared with the outter `Env`, so there will be a `returnResult` set after `visitErroneous`. `{ return ; }` is interpreted as an initializer, and there should be an error for the `return` there, but this error is missing, due to the set `returnResult`. This will then fail later in `Flow` with an exception:


$ javac -XDshould-stop.at=FLOW -XDdev /tmp/C.java

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

Commit messages:
 - 8301580: Error recovery does not clear returnResult

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

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

From mcimadamore at openjdk.org  Wed Feb  1 13:53:49 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 1 Feb 2023 13:53:49 GMT
Subject: RFR: 8295019: Cannot call a method with a parameter of a local
 class declared in a lambda
In-Reply-To: <RgTl0a5A7X51DERBJaYhKfiOgZmo-qbXUpWbLoZJwd8=.e869c7c9-fed7-478f-a974-f812b44ee277@github.com>
References: <RgTl0a5A7X51DERBJaYhKfiOgZmo-qbXUpWbLoZJwd8=.e869c7c9-fed7-478f-a974-f812b44ee277@github.com>
Message-ID: <vNN3E1L_5J_9Rnjs9LGR9Bx-uPQawA4lb_m3tpgGP8Q=.57111253-f8ef-4803-976d-5b6e29aff04b@github.com>

On Tue, 31 Jan 2023 05:32:28 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Very interesting and, a bit, tricky bug. So the compiler is rejecting code like:
> 
> class LocalClassDeclaredInsideLambdaTest {
>     void run(Runnable r) {}
> 
>     void m() {
>         run(() -> {
>             class C {
>                 static void takeC(C c) {}
>                 static C giveC() {
>                     return null;
>                 }
>             }
>             C.takeC(C.giveC());
>         });
>     }
> }
> 
> with error:
> 
> LocalClassInsideLambda.java:12: error: incompatible types: C cannot be converted to C
>             C.takeC(C.giveC());
>                            ^
> Note: Some messages have been simplified; recompile with -Xdiags:verbose to get full output
> 1 error
> 
> which is very misleading as the type seems to be the same. The issue here is that both the lambda and invocation `C.giveC()` are considered poly expressions. `C.giveC()` is not a poly expression but at the moment the compiler is analyzing if an invocation is a poly expression or not, it doesn't have enough information and errs on the safe side.
> 
> We have a cache at `com.sun.tools.javac.comp.ArgumentAttr`, see field `argumentTypeCache`, which stores the current deferred type of arguments considered poly expressions. The problem with this particular code is that inside of the lambda there is a class declaration and every time the lambda is attributed a new class type is created.
> 
> The lambda, and thus the expression `C.giveC()` are attributed twice. The first time we have an speculative attribution, as a result `argumentTypeCache` will have two entries, one for the lambda and one for `C.giveC()` but the type of `C` is the type created during speculative attribution on a copy of the original lambda tree, let's call it C1. Later on another pass the lambda is attributed `"for real"`, during the check phase. At this point the entry for the lambda in the cache pointed by `argumentTypeCache` has been removed but there is still the entry for `C.giveC()` which still refers to `C1`. So now in the `"for real"` attribution of the lambda which happens on the original tree, not in a copy, a new type for class `C` is created, let's call it `C2`. But when we get to the point where we need to attribute again `C.takeC(C.giveC())` invocation `C.takeC` is expecting `C2` but as `C.giveC()` is again considered a poly expression and an entry is found for it at the cache, the comp
 iler reuses that entry which refers to `C1`. And unfortunately `C1 != C2` and thus the error is issued. So the solution I propose is to use a local cache for the speculative attribution of lambda expressions. This is a one liner fix, although an alternative solution could be to scan the lambda body and only use a local cache if a new type is defined inside the lambda, this could be a more optimal solution performance wise as we could save some attributions in some cases. Comments?
> 
> TIA

I think the fix looks sensible. Browsing the `ArgumentAttr` code it also seems that the same strategy is used for checking the receiver expression of a method reference - so in that case we would also attribute multiple times.

IIRC, the cache is mostly used to save the speculative attribution results so that we don't need to re-check again when we're outside the speculative mode. E.g. if an explicit lambda is passed to an overloaded method, it is still checked only once (e.g. not one time per overload candidate). But, with this fix, if the lambda is nested deeper in a method call chain, it will be checked multiple times.

One thing that strikes my in your analysis is that we drop the cached entry for the lambda, but we don't drop the entry for the method call, even though the method call is "nested" inside the lambda. That seems like a potential angle to attack this.

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

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

From vromero at openjdk.org  Wed Feb  1 14:06:15 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 1 Feb 2023 14:06:15 GMT
Subject: RFR: 8296010: AssertionError in annotationTargetType [v4]
In-Reply-To: <DvQdjvJhItRaHF_AkTkzwM7yvZ4DUvuahgM2a9C1LHQ=.c23bb346-eed7-4d54-99b5-42969bc55ccf@github.com>
References: <DvQdjvJhItRaHF_AkTkzwM7yvZ4DUvuahgM2a9C1LHQ=.c23bb346-eed7-4d54-99b5-42969bc55ccf@github.com>
Message-ID: <C9bLN17IiFg9JJayGFja9yLqhGwDMLYAAYlyAF0HThI=.3c72c3ee-f98c-4e86-929c-ef29417a22c4@github.com>

> javac is crashing if a class file is forged so that an annotation can be applicable to an unknown target. It would be equivalent to the following declaration:
> 
> 
> @Target({ElementType.FIELD, ElementType.NO_SUCH})
> @interface A {}
> 
> if the compiler process this source it would issue a compiler error, indicating that symbol `NO_SUCH` cant be found. Currently our class reader just issues a warning and move on. This is OK as it could be that the loaded class won't be used anyway but if this annotation is actually applied to symbol as in:
> 
> 
> class B {
>     @A Object o;
> }
> 
> then this to my understanding should be a compilation error. Currently javac is crashing and this is not acceptable, so this PR is fixing this issue so that a compilation error is issued instead.

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

  minor update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12241/files
  - new: https://git.openjdk.org/jdk/pull/12241/files/e2f234bd..80014873

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

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

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

From hannesw at openjdk.org  Wed Feb  1 16:43:51 2023
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Wed, 1 Feb 2023 16:43:51 GMT
Subject: RFR: JDK-8301201: Allow \n@ inside inline tags using inlineContent
 [v2]
In-Reply-To: <2ywtOGpJGOOjYvNWp3xLX9jwK-bgaTnZAamZicv34Jw=.748a2509-f127-49cb-83df-939353b9ccf9@github.com>
References: <Aq9OARRHdHjmBiM2c8c3spmH58wp1l-pAOXk6-7tp7U=.0bb7925e-1ce2-49e5-875e-c336b6c79275@github.com>
 <2ywtOGpJGOOjYvNWp3xLX9jwK-bgaTnZAamZicv34Jw=.748a2509-f127-49cb-83df-939353b9ccf9@github.com>
Message-ID: <MEO4LXuu3y9Sx286CBmeJsi69alQbm8Wi_1pALBpTjE=.0eed177f-8983-4c59-80c0-7f5dfc4d5800@github.com>

On Wed, 1 Feb 2023 00:01:17 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a simple change to allow the use of _newline_ _whitespace_ `@` inside inline tags that allow rich content (that is, those parsed with `inlineContent`) as compared to those that only allow plain text (that is, those parsed with `inlineText`).
>> 
>> The fix is to delete the code which recognizes `@` as the beginning of a block tag. Compare to the similar fix in [JDK-8241780](https://bugs.openjdk.org/browse/JDK-8241780)
>> 
>> The general `TagTest.java` is updated for the new feature.
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix broken tests

Thanks for the extended comment for the `normalize` method. Looks good to me.

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

Marked as reviewed by hannesw (Reviewer).

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

From jjg at openjdk.org  Wed Feb  1 18:32:18 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 1 Feb 2023 18:32:18 GMT
Subject: RFR: JDK-8301201: Allow \n@ inside inline tags using inlineContent
In-Reply-To: <pk8esqauMGhdk2h9hAMySmRYIJv_Kyd5I7CeowC4mc0=.6e82f86b-f2d6-41c0-88ec-ff2066565215@github.com>
References: <Aq9OARRHdHjmBiM2c8c3spmH58wp1l-pAOXk6-7tp7U=.0bb7925e-1ce2-49e5-875e-c336b6c79275@github.com>
 <pk8esqauMGhdk2h9hAMySmRYIJv_Kyd5I7CeowC4mc0=.6e82f86b-f2d6-41c0-88ec-ff2066565215@github.com>
Message-ID: <WrNA36aSvtR23ChuKziPNQavVoH5lIKUn-kPq6Q2JC4=.2f3f8d8a-46c1-4898-8034-fd99172480e5@github.com>

On Tue, 31 Jan 2023 15:28:42 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> Please review a simple change to allow the use of _newline_ _whitespace_ `@` inside inline tags that allow rich content (that is, those parsed with `inlineContent`) as compared to those that only allow plain text (that is, those parsed with `inlineText`).
>> 
>> The fix is to delete the code which recognizes `@` as the beginning of a block tag. Compare to the similar fix in [JDK-8241780](https://bugs.openjdk.org/browse/JDK-8241780)
>> 
>> The general `TagTest.java` is updated for the new feature.
>
> There's something wrong with this, several `javac/doctree` tests are failing.

@hns Thanks for the reviews.

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

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

From jjg at openjdk.org  Wed Feb  1 18:32:21 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 1 Feb 2023 18:32:21 GMT
Subject: Integrated: JDK-8301201: Allow \n@ inside inline tags using
 inlineContent
In-Reply-To: <Aq9OARRHdHjmBiM2c8c3spmH58wp1l-pAOXk6-7tp7U=.0bb7925e-1ce2-49e5-875e-c336b6c79275@github.com>
References: <Aq9OARRHdHjmBiM2c8c3spmH58wp1l-pAOXk6-7tp7U=.0bb7925e-1ce2-49e5-875e-c336b6c79275@github.com>
Message-ID: <WcQx-NhTxX8xHOcqMI5OoBj8v0e_U4xEaUC7Fja230A=.fed4634c-e76c-495b-93a4-de1711036068@github.com>

On Fri, 27 Jan 2023 18:41:45 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a simple change to allow the use of _newline_ _whitespace_ `@` inside inline tags that allow rich content (that is, those parsed with `inlineContent`) as compared to those that only allow plain text (that is, those parsed with `inlineText`).
> 
> The fix is to delete the code which recognizes `@` as the beginning of a block tag. Compare to the similar fix in [JDK-8241780](https://bugs.openjdk.org/browse/JDK-8241780)
> 
> The general `TagTest.java` is updated for the new feature.

This pull request has now been integrated.

Changeset: 24ff3da0
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/24ff3da0543dc9e4c20594a7ff19e4b9eb1a6a1f
Stats:     78 lines in 4 files changed: 54 ins; 8 del; 16 mod

8301201: Allow \n@ inside inline tags using inlineContent

Reviewed-by: hannesw

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

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

From jjg at openjdk.org  Wed Feb  1 19:24:47 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 1 Feb 2023 19:24:47 GMT
Subject: RFR: JDK-8301294: Allow `@` as an escape in documentation comments
Message-ID: <FuwqJLq_p2KGjWFYjms8z_Qvxbov1wlBFdgWDArxCb8=.b017e75e-2994-474c-b1cd-b1335ad1f274@github.com>

Please review a moderately simple update to permit the use of `@` as the escape character in a limited set of escape sequences.

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

Commit messages:
 - JDK-8301294: Allow `@` as an escape in documentation comments

Changes: https://git.openjdk.org/jdk/pull/12372/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12372&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8301294
  Stats: 384 lines in 18 files changed: 351 ins; 6 del; 27 mod
  Patch: https://git.openjdk.org/jdk/pull/12372.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12372/head:pull/12372

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

From jjg at openjdk.org  Wed Feb  1 19:43:00 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 1 Feb 2023 19:43:00 GMT
Subject: RFR: JDK-8300914: Allow `@` as an escape in documentation comments
 [v2]
In-Reply-To: <FuwqJLq_p2KGjWFYjms8z_Qvxbov1wlBFdgWDArxCb8=.b017e75e-2994-474c-b1cd-b1335ad1f274@github.com>
References: <FuwqJLq_p2KGjWFYjms8z_Qvxbov1wlBFdgWDArxCb8=.b017e75e-2994-474c-b1cd-b1335ad1f274@github.com>
Message-ID: <RMF0PaxzTeajAlAwtxmkogS__ZlDPL6m5ZoUN68kun8=.ec26d109-b4ca-4b7c-b0d8-74ac3c71ef2a@github.com>

> Please review a moderately simple update to permit the use of `@` as the escape character in a limited set of escape sequences.

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

 - Merge with upstream/master
 - JDK-8301294: Allow `@` as an escape in documentation comments

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

Changes: https://git.openjdk.org/jdk/pull/12372/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12372&range=01
  Stats: 385 lines in 18 files changed: 356 ins; 6 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/12372.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12372/head:pull/12372

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

From archie.cobbs at gmail.com  Wed Feb  1 20:45:04 2023
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Wed, 1 Feb 2023 14:45:04 -0600
Subject: Type parameters inside super() calls?
Message-ID: <CANSoFxtsXsUxy1Xr5K8KGOSNd8-gOkJoWzAyx0WngOBgxSAsZw@mail.gmail.com>

This program compiles without error:

import java.util.concurrent.atomic.*;
public class TypeParamStaticContext<T> extends AtomicReference<T> {
    public TypeParamStaticContext(Object obj) {
        super((T)obj);
    }
}

Yet according to my reading of the JLS, the appearance of T inside the
super() call should be disallowed:

?8.8.7.1:

An explicit constructor invocation statement introduces a static context (
?8.1.3
<https://docs.oracle.com/javase/specs/jls/se19/html/jls-8.html#jls-8.1.3>),
which limits the use of constructs that refer to the current object.
Notably, the keywords this and super are prohibited in a static context (
?15.8.3
<https://docs.oracle.com/javase/specs/jls/se19/html/jls-15.html#jls-15.8.3>,
?15.11.2
<https://docs.oracle.com/javase/specs/jls/se19/html/jls-15.html#jls-15.11.2>),
as are unqualified references to instance variables, instance methods, and type
parameters of lexically enclosing declarations (?6.5.5.1
<https://docs.oracle.com/javase/specs/jls/se19/html/jls-6.html#jls-6.5.5.1>,
?6.5.6.1
<https://docs.oracle.com/javase/specs/jls/se19/html/jls-6.html#jls-6.5.6.1>,
?15.12.3
<https://docs.oracle.com/javase/specs/jls/se19/html/jls-15.html#jls-15.12.3>).


?6.5.5.1:

If a type name consists of a single *Identifier*, then the identifier must
occur in the scope of exactly one declaration of a class, interface, or
type parameter with this name (?6.3
<https://docs.oracle.com/javase/specs/jls/se19/html/jls-6.html#jls-6.3>),
or a compile-time error occurs.

If the declaration denotes a type parameter of a generic class or interface
C (?8.1.2
<https://docs.oracle.com/javase/specs/jls/se19/html/jls-8.html#jls-8.1.2>,
?9.1.2
<https://docs.oracle.com/javase/specs/jls/se19/html/jls-9.html#jls-9.1.2>),
then both of the following must be true, or a compile-time error occurs:

   -

   The type name does not occur in a static context (?8.1.3
   <https://docs.oracle.com/javase/specs/jls/se19/html/jls-8.html#jls-8.1.3>
   )
   -

   If the type name appears in a nested class or interface declaration of C,
   then the immediately enclosing class or interface declaration of the type
   name is an inner class of C.


What am I missing?

Thanks,
-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230201/01f23400/attachment.htm>

From jjg at openjdk.org  Wed Feb  1 21:21:52 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 1 Feb 2023 21:21:52 GMT
Subject: RFR: JDK-8301636: Minor cleanup in CommentHelper and DocPretty
Message-ID: <MIsQ48OrPq1EozZ6Gr_gksWKxRzL0MyoqDzOfjUPB08=.798b18ff-87ad-4d9f-8203-b46f02aaaa05@github.com>

Please review some simple cleanup suggested by IntelliJ IDEA that would be too much of a distraction in an otherwise unrelated PR.

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

Commit messages:
 - JDK-8301636: Minor cleanup in CommentHelper and DocPretty

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

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

From jjg at openjdk.org  Wed Feb  1 21:21:53 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 1 Feb 2023 21:21:53 GMT
Subject: RFR: JDK-8301636: Minor cleanup in CommentHelper and DocPretty
In-Reply-To: <MIsQ48OrPq1EozZ6Gr_gksWKxRzL0MyoqDzOfjUPB08=.798b18ff-87ad-4d9f-8203-b46f02aaaa05@github.com>
References: <MIsQ48OrPq1EozZ6Gr_gksWKxRzL0MyoqDzOfjUPB08=.798b18ff-87ad-4d9f-8203-b46f02aaaa05@github.com>
Message-ID: <Ho6PY6CCIe2uCBGAYkRJleoPuSKmScCZ6X0aN5-mdjc=.23c61c93-6ca3-4c2f-927d-1d21e6cc8e1f@github.com>

On Wed, 1 Feb 2023 21:14:42 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review some simple cleanup suggested by IntelliJ IDEA that would be too much of a distraction in an otherwise unrelated PR.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/CommentHelper.java line 159:

> 157:     }
> 158: 
> 159:     public TypeElement getReferencedClass(Element e) {

For what it's worth, I dislike the remaining `getReferenced`_Thing_ methods remaining in this class, since they are just null-safe wrappers around methods in `Utils` that are just wrappers for code in `java.lang.model`. But that's another more-manual cleanup for another day.

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

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

From prappo at openjdk.org  Wed Feb  1 22:16:22 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 1 Feb 2023 22:16:22 GMT
Subject: RFR: JDK-8301636: Minor cleanup in CommentHelper and DocPretty
In-Reply-To: <MIsQ48OrPq1EozZ6Gr_gksWKxRzL0MyoqDzOfjUPB08=.798b18ff-87ad-4d9f-8203-b46f02aaaa05@github.com>
References: <MIsQ48OrPq1EozZ6Gr_gksWKxRzL0MyoqDzOfjUPB08=.798b18ff-87ad-4d9f-8203-b46f02aaaa05@github.com>
Message-ID: <3oEeIBY55dKJY_V6ji2B_g5JDxkBoCVxmdGOSQTNCuY=.4ea97960-17ab-4447-8b85-3ab2c0db43db@github.com>

On Wed, 1 Feb 2023 21:14:42 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review some simple cleanup suggested by IntelliJ IDEA that would be too much of a distraction in an otherwise unrelated PR.

Looks good (assuming tests pass).

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

Marked as reviewed by prappo (Reviewer).

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

From alex.buckley at oracle.com  Wed Feb  1 22:39:35 2023
From: alex.buckley at oracle.com (Alex Buckley)
Date: Wed, 1 Feb 2023 14:39:35 -0800
Subject: Type parameters inside super() calls?
In-Reply-To: <CANSoFxtsXsUxy1Xr5K8KGOSNd8-gOkJoWzAyx0WngOBgxSAsZw@mail.gmail.com>
References: <CANSoFxtsXsUxy1Xr5K8KGOSNd8-gOkJoWzAyx0WngOBgxSAsZw@mail.gmail.com>
Message-ID: <21690dfc-9970-d1c8-a3ee-cb655d27f10a@oracle.com>

Your reading of the JLS is correct. The cast expression `(T)obj` occurs 
in a static context, so the use of T should be disallowed, and javac 
should reject the program.

These rules in 8.8.7.1 and 8.1.3 are longstanding, and have not changed 
recently, so I'm surprised that javac lets the program through. That 
said, JLS16 saw a reworking of 8.1.3 (driven by 
https://openjdk.org/jeps/395#Static-members-of-inner-classes) and 
perhaps javac got a bit turned around over static contexts.

As an additional test case, make the constructor generic -- `public <U 
extends T> TypeParam ...` -- and cast obj to U rather than T -- still 
illegal.

Alex

On 2/1/2023 12:45 PM, Archie Cobbs wrote:
> This program compiles without error:
> 
> import java.util.concurrent.atomic.*;
> public class TypeParamStaticContext<T> extends AtomicReference<T> {
>  ? ? public TypeParamStaticContext(Object obj) {
>  ? ? ? ? super((T)obj);
>  ? ? }
> }
> 
> Yet according to my reading of the JLS, the appearance of T inside the 
> super() call should be disallowed:
> 
> ?8.8.7.1 <http://8.8.7.1>:
> 
> An explicit constructor invocation statement introduces a static context 
> (?8.1.3 
> <https://docs.oracle.com/javase/specs/jls/se19/html/jls-8.html#jls-8.1.3>), which limits the use of constructs that refer to the current object. Notably, the keywords |this| and |super| are prohibited in a static context (?15.8.3 <https://docs.oracle.com/javase/specs/jls/se19/html/jls-15.html#jls-15.8.3>, ?15.11.2 <https://docs.oracle.com/javase/specs/jls/se19/html/jls-15.html#jls-15.11.2>), as are unqualified references to instance variables, instance methods, and type parameters of lexically enclosing declarations (?6.5.5.1 <https://docs.oracle.com/javase/specs/jls/se19/html/jls-6.html#jls-6.5.5.1>, ?6.5.6.1 <https://docs.oracle.com/javase/specs/jls/se19/html/jls-6.html#jls-6.5.6.1>, ?15.12.3 <https://docs.oracle.com/javase/specs/jls/se19/html/jls-15.html#jls-15.12.3>).
> 
> ?6.5.5.1 <http://6.5.5.1>:
> 
> If a type name consists of a single /Identifier/, then the identifier 
> must occur in the scope of exactly one declaration of a class, 
> interface, or type parameter with this name (?6.3 
> <https://docs.oracle.com/javase/specs/jls/se19/html/jls-6.html#jls-6.3>), or a compile-time error occurs.
> 
> If the declaration denotes a type parameter of a generic class or 
> interface C (?8.1.2 
> <https://docs.oracle.com/javase/specs/jls/se19/html/jls-8.html#jls-8.1.2>, ?9.1.2 <https://docs.oracle.com/javase/specs/jls/se19/html/jls-9.html#jls-9.1.2>), then both of the following must be true, or a compile-time error occurs:
> 
>   *
> 
>     The type name does not occur in a static context (?8.1.3
>     <https://docs.oracle.com/javase/specs/jls/se19/html/jls-8.html#jls-8.1.3>)
> 
>   *
> 
>     If the type name appears in a nested class or interface declaration
>     of C, then the immediately enclosing class or interface declaration
>     of the type name is an inner class of C.
> 
> 
> What am I missing?
> 
> Thanks,
> -Archie
> 
> -- 
> Archie L. Cobbs

From archie.cobbs at gmail.com  Wed Feb  1 22:55:12 2023
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Wed, 1 Feb 2023 16:55:12 -0600
Subject: Type parameters inside super() calls?
In-Reply-To: <21690dfc-9970-d1c8-a3ee-cb655d27f10a@oracle.com>
References: <CANSoFxtsXsUxy1Xr5K8KGOSNd8-gOkJoWzAyx0WngOBgxSAsZw@mail.gmail.com>
 <21690dfc-9970-d1c8-a3ee-cb655d27f10a@oracle.com>
Message-ID: <CANSoFxtBO9dzYkLjMFTywQMdyyQsNF+wxho3BL5a52pkd8-vtw@mail.gmail.com>

On Wed, Feb 1, 2023 at 4:40 PM Alex Buckley <alex.buckley at oracle.com> wrote:

> Your reading of the JLS is correct. The cast expression `(T)obj` occurs
> in a static context, so the use of T should be disallowed, and javac
> should reject the program.
>

Thanks. Filed as JDK-8301649 <https://bugs.openjdk.org/browse/JDK-8301649>.

-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230201/e529d14e/attachment.htm>

From forax at univ-mlv.fr  Wed Feb  1 22:59:36 2023
From: forax at univ-mlv.fr (Remi Forax)
Date: Wed, 1 Feb 2023 23:59:36 +0100 (CET)
Subject: Calling the constructor of a capturing local class in a static
 context throws a NPE
In-Reply-To: <601349861.68993242.1671369939583.JavaMail.zimbra@u-pem.fr>
References: <601349861.68993242.1671369939583.JavaMail.zimbra@u-pem.fr>
Message-ID: <2137493422.10524748.1675292376536.JavaMail.zimbra@u-pem.fr>

ping !

----- Original Message -----
> From: "Remi Forax" <forax at univ-mlv.fr>
> To: "compiler-dev" <compiler-dev at openjdk.org>
> Sent: Sunday, December 18, 2022 2:25:39 PM
> Subject: Calling the constructor of a capturing local class in a static context throws a NPE

> Hi everybody,
> a Christmas bug :)
> 
> public class StaticFieldInsideCapturingLocalClass {
>  public static void test(int value) {
>    class Foo {
>      private static final Foo FOO = new Foo();
> 
>      public void m() {
>        System.out.println(value);
>      }
>    }
>    Foo.FOO.m();
>  }
> }
> 
> For me, "new Foo()" should not be allowed in a static context given that Foo
> capture the local variable "value".
> 
> I was able to reproduce the issue with Java 16, 17, 19 and 20 but not with Java
> 11 and 15.
> This bug seems to have been introduced in Java 16 when Java starts to allow
> static final field in local class.
> 
> 
> ~/jdk/jdk-20-valhalla.jdk/Contents/Home/bin/javac
> StaticFieldInsideCapturingLocalClass.java
> An exception has occurred in the compiler (20-valhalla). Please file a bug
> against the Java compiler via the Java bug reporting page
> (https://bugreport.java.com) after checking the Bug Database
> (https://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[0]"
> is null
>        at jdk.compiler/com.sun.tools.javac.jvm.Code.emitop0(Code.java:570)
>        at jdk.compiler/com.sun.tools.javac.jvm.Items$SelfItem.load(Items.java:369)
>        at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitIdent(Gen.java:2354)
>        at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCIdent.accept(JCTree.java:2735)
>        at jdk.compiler/com.sun.tools.javac.jvm.Gen.genExpr(Gen.java:902)
>        at jdk.compiler/com.sun.tools.javac.jvm.Gen.genArgs(Gen.java:927)
>        at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitNewClass(Gen.java:2031)
>        at
>        jdk.compiler/com.sun.tools.javac.tree.JCTree$JCNewClass.accept(JCTree.java:1925)
>        at jdk.compiler/com.sun.tools.javac.jvm.Gen.genExpr(Gen.java:902)
>        at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitAssign(Gen.java:2087)
>        at
>        jdk.compiler/com.sun.tools.javac.tree.JCTree$JCAssign.accept(JCTree.java:2114)
>        at jdk.compiler/com.sun.tools.javac.jvm.Gen.genExpr(Gen.java:902)
>        at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitExec(Gen.java:1812)
>        at
>        jdk.compiler/com.sun.tools.javac.tree.JCTree$JCExpressionStatement.accept(JCTree.java:1657)
>        at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:631)
>        at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:666)
>        at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:652)
>        at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStats(Gen.java:703)
>        at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitBlock(Gen.java:1130)
>        at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:1097)
>        at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:631)
>        at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:666)
>        at jdk.compiler/com.sun.tools.javac.jvm.Gen.genMethod(Gen.java:992)
>        at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitMethodDef(Gen.java:955)
>        at
>        jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:923)
>        at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:631)
>        at jdk.compiler/com.sun.tools.javac.jvm.Gen.genClass(Gen.java:2505)
>        at
>        jdk.compiler/com.sun.tools.javac.main.JavaCompiler.genCode(JavaCompiler.java:738)
>        at
>        jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1636)
>        at
>        jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1604)
>        at
>        jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:947)
>        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)
> 
> happy Christmas,
> R?mi

From prappo at openjdk.org  Wed Feb  1 23:41:28 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 1 Feb 2023 23:41:28 GMT
Subject: RFR: JDK-8300914: Allow `@` as an escape in documentation comments
 [v2]
In-Reply-To: <RMF0PaxzTeajAlAwtxmkogS__ZlDPL6m5ZoUN68kun8=.ec26d109-b4ca-4b7c-b0d8-74ac3c71ef2a@github.com>
References: <FuwqJLq_p2KGjWFYjms8z_Qvxbov1wlBFdgWDArxCb8=.b017e75e-2994-474c-b1cd-b1335ad1f274@github.com>
 <RMF0PaxzTeajAlAwtxmkogS__ZlDPL6m5ZoUN68kun8=.ec26d109-b4ca-4b7c-b0d8-74ac3c71ef2a@github.com>
Message-ID: <8_sn3KytEC8oZf7krphnqREsrEvupP3iIlOZTST-5FQ=.e631623b-cd9d-49be-8796-b13d89227ddb@github.com>

On Wed, 1 Feb 2023 19:43:00 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a moderately simple update to permit the use of `@` as the escape character in a limited set of escape sequences.
>
> Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge with upstream/master
>  - JDK-8301294: Allow `@` as an escape in documentation comments

Below are my initial comments on the API; I'll have a look at the implementation soon.

src/jdk.compiler/share/classes/com/sun/source/doctree/DocTree.java line 110:

> 108:          * representing some escaped documentation text.
> 109:          */
> 110:         ESCAPE,

We seem to add `@since` to newer kinds of tags.

src/jdk.compiler/share/classes/com/sun/source/doctree/EscapeTree.java line 49:

> 47:      *
> 48:      * <p>Note: this method returns the escaped character, not the original escape sequence.
> 49:      *

Remove newline.

src/jdk.compiler/share/classes/com/sun/source/util/DocTreeFactory.java line 186:

> 184:      * @since 21
> 185:      */
> 186:     EscapeTree newEscapeTree(char ch);

For the record: I noticed this discrepancy between the `char` parameter here and the `String` return value in `EscapeTree.getBody()` while discussing CSR.

Initially, I thought that we could use `String` for the parameter too, but you provided reasonable arguments why we should keep it `char`.

I once again note that it's weird that `DocTreeFactory` is public API.

src/jdk.compiler/share/classes/com/sun/source/util/DocTreeScanner.java line 296:

> 294:     }
> 295: 
> 296: 

Remove newline.

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

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

From alex.buckley at oracle.com  Wed Feb  1 23:42:56 2023
From: alex.buckley at oracle.com (Alex Buckley)
Date: Wed, 1 Feb 2023 15:42:56 -0800
Subject: [External] : Re: Type parameters inside super() calls?
In-Reply-To: <CANSoFxtBO9dzYkLjMFTywQMdyyQsNF+wxho3BL5a52pkd8-vtw@mail.gmail.com>
References: <CANSoFxtsXsUxy1Xr5K8KGOSNd8-gOkJoWzAyx0WngOBgxSAsZw@mail.gmail.com>
 <21690dfc-9970-d1c8-a3ee-cb655d27f10a@oracle.com>
 <CANSoFxtBO9dzYkLjMFTywQMdyyQsNF+wxho3BL5a52pkd8-vtw@mail.gmail.com>
Message-ID: <cad18d56-3028-568d-55dd-4ac2bbb5ffe7@oracle.com>

// Paging Dan, since 6.5.5.1 was reworked in JLS16.

With regard to the example involving a generic constructor, 8.8.4 is 
clear about what it wants to happen:

   "References to a constructor's type parameter from an explicit 
constructor invocation statement or a nested class or interface are 
restricted, as specified in ?6.5.5.1."

but 6.5.5.1 doesn't actually specify that. It specifies what happens 
when an explicit constructor invocation statement refers to a class's or 
interface's type parameter:

   "If the declaration denotes a type parameter of a generic class or 
interface C (?8.1.2, ?9.1.2), then ..."

And it specifies what happens when a nested class or interface refers to 
a constructor's type parameter:

   "If the declaration denotes a type parameter of a generic method or 
constructor m (?8.4.4, ?8.8.4), and the type name appears directly or 
indirectly in the body of ..., then ..."

But it has nothing to say when an explicit constructor invocation 
statement refers to a constructor's type parameter.

Catching this case is tricky given the current factoring. The flow 
probably needs to be:

-----
If a type name consists of a single Identifier ...

If the declaration denotes a type parameter of a generic class, 
interface, constructor, or method, then the type name must not occur in 
a static context, or a compile-time error occurs.

If the declaration denotes a type parameter of a generic class or 
interface C, and the type name appears in a nested class or interface 
declaration of C, then the immediately enclosing class or interface 
declaration of the type name must be an inner class of C, or a 
compile-time error occurs.

If the declaration denotes a type parameter of a generic method or 
constructor m, and the type name appears directly or indirectly in the 
body of a local class, local interface, or anonymous class D declared 
directly in the body of m, then (i) D must be an inner class, and (ii) 
the immediately enclosing class or interface declaration of the type 
name must be D or an inner class of D, or a compile-time error occurs.
-----

And Example 6.5.5.1-1 should have a couple of constructors for Box<T>, 
one non-generic and performing `super((T)...);`, the other generic in U 
and performing `super((U)...);`.

Alex

On 2/1/2023 2:55 PM, Archie Cobbs wrote:
> On Wed, Feb 1, 2023 at 4:40 PM Alex Buckley <alex.buckley at oracle.com 
> <mailto:alex.buckley at oracle.com>> wrote:
> 
>     Your reading of the JLS is correct. The cast expression `(T)obj` occurs
>     in a static context, so the use of T should be disallowed, and javac
>     should reject the program.
> 
> 
> Thanks. Filed as JDK-8301649 <https://bugs.openjdk.org/browse/JDK-8301649>.
> 
> -Archie
> 
> -- 
> Archie L. Cobbs

From maurizio.cimadamore at oracle.com  Wed Feb  1 23:43:43 2023
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Wed, 1 Feb 2023 23:43:43 +0000
Subject: Type parameters inside super() calls?
In-Reply-To: <21690dfc-9970-d1c8-a3ee-cb655d27f10a@oracle.com>
References: <CANSoFxtsXsUxy1Xr5K8KGOSNd8-gOkJoWzAyx0WngOBgxSAsZw@mail.gmail.com>
 <21690dfc-9970-d1c8-a3ee-cb655d27f10a@oracle.com>
Message-ID: <03b6b91d-d3f9-a551-62cc-1b70c14e121e@oracle.com>

While I agree that what javac does is against the JLS, is this a javac 
or a spec bug?

I mean, consider this hierarchy:

|class Sup<X> { Sup(X x) { ... } } class Sub<Y> extends Sup<Y> { Sub(Y 
y) { super(y); } } |

What the rules are saying is that ?y? in the Sub super call should be 
evaluated in a static context. But that doesn?t make any sense - because 
Y is not even a valid type in such a static context.

And yet - this is a valid program. So, if typechecking ?y? is correct, 
then, surely, typechecking ?(Y)y? should also be correct? E.g. it seems 
to me that the use of ?static context? here is an ?approximation? for 
the behavior we really want (e.g. no access to instance fields, whether 
directly or indirectly).

Maurizio

On 01/02/2023 22:39, Alex Buckley wrote:

> Your reading of the JLS is correct. The cast expression `(T)obj` 
> occurs in a static context, so the use of T should be disallowed, and 
> javac should reject the program.
>
> These rules in 8.8.7.1 and 8.1.3 are longstanding, and have not 
> changed recently, so I'm surprised that javac lets the program 
> through. That said, JLS16 saw a reworking of 8.1.3 (driven by 
> https://openjdk.org/jeps/395#Static-members-of-inner-classes) and 
> perhaps javac got a bit turned around over static contexts.
>
> As an additional test case, make the constructor generic -- `public <U 
> extends T> TypeParam ...` -- and cast obj to U rather than T -- still 
> illegal.
>
> Alex
>
> On 2/1/2023 12:45 PM, Archie Cobbs wrote:
>> This program compiles without error:
>>
>> import java.util.concurrent.atomic.*;
>> public class TypeParamStaticContext<T> extends AtomicReference<T> {
>> ?? ? public TypeParamStaticContext(Object obj) {
>> ?? ? ? ? super((T)obj);
>> ?? ? }
>> }
>>
>> Yet according to my reading of the JLS, the appearance of T inside 
>> the super() call should be disallowed:
>>
>> ?8.8.7.1 <http://8.8.7.1>:
>>
>> An explicit constructor invocation statement introduces a static 
>> context (?8.1.3 
>> <https://docs.oracle.com/javase/specs/jls/se19/html/jls-8.html#jls-8.1.3>), 
>> which limits the use of constructs that refer to the current object. 
>> Notably, the keywords |this| and |super| are prohibited in a static 
>> context (?15.8.3 
>> <https://docs.oracle.com/javase/specs/jls/se19/html/jls-15.html#jls-15.8.3>, 
>> ?15.11.2 
>> <https://docs.oracle.com/javase/specs/jls/se19/html/jls-15.html#jls-15.11.2>), 
>> as are unqualified references to instance variables, instance 
>> methods, and type parameters of lexically enclosing declarations 
>> (?6.5.5.1 
>> <https://docs.oracle.com/javase/specs/jls/se19/html/jls-6.html#jls-6.5.5.1>, 
>> ?6.5.6.1 
>> <https://docs.oracle.com/javase/specs/jls/se19/html/jls-6.html#jls-6.5.6.1>, 
>> ?15.12.3 
>> <https://docs.oracle.com/javase/specs/jls/se19/html/jls-15.html#jls-15.12.3>).
>>
>> ?6.5.5.1 <http://6.5.5.1>:
>>
>> If a type name consists of a single /Identifier/, then the identifier 
>> must occur in the scope of exactly one declaration of a class, 
>> interface, or type parameter with this name (?6.3 
>> <https://docs.oracle.com/javase/specs/jls/se19/html/jls-6.html#jls-6.3>), 
>> or a compile-time error occurs.
>>
>> If the declaration denotes a type parameter of a generic class or 
>> interface C (?8.1.2 
>> <https://docs.oracle.com/javase/specs/jls/se19/html/jls-8.html#jls-8.1.2>, 
>> ?9.1.2 
>> <https://docs.oracle.com/javase/specs/jls/se19/html/jls-9.html#jls-9.1.2>), 
>> then both of the following must be true, or a compile-time error occurs:
>>
>> ? *
>>
>> ??? The type name does not occur in a static context (?8.1.3
>> <https://docs.oracle.com/javase/specs/jls/se19/html/jls-8.html#jls-8.1.3>)
>>
>> ? *
>>
>> ??? If the type name appears in a nested class or interface declaration
>> ??? of C, then the immediately enclosing class or interface declaration
>> ??? of the type name is an inner class of C.
>>
>>
>> What am I missing?
>>
>> Thanks,
>> -Archie
>>
>> -- 
>> Archie L. Cobbs

?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230201/ad718979/attachment-0001.htm>

From vromero at openjdk.org  Wed Feb  1 23:57:59 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 1 Feb 2023 23:57:59 GMT
Subject: RFR: 8295019: Cannot call a method with a parameter of a local
 class declared in a lambda [v2]
In-Reply-To: <RgTl0a5A7X51DERBJaYhKfiOgZmo-qbXUpWbLoZJwd8=.e869c7c9-fed7-478f-a974-f812b44ee277@github.com>
References: <RgTl0a5A7X51DERBJaYhKfiOgZmo-qbXUpWbLoZJwd8=.e869c7c9-fed7-478f-a974-f812b44ee277@github.com>
Message-ID: <OXdmJRiG6RLel5ftRxoM9ehem8iFOGHM8Mq6_llJ4EM=.30bcee8b-2dff-49ae-99ad-6419228db059@github.com>

> Very interesting and, a bit, tricky bug. So the compiler is rejecting code like:
> 
> class LocalClassDeclaredInsideLambdaTest {
>     void run(Runnable r) {}
> 
>     void m() {
>         run(() -> {
>             class C {
>                 static void takeC(C c) {}
>                 static C giveC() {
>                     return null;
>                 }
>             }
>             C.takeC(C.giveC());
>         });
>     }
> }
> 
> with error:
> 
> LocalClassInsideLambda.java:12: error: incompatible types: C cannot be converted to C
>             C.takeC(C.giveC());
>                            ^
> Note: Some messages have been simplified; recompile with -Xdiags:verbose to get full output
> 1 error
> 
> which is very misleading as the type seems to be the same. The issue here is that both the lambda and invocation `C.giveC()` are considered poly expressions. `C.giveC()` is not a poly expression but at the moment the compiler is analyzing if an invocation is a poly expression or not, it doesn't have enough information and errs on the safe side.
> 
> We have a cache at `com.sun.tools.javac.comp.ArgumentAttr`, see field `argumentTypeCache`, which stores the current deferred type of arguments considered poly expressions. The problem with this particular code is that inside of the lambda there is a class declaration and every time the lambda is attributed a new class type is created.
> 
> The lambda, and thus the expression `C.giveC()` are attributed twice. The first time we have an speculative attribution, as a result `argumentTypeCache` will have two entries, one for the lambda and one for `C.giveC()` but the type of `C` is the type created during speculative attribution on a copy of the original lambda tree, let's call it C1. Later on another pass the lambda is attributed `"for real"`, during the check phase. At this point the entry for the lambda in the cache pointed by `argumentTypeCache` has been removed but there is still the entry for `C.giveC()` which still refers to `C1`. So now in the `"for real"` attribution of the lambda which happens on the original tree, not in a copy, a new type for class `C` is created, let's call it `C2`. But when we get to the point where we need to attribute again `C.takeC(C.giveC())` invocation `C.takeC` is expecting `C2` but as `C.giveC()` is again considered a poly expression and an entry is found for it at the cache, the comp
 iler reuses that entry which refers to `C1`. And unfortunately `C1 != C2` and thus the error is issued. So the solution I propose is to use a local cache for the speculative attribution of lambda expressions. This is a one liner fix, although an alternative solution could be to scan the lambda body and only use a local cache if a new type is defined inside the lambda, this could be a more optimal solution performance wise as we could save some attributions in some cases. Comments?
> 
> TIA

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

  some experiments, close to a stable version

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12303/files
  - new: https://git.openjdk.org/jdk/pull/12303/files/66f688a5..9ad514b4

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

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

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

From alex.buckley at oracle.com  Thu Feb  2 00:13:31 2023
From: alex.buckley at oracle.com (Alex Buckley)
Date: Wed, 1 Feb 2023 16:13:31 -0800
Subject: Type parameters inside super() calls?
In-Reply-To: <03b6b91d-d3f9-a551-62cc-1b70c14e121e@oracle.com>
References: <CANSoFxtsXsUxy1Xr5K8KGOSNd8-gOkJoWzAyx0WngOBgxSAsZw@mail.gmail.com>
 <21690dfc-9970-d1c8-a3ee-cb655d27f10a@oracle.com>
 <03b6b91d-d3f9-a551-62cc-1b70c14e121e@oracle.com>
Message-ID: <df3891cf-9d5b-f105-d133-c78d63b7784a@oracle.com>

8.1.3 has a nice note about intent:

   "The purpose of a static context is to demarcate code that must not 
refer explicitly or implicitly to the current instance of the class 
whose declaration lexically encloses the static context. Consequently, 
code that occurs in a static context is restricted in the following 
ways: ..."

Beyond that, I'm not sure what to say, because all of this has been in 
place since Java 1.1.

Alex

On 2/1/2023 3:43 PM, Maurizio Cimadamore wrote:
> While I agree that what javac does is against the JLS, is this a javac 
> or a spec bug?
> 
> I mean, consider this hierarchy:
> 
> |class Sup<X> { Sup(X x) { ... } } class Sub<Y> extends Sup<Y> { Sub(Y 
> y) { super(y); } } |
> 
> What the rules are saying is that ?y? in the Sub super call should be 
> evaluated in a static context. But that doesn?t make any sense - because 
> Y is not even a valid type in such a static context.
> 
> And yet - this is a valid program. So, if typechecking ?y? is correct, 
> then, surely, typechecking ?(Y)y? should also be correct? E.g. it seems 
> to me that the use of ?static context? here is an ?approximation? for 
> the behavior we really want (e.g. no access to instance fields, whether 
> directly or indirectly).
> 
> Maurizio
> 
> On 01/02/2023 22:39, Alex Buckley wrote:
> 
>> Your reading of the JLS is correct. The cast expression `(T)obj` 
>> occurs in a static context, so the use of T should be disallowed, and 
>> javac should reject the program.
>>
>> These rules in 8.8.7.1 and 8.1.3 are longstanding, and have not 
>> changed recently, so I'm surprised that javac lets the program 
>> through. That said, JLS16 saw a reworking of 8.1.3 (driven by 
>> https://openjdk.org/jeps/395#Static-members-of-inner-classes) and 
>> perhaps javac got a bit turned around over static contexts.
>>
>> As an additional test case, make the constructor generic -- `public <U 
>> extends T> TypeParam ...` -- and cast obj to U rather than T -- still 
>> illegal.
>>
>> Alex
>>
>> On 2/1/2023 12:45 PM, Archie Cobbs wrote:
>>> This program compiles without error:
>>>
>>> import java.util.concurrent.atomic.*;
>>> public class TypeParamStaticContext<T> extends AtomicReference<T> {
>>> ?? ? public TypeParamStaticContext(Object obj) {
>>> ?? ? ? ? super((T)obj);
>>> ?? ? }
>>> }
>>>
>>> Yet according to my reading of the JLS, the appearance of T inside 
>>> the super() call should be disallowed:
>>>
>>> ?8.8.7.1 <http://8.8.7.1>:
>>>
>>> An explicit constructor invocation statement introduces a static 
>>> context (?8.1.3 
>>> <https://docs.oracle.com/javase/specs/jls/se19/html/jls-8.html#jls-8.1.3>), which limits the use of constructs that refer to the current object. Notably, the keywords |this| and |super| are prohibited in a static context (?15.8.3 <https://docs.oracle.com/javase/specs/jls/se19/html/jls-15.html#jls-15.8.3>, ?15.11.2 <https://docs.oracle.com/javase/specs/jls/se19/html/jls-15.html#jls-15.11.2>), as are unqualified references to instance variables, instance methods, and type parameters of lexically enclosing declarations (?6.5.5.1 <https://docs.oracle.com/javase/specs/jls/se19/html/jls-6.html#jls-6.5.5.1>, ?6.5.6.1 <https://docs.oracle.com/javase/specs/jls/se19/html/jls-6.html#jls-6.5.6.1>, ?15.12.3 <https://docs.oracle.com/javase/specs/jls/se19/html/jls-15.html#jls-15.12.3>).
>>>
>>> ?6.5.5.1 <http://6.5.5.1>:
>>>
>>> If a type name consists of a single /Identifier/, then the identifier 
>>> must occur in the scope of exactly one declaration of a class, 
>>> interface, or type parameter with this name (?6.3 
>>> <https://docs.oracle.com/javase/specs/jls/se19/html/jls-6.html#jls-6.3>), or a compile-time error occurs.
>>>
>>> If the declaration denotes a type parameter of a generic class or 
>>> interface C (?8.1.2 
>>> <https://docs.oracle.com/javase/specs/jls/se19/html/jls-8.html#jls-8.1.2>, ?9.1.2 <https://docs.oracle.com/javase/specs/jls/se19/html/jls-9.html#jls-9.1.2>), then both of the following must be true, or a compile-time error occurs:
>>>
>>> ? *
>>>
>>> ??? The type name does not occur in a static context (?8.1.3
>>> <https://docs.oracle.com/javase/specs/jls/se19/html/jls-8.html#jls-8.1.3>)
>>>
>>> ? *
>>>
>>> ??? If the type name appears in a nested class or interface declaration
>>> ??? of C, then the immediately enclosing class or interface declaration
>>> ??? of the type name is an inner class of C.
>>>
>>>
>>> What am I missing?
>>>
>>> Thanks,
>>> -Archie
>>>
>>> -- 
>>> Archie L. Cobbs
> 
> ?

From vromero at openjdk.org  Thu Feb  2 00:15:58 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 2 Feb 2023 00:15:58 GMT
Subject: RFR: 8295019: Cannot call a method with a parameter of a local
 class declared in a lambda [v3]
In-Reply-To: <RgTl0a5A7X51DERBJaYhKfiOgZmo-qbXUpWbLoZJwd8=.e869c7c9-fed7-478f-a974-f812b44ee277@github.com>
References: <RgTl0a5A7X51DERBJaYhKfiOgZmo-qbXUpWbLoZJwd8=.e869c7c9-fed7-478f-a974-f812b44ee277@github.com>
Message-ID: <zAk8P6ajLFOo35gSZaSrxOfWJs-475bIQanzOcaiQek=.022a3493-d1b0-4da6-a206-29d4c8eccab8@github.com>

> Very interesting and, a bit, tricky bug. So the compiler is rejecting code like:
> 
> class LocalClassDeclaredInsideLambdaTest {
>     void run(Runnable r) {}
> 
>     void m() {
>         run(() -> {
>             class C {
>                 static void takeC(C c) {}
>                 static C giveC() {
>                     return null;
>                 }
>             }
>             C.takeC(C.giveC());
>         });
>     }
> }
> 
> with error:
> 
> LocalClassInsideLambda.java:12: error: incompatible types: C cannot be converted to C
>             C.takeC(C.giveC());
>                            ^
> Note: Some messages have been simplified; recompile with -Xdiags:verbose to get full output
> 1 error
> 
> which is very misleading as the type seems to be the same. The issue here is that both the lambda and invocation `C.giveC()` are considered poly expressions. `C.giveC()` is not a poly expression but at the moment the compiler is analyzing if an invocation is a poly expression or not, it doesn't have enough information and errs on the safe side.
> 
> We have a cache at `com.sun.tools.javac.comp.ArgumentAttr`, see field `argumentTypeCache`, which stores the current deferred type of arguments considered poly expressions. The problem with this particular code is that inside of the lambda there is a class declaration and every time the lambda is attributed a new class type is created.
> 
> The lambda, and thus the expression `C.giveC()` are attributed twice. The first time we have an speculative attribution, as a result `argumentTypeCache` will have two entries, one for the lambda and one for `C.giveC()` but the type of `C` is the type created during speculative attribution on a copy of the original lambda tree, let's call it C1. Later on another pass the lambda is attributed `"for real"`, during the check phase. At this point the entry for the lambda in the cache pointed by `argumentTypeCache` has been removed but there is still the entry for `C.giveC()` which still refers to `C1`. So now in the `"for real"` attribution of the lambda which happens on the original tree, not in a copy, a new type for class `C` is created, let's call it `C2`. But when we get to the point where we need to attribute again `C.takeC(C.giveC())` invocation `C.takeC` is expecting `C2` but as `C.giveC()` is again considered a poly expression and an entry is found for it at the cache, the comp
 iler reuses that entry which refers to `C1`. And unfortunately `C1 != C2` and thus the error is issued. So the solution I propose is to use a local cache for the speculative attribution of lambda expressions. This is a one liner fix, although an alternative solution could be to scan the lambda body and only use a local cache if a new type is defined inside the lambda, this could be a more optimal solution performance wise as we could save some attributions in some cases. Comments?
> 
> TIA

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

  adding a comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12303/files
  - new: https://git.openjdk.org/jdk/pull/12303/files/9ad514b4..f0a298da

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

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

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

From mcimadamore at openjdk.org  Thu Feb  2 00:25:25 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 2 Feb 2023 00:25:25 GMT
Subject: RFR: 8295019: Cannot call a method with a parameter of a local
 class declared in a lambda [v2]
In-Reply-To: <OXdmJRiG6RLel5ftRxoM9ehem8iFOGHM8Mq6_llJ4EM=.30bcee8b-2dff-49ae-99ad-6419228db059@github.com>
References: <RgTl0a5A7X51DERBJaYhKfiOgZmo-qbXUpWbLoZJwd8=.e869c7c9-fed7-478f-a974-f812b44ee277@github.com>
 <OXdmJRiG6RLel5ftRxoM9ehem8iFOGHM8Mq6_llJ4EM=.30bcee8b-2dff-49ae-99ad-6419228db059@github.com>
Message-ID: <gxh6O-mSo5lj1jPuf6ADhN4Kzy5rO6Z11H3Z-yQhNmQ=.0c1e0050-ecba-4a75-8dc9-470d94e5ee45@github.com>

On Wed, 1 Feb 2023 23:57:59 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Very interesting and, a bit, tricky bug. So the compiler is rejecting code like:
>> 
>> class LocalClassDeclaredInsideLambdaTest {
>>     void run(Runnable r) {}
>> 
>>     void m() {
>>         run(() -> {
>>             class C {
>>                 static void takeC(C c) {}
>>                 static C giveC() {
>>                     return null;
>>                 }
>>             }
>>             C.takeC(C.giveC());
>>         });
>>     }
>> }
>> 
>> with error:
>> 
>> LocalClassInsideLambda.java:12: error: incompatible types: C cannot be converted to C
>>             C.takeC(C.giveC());
>>                            ^
>> Note: Some messages have been simplified; recompile with -Xdiags:verbose to get full output
>> 1 error
>> 
>> which is very misleading as the type seems to be the same. The issue here is that both the lambda and invocation `C.giveC()` are considered poly expressions. `C.giveC()` is not a poly expression but at the moment the compiler is analyzing if an invocation is a poly expression or not, it doesn't have enough information and errs on the safe side.
>> 
>> We have a cache at `com.sun.tools.javac.comp.ArgumentAttr`, see field `argumentTypeCache`, which stores the current deferred type of arguments considered poly expressions. The problem with this particular code is that inside of the lambda there is a class declaration and every time the lambda is attributed a new class type is created.
>> 
>> The lambda, and thus the expression `C.giveC()` are attributed twice. The first time we have an speculative attribution, as a result `argumentTypeCache` will have two entries, one for the lambda and one for `C.giveC()` but the type of `C` is the type created during speculative attribution on a copy of the original lambda tree, let's call it C1. Later on another pass the lambda is attributed `"for real"`, during the check phase. At this point the entry for the lambda in the cache pointed by `argumentTypeCache` has been removed but there is still the entry for `C.giveC()` which still refers to `C1`. So now in the `"for real"` attribution of the lambda which happens on the original tree, not in a copy, a new type for class `C` is created, let's call it `C2`. But when we get to the point where we need to attribute again `C.takeC(C.giveC())` invocation `C.takeC` is expecting `C2` but as `C.giveC()` is again considered a poly expression and an entry is found for it at the cache, the com
 piler reuses that entry which refers to `C1`. And unfortunately `C1 != C2` and thus the error is issued. So the solution I propose is to use a local cache for the speculative attribution of lambda expressions. This is a one liner fix, although an alternative solution could be to scan the lambda body and only use a local cache if a new type is defined inside the lambda, this could be a more optimal solution performance wise as we could save some attributions in some cases. Comments?
>> 
>> TIA
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   some experiments, close to a stable version

Marked as reviewed by mcimadamore (Reviewer).

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

> 460:     }
> 461: 
> 462:     boolean hasTypeDeclaration(JCLambda lambda) {

This is a good start.
A couple of comments:
* I believe this problem is more general than just lambdas (e.g. switch expression probably suffers from that as well)
* It would be better to write a single visitor which does everything in a single pass, rather than visit every statement in a block explicitly (after all, that's what the visitor is gonna do anyways). I even believe the visitor should recurse into everything (including nested lambdas and classes - after all, a class _nested_ in a local class might have a type which is then referred by the lambda return type!).

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

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

From mcimadamore at openjdk.org  Thu Feb  2 00:25:26 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 2 Feb 2023 00:25:26 GMT
Subject: RFR: 8295019: Cannot call a method with a parameter of a local
 class declared in a lambda [v2]
In-Reply-To: <gxh6O-mSo5lj1jPuf6ADhN4Kzy5rO6Z11H3Z-yQhNmQ=.0c1e0050-ecba-4a75-8dc9-470d94e5ee45@github.com>
References: <RgTl0a5A7X51DERBJaYhKfiOgZmo-qbXUpWbLoZJwd8=.e869c7c9-fed7-478f-a974-f812b44ee277@github.com>
 <OXdmJRiG6RLel5ftRxoM9ehem8iFOGHM8Mq6_llJ4EM=.30bcee8b-2dff-49ae-99ad-6419228db059@github.com>
 <gxh6O-mSo5lj1jPuf6ADhN4Kzy5rO6Z11H3Z-yQhNmQ=.0c1e0050-ecba-4a75-8dc9-470d94e5ee45@github.com>
Message-ID: <qgR22hG5jek5tgqVDri-GKe65D-GlgIf7SPBh1AN1QI=.4b34c61b-26b7-451e-9752-b17a43f58cc6@github.com>

On Thu, 2 Feb 2023 00:11:18 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   some experiments, close to a stable version
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java line 462:
> 
>> 460:     }
>> 461: 
>> 462:     boolean hasTypeDeclaration(JCLambda lambda) {
> 
> This is a good start.
> A couple of comments:
> * I believe this problem is more general than just lambdas (e.g. switch expression probably suffers from that as well)
> * It would be better to write a single visitor which does everything in a single pass, rather than visit every statement in a block explicitly (after all, that's what the visitor is gonna do anyways). I even believe the visitor should recurse into everything (including nested lambdas and classes - after all, a class _nested_ in a local class might have a type which is then referred by the lambda return type!).

This is the equivalent bug with switch expression:


class LocalClassDeclaredInsideSwitchTest {
    void run(int i) {}

    void m(int o) {
        run(switch(o) {
          case 1 -> {
            class C {
                static int takeC(C c) {}
                static C giveC() {
                    return null;
                }
            }
            yield C.takeC(C.giveC());
         }
         default -> throw new AssertionError();
       });
    }
}


We should come up with a fix that is general enough to handle all these cases.

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

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

From maurizio.cimadamore at oracle.com  Thu Feb  2 00:31:34 2023
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Thu, 2 Feb 2023 00:31:34 +0000
Subject: Type parameters inside super() calls?
In-Reply-To: <df3891cf-9d5b-f105-d133-c78d63b7784a@oracle.com>
References: <CANSoFxtsXsUxy1Xr5K8KGOSNd8-gOkJoWzAyx0WngOBgxSAsZw@mail.gmail.com>
 <21690dfc-9970-d1c8-a3ee-cb655d27f10a@oracle.com>
 <03b6b91d-d3f9-a551-62cc-1b70c14e121e@oracle.com>
 <df3891cf-9d5b-f105-d133-c78d63b7784a@oracle.com>
Message-ID: <e2d94951-ea11-6f0a-e07f-7060ba75c2bd@oracle.com>

On 02/02/2023 00:13, Alex Buckley wrote:

> 8.1.3 has a nice note about intent:
>
> ? "The purpose of a static context is to demarcate code that must not 
> refer explicitly or implicitly to the current instance of the class 
> whose declaration lexically encloses the static context. Consequently, 
> code that occurs in a static context is restricted in the following 
> ways: ..."
>
> Beyond that, I'm not sure what to say, because all of this has been in 
> place since Java 1.1.

I understand that this has been there since the beginning.

And, in a world where (a) there?s no generics and (b) you can?t have 
statements before super() - that para specifies the right behavior.

When you throw in type parameters, it seems to me that the ?this is a 
static context? no longer works - as it cannot explain programs that are 
obviously valid (such as the one I have shown).

And, if we add statements before |super| it gets even worse, because now 
we can have types that are non-static, but that it?s not clear as to why 
such types couldn?t be referred to:

|class Foo { Foo() { class Local { String aString() { ... } } super(new 
Local().aString()); // is this legal? } } |

Now that we?re planning to do more work in this area [1], it would be 
IMHO a good time to see if the use of ?static context? in 8.8.7.1 is 
really what we want.

Maurizio

[1] - https://bugs.openjdk.org/browse/JDK-8300786

>
> Alex
>
> On 2/1/2023 3:43 PM, Maurizio Cimadamore wrote:
>> While I agree that what javac does is against the JLS, is this a 
>> javac or a spec bug?
>>
>> I mean, consider this hierarchy:
>>
>> |class Sup<X> { Sup(X x) { ... } } class Sub<Y> extends Sup<Y> { 
>> Sub(Y y) { super(y); } } |
>>
>> What the rules are saying is that ?y? in the Sub super call should be 
>> evaluated in a static context. But that doesn?t make any sense - 
>> because Y is not even a valid type in such a static context.
>>
>> And yet - this is a valid program. So, if typechecking ?y? is 
>> correct, then, surely, typechecking ?(Y)y? should also be correct? 
>> E.g. it seems to me that the use of ?static context? here is an 
>> ?approximation? for the behavior we really want (e.g. no access to 
>> instance fields, whether directly or indirectly).
>>
>> Maurizio
>>
>> On 01/02/2023 22:39, Alex Buckley wrote:
>>
>>> Your reading of the JLS is correct. The cast expression `(T)obj` 
>>> occurs in a static context, so the use of T should be disallowed, 
>>> and javac should reject the program.
>>>
>>> These rules in 8.8.7.1 and 8.1.3 are longstanding, and have not 
>>> changed recently, so I'm surprised that javac lets the program 
>>> through. That said, JLS16 saw a reworking of 8.1.3 (driven by 
>>> https://openjdk.org/jeps/395#Static-members-of-inner-classes) and 
>>> perhaps javac got a bit turned around over static contexts.
>>>
>>> As an additional test case, make the constructor generic -- `public 
>>> <U extends T> TypeParam ...` -- and cast obj to U rather than T -- 
>>> still illegal.
>>>
>>> Alex
>>>
>>> On 2/1/2023 12:45 PM, Archie Cobbs wrote:
>>>> This program compiles without error:
>>>>
>>>> import java.util.concurrent.atomic.*;
>>>> public class TypeParamStaticContext<T> extends AtomicReference<T> {
>>>> ?? ? public TypeParamStaticContext(Object obj) {
>>>> ?? ? ? ? super((T)obj);
>>>> ?? ? }
>>>> }
>>>>
>>>> Yet according to my reading of the JLS, the appearance of T inside 
>>>> the super() call should be disallowed:
>>>>
>>>> ?8.8.7.1 <http://8.8.7.1>:
>>>>
>>>> An explicit constructor invocation statement introduces a static 
>>>> context (?8.1.3 
>>>> <https://docs.oracle.com/javase/specs/jls/se19/html/jls-8.html#jls-8.1.3>), 
>>>> which limits the use of constructs that refer to the current 
>>>> object. Notably, the keywords |this| and |super| are prohibited in 
>>>> a static context (?15.8.3 
>>>> <https://docs.oracle.com/javase/specs/jls/se19/html/jls-15.html#jls-15.8.3>, 
>>>> ?15.11.2 
>>>> <https://docs.oracle.com/javase/specs/jls/se19/html/jls-15.html#jls-15.11.2>), 
>>>> as are unqualified references to instance variables, instance 
>>>> methods, and type parameters of lexically enclosing declarations 
>>>> (?6.5.5.1 
>>>> <https://docs.oracle.com/javase/specs/jls/se19/html/jls-6.html#jls-6.5.5.1>, 
>>>> ?6.5.6.1 
>>>> <https://docs.oracle.com/javase/specs/jls/se19/html/jls-6.html#jls-6.5.6.1>, 
>>>> ?15.12.3 
>>>> <https://docs.oracle.com/javase/specs/jls/se19/html/jls-15.html#jls-15.12.3>).
>>>>
>>>> ?6.5.5.1 <http://6.5.5.1>:
>>>>
>>>> If a type name consists of a single /Identifier/, then the 
>>>> identifier must occur in the scope of exactly one declaration of a 
>>>> class, interface, or type parameter with this name (?6.3 
>>>> <https://docs.oracle.com/javase/specs/jls/se19/html/jls-6.html#jls-6.3>), 
>>>> or a compile-time error occurs.
>>>>
>>>> If the declaration denotes a type parameter of a generic class or 
>>>> interface C (?8.1.2 
>>>> <https://docs.oracle.com/javase/specs/jls/se19/html/jls-8.html#jls-8.1.2>, 
>>>> ?9.1.2 
>>>> <https://docs.oracle.com/javase/specs/jls/se19/html/jls-9.html#jls-9.1.2>), 
>>>> then both of the following must be true, or a compile-time error 
>>>> occurs:
>>>>
>>>> ? *
>>>>
>>>> ??? The type name does not occur in a static context (?8.1.3
>>>> <https://docs.oracle.com/javase/specs/jls/se19/html/jls-8.html#jls-8.1.3>) 
>>>>
>>>>
>>>> ? *
>>>>
>>>> ??? If the type name appears in a nested class or interface 
>>>> declaration
>>>> ??? of C, then the immediately enclosing class or interface 
>>>> declaration
>>>> ??? of the type name is an inner class of C.
>>>>
>>>>
>>>> What am I missing?
>>>>
>>>> Thanks,
>>>> -Archie
>>>>
>>>> -- 
>>>> Archie L. Cobbs
>>
>> ?

?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230202/b8b7d405/attachment-0001.htm>

From jjg at openjdk.org  Thu Feb  2 00:41:25 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 2 Feb 2023 00:41:25 GMT
Subject: RFR: JDK-8300914: Allow `@` as an escape in documentation comments
 [v2]
In-Reply-To: <8_sn3KytEC8oZf7krphnqREsrEvupP3iIlOZTST-5FQ=.e631623b-cd9d-49be-8796-b13d89227ddb@github.com>
References: <FuwqJLq_p2KGjWFYjms8z_Qvxbov1wlBFdgWDArxCb8=.b017e75e-2994-474c-b1cd-b1335ad1f274@github.com>
 <RMF0PaxzTeajAlAwtxmkogS__ZlDPL6m5ZoUN68kun8=.ec26d109-b4ca-4b7c-b0d8-74ac3c71ef2a@github.com>
 <8_sn3KytEC8oZf7krphnqREsrEvupP3iIlOZTST-5FQ=.e631623b-cd9d-49be-8796-b13d89227ddb@github.com>
Message-ID: <8upQRH9JSnVu_rafGBiLGGcy95B9fmEhlZAoQCECRj0=.2f7036a8-176e-44df-bdc3-6f690d6df322@github.com>

On Wed, 1 Feb 2023 22:22:07 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
>> 
>>  - Merge with upstream/master
>>  - JDK-8301294: Allow `@` as an escape in documentation comments
>
> src/jdk.compiler/share/classes/com/sun/source/doctree/DocTree.java line 110:
> 
>> 108:          * representing some escaped documentation text.
>> 109:          */
>> 110:         ESCAPE,
> 
> We seem to add `@since` to newer kinds of tags.

Yes, ooops, I missed that one

> src/jdk.compiler/share/classes/com/sun/source/util/DocTreeFactory.java line 186:
> 
>> 184:      * @since 21
>> 185:      */
>> 186:     EscapeTree newEscapeTree(char ch);
> 
> For the record: I noticed this discrepancy between the `char` parameter here and the `String` return value in `EscapeTree.getBody()` while discussing CSR.
> 
> Initially, I thought that we could use `String` for the parameter too, but you provided reasonable arguments why we should keep it `char`.
> 
> I once again note that it's weird that `DocTreeFactory` is public API.

On `DocTreeFactory`
1. at the time the API was created, it was modeled on the javac AST, and yes, while it might be a bit weird here, it's less weird than the one for javac.
2. `DocTreeFactory` is used in the doclet to create comments for mandated methods, so one way or another, it needs to be public.

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

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

From alex.buckley at oracle.com  Thu Feb  2 01:04:44 2023
From: alex.buckley at oracle.com (Alex Buckley)
Date: Wed, 1 Feb 2023 17:04:44 -0800
Subject: Type parameters inside super() calls?
In-Reply-To: <e2d94951-ea11-6f0a-e07f-7060ba75c2bd@oracle.com>
References: <CANSoFxtsXsUxy1Xr5K8KGOSNd8-gOkJoWzAyx0WngOBgxSAsZw@mail.gmail.com>
 <21690dfc-9970-d1c8-a3ee-cb655d27f10a@oracle.com>
 <03b6b91d-d3f9-a551-62cc-1b70c14e121e@oracle.com>
 <df3891cf-9d5b-f105-d133-c78d63b7784a@oracle.com>
 <e2d94951-ea11-6f0a-e07f-7060ba75c2bd@oracle.com>
Message-ID: <768a623a-2d8f-c69c-6a73-6ea8e73bab7a@oracle.com>

On 2/1/2023 4:31 PM, Maurizio Cimadamore wrote:> And, if we add 
statements before |super| it gets even worse, because now
> we can have types that are non-static, but that it?s not clear as to why 
> such types couldn?t be referred to:
> 
> |class Foo { Foo() { class Local { String aString() { ... } } super(new 
> Local().aString()); // is this legal? } } |

To answer the question: the argument to `super(..)` is presently not 
legal because the `new Local()` part is presently not legal. (15.9.2: 
"If <<Local>> is an inner local class, then ... if the class instance 
creation expression occurs in a static context, then a compile-time 
error occurs.")

But you are saying this is "static context overreach", and that perhaps 
`new Local()` should be allowed there. Such an expression needs to use 
`this` as the immediately enclosing instance of the Local object, and 
that's fine as long as no-one can access the immediately enclosing 
instance ... but now we invoke a method on the Local object and ????

> Now that we?re planning to do more work in this area [1], it would be 
> IMHO a good time to see if the use of ?static context? in 8.8.7.1 is 
> really what we want.

I don't disagree.

Alex

> Maurizio
> 
> [1] - https://bugs.openjdk.org/browse/JDK-8300786
> 
>>
>> Alex
>>
>> On 2/1/2023 3:43 PM, Maurizio Cimadamore wrote:
>>> While I agree that what javac does is against the JLS, is this a 
>>> javac or a spec bug?
>>>
>>> I mean, consider this hierarchy:
>>>
>>> |class Sup<X> { Sup(X x) { ... } } class Sub<Y> extends Sup<Y> { 
>>> Sub(Y y) { super(y); } } |
>>>
>>> What the rules are saying is that ?y? in the Sub super call should be 
>>> evaluated in a static context. But that doesn?t make any sense - 
>>> because Y is not even a valid type in such a static context.
>>>
>>> And yet - this is a valid program. So, if typechecking ?y? is 
>>> correct, then, surely, typechecking ?(Y)y? should also be correct? 
>>> E.g. it seems to me that the use of ?static context? here is an 
>>> ?approximation? for the behavior we really want (e.g. no access to 
>>> instance fields, whether directly or indirectly).
>>>
>>> Maurizio
>>>
>>> On 01/02/2023 22:39, Alex Buckley wrote:
>>>
>>>> Your reading of the JLS is correct. The cast expression `(T)obj` 
>>>> occurs in a static context, so the use of T should be disallowed, 
>>>> and javac should reject the program.
>>>>
>>>> These rules in 8.8.7.1 and 8.1.3 are longstanding, and have not 
>>>> changed recently, so I'm surprised that javac lets the program 
>>>> through. That said, JLS16 saw a reworking of 8.1.3 (driven by 
>>>> https://openjdk.org/jeps/395#Static-members-of-inner-classes) and 
>>>> perhaps javac got a bit turned around over static contexts.
>>>>
>>>> As an additional test case, make the constructor generic -- `public 
>>>> <U extends T> TypeParam ...` -- and cast obj to U rather than T -- 
>>>> still illegal.
>>>>
>>>> Alex
>>>>
>>>> On 2/1/2023 12:45 PM, Archie Cobbs wrote:
>>>>> This program compiles without error:
>>>>>
>>>>> import java.util.concurrent.atomic.*;
>>>>> public class TypeParamStaticContext<T> extends AtomicReference<T> {
>>>>> ?? ? public TypeParamStaticContext(Object obj) {
>>>>> ?? ? ? ? super((T)obj);
>>>>> ?? ? }
>>>>> }
>>>>>
>>>>> Yet according to my reading of the JLS, the appearance of T inside 
>>>>> the super() call should be disallowed:
>>>>>
>>>>> ?8.8.7.1 <http://8.8.7.1>:
>>>>>
>>>>> An explicit constructor invocation statement introduces a static 
>>>>> context (?8.1.3 
>>>>> <https://docs.oracle.com/javase/specs/jls/se19/html/jls-8.html#jls-8.1.3>), which limits the use of constructs that refer to the current object. Notably, the keywords |this| and |super| are prohibited in a static context (?15.8.3 <https://docs.oracle.com/javase/specs/jls/se19/html/jls-15.html#jls-15.8.3>, ?15.11.2 <https://docs.oracle.com/javase/specs/jls/se19/html/jls-15.html#jls-15.11.2>), as are unqualified references to instance variables, instance methods, and type parameters of lexically enclosing declarations (?6.5.5.1 <https://docs.oracle.com/javase/specs/jls/se19/html/jls-6.html#jls-6.5.5.1>, ?6.5.6.1 <https://docs.oracle.com/javase/specs/jls/se19/html/jls-6.html#jls-6.5.6.1>, ?15.12.3 <https://docs.oracle.com/javase/specs/jls/se19/html/jls-15.html#jls-15.12.3>).
>>>>>
>>>>> ?6.5.5.1 <http://6.5.5.1>:
>>>>>
>>>>> If a type name consists of a single /Identifier/, then the 
>>>>> identifier must occur in the scope of exactly one declaration of a 
>>>>> class, interface, or type parameter with this name (?6.3 
>>>>> <https://docs.oracle.com/javase/specs/jls/se19/html/jls-6.html#jls-6.3>), or a compile-time error occurs.
>>>>>
>>>>> If the declaration denotes a type parameter of a generic class or 
>>>>> interface C (?8.1.2 
>>>>> <https://docs.oracle.com/javase/specs/jls/se19/html/jls-8.html#jls-8.1.2>, ?9.1.2 <https://docs.oracle.com/javase/specs/jls/se19/html/jls-9.html#jls-9.1.2>), then both of the following must be true, or a compile-time error occurs:
>>>>>
>>>>> ? *
>>>>>
>>>>> ??? The type name does not occur in a static context (?8.1.3
>>>>> <https://docs.oracle.com/javase/specs/jls/se19/html/jls-8.html#jls-8.1.3>)
>>>>>
>>>>> ? *
>>>>>
>>>>> ??? If the type name appears in a nested class or interface 
>>>>> declaration
>>>>> ??? of C, then the immediately enclosing class or interface 
>>>>> declaration
>>>>> ??? of the type name is an inner class of C.
>>>>>
>>>>>
>>>>> What am I missing?
>>>>>
>>>>> Thanks,
>>>>> -Archie
>>>>>
>>>>> -- 
>>>>> Archie L. Cobbs
>>>
>>> ?
> 
> ?

From archie.cobbs at gmail.com  Thu Feb  2 02:04:13 2023
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Wed, 1 Feb 2023 20:04:13 -0600
Subject: Type parameters inside super() calls?
In-Reply-To: <768a623a-2d8f-c69c-6a73-6ea8e73bab7a@oracle.com>
References: <CANSoFxtsXsUxy1Xr5K8KGOSNd8-gOkJoWzAyx0WngOBgxSAsZw@mail.gmail.com>
 <21690dfc-9970-d1c8-a3ee-cb655d27f10a@oracle.com>
 <03b6b91d-d3f9-a551-62cc-1b70c14e121e@oracle.com>
 <df3891cf-9d5b-f105-d133-c78d63b7784a@oracle.com>
 <e2d94951-ea11-6f0a-e07f-7060ba75c2bd@oracle.com>
 <768a623a-2d8f-c69c-6a73-6ea8e73bab7a@oracle.com>
Message-ID: <CANSoFxvzgaz4y-dNvk0N96bAoQEkZoK6gOPCYPGTtjoWE+TqSA@mail.gmail.com>

I'm starting to have a weird fondness for obscure JLS corners like this :)

Some thoughts...

>From a purely practical point of view, the "static context" concept seems
to exist to prevent these two bad things:

   1. Accessing the 'this' object (via this, super, or any implicit means)
   when there is no such object available
   2. Accessing the 'this' object (via this, super, or any implicit means)
   when that object is uninitialized

(Are there others?) By "bad things" I mean problems with language
semantics, not problems because the compiler happens to be implemented a
certain way.

The example super(new Local().aString()) can never be allowed, because of
#2 above. But note you can *define* Local prior to super() ... you just
can't instantiate it.

In other words the type itself is not a problem. There's no mention of
types at all in the above two reasons.

So one thought experiment is: What would happen if we eliminated all
restrictions on generic type parameters in static contexts? What would
actually go wrong?

Put another way, a static method is just an instance method without a
'this' instance. So neither issue #1 or #2 is possible. So, no problem,
right?

You might be able to write code that looks silly, but would it actually be
nonsensical?

    public class Foo<T extends Number> {
        public static toFloat(T value) {
            return value.floatValue();   // why not?
        }
    }

I'm sure I'm missing something but what?

-Archie

On Wed, Feb 1, 2023 at 7:05 PM Alex Buckley <alex.buckley at oracle.com> wrote:

> On 2/1/2023 4:31 PM, Maurizio Cimadamore wrote:> And, if we add
> statements before |super| it gets even worse, because now
> > we can have types that are non-static, but that it?s not clear as to why
> > such types couldn?t be referred to:
> >
> > |class Foo { Foo() { class Local { String aString() { ... } } super(new
> > Local().aString()); // is this legal? } } |
>
> To answer the question: the argument to `super(..)` is presently not
> legal because the `new Local()` part is presently not legal. (15.9.2:
> "If <<Local>> is an inner local class, then ... if the class instance
> creation expression occurs in a static context, then a compile-time
> error occurs.")
>
> But you are saying this is "static context overreach", and that perhaps
> `new Local()` should be allowed there. Such an expression needs to use
> `this` as the immediately enclosing instance of the Local object, and
> that's fine as long as no-one can access the immediately enclosing
> instance ... but now we invoke a method on the Local object and ????
>
> > Now that we?re planning to do more work in this area [1], it would be
> > IMHO a good time to see if the use of ?static context? in 8.8.7.1 is
> > really what we want.
>
> I don't disagree.
>
> Alex
>
> > Maurizio
> >
> > [1] - https://bugs.openjdk.org/browse/JDK-8300786
> >
> >>
> >> Alex
> >>
> >> On 2/1/2023 3:43 PM, Maurizio Cimadamore wrote:
> >>> While I agree that what javac does is against the JLS, is this a
> >>> javac or a spec bug?
> >>>
> >>> I mean, consider this hierarchy:
> >>>
> >>> |class Sup<X> { Sup(X x) { ... } } class Sub<Y> extends Sup<Y> {
> >>> Sub(Y y) { super(y); } } |
> >>>
> >>> What the rules are saying is that ?y? in the Sub super call should be
> >>> evaluated in a static context. But that doesn?t make any sense -
> >>> because Y is not even a valid type in such a static context.
> >>>
> >>> And yet - this is a valid program. So, if typechecking ?y? is
> >>> correct, then, surely, typechecking ?(Y)y? should also be correct?
> >>> E.g. it seems to me that the use of ?static context? here is an
> >>> ?approximation? for the behavior we really want (e.g. no access to
> >>> instance fields, whether directly or indirectly).
> >>>
> >>> Maurizio
> >>>
> >>> On 01/02/2023 22:39, Alex Buckley wrote:
> >>>
> >>>> Your reading of the JLS is correct. The cast expression `(T)obj`
> >>>> occurs in a static context, so the use of T should be disallowed,
> >>>> and javac should reject the program.
> >>>>
> >>>> These rules in 8.8.7.1 and 8.1.3 are longstanding, and have not
> >>>> changed recently, so I'm surprised that javac lets the program
> >>>> through. That said, JLS16 saw a reworking of 8.1.3 (driven by
> >>>> https://openjdk.org/jeps/395#Static-members-of-inner-classes) and
> >>>> perhaps javac got a bit turned around over static contexts.
> >>>>
> >>>> As an additional test case, make the constructor generic -- `public
> >>>> <U extends T> TypeParam ...` -- and cast obj to U rather than T --
> >>>> still illegal.
> >>>>
> >>>> Alex
> >>>>
> >>>> On 2/1/2023 12:45 PM, Archie Cobbs wrote:
> >>>>> This program compiles without error:
> >>>>>
> >>>>> import java.util.concurrent.atomic.*;
> >>>>> public class TypeParamStaticContext<T> extends AtomicReference<T> {
> >>>>>      public TypeParamStaticContext(Object obj) {
> >>>>>          super((T)obj);
> >>>>>      }
> >>>>> }
> >>>>>
> >>>>> Yet according to my reading of the JLS, the appearance of T inside
> >>>>> the super() call should be disallowed:
> >>>>>
> >>>>> ?8.8.7.1 <http://8.8.7.1>:
> >>>>>
> >>>>> An explicit constructor invocation statement introduces a static
> >>>>> context (?8.1.3
> >>>>> <
> https://docs.oracle.com/javase/specs/jls/se19/html/jls-8.html#jls-8.1.3>),
> which limits the use of constructs that refer to the current object.
> Notably, the keywords |this| and |super| are prohibited in a static context
> (?15.8.3 <
> https://docs.oracle.com/javase/specs/jls/se19/html/jls-15.html#jls-15.8.3>,
> ?15.11.2 <
> https://docs.oracle.com/javase/specs/jls/se19/html/jls-15.html#jls-15.11.2>),
> as are unqualified references to instance variables, instance methods, and
> type parameters of lexically enclosing declarations (?6.5.5.1 <
> https://docs.oracle.com/javase/specs/jls/se19/html/jls-6.html#jls-6.5.5.1>,
> ?6.5.6.1 <
> https://docs.oracle.com/javase/specs/jls/se19/html/jls-6.html#jls-6.5.6.1>,
> ?15.12.3 <
> https://docs.oracle.com/javase/specs/jls/se19/html/jls-15.html#jls-15.12.3
> >).
> >>>>>
> >>>>> ?6.5.5.1 <http://6.5.5.1>:
> >>>>>
> >>>>> If a type name consists of a single /Identifier/, then the
> >>>>> identifier must occur in the scope of exactly one declaration of a
> >>>>> class, interface, or type parameter with this name (?6.3
> >>>>> <
> https://docs.oracle.com/javase/specs/jls/se19/html/jls-6.html#jls-6.3>),
> or a compile-time error occurs.
> >>>>>
> >>>>> If the declaration denotes a type parameter of a generic class or
> >>>>> interface C (?8.1.2
> >>>>> <
> https://docs.oracle.com/javase/specs/jls/se19/html/jls-8.html#jls-8.1.2>,
> ?9.1.2 <
> https://docs.oracle.com/javase/specs/jls/se19/html/jls-9.html#jls-9.1.2>),
> then both of the following must be true, or a compile-time error occurs:
> >>>>>
> >>>>>   *
> >>>>>
> >>>>>     The type name does not occur in a static context (?8.1.3
> >>>>> <
> https://docs.oracle.com/javase/specs/jls/se19/html/jls-8.html#jls-8.1.3>)
> >>>>>
> >>>>>   *
> >>>>>
> >>>>>     If the type name appears in a nested class or interface
> >>>>> declaration
> >>>>>     of C, then the immediately enclosing class or interface
> >>>>> declaration
> >>>>>     of the type name is an inner class of C.
> >>>>>
> >>>>>
> >>>>> What am I missing?
> >>>>>
> >>>>> Thanks,
> >>>>> -Archie
> >>>>>
> >>>>> --
> >>>>> Archie L. Cobbs
> >>>
> >>>
> >
> >
>


-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230201/271808dc/attachment-0001.htm>

From maurizio.cimadamore at oracle.com  Thu Feb  2 10:12:32 2023
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Thu, 2 Feb 2023 10:12:32 +0000
Subject: Type parameters inside super() calls?
In-Reply-To: <768a623a-2d8f-c69c-6a73-6ea8e73bab7a@oracle.com>
References: <CANSoFxtsXsUxy1Xr5K8KGOSNd8-gOkJoWzAyx0WngOBgxSAsZw@mail.gmail.com>
 <21690dfc-9970-d1c8-a3ee-cb655d27f10a@oracle.com>
 <03b6b91d-d3f9-a551-62cc-1b70c14e121e@oracle.com>
 <df3891cf-9d5b-f105-d133-c78d63b7784a@oracle.com>
 <e2d94951-ea11-6f0a-e07f-7060ba75c2bd@oracle.com>
 <768a623a-2d8f-c69c-6a73-6ea8e73bab7a@oracle.com>
Message-ID: <3c1d8459-aecf-1f39-9042-f5b3b3b6f3fa@oracle.com>


On 02/02/2023 01:04, Alex Buckley wrote:
> But you are saying this is "static context overreach", and that 
> perhaps `new Local()` should be allowed there. Such an expression 
> needs to use `this` as the immediately enclosing instance of the Local 
> object, and that's fine as long as no-one can access the immediately 
> enclosing instance ... but now we invoke a method on the Local object 
> and ???? 

I realized my local class example was borked in some ways, and not in 
others.

It is borked because when you do `new Local()` you need an enclosing 
instance (`this`), but you have not yet ran `super`, so that's a clear 
issue (same accessing an instance method).

But, should the _type_ Local be unavailable? What if I do `(Local)null` 
- is that an error? Today it will be - but here the expression is not 
using `this` in any way.

What irks me is that using the "static context" trick biases us on which 
_types_ we can and cannot see, while the whole point of the restrictions 
is to prevent initialization bugs (e.g. use `this` before `super` is 
called) which involve _expressions_ not _types_.

Because of that, I find the type-variable restriction too over-reaching 
- if the only way to sensibly use a type-variable was by using `this`, 
fine, it wouldn't matter in practice. But a constructor can accept an 
argument whose type is a type-variable - to manipulate that type you 
never need to use `this`. And, more concretely, let's say you need to 
call a _static_ generic method and pass that argument (some T), and 
inference fails, then the user, with the current restrictions, has no 
way to "fix" the inference error by providing a concrete <T> witness. 
Again, I don't expect this to come up much, but it's one of those things 
that seems somewhat arbitrary.

Maurizio



From maurizio.cimadamore at oracle.com  Thu Feb  2 10:18:39 2023
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Thu, 2 Feb 2023 10:18:39 +0000
Subject: Type parameters inside super() calls?
In-Reply-To: <CANSoFxvzgaz4y-dNvk0N96bAoQEkZoK6gOPCYPGTtjoWE+TqSA@mail.gmail.com>
References: <CANSoFxtsXsUxy1Xr5K8KGOSNd8-gOkJoWzAyx0WngOBgxSAsZw@mail.gmail.com>
 <21690dfc-9970-d1c8-a3ee-cb655d27f10a@oracle.com>
 <03b6b91d-d3f9-a551-62cc-1b70c14e121e@oracle.com>
 <df3891cf-9d5b-f105-d133-c78d63b7784a@oracle.com>
 <e2d94951-ea11-6f0a-e07f-7060ba75c2bd@oracle.com>
 <768a623a-2d8f-c69c-6a73-6ea8e73bab7a@oracle.com>
 <CANSoFxvzgaz4y-dNvk0N96bAoQEkZoK6gOPCYPGTtjoWE+TqSA@mail.gmail.com>
Message-ID: <50e30583-5516-0335-f4cf-1dd63ab73651@oracle.com>


On 02/02/2023 02:04, Archie Cobbs wrote:
> The example super(new Local().aString()) can never be allowed, because 
> of #2 above. But note you can /define/ Local prior to super() ... you 
> just can't instantiate it.
>
> In other words the type itself is not a problem. There's no mention of 
> types at all in the above two reasons.
Exactly - I came up with the same conclusion in my long-winded reply to 
myself :-)
>
> So one thought experiment is: What would happen if we eliminated all 
> restrictions on generic type parameters in static contexts? What would 
> actually go wrong?

I don't think anything can _go wrong_ - because, as I also said in my 
email, the constructor code will have to manipulate expression with 
those types _regardless_ of whether their types is manifest or not. So, 
the language is already behaving as if the arguments to the supercall 
were type-checked in a non-static context, otherwise my perfectly legal 
example:

```java
class Sup<X> {
 ??? Sup(X x) { ... }
}

class Sub<Y> extends Sup<Y> {
 ?? Sub(Y y) {
 ??????? super(y);
 ?? }
}
```

Should be rejected (as `y` has no valid type in a static context). And I 
don't think anyone is willing to go down this path.

In other words, my angle is the opposite: if javac blindly followed the 
"static context" rule, what would happen to existing code? What could go 
wrong? And my answer there was: quite a bit, actually. Which leads me to 
think that the "static" rule, while fine in a pre-generics world (and in 
a world where super calls are the first statement in a constructor) is a 
good and concise way to say what we mean. But, in a post-generics world, 
conflating types with expressions (and initializaton only cares about 
the latter) leads to problems - at least if restrictions are to be 
interpreted literally.

Maurizio
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230202/807402ae/attachment.htm>

From maurizio.cimadamore at oracle.com  Thu Feb  2 10:25:10 2023
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Thu, 2 Feb 2023 10:25:10 +0000
Subject: Type parameters inside super() calls?
In-Reply-To: <CANSoFxvzgaz4y-dNvk0N96bAoQEkZoK6gOPCYPGTtjoWE+TqSA@mail.gmail.com>
References: <CANSoFxtsXsUxy1Xr5K8KGOSNd8-gOkJoWzAyx0WngOBgxSAsZw@mail.gmail.com>
 <21690dfc-9970-d1c8-a3ee-cb655d27f10a@oracle.com>
 <03b6b91d-d3f9-a551-62cc-1b70c14e121e@oracle.com>
 <df3891cf-9d5b-f105-d133-c78d63b7784a@oracle.com>
 <e2d94951-ea11-6f0a-e07f-7060ba75c2bd@oracle.com>
 <768a623a-2d8f-c69c-6a73-6ea8e73bab7a@oracle.com>
 <CANSoFxvzgaz4y-dNvk0N96bAoQEkZoK6gOPCYPGTtjoWE+TqSA@mail.gmail.com>
Message-ID: <46cc73d8-4117-96e4-6f18-b17ed1e69166@oracle.com>


On 02/02/2023 02:04, Archie Cobbs wrote:
> Put another way, a static method is just an instance method without a 
> 'this' instance. So neither issue #1 or #2 is possible. So, no 
> problem, right?
>
> You might be able to write code that looks silly, but would it 
> actually be nonsensical?
>
> ??? public class Foo<T extends Number> {
> ??????? public static toFloat(T value) {
> ??????????? return value.floatValue();?? // why not?
> ??????? }
> ??? }
>
IMHO, this is taking it a step too far.

As I said, I believe the issue stems from using the "static context" 
trick to put restriction on _expressions_ - which then ends up also 
affecting _types_.

I do not think the bug has to do with "static context" being 
ill-defined. There is a big difference between using a T in a 
constructor, and using T in a static method:

* when a constructor is called, you are already initializing a 
_specific_ instance, so T is _bound_;
* when a static method is called, there is no instance, so T is _not 
bound_, and has no real meaning.

Allowing access to T from static method as if it was a "real thing"? 
seems like a recipe for disaster: how do we validate that a call to 
`toFloat` is correct? And, if `toFloat` returned a T, how do we validate 
that the return type is also used correctly at the callsite? And which 
synthetic cast should be generated (given that T not known?).

Maurizio
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230202/dd3cc5ed/attachment-0001.htm>

From prappo at openjdk.org  Thu Feb  2 10:45:30 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 2 Feb 2023 10:45:30 GMT
Subject: RFR: JDK-8300914: Allow `@` as an escape in documentation comments
 [v2]
In-Reply-To: <RMF0PaxzTeajAlAwtxmkogS__ZlDPL6m5ZoUN68kun8=.ec26d109-b4ca-4b7c-b0d8-74ac3c71ef2a@github.com>
References: <FuwqJLq_p2KGjWFYjms8z_Qvxbov1wlBFdgWDArxCb8=.b017e75e-2994-474c-b1cd-b1335ad1f274@github.com>
 <RMF0PaxzTeajAlAwtxmkogS__ZlDPL6m5ZoUN68kun8=.ec26d109-b4ca-4b7c-b0d8-74ac3c71ef2a@github.com>
Message-ID: <kUlqiNAySl3KF_olX7gReT4SS0tq_gurTVNC67XR0UQ=.052015ef-04b2-4353-b34b-3e5e9c67ceea@github.com>

On Wed, 1 Feb 2023 19:43:00 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a moderately simple update to permit the use of `@` as the escape character in a limited set of escape sequences.
>
> Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge with upstream/master
>  - JDK-8301294: Allow `@` as an escape in documentation comments

src/jdk.compiler/share/classes/com/sun/source/doctree/EscapeTree.java line 37:

> 35:  * <ul>
> 36:  *     <li>{@code @@}, representing {@code @}, where it would otherwise be treated as introducing a block or inline tag,
> 37:  *     <li>{@code @/}, representing {@code /}, as part of {@code *@/} to represent <code>&ast;&sol;</code>, and

For other reviewers. Interpret that middle bullet literally: `@` escapes `/` only if it is preceded by `*`. In other words, it's a triple `*@/`, not a pair `@/`.

`@/` without preceding `*` causes errors if it can be confused for a start of a tag.

For a block tag:

    error: no tag name after '@'
         @/
          ^

For an inline tag:

    error: no tag name after '@'
         {@/
          ^

(FWIW, @jonathan-gibbons, note that the caret positions differ: the former points to `/` while the latter points to `@`. )

`*` is a sort of looked-behind and not consumed, which can be seen from the fact that

    /**
     @*@/
     */

is translated to this in documentation

    */

Given all of the above, I'm not sure if `@/` can be technically qualified as an ordinary escape sequence.

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

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

From mcimadamore at openjdk.org  Thu Feb  2 11:04:22 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 2 Feb 2023 11:04:22 GMT
Subject: RFR: 8295019: Cannot call a method with a parameter of a local
 class declared in a lambda [v3]
In-Reply-To: <zAk8P6ajLFOo35gSZaSrxOfWJs-475bIQanzOcaiQek=.022a3493-d1b0-4da6-a206-29d4c8eccab8@github.com>
References: <RgTl0a5A7X51DERBJaYhKfiOgZmo-qbXUpWbLoZJwd8=.e869c7c9-fed7-478f-a974-f812b44ee277@github.com>
 <zAk8P6ajLFOo35gSZaSrxOfWJs-475bIQanzOcaiQek=.022a3493-d1b0-4da6-a206-29d4c8eccab8@github.com>
Message-ID: <XT4MXT7LxXZ227mxUdgJ8pqQrjX1Y3ywNFqS6n1SwjY=.2a986951-ebdc-4702-a961-6dc4b7f1ce5a@github.com>

On Thu, 2 Feb 2023 00:15:58 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Very interesting and, a bit, tricky bug. So the compiler is rejecting code like:
>> 
>> class LocalClassDeclaredInsideLambdaTest {
>>     void run(Runnable r) {}
>> 
>>     void m() {
>>         run(() -> {
>>             class C {
>>                 static void takeC(C c) {}
>>                 static C giveC() {
>>                     return null;
>>                 }
>>             }
>>             C.takeC(C.giveC());
>>         });
>>     }
>> }
>> 
>> with error:
>> 
>> LocalClassInsideLambda.java:12: error: incompatible types: C cannot be converted to C
>>             C.takeC(C.giveC());
>>                            ^
>> Note: Some messages have been simplified; recompile with -Xdiags:verbose to get full output
>> 1 error
>> 
>> which is very misleading as the type seems to be the same. The issue here is that both the lambda and invocation `C.giveC()` are considered poly expressions. `C.giveC()` is not a poly expression but at the moment the compiler is analyzing if an invocation is a poly expression or not, it doesn't have enough information and errs on the safe side.
>> 
>> We have a cache at `com.sun.tools.javac.comp.ArgumentAttr`, see field `argumentTypeCache`, which stores the current deferred type of arguments considered poly expressions. The problem with this particular code is that inside of the lambda there is a class declaration and every time the lambda is attributed a new class type is created.
>> 
>> The lambda, and thus the expression `C.giveC()` are attributed twice. The first time we have an speculative attribution, as a result `argumentTypeCache` will have two entries, one for the lambda and one for `C.giveC()` but the type of `C` is the type created during speculative attribution on a copy of the original lambda tree, let's call it C1. Later on another pass the lambda is attributed `"for real"`, during the check phase. At this point the entry for the lambda in the cache pointed by `argumentTypeCache` has been removed but there is still the entry for `C.giveC()` which still refers to `C1`. So now in the `"for real"` attribution of the lambda which happens on the original tree, not in a copy, a new type for class `C` is created, let's call it `C2`. But when we get to the point where we need to attribute again `C.takeC(C.giveC())` invocation `C.takeC` is expecting `C2` but as `C.giveC()` is again considered a poly expression and an entry is found for it at the cache, the com
 piler reuses that entry which refers to `C1`. And unfortunately `C1 != C2` and thus the error is issued. So the solution I propose is to use a local cache for the speculative attribution of lambda expressions. This is a one liner fix, although an alternative solution could be to scan the lambda body and only use a local cache if a new type is defined inside the lambda, this could be a more optimal solution performance wise as we could save some attributions in some cases. Comments?
>> 
>> TIA
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adding a comment

It seems like I have clicked on the "approve" button by accident...

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

Changes requested by mcimadamore (Reviewer).

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

From forax at univ-mlv.fr  Thu Feb  2 11:30:09 2023
From: forax at univ-mlv.fr (Remi Forax)
Date: Thu, 2 Feb 2023 12:30:09 +0100 (CET)
Subject: Type parameters inside super() calls?
In-Reply-To: <46cc73d8-4117-96e4-6f18-b17ed1e69166@oracle.com>
References: <CANSoFxtsXsUxy1Xr5K8KGOSNd8-gOkJoWzAyx0WngOBgxSAsZw@mail.gmail.com>
 <21690dfc-9970-d1c8-a3ee-cb655d27f10a@oracle.com>
 <03b6b91d-d3f9-a551-62cc-1b70c14e121e@oracle.com>
 <df3891cf-9d5b-f105-d133-c78d63b7784a@oracle.com>
 <e2d94951-ea11-6f0a-e07f-7060ba75c2bd@oracle.com>
 <768a623a-2d8f-c69c-6a73-6ea8e73bab7a@oracle.com>
 <CANSoFxvzgaz4y-dNvk0N96bAoQEkZoK6gOPCYPGTtjoWE+TqSA@mail.gmail.com>
 <46cc73d8-4117-96e4-6f18-b17ed1e69166@oracle.com>
Message-ID: <1479348705.10794564.1675337409784.JavaMail.zimbra@u-pem.fr>

> From: "Maurizio Cimadamore" <maurizio.cimadamore at oracle.com>
> To: "Archie Cobbs" <archie.cobbs at gmail.com>, "Alex Buckley"
> <alex.buckley at oracle.com>
> Cc: "compiler-dev" <compiler-dev at openjdk.java.net>
> Sent: Thursday, February 2, 2023 11:25:10 AM
> Subject: Re: Type parameters inside super() calls?

> On 02/02/2023 02:04, Archie Cobbs wrote:

>> Put another way, a static method is just an instance method without a 'this'
>> instance. So neither issue #1 or #2 is possible. So, no problem, right?

>> You might be able to write code that looks silly, but would it actually be
>> nonsensical?

>> public class Foo<T extends Number> {
>> public static toFloat(T value) {
>> return value.floatValue(); // why not?
>> }
>> }

> IMHO, this is taking it a step too far.

> As I said, I believe the issue stems from using the "static context" trick to
> put restriction on _expressions_ - which then ends up also affecting _types_.

> I do not think the bug has to do with "static context" being ill-defined. There
> is a big difference between using a T in a constructor, and using T in a static
> method:

> * when a constructor is called, you are already initializing a _specific_
> instance, so T is _bound_;
> * when a static method is called, there is no instance, so T is _not bound_, and
> has no real meaning.

> Allowing access to T from static method as if it was a "real thing" seems like a
> recipe for disaster: how do we validate that a call to `toFloat` is correct?
> And, if `toFloat` returned a T, how do we validate that the return type is also
> used correctly at the callsite? And which synthetic cast should be generated
> (given that T not known?).
C# does something like this, 
with the call, Foo<String>.toFloat(), T is equals to String 
by extension, the call Foo.toFloat() is a raw call equivalent to Foo<Number>.toFloat(). 

It works because static fields have the same behavior, you have one static field value per specialization. 

This is not how Java works, and this is great for Valhalla because it means that Java does not have to reified parametrized types (no Foo<Integer> at runtime) but only to attach the type arguments to an existing Class at runtime (Foo + erasure[Integer]). This is an important difference because it means that there is no need to define the subtyping relationship between Foo<Integer> and Foo<Double>. 

> Maurizio

R?mi 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230202/edd99f33/attachment-0001.htm>

From jlahoda at openjdk.org  Thu Feb  2 12:11:26 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 2 Feb 2023 12:11:26 GMT
Subject: RFR: 8301025: ClassCastException in switch with generic record
In-Reply-To: <nCU-hxSmgegCT4CMPj1A9iVf-Q4UdSnT-bULBVa8m9I=.30dc7ac5-13c0-40eb-a1dc-0fb0267be580@github.com>
References: <nCU-hxSmgegCT4CMPj1A9iVf-Q4UdSnT-bULBVa8m9I=.30dc7ac5-13c0-40eb-a1dc-0fb0267be580@github.com>
Message-ID: <MgRc2VrVi-LzwCLbu8f_Z2ljwOU-DAYI7iBs5zN75XM=.6eea07e6-b109-492f-b3ad-b8af7ef63f86@github.com>

On Wed, 25 Jan 2023 15:11:40 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> Add missing class bound propagation during pattern matching translation.

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

> 483:                     cases.stream()
> 484:                          .flatMap(c -> c.labels.stream())
> 485:                          .map(l -> toLoadableConstant(l, seltype))

I believe it is a mistake to have non-erased types in the backend (after `TransTypes`). I.e. it is a mistake `TransPatterns` create a tree with non-erased type. Something like this might be a better solution:

diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java
index 57cd9671ca9..c928c7c75d1 100644
--- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java
+++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java
@@ -334,7 +334,7 @@ public class TransPatterns extends TreeTranslator {
             }
             JCMethodInvocation componentAccessor =
                     make.App(make.Select(convert(make.Ident(recordBinding), recordBinding.type), //TODO - cast needed????
-                             component.accessor));
+                             component.accessor)).setType(types.erasure(component.accessor.getReturnType()));
             if (deconstructorCalls == null) {
                 deconstructorCalls = Collections.newSetFromMap(new IdentityHashMap<>());
             }

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

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

From abimpoudis at openjdk.org  Thu Feb  2 13:00:06 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 2 Feb 2023 13:00:06 GMT
Subject: RFR: 8301025: ClassCastException in switch with generic record
 [v2]
In-Reply-To: <nCU-hxSmgegCT4CMPj1A9iVf-Q4UdSnT-bULBVa8m9I=.30dc7ac5-13c0-40eb-a1dc-0fb0267be580@github.com>
References: <nCU-hxSmgegCT4CMPj1A9iVf-Q4UdSnT-bULBVa8m9I=.30dc7ac5-13c0-40eb-a1dc-0fb0267be580@github.com>
Message-ID: <X7uO6sicgcPAK2zz4pJ1prWUN95MgjvAS1HDR-lRm7Y=.21a9461c-5bf9-4106-9b0c-8274cc7955a3@github.com>

> Add missing class bound propagation during pattern matching translation.

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

  Address review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12200/files
  - new: https://git.openjdk.org/jdk/pull/12200/files/c5600c9c..4a2810b2

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

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

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

From abimpoudis at openjdk.org  Thu Feb  2 13:00:10 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 2 Feb 2023 13:00:10 GMT
Subject: RFR: 8301025: ClassCastException in switch with generic record
 [v2]
In-Reply-To: <MgRc2VrVi-LzwCLbu8f_Z2ljwOU-DAYI7iBs5zN75XM=.6eea07e6-b109-492f-b3ad-b8af7ef63f86@github.com>
References: <nCU-hxSmgegCT4CMPj1A9iVf-Q4UdSnT-bULBVa8m9I=.30dc7ac5-13c0-40eb-a1dc-0fb0267be580@github.com>
 <MgRc2VrVi-LzwCLbu8f_Z2ljwOU-DAYI7iBs5zN75XM=.6eea07e6-b109-492f-b3ad-b8af7ef63f86@github.com>
Message-ID: <qXnjahDUdTFf1X-RoCaz4yu2A806T2nJ9HOWc4y0hUQ=.e5cdf993-4a81-44b4-b2b9-abde80fbee73@github.com>

On Thu, 2 Feb 2023 12:08:08 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java line 485:
> 
>> 483:                     cases.stream()
>> 484:                          .flatMap(c -> c.labels.stream())
>> 485:                          .map(l -> toLoadableConstant(l, seltype))
> 
> I believe it is a mistake to have non-erased types in the backend (after `TransTypes`). I.e. it is a mistake `TransPatterns` create a tree with non-erased type. Something like this might be a better solution:
> 
> diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java
> index 57cd9671ca9..c928c7c75d1 100644
> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java
> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java
> @@ -334,7 +334,7 @@ public class TransPatterns extends TreeTranslator {
>              }
>              JCMethodInvocation componentAccessor =
>                      make.App(make.Select(convert(make.Ident(recordBinding), recordBinding.type), //TODO - cast needed????
> -                             component.accessor));
> +                             component.accessor)).setType(types.erasure(component.accessor.getReturnType()));
>              if (deconstructorCalls == null) {
>                  deconstructorCalls = Collections.newSetFromMap(new IdentityHashMap<>());
>              }

Ha, indeed we need to keep the invariant "it is a mistake to have non-erased types in the backend".

I am convinced. 

Thx!

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

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

From prappo at openjdk.org  Thu Feb  2 14:21:53 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 2 Feb 2023 14:21:53 GMT
Subject: RFR: JDK-8300914: Allow `@` as an escape in documentation comments
 [v2]
In-Reply-To: <RMF0PaxzTeajAlAwtxmkogS__ZlDPL6m5ZoUN68kun8=.ec26d109-b4ca-4b7c-b0d8-74ac3c71ef2a@github.com>
References: <FuwqJLq_p2KGjWFYjms8z_Qvxbov1wlBFdgWDArxCb8=.b017e75e-2994-474c-b1cd-b1335ad1f274@github.com>
 <RMF0PaxzTeajAlAwtxmkogS__ZlDPL6m5ZoUN68kun8=.ec26d109-b4ca-4b7c-b0d8-74ac3c71ef2a@github.com>
Message-ID: <SWorQsA8z6f5ImSDRwATMRMi1MfaM1xJoKm6F_BdPS4=.8bf4e546-f91a-4518-a99b-e7cbbc8228a4@github.com>

On Wed, 1 Feb 2023 19:43:00 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a moderately simple update to permit the use of `@` as the escape character in a limited set of escape sequences.
>
> Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge with upstream/master
>  - JDK-8301294: Allow `@` as an escape in documentation comments

FWIW, I ran our CI with this PR and the run was green.

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 231:

> 229: 
> 230:                 case '@':
> 231:                     if (newline) {

Here and on L250: why do you set `newline` unconditionally immediately after reading a character?

test/langtools/tools/javac/doctree/AtEscapeTest.java line 39:

> 37:     /**
> 38:      * abc
> 39:      * @@tag

I'd add a couple of tests to assert that `@@` and `@*` also work in the middle of a line. Unlike `@/`, which requires preceding `*`, `@@` and `@*` do not require preceding whitespace. That seems useful. In particular, `@@` could be used in the middle of a line for robustness. For example, one could prepend plaintext `@Override` in the middle of a line with an extra `@` to defend against text reflow that brings `@Override` to the beginning of a line.

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

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

From archie.cobbs at gmail.com  Thu Feb  2 14:33:09 2023
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Thu, 2 Feb 2023 08:33:09 -0600
Subject: Type parameters inside super() calls?
In-Reply-To: <50e30583-5516-0335-f4cf-1dd63ab73651@oracle.com>
References: <CANSoFxtsXsUxy1Xr5K8KGOSNd8-gOkJoWzAyx0WngOBgxSAsZw@mail.gmail.com>
 <21690dfc-9970-d1c8-a3ee-cb655d27f10a@oracle.com>
 <03b6b91d-d3f9-a551-62cc-1b70c14e121e@oracle.com>
 <df3891cf-9d5b-f105-d133-c78d63b7784a@oracle.com>
 <e2d94951-ea11-6f0a-e07f-7060ba75c2bd@oracle.com>
 <768a623a-2d8f-c69c-6a73-6ea8e73bab7a@oracle.com>
 <CANSoFxvzgaz4y-dNvk0N96bAoQEkZoK6gOPCYPGTtjoWE+TqSA@mail.gmail.com>
 <50e30583-5516-0335-f4cf-1dd63ab73651@oracle.com>
Message-ID: <CANSoFxs=cszkRC5MmEzhWr7W67cd6YxQPaxAK5M1KG5ctf06dw@mail.gmail.com>

On Thu, Feb 2, 2023 at 4:18 AM Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

> On 02/02/2023 02:04, Archie Cobbs wrote:
>
> In other words the type itself is not a problem. There's no mention of
> types at all in the above two reasons.
>
> Exactly - I came up with the same conclusion in my long-winded reply to
> myself :-)
>

Hah, glad we think alike. At least that makes two of us.


> So one thought experiment is: What would happen if we eliminated all
> restrictions on generic type parameters in static contexts? What would
> actually go wrong?
>
> In other words, my angle is the opposite: if javac blindly followed the
> "static context" rule, what would happen to existing code? What could go
> wrong? And my answer there was: quite a bit, actually. Which leads me to
> think that the "static" rule, while fine in a pre-generics world (and in a
> world where super calls are the first statement in a constructor) is a good
> and concise way to say what we mean. But, in a post-generics world,
> conflating types with expressions (and initializaton only cares about the
> latter) leads to problems - at least if restrictions are to be interpreted
> literally.
>

I agree that something definitely needs to be improved here...

I do not think the bug has to do with "static context" being ill-defined.
> There is a big difference between using a T in a constructor, and using T
> in a static method:
>
> * when a constructor is called, you are already initializing a _specific_
> instance, so T is _bound_;
> * when a static method is called, there is no instance, so T is _not
> bound_, and has no real meaning.
>
Good point, these are definitely two different cases.

So it sounds like we both agree the use of T in a constructor (case #1),
even prior to super(), should be allowed. Of course the 'this' instance,
which happens to have a type involving T, is unavailable, but that's really
an entirely separate issue.

> Allowing access to T from static method as if it was a "real thing"  seems
> like a recipe for disaster:
>
Well in my twisted way of looking at it, a static method is just an
instance method with one less parameter, and yes, it so happens that the
particular parameter that's missing happens to have a type involving T, but
so what? That doesn't affect how we should treat T itself. As in
constructors (case #1), these are two separate issues.

> how do we validate that a call to `toFloat` is correct? And, if `toFloat`
> returned a T, how do we validate that the return type is also used
> correctly at the callsite? And which synthetic cast should be generated
> (given that T not known?).
>
I think the answer would be "T is always not known". So you fall into the
same behavior as you would with a Foo<?>.

Referring to the example (btw, I forgot to include the return type of the
method which obviously is float):

- Any call to toFloat() is correct, because T has Number as upper bound.
Same as if the method were not static and you invoked it on a Foo<?>.
- If a static method returns T, then the compiler treats this as if it
returned ? extends Number.
- The synthetic cast for T would always be to Number

I'm NOT saying that allowing static methods would be an intuitive and
obviously beneficial addition to the language. I'm just saying that it
could be done in a reasonably coherent way. The point of that is just to
provide more evidence that it's NOT automatically true that type parameters
should be forbidden from static contexts.

-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230202/3f5e6b6d/attachment.htm>

From maurizio.cimadamore at oracle.com  Thu Feb  2 15:02:55 2023
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Thu, 2 Feb 2023 15:02:55 +0000
Subject: Type parameters inside super() calls?
In-Reply-To: <CANSoFxs=cszkRC5MmEzhWr7W67cd6YxQPaxAK5M1KG5ctf06dw@mail.gmail.com>
References: <CANSoFxtsXsUxy1Xr5K8KGOSNd8-gOkJoWzAyx0WngOBgxSAsZw@mail.gmail.com>
 <21690dfc-9970-d1c8-a3ee-cb655d27f10a@oracle.com>
 <03b6b91d-d3f9-a551-62cc-1b70c14e121e@oracle.com>
 <df3891cf-9d5b-f105-d133-c78d63b7784a@oracle.com>
 <e2d94951-ea11-6f0a-e07f-7060ba75c2bd@oracle.com>
 <768a623a-2d8f-c69c-6a73-6ea8e73bab7a@oracle.com>
 <CANSoFxvzgaz4y-dNvk0N96bAoQEkZoK6gOPCYPGTtjoWE+TqSA@mail.gmail.com>
 <50e30583-5516-0335-f4cf-1dd63ab73651@oracle.com>
 <CANSoFxs=cszkRC5MmEzhWr7W67cd6YxQPaxAK5M1KG5ctf06dw@mail.gmail.com>
Message-ID: <51b9794a-1ccf-6129-bede-5ff60478d3fc@oracle.com>


On 02/02/2023 14:33, Archie Cobbs wrote:
> Referring to the example (btw, I forgot to include the return type of 
> the method which obviously is float):
>
> - Any call to toFloat() is correct, because T has Number as upper 
> bound. Same as if the method were not static and you invoked it on a 
> Foo<?>.
> - If a static method returns T, then the compiler treats this as if it 
> returned ? extends Number.
> - The synthetic cast for T would always be to Number
>
> I'm NOT saying that allowing static methods would be an intuitive and 
> obviously beneficial addition to the language. I'm just saying that it 
> could be done in a reasonably coherent way. The point of that is just 
> to provide more evidence that it's NOT automatically true that type 
> parameters should be forbidden from static contexts.
>
There are indeed more ways to get there - but I believe that this 
particular way doesn't seem very economical - because different 
occurrences of T in different methods (static vs. instance) end up 
having different semantics. Which seems indesirable and put (as Remi 
observed) this on collision course with any attempt to add "species 
statics" later on (e.g. specialization-specific type parameters).

So, in abstract terms I agree with you; for the specific case of the 
Java language we have, I tend to disagree - regular type parameters and 
static contexts don't seem a good fit.

Maurizio
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230202/84a86c87/attachment-0001.htm>

From brian.goetz at oracle.com  Thu Feb  2 15:20:43 2023
From: brian.goetz at oracle.com (Brian Goetz)
Date: Thu, 2 Feb 2023 10:20:43 -0500
Subject: Type parameters inside super() calls?
In-Reply-To: <46cc73d8-4117-96e4-6f18-b17ed1e69166@oracle.com>
References: <CANSoFxtsXsUxy1Xr5K8KGOSNd8-gOkJoWzAyx0WngOBgxSAsZw@mail.gmail.com>
 <21690dfc-9970-d1c8-a3ee-cb655d27f10a@oracle.com>
 <03b6b91d-d3f9-a551-62cc-1b70c14e121e@oracle.com>
 <df3891cf-9d5b-f105-d133-c78d63b7784a@oracle.com>
 <e2d94951-ea11-6f0a-e07f-7060ba75c2bd@oracle.com>
 <768a623a-2d8f-c69c-6a73-6ea8e73bab7a@oracle.com>
 <CANSoFxvzgaz4y-dNvk0N96bAoQEkZoK6gOPCYPGTtjoWE+TqSA@mail.gmail.com>
 <46cc73d8-4117-96e4-6f18-b17ed1e69166@oracle.com>
Message-ID: <ea95b4d5-b4bd-5ed0-6006-c3284b0dc5f2@oracle.com>

Yeah, I think we are abusing the notion of static context here.? It 
worked pre-generics, but there is no reason the class tvars should not 
be in scope.? And when you extend to statements before the super, 
there's no reason they should not be in scope there.

I think the cure here is to simply update the constructor-body logic to 
say that this region is not a static context, but a restricted context 
in which you can't use this, super, instance members, etc.? This is a 
small and localized change (to spec language we're already touching anyway.)

On 2/2/2023 5:25 AM, Maurizio Cimadamore wrote:
>
>
> On 02/02/2023 02:04, Archie Cobbs wrote:
>> Put another way, a static method is just an instance method without a 
>> 'this' instance. So neither issue #1 or #2 is possible. So, no 
>> problem, right?
>>
>> You might be able to write code that looks silly, but would it 
>> actually be nonsensical?
>>
>> ??? public class Foo<T extends Number> {
>> ??????? public static toFloat(T value) {
>> ??????????? return value.floatValue();?? // why not?
>> ??????? }
>> ??? }
>>
> IMHO, this is taking it a step too far.
>
> As I said, I believe the issue stems from using the "static context" 
> trick to put restriction on _expressions_ - which then ends up also 
> affecting _types_.
>
> I do not think the bug has to do with "static context" being 
> ill-defined. There is a big difference between using a T in a 
> constructor, and using T in a static method:
>
> * when a constructor is called, you are already initializing a 
> _specific_ instance, so T is _bound_;
> * when a static method is called, there is no instance, so T is _not 
> bound_, and has no real meaning.
>
> Allowing access to T from static method as if it was a "real thing"? 
> seems like a recipe for disaster: how do we validate that a call to 
> `toFloat` is correct? And, if `toFloat` returned a T, how do we 
> validate that the return type is also used correctly at the callsite? 
> And which synthetic cast should be generated (given that T not known?).
>
> Maurizio
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230202/cc595ccb/attachment.htm>

From jjg at openjdk.org  Thu Feb  2 15:28:48 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 2 Feb 2023 15:28:48 GMT
Subject: Integrated: JDK-8301636: Minor cleanup in CommentHelper and DocPretty
In-Reply-To: <MIsQ48OrPq1EozZ6Gr_gksWKxRzL0MyoqDzOfjUPB08=.798b18ff-87ad-4d9f-8203-b46f02aaaa05@github.com>
References: <MIsQ48OrPq1EozZ6Gr_gksWKxRzL0MyoqDzOfjUPB08=.798b18ff-87ad-4d9f-8203-b46f02aaaa05@github.com>
Message-ID: <sAChUR8LyjFDuoGD_5ENYk1Qtg2zDvFxJMs24ukJaDI=.38a000a8-a9c2-44f3-9c70-ae017a7ecd13@github.com>

On Wed, 1 Feb 2023 21:14:42 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review some simple cleanup suggested by IntelliJ IDEA that would be too much of a distraction in an otherwise unrelated PR.

This pull request has now been integrated.

Changeset: 930ec008
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/930ec008e00ea83b3d6ca21631d0cc15c9a3f4d8
Stats:     79 lines in 2 files changed: 0 ins; 52 del; 27 mod

8301636: Minor cleanup in CommentHelper and DocPretty

Reviewed-by: prappo

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

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

From archie.cobbs at gmail.com  Thu Feb  2 15:55:19 2023
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Thu, 2 Feb 2023 09:55:19 -0600
Subject: Type parameters inside super() calls?
In-Reply-To: <51b9794a-1ccf-6129-bede-5ff60478d3fc@oracle.com>
References: <CANSoFxtsXsUxy1Xr5K8KGOSNd8-gOkJoWzAyx0WngOBgxSAsZw@mail.gmail.com>
 <21690dfc-9970-d1c8-a3ee-cb655d27f10a@oracle.com>
 <03b6b91d-d3f9-a551-62cc-1b70c14e121e@oracle.com>
 <df3891cf-9d5b-f105-d133-c78d63b7784a@oracle.com>
 <e2d94951-ea11-6f0a-e07f-7060ba75c2bd@oracle.com>
 <768a623a-2d8f-c69c-6a73-6ea8e73bab7a@oracle.com>
 <CANSoFxvzgaz4y-dNvk0N96bAoQEkZoK6gOPCYPGTtjoWE+TqSA@mail.gmail.com>
 <50e30583-5516-0335-f4cf-1dd63ab73651@oracle.com>
 <CANSoFxs=cszkRC5MmEzhWr7W67cd6YxQPaxAK5M1KG5ctf06dw@mail.gmail.com>
 <51b9794a-1ccf-6129-bede-5ff60478d3fc@oracle.com>
Message-ID: <CANSoFxvxnb5QEH_EaAMByqeHzD0tjmYVEiOyg83gGCYHzzB5cw@mail.gmail.com>

On Thu, Feb 2, 2023 at 9:03 AM Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

> On 02/02/2023 14:33, Archie Cobbs wrote:
>
> Referring to the example (btw, I forgot to include the return type of the
> method which obviously is float):
>
> - Any call to toFloat() is correct, because T has Number as upper bound.
> Same as if the method were not static and you invoked it on a Foo<?>.
> - If a static method returns T, then the compiler treats this as if it
> returned ? extends Number.
> - The synthetic cast for T would always be to Number
>
> I'm NOT saying that allowing static methods would be an intuitive and
> obviously beneficial addition to the language. I'm just saying that it
> could be done in a reasonably coherent way. The point of that is just to
> provide more evidence that it's NOT automatically true that type parameters
> should be forbidden from static contexts.
>
> There are indeed more ways to get there - but I believe that this
> particular way doesn't seem very economical - because different occurrences
> of T in different methods (static vs. instance) end up having different
> semantics. Which seems indesirable and put (as Remi observed) this on
> collision course with any attempt to add "species statics" later on (e.g.
> specialization-specific type parameters).
>
> So, in abstract terms I agree with you; for the specific case of the Java
> language we have, I tend to disagree - regular type parameters and static
> contexts don't seem a good fit.
>
We do agree - I don't think it's a good fit either. I'm just saying it's an
interesting thought experiment, and it shows that types don't NEED to be
excluded from static contexts "in abstract terms".

-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230202/15cb411c/attachment-0001.htm>

From archie.cobbs at gmail.com  Thu Feb  2 16:10:06 2023
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Thu, 2 Feb 2023 10:10:06 -0600
Subject: Type parameters inside super() calls?
In-Reply-To: <ea95b4d5-b4bd-5ed0-6006-c3284b0dc5f2@oracle.com>
References: <CANSoFxtsXsUxy1Xr5K8KGOSNd8-gOkJoWzAyx0WngOBgxSAsZw@mail.gmail.com>
 <21690dfc-9970-d1c8-a3ee-cb655d27f10a@oracle.com>
 <03b6b91d-d3f9-a551-62cc-1b70c14e121e@oracle.com>
 <df3891cf-9d5b-f105-d133-c78d63b7784a@oracle.com>
 <e2d94951-ea11-6f0a-e07f-7060ba75c2bd@oracle.com>
 <768a623a-2d8f-c69c-6a73-6ea8e73bab7a@oracle.com>
 <CANSoFxvzgaz4y-dNvk0N96bAoQEkZoK6gOPCYPGTtjoWE+TqSA@mail.gmail.com>
 <46cc73d8-4117-96e4-6f18-b17ed1e69166@oracle.com>
 <ea95b4d5-b4bd-5ed0-6006-c3284b0dc5f2@oracle.com>
Message-ID: <CANSoFxs+jiQDcPw8HRUbUf5v4B8cqEfFFk-mDw0zD8yXGn5kow@mail.gmail.com>

On Thu, Feb 2, 2023 at 9:20 AM Brian Goetz <brian.goetz at oracle.com> wrote:

> And when you extend to statements before the super, there's no reason they
> should not be in scope there.
>

Here's a plausible if a bit contrived example of needing a type parameter
prior to super():

import java.util.*;
import java.util.concurrent.atomic.*;

public class TypeParamCtorPrologue<T> extends AtomicReference<T> {

    /**
     * Initialize using the list element with the smallest hash code.
     */
    public TypeParamCtorPrologue(List<T> objs) {
        final T choice = objs.stream()
          .sorted(Comparator.comparingInt(T::hashCode))
          .findFirst();
          .orElse(null);
        super(choice);
    }
}

The "choice" calculation could have also been inlined into the super()
call, so this is not a new problem with the spec.

Because of the reported compiler bug, that variant is (incorrectly) allowed
by the current compiler:

import java.util.*;
import java.util.concurrent.atomic.*;
public class TypeParamCtorPrologue<T> extends AtomicReference<T> {

    /**
     * Choose the object in the list with the smallest hash code.
     */
    public TypeParamCtorPrologue(List<T> objs) {
        super(objs.stream()
          .sorted(Comparator.comparingInt(T::hashCode))
          .findFirst()
          .orElse(null));
    }
}

So the current situation is one of two wrongs making a right.

I think the cure here is to simply update the constructor-body logic to say
> that this region is not a static context, but a restricted context in which
> you can't use this, super, instance members, etc.  This is a small and
> localized change (to spec language we're already touching anyway.)
>

This would correct both wrongs at once and automatically fix the reported
bug. So I'm all for it :)

-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230202/e5178b8a/attachment.htm>

From jlahoda at openjdk.org  Thu Feb  2 17:52:24 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 2 Feb 2023 17:52:24 GMT
Subject: RFR: 8301025: ClassCastException in switch with generic record
 [v2]
In-Reply-To: <X7uO6sicgcPAK2zz4pJ1prWUN95MgjvAS1HDR-lRm7Y=.21a9461c-5bf9-4106-9b0c-8274cc7955a3@github.com>
References: <nCU-hxSmgegCT4CMPj1A9iVf-Q4UdSnT-bULBVa8m9I=.30dc7ac5-13c0-40eb-a1dc-0fb0267be580@github.com>
 <X7uO6sicgcPAK2zz4pJ1prWUN95MgjvAS1HDR-lRm7Y=.21a9461c-5bf9-4106-9b0c-8274cc7955a3@github.com>
Message-ID: <-aP5I8EBSW4PW5A5D_x-GJR9YhQE4uHfZDrhT95wT3g=.bfd11728-145a-4d24-8d7d-40b479615fc2@github.com>

On Thu, 2 Feb 2023 13:00:06 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> Add missing class bound propagation during pattern matching translation.
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review

Looks good to me.

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

Marked as reviewed by jlahoda (Reviewer).

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

From prappo at openjdk.org  Thu Feb  2 18:08:29 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 2 Feb 2023 18:08:29 GMT
Subject: RFR: JDK-8300914: Allow `@` as an escape in documentation comments
 [v2]
In-Reply-To: <SWorQsA8z6f5ImSDRwATMRMi1MfaM1xJoKm6F_BdPS4=.8bf4e546-f91a-4518-a99b-e7cbbc8228a4@github.com>
References: <FuwqJLq_p2KGjWFYjms8z_Qvxbov1wlBFdgWDArxCb8=.b017e75e-2994-474c-b1cd-b1335ad1f274@github.com>
 <RMF0PaxzTeajAlAwtxmkogS__ZlDPL6m5ZoUN68kun8=.ec26d109-b4ca-4b7c-b0d8-74ac3c71ef2a@github.com>
 <SWorQsA8z6f5ImSDRwATMRMi1MfaM1xJoKm6F_BdPS4=.8bf4e546-f91a-4518-a99b-e7cbbc8228a4@github.com>
Message-ID: <3Kk2ozsTQwhb0-Xa-Nk1ggX_ngV4_yP-97d1TAjX464=.390bc514-9063-4ea4-8b56-dd88fbe87b2f@github.com>

On Thu, 2 Feb 2023 13:01:29 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
>> 
>>  - Merge with upstream/master
>>  - JDK-8301294: Allow `@` as an escape in documentation comments
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 231:
> 
>> 229: 
>> 230:                 case '@':
>> 231:                     if (newline) {
> 
> Here and on L250: why do you set `newline` unconditionally immediately after reading a character?

Oops, wrong "Here" line. Should be 238; so the two lines are 238 and 250.

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

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

From vromero at openjdk.org  Thu Feb  2 19:30:06 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 2 Feb 2023 19:30:06 GMT
Subject: RFR: 8295019: Cannot call a method with a parameter of a local
 class declared in a lambda [v4]
In-Reply-To: <RgTl0a5A7X51DERBJaYhKfiOgZmo-qbXUpWbLoZJwd8=.e869c7c9-fed7-478f-a974-f812b44ee277@github.com>
References: <RgTl0a5A7X51DERBJaYhKfiOgZmo-qbXUpWbLoZJwd8=.e869c7c9-fed7-478f-a974-f812b44ee277@github.com>
Message-ID: <nyvMwQrz02Ym-VJqaFNvQbBh8cNxZ3L4Yvu80hL7yeQ=.42d666c3-ac39-4055-b924-241456706bd5@github.com>

> Very interesting and, a bit, tricky bug. So the compiler is rejecting code like:
> 
> class LocalClassDeclaredInsideLambdaTest {
>     void run(Runnable r) {}
> 
>     void m() {
>         run(() -> {
>             class C {
>                 static void takeC(C c) {}
>                 static C giveC() {
>                     return null;
>                 }
>             }
>             C.takeC(C.giveC());
>         });
>     }
> }
> 
> with error:
> 
> LocalClassInsideLambda.java:12: error: incompatible types: C cannot be converted to C
>             C.takeC(C.giveC());
>                            ^
> Note: Some messages have been simplified; recompile with -Xdiags:verbose to get full output
> 1 error
> 
> which is very misleading as the type seems to be the same. The issue here is that both the lambda and invocation `C.giveC()` are considered poly expressions. `C.giveC()` is not a poly expression but at the moment the compiler is analyzing if an invocation is a poly expression or not, it doesn't have enough information and errs on the safe side.
> 
> We have a cache at `com.sun.tools.javac.comp.ArgumentAttr`, see field `argumentTypeCache`, which stores the current deferred type of arguments considered poly expressions. The problem with this particular code is that inside of the lambda there is a class declaration and every time the lambda is attributed a new class type is created.
> 
> The lambda, and thus the expression `C.giveC()` are attributed twice. The first time we have an speculative attribution, as a result `argumentTypeCache` will have two entries, one for the lambda and one for `C.giveC()` but the type of `C` is the type created during speculative attribution on a copy of the original lambda tree, let's call it C1. Later on another pass the lambda is attributed `"for real"`, during the check phase. At this point the entry for the lambda in the cache pointed by `argumentTypeCache` has been removed but there is still the entry for `C.giveC()` which still refers to `C1`. So now in the `"for real"` attribution of the lambda which happens on the original tree, not in a copy, a new type for class `C` is created, let's call it `C2`. But when we get to the point where we need to attribute again `C.takeC(C.giveC())` invocation `C.takeC` is expecting `C2` but as `C.giveC()` is again considered a poly expression and an entry is found for it at the cache, the comp
 iler reuses that entry which refers to `C1`. And unfortunately `C1 != C2` and thus the error is issued. So the solution I propose is to use a local cache for the speculative attribution of lambda expressions. This is a one liner fix, although an alternative solution could be to scan the lambda body and only use a local cache if a new type is defined inside the lambda, this could be a more optimal solution performance wise as we could save some attributions in some cases. Comments?
> 
> TIA

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

  a more general approach to cover every expression

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12303/files
  - new: https://git.openjdk.org/jdk/pull/12303/files/f0a298da..ce51420f

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

  Stats: 194 lines in 3 files changed: 104 ins; 85 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/12303.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12303/head:pull/12303

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

From jjg at openjdk.org  Thu Feb  2 19:41:25 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 2 Feb 2023 19:41:25 GMT
Subject: RFR: JDK-8300914: Allow `@` as an escape in documentation comments
 [v2]
In-Reply-To: <kUlqiNAySl3KF_olX7gReT4SS0tq_gurTVNC67XR0UQ=.052015ef-04b2-4353-b34b-3e5e9c67ceea@github.com>
References: <FuwqJLq_p2KGjWFYjms8z_Qvxbov1wlBFdgWDArxCb8=.b017e75e-2994-474c-b1cd-b1335ad1f274@github.com>
 <RMF0PaxzTeajAlAwtxmkogS__ZlDPL6m5ZoUN68kun8=.ec26d109-b4ca-4b7c-b0d8-74ac3c71ef2a@github.com>
 <kUlqiNAySl3KF_olX7gReT4SS0tq_gurTVNC67XR0UQ=.052015ef-04b2-4353-b34b-3e5e9c67ceea@github.com>
Message-ID: <_OZF5XKxDKfgkZfkRE1f7T4u6_LNivE0UiUYFi-c22E=.a3b4ed76-f79f-4760-bc0b-4bf61399242f@github.com>

On Thu, 2 Feb 2023 10:41:27 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
>> 
>>  - Merge with upstream/master
>>  - JDK-8301294: Allow `@` as an escape in documentation comments
>
> src/jdk.compiler/share/classes/com/sun/source/doctree/EscapeTree.java line 37:
> 
>> 35:  * <ul>
>> 36:  *     <li>{@code @@}, representing {@code @}, where it would otherwise be treated as introducing a block or inline tag,
>> 37:  *     <li>{@code @/}, representing {@code /}, as part of {@code *@/} to represent <code>&ast;&sol;</code>, and
> 
> For other reviewers. Interpret that middle bullet literally: `@` escapes `/` only if it is preceded by `*`. In other words, it's a triple `*@/`, not a pair `@/`.
> 
> `@/` without preceding `*` causes errors if it can be confused for a start of a tag.
> 
> For a block tag:
> 
>     error: no tag name after '@'
>          @/
>           ^
> 
> For an inline tag:
> 
>     error: no tag name after '@'
>          {@/
>           ^
> 
> (FWIW, @jonathan-gibbons, note that the caret positions differ: the former points to `/` while the latter points to `@`. )
> 
> `*` is a sort of looked-behind and not consumed, which can be seen from the fact that
> 
>     /**
>      @*@/
>      */
> 
> is translated to this in documentation
> 
>     */
> 
> Given all of the above, I'm not sure if `@/` can be technically qualified as an ordinary escape sequence.

'/' cannot be part of a tag name.

A tag name starts with a character for which `isUnicodeIdentifierStart` is true, followed by zero or more characters for which `isUnicodeIdentifierPart` is true or is one of `.`, `-`, `:`.  See `DocCommentParser.readTagName` for verification. (We should update the Doc Comment Spec for that as well.)

So, the text of error messages above are correct, even if the positions require tweaking.

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

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

From jjg at openjdk.org  Thu Feb  2 19:55:28 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 2 Feb 2023 19:55:28 GMT
Subject: RFR: JDK-8300914: Allow `@` as an escape in documentation comments
 [v2]
In-Reply-To: <3Kk2ozsTQwhb0-Xa-Nk1ggX_ngV4_yP-97d1TAjX464=.390bc514-9063-4ea4-8b56-dd88fbe87b2f@github.com>
References: <FuwqJLq_p2KGjWFYjms8z_Qvxbov1wlBFdgWDArxCb8=.b017e75e-2994-474c-b1cd-b1335ad1f274@github.com>
 <RMF0PaxzTeajAlAwtxmkogS__ZlDPL6m5ZoUN68kun8=.ec26d109-b4ca-4b7c-b0d8-74ac3c71ef2a@github.com>
 <SWorQsA8z6f5ImSDRwATMRMi1MfaM1xJoKm6F_BdPS4=.8bf4e546-f91a-4518-a99b-e7cbbc8228a4@github.com>
 <3Kk2ozsTQwhb0-Xa-Nk1ggX_ngV4_yP-97d1TAjX464=.390bc514-9063-4ea4-8b56-dd88fbe87b2f@github.com>
Message-ID: <ehK90OyAg0fs4GcaNYn45N8359WVSEHxY3Qm6KzZl6Y=.ef8cb02b-f1c7-496e-9e0d-965cdfe12054@github.com>

On Thu, 2 Feb 2023 18:05:18 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 231:
>> 
>>> 229: 
>>> 230:                 case '@':
>>> 231:                     if (newline) {
>> 
>> Here and on L250: why do you set `newline` unconditionally immediately after reading a character?
>
> Oops, wrong "Here" line. Should be 238; so the two lines are 238 and 250.

`newline` is a flag with a name that is less than ideal. It indicates whether we are at the beginning of a line, part from whitespace.  It is used to determine whether an `@` character should be treated as introducing a block tag.  As soon as a non-white character is encountered, it is unconditionally set to `false`, and remains that way until the next newline is encountered.

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

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

From jjg at openjdk.org  Thu Feb  2 19:55:34 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 2 Feb 2023 19:55:34 GMT
Subject: RFR: JDK-8300914: Allow `@` as an escape in documentation comments
 [v2]
In-Reply-To: <SWorQsA8z6f5ImSDRwATMRMi1MfaM1xJoKm6F_BdPS4=.8bf4e546-f91a-4518-a99b-e7cbbc8228a4@github.com>
References: <FuwqJLq_p2KGjWFYjms8z_Qvxbov1wlBFdgWDArxCb8=.b017e75e-2994-474c-b1cd-b1335ad1f274@github.com>
 <RMF0PaxzTeajAlAwtxmkogS__ZlDPL6m5ZoUN68kun8=.ec26d109-b4ca-4b7c-b0d8-74ac3c71ef2a@github.com>
 <SWorQsA8z6f5ImSDRwATMRMi1MfaM1xJoKm6F_BdPS4=.8bf4e546-f91a-4518-a99b-e7cbbc8228a4@github.com>
Message-ID: <_8jB-KzNpNKsWiYByy7_ffiGg2Na-jTSWnk7tbcmFmQ=.2f38e38c-2aa6-4d1c-a7e8-53aa71df41be@github.com>

On Thu, 2 Feb 2023 14:16:33 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
>> 
>>  - Merge with upstream/master
>>  - JDK-8301294: Allow `@` as an escape in documentation comments
>
> test/langtools/tools/javac/doctree/AtEscapeTest.java line 39:
> 
>> 37:     /**
>> 38:      * abc
>> 39:      * @@tag
> 
> I'd add a couple of tests to assert that `@@` and `@*` also work in the middle of a line. Unlike `@/`, which requires preceding `*`, `@@` and `@*` do not require preceding whitespace. That seems useful. In particular, `@@` could be used in the middle of a line for robustness. For example, one could prepend plaintext `@Override` in the middle of a line with an extra `@` to defend against text reflow that brings `@Override` to the beginning of a line.

Will do.

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

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

From vromero at openjdk.org  Thu Feb  2 19:57:24 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 2 Feb 2023 19:57:24 GMT
Subject: RFR: 8295019: Cannot call a method with a parameter of a local
 class declared in a lambda [v2]
In-Reply-To: <qgR22hG5jek5tgqVDri-GKe65D-GlgIf7SPBh1AN1QI=.4b34c61b-26b7-451e-9752-b17a43f58cc6@github.com>
References: <RgTl0a5A7X51DERBJaYhKfiOgZmo-qbXUpWbLoZJwd8=.e869c7c9-fed7-478f-a974-f812b44ee277@github.com>
 <OXdmJRiG6RLel5ftRxoM9ehem8iFOGHM8Mq6_llJ4EM=.30bcee8b-2dff-49ae-99ad-6419228db059@github.com>
 <gxh6O-mSo5lj1jPuf6ADhN4Kzy5rO6Z11H3Z-yQhNmQ=.0c1e0050-ecba-4a75-8dc9-470d94e5ee45@github.com>
 <qgR22hG5jek5tgqVDri-GKe65D-GlgIf7SPBh1AN1QI=.4b34c61b-26b7-451e-9752-b17a43f58cc6@github.com>
Message-ID: <Q0Qg9sIPeDvqFBOrBkSHgculwVhohw0AMFWX-ZIvE7o=.32a1d155-b2f4-4087-a264-40065c90c1bc@github.com>

On Thu, 2 Feb 2023 00:22:06 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java line 462:
>> 
>>> 460:     }
>>> 461: 
>>> 462:     boolean hasTypeDeclaration(JCLambda lambda) {
>> 
>> This is a good start.
>> A couple of comments:
>> * I believe this problem is more general than just lambdas (e.g. switch expression probably suffers from that as well)
>> * It would be better to write a single visitor which does everything in a single pass, rather than visit every statement in a block explicitly (after all, that's what the visitor is gonna do anyways). I even believe the visitor should recurse into everything (including nested lambdas and classes - after all, a class _nested_ in a local class might have a type which is then referred by the lambda return type!).
>
> This is the equivalent bug with switch expression:
> 
> 
> class LocalClassDeclaredInsideSwitchTest {
>     void run(int i) {}
> 
>     void m(int o) {
>         run(switch(o) {
>           case 1 -> {
>             class C {
>                 static int takeC(C c) {}
>                 static C giveC() {
>                     return null;
>                 }
>             }
>             yield C.takeC(C.giveC());
>          }
>          default -> throw new AssertionError();
>        });
>     }
> }
> 
> 
> We should come up with a fix that is general enough to handle all these cases.

right, I forgot about that case, uploaded a new iteration, thanks!

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

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

From prappo at openjdk.org  Thu Feb  2 20:13:26 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 2 Feb 2023 20:13:26 GMT
Subject: RFR: JDK-8300914: Allow `@` as an escape in documentation comments
 [v2]
In-Reply-To: <ehK90OyAg0fs4GcaNYn45N8359WVSEHxY3Qm6KzZl6Y=.ef8cb02b-f1c7-496e-9e0d-965cdfe12054@github.com>
References: <FuwqJLq_p2KGjWFYjms8z_Qvxbov1wlBFdgWDArxCb8=.b017e75e-2994-474c-b1cd-b1335ad1f274@github.com>
 <RMF0PaxzTeajAlAwtxmkogS__ZlDPL6m5ZoUN68kun8=.ec26d109-b4ca-4b7c-b0d8-74ac3c71ef2a@github.com>
 <SWorQsA8z6f5ImSDRwATMRMi1MfaM1xJoKm6F_BdPS4=.8bf4e546-f91a-4518-a99b-e7cbbc8228a4@github.com>
 <3Kk2ozsTQwhb0-Xa-Nk1ggX_ngV4_yP-97d1TAjX464=.390bc514-9063-4ea4-8b56-dd88fbe87b2f@github.com>
 <ehK90OyAg0fs4GcaNYn45N8359WVSEHxY3Qm6KzZl6Y=.ef8cb02b-f1c7-496e-9e0d-965cdfe12054@github.com>
Message-ID: <Yjz8lcdn0YJuZveIMlI3TMiUIuST0Ud7vxy5ajW-0Jc=.3e8dc209-aa89-4d9a-810b-891fa94e1670@github.com>

On Thu, 2 Feb 2023 19:51:04 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Oops, wrong "Here" line. Should be 238; so the two lines are 238 and 250.
>
> `newline` is a flag with a name that is less than ideal. It indicates whether we are at the beginning of a line, part from whitespace.  It is used to determine whether an `@` character should be treated as introducing a block tag.  As soon as a non-white character is encountered, it is unconditionally set to `false`, and remains that way until the next newline is encountered.

What I mean is this: why would anyone read a character using `nextChar()`, which sets the flag if encounters a newline, and then immediately clears the flag?

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

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

From jjg at openjdk.org  Fri Feb  3 00:03:53 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 3 Feb 2023 00:03:53 GMT
Subject: RFR: JDK-8300914: Allow `@` as an escape in documentation comments
 [v2]
In-Reply-To: <Yjz8lcdn0YJuZveIMlI3TMiUIuST0Ud7vxy5ajW-0Jc=.3e8dc209-aa89-4d9a-810b-891fa94e1670@github.com>
References: <FuwqJLq_p2KGjWFYjms8z_Qvxbov1wlBFdgWDArxCb8=.b017e75e-2994-474c-b1cd-b1335ad1f274@github.com>
 <RMF0PaxzTeajAlAwtxmkogS__ZlDPL6m5ZoUN68kun8=.ec26d109-b4ca-4b7c-b0d8-74ac3c71ef2a@github.com>
 <SWorQsA8z6f5ImSDRwATMRMi1MfaM1xJoKm6F_BdPS4=.8bf4e546-f91a-4518-a99b-e7cbbc8228a4@github.com>
 <3Kk2ozsTQwhb0-Xa-Nk1ggX_ngV4_yP-97d1TAjX464=.390bc514-9063-4ea4-8b56-dd88fbe87b2f@github.com>
 <ehK90OyAg0fs4GcaNYn45N8359WVSEHxY3Qm6KzZl6Y=.ef8cb02b-f1c7-496e-9e0d-965cdfe12054@github.com>
 <Yjz8lcdn0YJuZveIMlI3TMiUIuST0Ud7vxy5ajW-0Jc=.3e8dc209-aa89-4d9a-810b-891fa94e1670@github.com>
Message-ID: <53A6P3L_tRweSeMrlFB-9W2yG92jCdFXQZpAPCM0k_Y=.f8bda728-d94f-4479-85e5-640964deacd4@github.com>

On Thu, 2 Feb 2023 20:11:03 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> `newline` is a flag with a name that is less than ideal. It indicates whether we are at the beginning of a line, part from whitespace.  It is used to determine whether an `@` character should be treated as introducing a block tag.  As soon as a non-white character is encountered, it is unconditionally set to `false`, and remains that way until the next newline is encountered.
>
> What I mean is this: why would anyone read a character using `nextChar()`, which sets the flag if encounters a newline, and then immediately clear the flag?

Aha, sorry, I misunderstood your comment.

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

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

From jjg at openjdk.org  Fri Feb  3 00:28:05 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 3 Feb 2023 00:28:05 GMT
Subject: RFR: JDK-8300914: Allow `@` as an escape in documentation comments
 [v2]
In-Reply-To: <_OZF5XKxDKfgkZfkRE1f7T4u6_LNivE0UiUYFi-c22E=.a3b4ed76-f79f-4760-bc0b-4bf61399242f@github.com>
References: <FuwqJLq_p2KGjWFYjms8z_Qvxbov1wlBFdgWDArxCb8=.b017e75e-2994-474c-b1cd-b1335ad1f274@github.com>
 <RMF0PaxzTeajAlAwtxmkogS__ZlDPL6m5ZoUN68kun8=.ec26d109-b4ca-4b7c-b0d8-74ac3c71ef2a@github.com>
 <kUlqiNAySl3KF_olX7gReT4SS0tq_gurTVNC67XR0UQ=.052015ef-04b2-4353-b34b-3e5e9c67ceea@github.com>
 <_OZF5XKxDKfgkZfkRE1f7T4u6_LNivE0UiUYFi-c22E=.a3b4ed76-f79f-4760-bc0b-4bf61399242f@github.com>
Message-ID: <SDcR_0h8wo_lAiJJIjSMBYchGvtI2MbdNuquBck1OlU=.93530241-33fe-4b74-a0c8-b092c6d6dbfd@github.com>

On Thu, 2 Feb 2023 19:38:34 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/source/doctree/EscapeTree.java line 37:
>> 
>>> 35:  * <ul>
>>> 36:  *     <li>{@code @@}, representing {@code @}, where it would otherwise be treated as introducing a block or inline tag,
>>> 37:  *     <li>{@code @/}, representing {@code /}, as part of {@code *@/} to represent <code>&ast;&sol;</code>, and
>> 
>> For other reviewers. Interpret that middle bullet literally: `@` escapes `/` only if it is preceded by `*`. In other words, it's a triple `*@/`, not a pair `@/`.
>> 
>> `@/` without preceding `*` causes errors if it can be confused for a start of a tag.
>> 
>> For a block tag:
>> 
>>     error: no tag name after '@'
>>          @/
>>           ^
>> 
>> For an inline tag:
>> 
>>     error: no tag name after '@'
>>          {@/
>>           ^
>> 
>> (FWIW, @jonathan-gibbons, note that the caret positions differ: the former points to `/` while the latter points to `@`. )
>> 
>> `*` is a sort of looked-behind and not consumed, which can be seen from the fact that
>> 
>>     /**
>>      @*@/
>>      */
>> 
>> is translated to this in documentation
>> 
>>     */
>> 
>> Given all of the above, I'm not sure if `@/` can be technically qualified as an ordinary escape sequence.
>
> '/' cannot be part of a tag name.
> 
> A tag name starts with a character for which `isUnicodeIdentifierStart` is true, followed by zero or more characters for which `isUnicodeIdentifierPart` is true or is one of `.`, `-`, `:`.  See `DocCommentParser.readTagName` for verification. (We should update the Doc Comment Spec for that as well.)
> 
> So, the text of error messages above are correct, even if the positions require tweaking.

Note that all the proposed escape sequences are context-sensitive, and are only enabled in appropriate circumstances.

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

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

From vromero at openjdk.org  Fri Feb  3 12:30:52 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 3 Feb 2023 12:30:52 GMT
Subject: RFR: 8301580: Error recovery does not clear returnResult
In-Reply-To: <5pitppiKIdloYWKA9MOQpJWhSlMuKYbMOU4h1sJ-eqQ=.2b7c84f4-227c-4608-b60f-ac0d11a1ed1b@github.com>
References: <5pitppiKIdloYWKA9MOQpJWhSlMuKYbMOU4h1sJ-eqQ=.2b7c84f4-227c-4608-b60f-ac0d11a1ed1b@github.com>
Message-ID: <XUakmFsBzo6aVQvNDofynHmF49j-caTdfkAb_zUxHYk=.ee9a129c-7286-4274-96b5-2a6cbf9dd46e@github.com>

On Wed, 1 Feb 2023 12:00:58 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Considering code like:
> 
> class C {
>     void m
>     {
>         return;
>     }
> }
> 
> 
> `void m` is wrapped in an erroneous tree (which is good), and if/when `Attr` is processing it in `visitErroneous`, it will create a new `Env` to attribute the erroneous part.
> 
> But, `Attr` will set a `returnResult` into the `Env`'s info - and that info is shared with the outter `Env`, so there will be a `returnResult` set after `visitErroneous`. `{ return ; }` is interpreted as an initializer, and there should be an error for the `return` there, but this error is missing, due to the set `returnResult`. This will then fail later in `Flow` with an exception:
> 
> 
> $ javac -XDshould-stop.at=FLOW -XDdev /tmp/C.java

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

> 5220:     public void visitErroneous(JCErroneous tree) {
> 5221:         if (tree.errs != null) {
> 5222:             Env<AttrContext> errEnv = env.dup(env.tree);

question: shouldn't we do: `env.dup(node, env.info.dup());` instead, that way both env's won't share the info?

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

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

From duke at openjdk.org  Fri Feb  3 17:41:31 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Fri, 3 Feb 2023 17:41:31 GMT
Subject: RFR: 8221580: Confusing diagnostic for assigning a static final field
 in a constructor
Message-ID: <VOJv0zjPJ5ubKy7RKH6Ekesk4PqDYR5ls4hmeLL2kqs=.1d1cf673-47bb-4bde-aaf0-702008c68dfd@github.com>

When a program attempts to assign a value to a final field, javac reports `cannot assign a value to final variable x`.

If the field is `static`, the exact same error message is used, which can be confusing, because no mention is made of the field's `static`ness.

This change does two things:
* Refactor the error message so that arbitrary modifiers can be included, instead of hard-wiring `final`
* Include both `static final` in the error message in the case of `static final` variables.

So for a `static final` field the error is now `cannot assign a value to static final variable x`.

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

Commit messages:
 - Distinguish static fields in "can't assign to final variable" error message.
 - Refactor error message to display arbitrary modifiers, not just 'final'.

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

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

From jjg at openjdk.org  Fri Feb  3 18:13:57 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 3 Feb 2023 18:13:57 GMT
Subject: RFR: JDK-8300914: Allow `@` as an escape in documentation comments
 [v2]
In-Reply-To: <8upQRH9JSnVu_rafGBiLGGcy95B9fmEhlZAoQCECRj0=.2f7036a8-176e-44df-bdc3-6f690d6df322@github.com>
References: <FuwqJLq_p2KGjWFYjms8z_Qvxbov1wlBFdgWDArxCb8=.b017e75e-2994-474c-b1cd-b1335ad1f274@github.com>
 <RMF0PaxzTeajAlAwtxmkogS__ZlDPL6m5ZoUN68kun8=.ec26d109-b4ca-4b7c-b0d8-74ac3c71ef2a@github.com>
 <8_sn3KytEC8oZf7krphnqREsrEvupP3iIlOZTST-5FQ=.e631623b-cd9d-49be-8796-b13d89227ddb@github.com>
 <8upQRH9JSnVu_rafGBiLGGcy95B9fmEhlZAoQCECRj0=.2f7036a8-176e-44df-bdc3-6f690d6df322@github.com>
Message-ID: <t4pinNDX67FBFsGpTLApExpIxPcqrMNu8-y4gkaL1bo=.5b9478d5-cfbb-4cac-aca4-e418cb819cea@github.com>

On Thu, 2 Feb 2023 00:39:02 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/source/doctree/DocTree.java line 110:
>> 
>>> 108:          * representing some escaped documentation text.
>>> 109:          */
>>> 110:         ESCAPE,
>> 
>> We seem to add `@since` to newer kinds of tags.
>
> Yes, ooops, I missed that one

fixed

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

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

From jjg at openjdk.org  Fri Feb  3 18:14:02 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 3 Feb 2023 18:14:02 GMT
Subject: RFR: JDK-8300914: Allow `@` as an escape in documentation comments
 [v2]
In-Reply-To: <8_sn3KytEC8oZf7krphnqREsrEvupP3iIlOZTST-5FQ=.e631623b-cd9d-49be-8796-b13d89227ddb@github.com>
References: <FuwqJLq_p2KGjWFYjms8z_Qvxbov1wlBFdgWDArxCb8=.b017e75e-2994-474c-b1cd-b1335ad1f274@github.com>
 <RMF0PaxzTeajAlAwtxmkogS__ZlDPL6m5ZoUN68kun8=.ec26d109-b4ca-4b7c-b0d8-74ac3c71ef2a@github.com>
 <8_sn3KytEC8oZf7krphnqREsrEvupP3iIlOZTST-5FQ=.e631623b-cd9d-49be-8796-b13d89227ddb@github.com>
Message-ID: <Qvov3WTGFYfuXLu2AnOotNUv1ZfD0o-kz5zh4gvrRls=.8d87c7c1-2858-41ac-8a7d-5850e4db792c@github.com>

On Wed, 1 Feb 2023 23:35:51 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
>> 
>>  - Merge with upstream/master
>>  - JDK-8301294: Allow `@` as an escape in documentation comments
>
> src/jdk.compiler/share/classes/com/sun/source/util/DocTreeScanner.java line 296:
> 
>> 294:     }
>> 295: 
>> 296: 
> 
> Remove newline.

??

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

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

From jjg at openjdk.org  Fri Feb  3 19:01:53 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 3 Feb 2023 19:01:53 GMT
Subject: RFR: JDK-8300914: Allow `@` as an escape in documentation comments
 [v2]
In-Reply-To: <SDcR_0h8wo_lAiJJIjSMBYchGvtI2MbdNuquBck1OlU=.93530241-33fe-4b74-a0c8-b092c6d6dbfd@github.com>
References: <FuwqJLq_p2KGjWFYjms8z_Qvxbov1wlBFdgWDArxCb8=.b017e75e-2994-474c-b1cd-b1335ad1f274@github.com>
 <RMF0PaxzTeajAlAwtxmkogS__ZlDPL6m5ZoUN68kun8=.ec26d109-b4ca-4b7c-b0d8-74ac3c71ef2a@github.com>
 <kUlqiNAySl3KF_olX7gReT4SS0tq_gurTVNC67XR0UQ=.052015ef-04b2-4353-b34b-3e5e9c67ceea@github.com>
 <_OZF5XKxDKfgkZfkRE1f7T4u6_LNivE0UiUYFi-c22E=.a3b4ed76-f79f-4760-bc0b-4bf61399242f@github.com>
 <SDcR_0h8wo_lAiJJIjSMBYchGvtI2MbdNuquBck1OlU=.93530241-33fe-4b74-a0c8-b092c6d6dbfd@github.com>
Message-ID: <tkGC6BzaTf_H3Yx3iEg3l3ckPFSRmaQEio8r34SgTeI=.45e9cead-7215-4444-a0ef-4b1fffc177a1@github.com>

On Fri, 3 Feb 2023 00:25:22 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> '/' cannot be part of a tag name.
>> 
>> A tag name starts with a character for which `isUnicodeIdentifierStart` is true, followed by zero or more characters for which `isUnicodeIdentifierPart` is true or is one of `.`, `-`, `:`.  See `DocCommentParser.readTagName` for verification. (We should update the Doc Comment Spec for that as well.)
>> 
>> So, the text of error messages above are correct, even if the positions require tweaking.
>
> Note that all the proposed escape sequences are context-sensitive, and are only enabled in appropriate circumstances.

updated code, comments and spec.

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

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

From jjg at openjdk.org  Fri Feb  3 19:01:55 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 3 Feb 2023 19:01:55 GMT
Subject: RFR: JDK-8300914: Allow `@` as an escape in documentation comments
 [v2]
In-Reply-To: <_8jB-KzNpNKsWiYByy7_ffiGg2Na-jTSWnk7tbcmFmQ=.2f38e38c-2aa6-4d1c-a7e8-53aa71df41be@github.com>
References: <FuwqJLq_p2KGjWFYjms8z_Qvxbov1wlBFdgWDArxCb8=.b017e75e-2994-474c-b1cd-b1335ad1f274@github.com>
 <RMF0PaxzTeajAlAwtxmkogS__ZlDPL6m5ZoUN68kun8=.ec26d109-b4ca-4b7c-b0d8-74ac3c71ef2a@github.com>
 <SWorQsA8z6f5ImSDRwATMRMi1MfaM1xJoKm6F_BdPS4=.8bf4e546-f91a-4518-a99b-e7cbbc8228a4@github.com>
 <_8jB-KzNpNKsWiYByy7_ffiGg2Na-jTSWnk7tbcmFmQ=.2f38e38c-2aa6-4d1c-a7e8-53aa71df41be@github.com>
Message-ID: <_7PKd6edXoycBJHkHmtn_Jj9oQChu3JsYJqX4amlKSc=.8135adcc-ac46-4041-b021-0b7cc524f511@github.com>

On Thu, 2 Feb 2023 19:52:36 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> test/langtools/tools/javac/doctree/AtEscapeTest.java line 39:
>> 
>>> 37:     /**
>>> 38:      * abc
>>> 39:      * @@tag
>> 
>> I'd add a couple of tests to assert that `@@` and `@*` also work in the middle of a line. Unlike `@/`, which requires preceding `*`, `@@` and `@*` do not require preceding whitespace. That seems useful. In particular, `@@` could be used in the middle of a line for robustness. For example, one could prepend plaintext `@Override` in the middle of a line with an extra `@` to defend against text reflow that brings `@Override` to the beginning of a line.
>
> Will do.

Note that `@@` and `@*` are also context-sensitive, and can only be used where the unescaped character would have a different effect.

Nevertheless, the suggestion for additional tests to demonstrate the behavior is well-taken.

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

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

From jlahoda at openjdk.org  Fri Feb  3 19:08:25 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 3 Feb 2023 19:08:25 GMT
Subject: RFR: 8301580: Error recovery does not clear returnResult [v2]
In-Reply-To: <5pitppiKIdloYWKA9MOQpJWhSlMuKYbMOU4h1sJ-eqQ=.2b7c84f4-227c-4608-b60f-ac0d11a1ed1b@github.com>
References: <5pitppiKIdloYWKA9MOQpJWhSlMuKYbMOU4h1sJ-eqQ=.2b7c84f4-227c-4608-b60f-ac0d11a1ed1b@github.com>
Message-ID: <_Mvu0bE4c3YmXhXRILWiywi-WJ8Hl2Cz-3n8rqCZjSU=.9d740933-ce65-4888-9532-dc1c237c4d25@github.com>

> Considering code like:
> 
> class C {
>     void m
>     {
>         return;
>     }
> }
> 
> 
> `void m` is wrapped in an erroneous tree (which is good), and if/when `Attr` is processing it in `visitErroneous`, it will create a new `Env` to attribute the erroneous part.
> 
> But, `Attr` will set a `returnResult` into the `Env`'s info - and that info is shared with the outter `Env`, so there will be a `returnResult` set after `visitErroneous`. `{ return ; }` is interpreted as an initializer, and there should be an error for the `return` there, but this error is missing, due to the set `returnResult`. This will then fail later in `Flow` with an exception:
> 
> 
> $ javac -XDshould-stop.at=FLOW -XDdev /tmp/C.java

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

  Using info.dup(), as suggested.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12361/files
  - new: https://git.openjdk.org/jdk/pull/12361/files/4acb0d43..06a70c81

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

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

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

From jlahoda at openjdk.org  Fri Feb  3 19:08:25 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 3 Feb 2023 19:08:25 GMT
Subject: RFR: 8301580: Error recovery does not clear returnResult [v2]
In-Reply-To: <XUakmFsBzo6aVQvNDofynHmF49j-caTdfkAb_zUxHYk=.ee9a129c-7286-4274-96b5-2a6cbf9dd46e@github.com>
References: <5pitppiKIdloYWKA9MOQpJWhSlMuKYbMOU4h1sJ-eqQ=.2b7c84f4-227c-4608-b60f-ac0d11a1ed1b@github.com>
 <XUakmFsBzo6aVQvNDofynHmF49j-caTdfkAb_zUxHYk=.ee9a129c-7286-4274-96b5-2a6cbf9dd46e@github.com>
Message-ID: <HhFWK098JEwzi6K8pag1k3nxUi4HYyHHdXWhAhW5-Cc=.1d2bbed9-8900-4341-bb77-80a71b471272@github.com>

On Fri, 3 Feb 2023 12:26:16 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Using info.dup(), as suggested.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 5222:
> 
>> 5220:     public void visitErroneous(JCErroneous tree) {
>> 5221:         if (tree.errs != null) {
>> 5222:             Env<AttrContext> errEnv = env.dup(env.tree);
> 
> question: shouldn't we do: `env.dup(node, env.info.dup());` instead, that way both env's won't share the info?

I was a little bit on the fence on this, as some code, like `Attr.attribClass` stores and re-sets the result, while other dupes the info. Let's dupe the info then. Thanks!

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

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

From vromero at openjdk.org  Fri Feb  3 20:19:50 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 3 Feb 2023 20:19:50 GMT
Subject: RFR: 8301580: Error recovery does not clear returnResult [v2]
In-Reply-To: <_Mvu0bE4c3YmXhXRILWiywi-WJ8Hl2Cz-3n8rqCZjSU=.9d740933-ce65-4888-9532-dc1c237c4d25@github.com>
References: <5pitppiKIdloYWKA9MOQpJWhSlMuKYbMOU4h1sJ-eqQ=.2b7c84f4-227c-4608-b60f-ac0d11a1ed1b@github.com>
 <_Mvu0bE4c3YmXhXRILWiywi-WJ8Hl2Cz-3n8rqCZjSU=.9d740933-ce65-4888-9532-dc1c237c4d25@github.com>
Message-ID: <9AHoBbCuzl4uNd4YEM5sqQQmgMoCq3uqD7-0P97OHVw=.2e3a401a-1d30-4013-afd0-15b590c5dd34@github.com>

On Fri, 3 Feb 2023 19:08:25 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Considering code like:
>> 
>> class C {
>>     void m
>>     {
>>         return;
>>     }
>> }
>> 
>> 
>> `void m` is wrapped in an erroneous tree (which is good), and if/when `Attr` is processing it in `visitErroneous`, it will create a new `Env` to attribute the erroneous part.
>> 
>> But, `Attr` will set a `returnResult` into the `Env`'s info - and that info is shared with the outter `Env`, so there will be a `returnResult` set after `visitErroneous`. `{ return ; }` is interpreted as an initializer, and there should be an error for the `return` there, but this error is missing, due to the set `returnResult`. This will then fail later in `Flow` with an exception:
>> 
>> 
>> $ javac -XDshould-stop.at=FLOW -XDdev /tmp/C.java
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Using info.dup(), as suggested.

looks good

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

Marked as reviewed by vromero (Reviewer).

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

From vromero at openjdk.org  Fri Feb  3 20:19:53 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 3 Feb 2023 20:19:53 GMT
Subject: RFR: 8301580: Error recovery does not clear returnResult [v2]
In-Reply-To: <HhFWK098JEwzi6K8pag1k3nxUi4HYyHHdXWhAhW5-Cc=.1d2bbed9-8900-4341-bb77-80a71b471272@github.com>
References: <5pitppiKIdloYWKA9MOQpJWhSlMuKYbMOU4h1sJ-eqQ=.2b7c84f4-227c-4608-b60f-ac0d11a1ed1b@github.com>
 <XUakmFsBzo6aVQvNDofynHmF49j-caTdfkAb_zUxHYk=.ee9a129c-7286-4274-96b5-2a6cbf9dd46e@github.com>
 <HhFWK098JEwzi6K8pag1k3nxUi4HYyHHdXWhAhW5-Cc=.1d2bbed9-8900-4341-bb77-80a71b471272@github.com>
Message-ID: <JqM8SEPAqqXvmVqQULxoUkOEeqiCRQ6eqZjBM56dmJQ=.7d69ee01-7d61-4ec1-abd5-a686e96f869a@github.com>

On Fri, 3 Feb 2023 19:04:15 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 5222:
>> 
>>> 5220:     public void visitErroneous(JCErroneous tree) {
>>> 5221:         if (tree.errs != null) {
>>> 5222:             Env<AttrContext> errEnv = env.dup(env.tree);
>> 
>> question: shouldn't we do: `env.dup(node, env.info.dup());` instead, that way both env's won't share the info?
>
> I was a little bit on the fence on this, as some code, like `Attr.attribClass` stores and re-sets the result, while other dupes the info. Let's dupe the info then. Thanks!

I see, I didn't realize of the other pattern, not duping the info, we should probably standardize what we do at some point

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

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

From jjg at openjdk.org  Fri Feb  3 20:25:53 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 3 Feb 2023 20:25:53 GMT
Subject: RFR: JDK-8301810: Bug in doctree DocCommentTester.compress
Message-ID: <u06shK1KvoC4Jfdj1DRzNuUAwTTc9igcXt2YIZ5v-d8=.0b364a28-49d2-42f5-add7-7614e571438c@github.com>

Please review a minor but long-standing bug in the code to "compress" long strings in the `doctree` `DocCommentTester` class.

The primary change is in `DocCommentTester`, to fix the code, and make it somewhat more robust.  The change does break some golden output, in comments and files, so advantage is taken to increase the max size of compressed strings.

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

Commit messages:
 - JDK-8301810: Bug in doctree DocCommentTester.compress

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

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

From jjg at openjdk.org  Fri Feb  3 21:17:54 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 3 Feb 2023 21:17:54 GMT
Subject: RFR: JDK-8300914: Allow `@` as an escape in documentation comments
 [v2]
In-Reply-To: <8_sn3KytEC8oZf7krphnqREsrEvupP3iIlOZTST-5FQ=.e631623b-cd9d-49be-8796-b13d89227ddb@github.com>
References: <FuwqJLq_p2KGjWFYjms8z_Qvxbov1wlBFdgWDArxCb8=.b017e75e-2994-474c-b1cd-b1335ad1f274@github.com>
 <RMF0PaxzTeajAlAwtxmkogS__ZlDPL6m5ZoUN68kun8=.ec26d109-b4ca-4b7c-b0d8-74ac3c71ef2a@github.com>
 <8_sn3KytEC8oZf7krphnqREsrEvupP3iIlOZTST-5FQ=.e631623b-cd9d-49be-8796-b13d89227ddb@github.com>
Message-ID: <-Di9SQl6wjMNyuIKc_SVwyA-37Zjd8bV0THXSKbDkII=.fdca104f-58f1-469d-abcb-029cf7f61e17@github.com>

On Wed, 1 Feb 2023 22:33:13 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
>> 
>>  - Merge with upstream/master
>>  - JDK-8301294: Allow `@` as an escape in documentation comments
>
> src/jdk.compiler/share/classes/com/sun/source/doctree/EscapeTree.java line 49:
> 
>> 47:      *
>> 48:      * <p>Note: this method returns the escaped character, not the original escape sequence.
>> 49:      *
> 
> Remove newline.

Rewritten this comment.

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

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

From jjg at openjdk.org  Fri Feb  3 21:26:51 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 3 Feb 2023 21:26:51 GMT
Subject: RFR: JDK-8300914: Allow `@` as an escape in documentation comments
 [v2]
In-Reply-To: <_7PKd6edXoycBJHkHmtn_Jj9oQChu3JsYJqX4amlKSc=.8135adcc-ac46-4041-b021-0b7cc524f511@github.com>
References: <FuwqJLq_p2KGjWFYjms8z_Qvxbov1wlBFdgWDArxCb8=.b017e75e-2994-474c-b1cd-b1335ad1f274@github.com>
 <RMF0PaxzTeajAlAwtxmkogS__ZlDPL6m5ZoUN68kun8=.ec26d109-b4ca-4b7c-b0d8-74ac3c71ef2a@github.com>
 <SWorQsA8z6f5ImSDRwATMRMi1MfaM1xJoKm6F_BdPS4=.8bf4e546-f91a-4518-a99b-e7cbbc8228a4@github.com>
 <_8jB-KzNpNKsWiYByy7_ffiGg2Na-jTSWnk7tbcmFmQ=.2f38e38c-2aa6-4d1c-a7e8-53aa71df41be@github.com>
 <_7PKd6edXoycBJHkHmtn_Jj9oQChu3JsYJqX4amlKSc=.8135adcc-ac46-4041-b021-0b7cc524f511@github.com>
Message-ID: <WXd_JcEHkaSqKOBxuVkYzCFEYCOK4tItVLRgGl9pxP8=.d59efc14-5e3f-4764-be69-026c443552e6@github.com>

On Fri, 3 Feb 2023 18:59:00 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Will do.
>
> Note that `@@` and `@*` are also context-sensitive, and can only be used where the unescaped character would have a different effect.
> 
> Nevertheless, the suggestion for additional tests to demonstrate the behavior is well-taken.

done

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

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

From jjg at openjdk.org  Fri Feb  3 21:45:51 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 3 Feb 2023 21:45:51 GMT
Subject: RFR: JDK-8300914: Allow `@` as an escape in documentation comments
 [v2]
In-Reply-To: <tkGC6BzaTf_H3Yx3iEg3l3ckPFSRmaQEio8r34SgTeI=.45e9cead-7215-4444-a0ef-4b1fffc177a1@github.com>
References: <FuwqJLq_p2KGjWFYjms8z_Qvxbov1wlBFdgWDArxCb8=.b017e75e-2994-474c-b1cd-b1335ad1f274@github.com>
 <RMF0PaxzTeajAlAwtxmkogS__ZlDPL6m5ZoUN68kun8=.ec26d109-b4ca-4b7c-b0d8-74ac3c71ef2a@github.com>
 <kUlqiNAySl3KF_olX7gReT4SS0tq_gurTVNC67XR0UQ=.052015ef-04b2-4353-b34b-3e5e9c67ceea@github.com>
 <_OZF5XKxDKfgkZfkRE1f7T4u6_LNivE0UiUYFi-c22E=.a3b4ed76-f79f-4760-bc0b-4bf61399242f@github.com>
 <SDcR_0h8wo_lAiJJIjSMBYchGvtI2MbdNuquBck1OlU=.93530241-33fe-4b74-a0c8-b092c6d6dbfd@github.com>
 <tkGC6BzaTf_H3Yx3iEg3l3ckPFSRmaQEio8r34SgTeI=.45e9cead-7215-4444-a0ef-4b1fffc177a1@github.com>
Message-ID: <2hH2CaB3HFwNLWv4V0xC3NBGY2Wyw42SMhbbqIzSvaI=.87e8e493-99ab-4112-890b-f07626e3cfe5@github.com>

On Fri, 3 Feb 2023 18:57:06 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Note that all the proposed escape sequences are context-sensitive, and are only enabled in appropriate circumstances.
>
> updated code, comments and spec.

> (FWIW, @jonathan-gibbons, note that the caret positions differ: the former points to / while the latter points to @. )

I see the problem and think I understand the fix, but it is unrelated to the work here.  I'll defer this to a separate JBS issue and PR.

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

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

From jjg at openjdk.org  Fri Feb  3 23:04:39 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 3 Feb 2023 23:04:39 GMT
Subject: RFR: 8301813: Bad caret position in error message
Message-ID: <_y8teoHhWOcrJaQdxbnTob2lCmRDCJXAk_JO0bBQ56c=.ca22c38d-f070-4e61-a186-3145d68569d4@github.com>

Please review a trivial update to `DocCommentParser` and corresponding updates to tests, to fix the caret position in the two forms of the "no tag name found" error message.

The fix is simply to use the overload of `erroneous` that allows the preferred caret position to be specified. This overload was not available at the time the affected lines were originally written.

The "natural" place to test this is in the `doctree` tests (that is, `TagTest.java`) but that test is not set up for easy monitoring of the end-user visible caret, so a new doclet test is created for that. (`TestNoTagName.java`).   

BadPackageCommentTest.java is also affected. It is updated in a manner similar to that in a parallel PR for handling at-escapes. However, the changed caret position will eventually probably cause a minor change conflict that will need to be resolved.

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

Commit messages:
 - 8301813: Bad caret position in error message

Changes: https://git.openjdk.org/jdk/pull/12421/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12421&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8301813
  Stats: 148 lines in 5 files changed: 134 ins; 6 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/12421.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12421/head:pull/12421

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

From jjg at openjdk.org  Fri Feb  3 23:06:25 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 3 Feb 2023 23:06:25 GMT
Subject: RFR: JDK-8300914: Allow `@` as an escape in documentation comments
 [v3]
In-Reply-To: <FuwqJLq_p2KGjWFYjms8z_Qvxbov1wlBFdgWDArxCb8=.b017e75e-2994-474c-b1cd-b1335ad1f274@github.com>
References: <FuwqJLq_p2KGjWFYjms8z_Qvxbov1wlBFdgWDArxCb8=.b017e75e-2994-474c-b1cd-b1335ad1f274@github.com>
Message-ID: <yyl9vJcffiutTCQi9vEt9qdozPV0A5QGbal1hvk3wUM=.b0daa516-7983-4720-b464-6ab2d88019a7@github.com>

> Please review a moderately simple update to permit the use of `@` as the escape character in a limited set of escape sequences.

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

  Address review feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12372/files
  - new: https://git.openjdk.org/jdk/pull/12372/files/cf207d54..f54ddcac

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

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

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

From mcimadamore at openjdk.org  Sat Feb  4 00:44:02 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Sat, 4 Feb 2023 00:44:02 GMT
Subject: RFR: 8295019: Cannot call a method with a parameter of a local
 class declared in a lambda [v4]
In-Reply-To: <nyvMwQrz02Ym-VJqaFNvQbBh8cNxZ3L4Yvu80hL7yeQ=.42d666c3-ac39-4055-b924-241456706bd5@github.com>
References: <RgTl0a5A7X51DERBJaYhKfiOgZmo-qbXUpWbLoZJwd8=.e869c7c9-fed7-478f-a974-f812b44ee277@github.com>
 <nyvMwQrz02Ym-VJqaFNvQbBh8cNxZ3L4Yvu80hL7yeQ=.42d666c3-ac39-4055-b924-241456706bd5@github.com>
Message-ID: <LYB6m2k2Mk57Xvzcyoiie2aFUcPRhS_2SV2BD1Edn1w=.9d98bb91-8031-44e3-909d-ac1a928ec197@github.com>

On Thu, 2 Feb 2023 19:30:06 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Very interesting and, a bit, tricky bug. So the compiler is rejecting code like:
>> 
>> class LocalClassDeclaredInsideLambdaTest {
>>     void run(Runnable r) {}
>> 
>>     void m() {
>>         run(() -> {
>>             class C {
>>                 static void takeC(C c) {}
>>                 static C giveC() {
>>                     return null;
>>                 }
>>             }
>>             C.takeC(C.giveC());
>>         });
>>     }
>> }
>> 
>> with error:
>> 
>> LocalClassInsideLambda.java:12: error: incompatible types: C cannot be converted to C
>>             C.takeC(C.giveC());
>>                            ^
>> Note: Some messages have been simplified; recompile with -Xdiags:verbose to get full output
>> 1 error
>> 
>> which is very misleading as the type seems to be the same. The issue here is that both the lambda and invocation `C.giveC()` are considered poly expressions. `C.giveC()` is not a poly expression but at the moment the compiler is analyzing if an invocation is a poly expression or not, it doesn't have enough information and errs on the safe side.
>> 
>> We have a cache at `com.sun.tools.javac.comp.ArgumentAttr`, see field `argumentTypeCache`, which stores the current deferred type of arguments considered poly expressions. The problem with this particular code is that inside of the lambda there is a class declaration and every time the lambda is attributed a new class type is created.
>> 
>> The lambda, and thus the expression `C.giveC()` are attributed twice. The first time we have an speculative attribution, as a result `argumentTypeCache` will have two entries, one for the lambda and one for `C.giveC()` but the type of `C` is the type created during speculative attribution on a copy of the original lambda tree, let's call it C1. Later on another pass the lambda is attributed `"for real"`, during the check phase. At this point the entry for the lambda in the cache pointed by `argumentTypeCache` has been removed but there is still the entry for `C.giveC()` which still refers to `C1`. So now in the `"for real"` attribution of the lambda which happens on the original tree, not in a copy, a new type for class `C` is created, let's call it `C2`. But when we get to the point where we need to attribute again `C.takeC(C.giveC())` invocation `C.takeC` is expecting `C2` but as `C.giveC()` is again considered a poly expression and an entry is found for it at the cache, the com
 piler reuses that entry which refers to `C1`. And unfortunately `C1 != C2` and thus the error is issued. So the solution I propose is to use a local cache for the speculative attribution of lambda expressions. This is a one liner fix, although an alternative solution could be to scan the lambda body and only use a local cache if a new type is defined inside the lambda, this could be a more optimal solution performance wise as we could save some attributions in some cases. Comments?
>> 
>> TIA
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   a more general approach to cover every expression

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

> 440:         try {
> 441:             localEnv.info.returnResult = resultInfo;
> 442:             /* we should be on the safe side for lambdas that declare a local type as it could be that the cache

I'd suggest a more succinct comment - e.g.:


When performing speculative attribution on an argument expression, we should make sure that argument type cache does not get polluted with local types, as that leads to spurious type errors (see JDK-8295019)

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

> 447:              */
> 448:             JCBlock speculativeTree = hasTypeDeclaration(that) ?
> 449:                     (JCBlock)attribSpeculative(lambdaBlock, localEnv, resultInfo, argumentAttr.withLocalCacheContext()) :

Given `attribSpeculative` also checks for `hasTypeDeclaration` do we need to also check here?

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

> 466:     }
> 467: 
> 468:     boolean hasTypeDeclaration(JCTree tree) {

Nice and simple!

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

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

From mcimadamore at openjdk.org  Sat Feb  4 00:44:03 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Sat, 4 Feb 2023 00:44:03 GMT
Subject: RFR: 8295019: Cannot call a method with a parameter of a local
 class declared in a lambda [v4]
In-Reply-To: <LYB6m2k2Mk57Xvzcyoiie2aFUcPRhS_2SV2BD1Edn1w=.9d98bb91-8031-44e3-909d-ac1a928ec197@github.com>
References: <RgTl0a5A7X51DERBJaYhKfiOgZmo-qbXUpWbLoZJwd8=.e869c7c9-fed7-478f-a974-f812b44ee277@github.com>
 <nyvMwQrz02Ym-VJqaFNvQbBh8cNxZ3L4Yvu80hL7yeQ=.42d666c3-ac39-4055-b924-241456706bd5@github.com>
 <LYB6m2k2Mk57Xvzcyoiie2aFUcPRhS_2SV2BD1Edn1w=.9d98bb91-8031-44e3-909d-ac1a928ec197@github.com>
Message-ID: <imOYB1lRtTuvy3VO7QsvHKs1CRfadA58iTjwgOg4m6c=.0ba934f8-8519-4e5e-9af0-47d83b350d52@github.com>

On Sat, 4 Feb 2023 00:37:40 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   a more general approach to cover every expression
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java line 442:
> 
>> 440:         try {
>> 441:             localEnv.info.returnResult = resultInfo;
>> 442:             /* we should be on the safe side for lambdas that declare a local type as it could be that the cache
> 
> I'd suggest a more succinct comment - e.g.:
> 
> 
> When performing speculative attribution on an argument expression, we should make sure that argument type cache does not get polluted with local types, as that leads to spurious type errors (see JDK-8295019)

Also, perhaps we should move this comment on the `attribSpeculative` method.

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

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

From ethan at mccue.dev  Sat Feb  4 03:48:03 2023
From: ethan at mccue.dev (Ethan McCue)
Date: Fri, 3 Feb 2023 22:48:03 -0500
Subject: [External] : Re: Error examples page
In-Reply-To: <bbeec72f-04e1-709c-cb4e-e173f5b15f06@oracle.com>
References: <CA+NR86hzKmTDQQm93jU+g-KmE-f9h807AnzqPAFPnY9UJEV+Vw@mail.gmail.com>
 <d13c8ca2-9602-8656-33fa-2eabcae9611a@oracle.com>
 <71606e79-2d79-68e8-deb5-d2e79066392c@oracle.com>
 <CA+NR86gD81zb0ssocFgtbdAO3NtGz=T_eMngwT42ZBsqhudAwQ@mail.gmail.com>
 <86f1c26f-1756-4d8e-ae08-d2bbf4edea8a@oracle.com>
 <CA+NR86gf=zrhzKrvTtGggcPKkojqS3QqC0qEjPgzCa2mqogrfg@mail.gmail.com>
 <CA+NR86huXFfVZiPQM-6Q=44ezDQxPQqyq8cetGDV+ddSKhKpsw@mail.gmail.com>
 <bbeec72f-04e1-709c-cb4e-e173f5b15f06@oracle.com>
Message-ID: <CA+NR86gm4gcZ+1nhYmAY2orUEhiOxjqtACPZ-GgA22g9JzYAQA@mail.gmail.com>

> IDEs have arguably more context to do it better, providing GUI support
for "suggestions" on how to change the code.

I've been thinking about this for a while and trying to zero in on
why the idea of leaving it to the IDE doesn't satisfy me.

I still struggle to put it into words, but I wanted to share (with
participants permission) an interaction I witnessed online that I think is
somewhat relevant.

-----


Student: Hello, I'm 16, and in AP computer science  in highschool.
Currently I have a repl.it project and have errors which I would appreciate
could be explained to me and help clarify the concepts if possible. Thank
you!
Student: I'm sry i am not very verse with code and am still trying to learn
and understand the error messages

./bank.java:101: error: class, interface, enum, or record expected
  double withdraw(){
  ^
./bank.java:103: error: class, interface, enum, or record expected
    double withdraw = 0;
    ^
./bank.java:104: error: class, interface, enum, or record expected
     double withdraw = scan.nextDouble();
     ^
./bank.java:105: error: class, interface, enum, or record expected
    while(withdraw >= 0){
    ^
./bank.java:108: error: class, interface, enum, or record expected
        withdraw = 0;
        ^
./bank.java:109: error: class, interface, enum, or record expected
      }
      ^
./bank.java:112: error: class, interface, enum, or record expected
          break;
          ^
./bank.java:113: error: class, interface, enum, or record expected
      }
      ^
./bank.java:116: error: class, interface, enum, or record expected
  }
  ^

Student: may i send you the assignment doc so you know what im trying to do?

Helper: would be helpful
Helper: also why not using an IDE for programming?

Student: im not sure what that is

Helper: Intellij or Eclipse etc?

Student: never heard of it. I use replit because its what my teacher tells
me to use

---------

In this there are two I think are of note

1. The error messages that the student got were not helpful for them seeing
their error. I don't have their original code so I can't dive in to why and
say "ah, we could obviously make this case better", but I choose to believe
there was some way to not vomit "class, interface, enum, or record
expected" nine times.

2. They are not using an IDE. They are using repl.it. This is really common
for early learners, as the hardware requirements of platforms like that are
lower and school systems will choose them for a myriad of reasons (cheaper
to buy chrome books, ability to share starter templates, etc.) Even *if*
IDEs are in a hypothetically better position to provide give corrective
feedback, they aren't always "in the room" for the sort of person that
needs it most.


On Thu, Nov 10, 2022 at 5:38 PM Jonathan Gibbons <
jonathan.gibbons at oracle.com> wrote:

> Thanks for all the extra info.
>
> Yes, the desire for JLS references was primarily for some of the more
> obscure messages about generic types, and bounds checking, etc.
>
> Giving advice about how to fix code is definitely a challenge.  Bad or
> incorrect advice is arguably worse than no advice at all.   Generally, the
> policy for javac over the past few years has been to provide more specific
> details about what is wrong, and the general context of the error, but
> stopping short of suggesting changes.  IDEs have arguably more context to
> do it better, providing GUI support for "suggestions" on how to change the
> code.
>
> -- Jon
> On 11/10/22 2:21 PM, Ethan McCue wrote:
>
> I think for the JLS justification in particular - that is something which
> fits within the "info" part of our model but also isn't
> particularly interesting for the target audience of "people who trigger
> compiler errors."
>
>  A motivating example I sent to Vicente (almost 9 months ago! God I'm
> unproductive) was the contrast between the information conveyed in this
> message
>
>     import java.util.List;
>
>     enum Ex {
>         A,
>         B
>     }
>
>     public class MyClass {
>         public static void main(String args[]) {
>             var ex = B;
>         }
>     }
>
>
>
>     /MyClass.java:10: error: cannot find symbol
>             var ex = B;
>                      ^
>       symbol:   variable B
>       location: class MyClass
>
> As compared to that emitted by rustc
>
>     enum Ex {
>         A,
>         B
>     }
>
>     pub fn main() {
>         let ex = A;
>     }
>
>     error[E0425]: cannot find value `A` in this scope
>      --> src/main.rs:7:14
>       |
>     7 |     let ex = A;
>       |              ^ not found in this scope
>       |
>     help: consider importing this unit variant
>       |
>     1 | use crate::Ex::A;
>       |
>
>     For more information about this error, try `rustc --explain E0425`.
>
> Which could look like (ignoring the finer details of the ascii art)
>
>     error[E0123]: cannot find symbol `A` in this scope
>      --> src/Main.java:9:18
>       |
>     9 |     var ex = B;
>       |              ^ not found in this scope
>       |
>     help: consider importing this enum variant
>       |
>     1 | import static Ex.B;
>       |
>
>     For more information about this error, try `javac --explain E0123`.
>
> Where it is not enough to just "make a better message." There are
> structural deficiencies which preclude giving this sort of feedback.
>
> The *desire* to give a hint on how to fix something or extra context on
> why something is an error is what I think the true monster hiding under the
> bed of JDK-6397027 was. Language kinda has to be irregular in order to
> contain multiple of these semantic elements - y'know?
>
> (sorry if this isn't the most complete justification)
>
> ---
>
> My strategy for making progress has been to recruit the help of some
> students for whom working out a prototype is their senior design project.
> It's slow going, but we're all learning.
>
> On Thu, Nov 10, 2022, 4:40 PM Ethan McCue <ethan at mccue.dev> wrote:
>
>> Pithy instant response: it's not too big for mainstream rustc
>>
>>
>> On Thu, Nov 10, 2022, 4:31 PM Jonathan Gibbons <
>> jonathan.gibbons at oracle.com> wrote:
>>
>>>
>>> Our current brain scratcher is how to represent suggestions on how to
>>> fix code that actually "makes the correction for them"
>>>
>>> So like
>>>
>>>     int assert;
>>>
>>> How to model some code that can be later formatted as a suggestion to
>>> rename the "assert" variable to "assert_"
>>>
>>>
>>>
>>> While it sounds fun, it also sounds "too big" for mainstream javac.
>>> That suggests there could be a plugin mechanism to add more info to
>>> diagnostics.  Maybe.
>>>
>>> -- Jon
>>>
>>>
>>>
>>> On 11/10/22 11:42 AM, Ethan McCue wrote:
>>>
>>> Thanks - we have been tracking the PR. It will be helpful for us to
>>> track our progress.
>>>
>>> ---
>>>
>>> To springboard into something different but related:
>>>
>>> We have been working on modeling how to add kinds of information to
>>> JCDiagnostics that are semantically different from a message as produced by
>>> DiagnosticInfo.
>>>
>>> In the current hypothesis there are two new categories of information we
>>> are calling "help" and "info".
>>>
>>> "help" contains some suggestions on how to rectify a given sort of
>>> error. In the simplest form this is a codification of the "try using
>>> --enable-preview" type messages which exist somewhat ad-hoc throughout the
>>> codebase.
>>>
>>> Our current brain scratcher is how to represent suggestions on how to
>>> fix code that actually "makes the correction for them"
>>>
>>> So like
>>>
>>>     int assert;
>>>
>>> How to model some code that can be later formatted as a suggestion to
>>> rename the "assert" variable to "assert_"
>>>
>>>
>>>
>>>
>>>
>>> On Thu, Nov 10, 2022, 2:25 PM Jonathan Gibbons <
>>> jonathan.gibbons at oracle.com> wrote:
>>>
>>>> As a followup, the code to generate diags-examples.html needed some
>>>> TLC, and was fixed in JDK-8296137
>>>> <https://bugs.openjdk.org/browse/JDK-8296137>.
>>>>
>>>> The command to generate the report is effectively this:
>>>>
>>>> JAVA_HOME=$JDK $ANT \
>>>>     -Dlangtools.jdk.home=$JDK \
>>>>     -f make/langtools/diags-examples.xml
>>>>
>>>> where:
>>>>
>>>>    - the current directory is the root of the OpenJDK repo
>>>>    - ANT refers to a recent executable for Ant,
>>>>    - JDK refers to a build of JDK in the same repo containing the
>>>>    examples directory
>>>>
>>>> The report will be written to build/langtools/diags-examples/
>>>> -- Jon
>>>>
>>>> On 10/3/22 1:22 PM, Jonathan Gibbons wrote:
>>>>
>>>> It's generated by the code in open/test/langtools/tools/javac/diags/.
>>>>
>>>> There are various classes there, like RunExamples.java,
>>>> CheckExamples.java etc. You are probably looking for RunExamples.java;
>>>> there are comments in the code on how to use it.
>>>>
>>>> -- Jon
>>>> On 10/3/22 7:31 AM, Ethan McCue wrote:
>>>>
>>>> Hey all,
>>>>
>>>> My group stumbled upon this page with a bunch of error examples in a
>>>> nice presentable format.
>>>>
>>>> https://cr.openjdk.java.net/~jjg/diags-examples.html
>>>>
>>>> My suspicion is that this was generated by something in the codebase -
>>>> if so does anyone know the command of the top of their head?
>>>>
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230203/34b548fd/attachment-0001.htm>

From vromero at openjdk.org  Mon Feb  6 04:04:10 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 6 Feb 2023 04:04:10 GMT
Subject: RFR: 8295019: Cannot call a method with a parameter of a local
 class declared in a lambda [v5]
In-Reply-To: <RgTl0a5A7X51DERBJaYhKfiOgZmo-qbXUpWbLoZJwd8=.e869c7c9-fed7-478f-a974-f812b44ee277@github.com>
References: <RgTl0a5A7X51DERBJaYhKfiOgZmo-qbXUpWbLoZJwd8=.e869c7c9-fed7-478f-a974-f812b44ee277@github.com>
Message-ID: <9h1WIcQRVBsffUdwC0E48V86ie5qTOLq9e7jAA4Yo-0=.ca023245-8d99-42b6-b88f-0c1d82fc0280@github.com>

> Very interesting and, a bit, tricky bug. So the compiler is rejecting code like:
> 
> class LocalClassDeclaredInsideLambdaTest {
>     void run(Runnable r) {}
> 
>     void m() {
>         run(() -> {
>             class C {
>                 static void takeC(C c) {}
>                 static C giveC() {
>                     return null;
>                 }
>             }
>             C.takeC(C.giveC());
>         });
>     }
> }
> 
> with error:
> 
> LocalClassInsideLambda.java:12: error: incompatible types: C cannot be converted to C
>             C.takeC(C.giveC());
>                            ^
> Note: Some messages have been simplified; recompile with -Xdiags:verbose to get full output
> 1 error
> 
> which is very misleading as the type seems to be the same. The issue here is that both the lambda and invocation `C.giveC()` are considered poly expressions. `C.giveC()` is not a poly expression but at the moment the compiler is analyzing if an invocation is a poly expression or not, it doesn't have enough information and errs on the safe side.
> 
> We have a cache at `com.sun.tools.javac.comp.ArgumentAttr`, see field `argumentTypeCache`, which stores the current deferred type of arguments considered poly expressions. The problem with this particular code is that inside of the lambda there is a class declaration and every time the lambda is attributed a new class type is created.
> 
> The lambda, and thus the expression `C.giveC()` are attributed twice. The first time we have an speculative attribution, as a result `argumentTypeCache` will have two entries, one for the lambda and one for `C.giveC()` but the type of `C` is the type created during speculative attribution on a copy of the original lambda tree, let's call it C1. Later on another pass the lambda is attributed `"for real"`, during the check phase. At this point the entry for the lambda in the cache pointed by `argumentTypeCache` has been removed but there is still the entry for `C.giveC()` which still refers to `C1`. So now in the `"for real"` attribution of the lambda which happens on the original tree, not in a copy, a new type for class `C` is created, let's call it `C2`. But when we get to the point where we need to attribute again `C.takeC(C.giveC())` invocation `C.takeC` is expecting `C2` but as `C.giveC()` is again considered a poly expression and an entry is found for it at the cache, the comp
 iler reuses that entry which refers to `C1`. And unfortunately `C1 != C2` and thus the error is issued. So the solution I propose is to use a local cache for the speculative attribution of lambda expressions. This is a one liner fix, although an alternative solution could be to scan the lambda body and only use a local cache if a new type is defined inside the lambda, this could be a more optimal solution performance wise as we could save some attributions in some cases. Comments?
> 
> TIA

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

 - moving the visitor closer to its client
 - addressing review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12303/files
  - new: https://git.openjdk.org/jdk/pull/12303/files/ce51420f..6fed77b9

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

  Stats: 43 lines in 1 file changed: 19 ins; 23 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12303.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12303/head:pull/12303

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

From vromero at openjdk.org  Mon Feb  6 04:04:12 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 6 Feb 2023 04:04:12 GMT
Subject: RFR: 8295019: Cannot call a method with a parameter of a local
 class declared in a lambda
In-Reply-To: <vNN3E1L_5J_9Rnjs9LGR9Bx-uPQawA4lb_m3tpgGP8Q=.57111253-f8ef-4803-976d-5b6e29aff04b@github.com>
References: <RgTl0a5A7X51DERBJaYhKfiOgZmo-qbXUpWbLoZJwd8=.e869c7c9-fed7-478f-a974-f812b44ee277@github.com>
 <vNN3E1L_5J_9Rnjs9LGR9Bx-uPQawA4lb_m3tpgGP8Q=.57111253-f8ef-4803-976d-5b6e29aff04b@github.com>
Message-ID: <BT13KheEbz8OEhG24WbsNQeFNoeN6uGoZ0CTukTB-1A=.37e00252-7fdd-48ad-b90f-098ccc1c378c@github.com>

On Wed, 1 Feb 2023 13:51:21 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Very interesting and, a bit, tricky bug. So the compiler is rejecting code like:
>> 
>> class LocalClassDeclaredInsideLambdaTest {
>>     void run(Runnable r) {}
>> 
>>     void m() {
>>         run(() -> {
>>             class C {
>>                 static void takeC(C c) {}
>>                 static C giveC() {
>>                     return null;
>>                 }
>>             }
>>             C.takeC(C.giveC());
>>         });
>>     }
>> }
>> 
>> with error:
>> 
>> LocalClassInsideLambda.java:12: error: incompatible types: C cannot be converted to C
>>             C.takeC(C.giveC());
>>                            ^
>> Note: Some messages have been simplified; recompile with -Xdiags:verbose to get full output
>> 1 error
>> 
>> which is very misleading as the type seems to be the same. The issue here is that both the lambda and invocation `C.giveC()` are considered poly expressions. `C.giveC()` is not a poly expression but at the moment the compiler is analyzing if an invocation is a poly expression or not, it doesn't have enough information and errs on the safe side.
>> 
>> We have a cache at `com.sun.tools.javac.comp.ArgumentAttr`, see field `argumentTypeCache`, which stores the current deferred type of arguments considered poly expressions. The problem with this particular code is that inside of the lambda there is a class declaration and every time the lambda is attributed a new class type is created.
>> 
>> The lambda, and thus the expression `C.giveC()` are attributed twice. The first time we have an speculative attribution, as a result `argumentTypeCache` will have two entries, one for the lambda and one for `C.giveC()` but the type of `C` is the type created during speculative attribution on a copy of the original lambda tree, let's call it C1. Later on another pass the lambda is attributed `"for real"`, during the check phase. At this point the entry for the lambda in the cache pointed by `argumentTypeCache` has been removed but there is still the entry for `C.giveC()` which still refers to `C1`. So now in the `"for real"` attribution of the lambda which happens on the original tree, not in a copy, a new type for class `C` is created, let's call it `C2`. But when we get to the point where we need to attribute again `C.takeC(C.giveC())` invocation `C.takeC` is expecting `C2` but as `C.giveC()` is again considered a poly expression and an entry is found for it at the cache, the com
 piler reuses that entry which refers to `C1`. And unfortunately `C1 != C2` and thus the error is issued. So the solution I propose is to use a local cache for the speculative attribution of lambda expressions. This is a one liner fix, although an alternative solution could be to scan the lambda body and only use a local cache if a new type is defined inside the lambda, this could be a more optimal solution performance wise as we could save some attributions in some cases. Comments?
>> 
>> TIA
>
> I think the fix looks sensible. Browsing the `ArgumentAttr` code it also seems that the same strategy is used for checking the receiver expression of a method reference - so in that case we would also attribute multiple times.
> 
> IIRC, the cache is mostly used to save the speculative attribution results so that we don't need to re-check again when we're outside the speculative mode. E.g. if an explicit lambda is passed to an overloaded method, it is still checked only once (e.g. not one time per overload candidate). But, with this fix, if the lambda is nested deeper in a method call chain, it will be checked multiple times.
> 
> One thing that strikes my in your analysis is that we drop the cached entry for the lambda, but we don't drop the entry for the method call, even though the method call is "nested" inside the lambda. That seems like a potential angle to attack this.

@mcimadamore thanks for all the comments and suggestions. I have uploaded a new iteration, code cleaner now thanks!

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

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

From vromero at openjdk.org  Mon Feb  6 04:20:50 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 6 Feb 2023 04:20:50 GMT
Subject: RFR: 8221580: Confusing diagnostic for assigning a static final
 field in a constructor
In-Reply-To: <VOJv0zjPJ5ubKy7RKH6Ekesk4PqDYR5ls4hmeLL2kqs=.1d1cf673-47bb-4bde-aaf0-702008c68dfd@github.com>
References: <VOJv0zjPJ5ubKy7RKH6Ekesk4PqDYR5ls4hmeLL2kqs=.1d1cf673-47bb-4bde-aaf0-702008c68dfd@github.com>
Message-ID: <RhysduexLGdOB-3Tpc_OaJr_gSQjuUw6DrdG7oLkD8E=.6352d82b-0593-4a54-affa-a67fc28b88c5@github.com>

On Fri, 3 Feb 2023 17:33:34 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

> When a program attempts to assign a value to a final field, javac reports `cannot assign a value to final variable x`.
> 
> If the field is `static`, the exact same error message is used, which can be confusing, because no mention is made of the field's `static`ness.
> 
> This change does two things:
> * Refactor the error message so that arbitrary modifiers can be included, instead of hard-wiring `final`
> * Include both `static final` in the error message in the case of `static final` variables.
> 
> So for a `static final` field the error is now `cannot assign a value to static final variable x`.

looks good to me

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

Marked as reviewed by vromero (Reviewer).

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

From duke at openjdk.org  Mon Feb  6 12:04:59 2023
From: duke at openjdk.org (Hannes Greule)
Date: Mon, 6 Feb 2023 12:04:59 GMT
Subject: RFR: 8292275: javac does not emit SYNTHETIC and MANDATED flags for
 parameters by default [v6]
In-Reply-To: <IikwrsO98qW1bsxuBfxFQDDOlnScikoHFapIvei2MTw=.83c1c8aa-ca21-42c3-8221-e634e3674c23@github.com>
References: <cXBKN2YWuFVzdacmxsQvmYPy16bODPQvoyy_ovJ2EiM=.052011cd-598e-4bf7-bc10-3a2171f4b317@github.com>
 <IikwrsO98qW1bsxuBfxFQDDOlnScikoHFapIvei2MTw=.83c1c8aa-ca21-42c3-8221-e634e3674c23@github.com>
Message-ID: <lXSznkrKJkhdyPG8rDjM_LF71r_Yp5DaqzLPITKnoB0=.f7152ab0-ea96-44fb-a08e-9b508b15c1b0@github.com>

On Mon, 9 Jan 2023 07:34:41 GMT, Hannes Greule <duke at openjdk.org> wrote:

>> With this change, javac emits the MethodParameters attribute in cases where the JLS requires the information about synthetic and mandated parameters to be stored (see issue).
>> Parameter names are *not* emitted unless the `-parameter` flag is set.
>> 
>> The relevant changes are in `ClassWriter`, where we go through the params to see if we need the attribute if the `-parameter` flag is not set (if it is set, both names and flags will be emitted).
>> For records, the mandated flag wasn't set at all, this is solved by the one line fix in `JavacParser`.
>> 
>> The changes to `CreateSymbols` and `ClassReader` are needed as they weren't able to deal with missing names in the attribute.
>> I also had to update some tests as they got a new constant pool entry.
>> 
>> Only the mandated flag is covered by tests at the moment, as the occurrences are well-specified in the JLS.
>> Please let me know if you want tests for specific appearances of synthetic parameters.
>
> Hannes Greule 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 21 additional commits since the last revision:
> 
>  - Update copyright year
>  - Merge remote-tracking branch 'upstream/master' into fix/enforce-methodparam_attr-if-mandated
>  - address comments
>  - cleanup
>  - add annotation processing test
>  - fix line breaks
>  - add access flag based test
>  - remove spaces from empty lines in text block
>  - add bug number to test
>  - copyright
>  - ... and 11 more: https://git.openjdk.org/jdk/compare/479a0e69...43780935

Still waiting for any kind of feedback.

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

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

From abimpoudis at openjdk.org  Mon Feb  6 12:28:02 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 6 Feb 2023 12:28:02 GMT
Subject: Integrated: 8301025: ClassCastException in switch with generic record
In-Reply-To: <nCU-hxSmgegCT4CMPj1A9iVf-Q4UdSnT-bULBVa8m9I=.30dc7ac5-13c0-40eb-a1dc-0fb0267be580@github.com>
References: <nCU-hxSmgegCT4CMPj1A9iVf-Q4UdSnT-bULBVa8m9I=.30dc7ac5-13c0-40eb-a1dc-0fb0267be580@github.com>
Message-ID: <atjNFnf1ERLJQC1r84lu-y9unY99n7GqWrXjOT9fEEA=.90f863fe-8476-44b4-b948-ca512c72ee8d@github.com>

On Wed, 25 Jan 2023 15:11:40 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> Add missing class bound propagation during pattern matching translation.

This pull request has now been integrated.

Changeset: 7ac2079b
Author:    Aggelos Biboudis <abimpoudis at openjdk.org>
Committer: Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7ac2079ba7dd07c61576e0b39692a94eecc96e07
Stats:     46 lines in 2 files changed: 45 ins; 0 del; 1 mod

8301025: ClassCastException in switch with generic record

Reviewed-by: jlahoda

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

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

From jlahoda at openjdk.org  Mon Feb  6 12:28:02 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 6 Feb 2023 12:28:02 GMT
Subject: Integrated: 8301580: Error recovery does not clear returnResult
In-Reply-To: <5pitppiKIdloYWKA9MOQpJWhSlMuKYbMOU4h1sJ-eqQ=.2b7c84f4-227c-4608-b60f-ac0d11a1ed1b@github.com>
References: <5pitppiKIdloYWKA9MOQpJWhSlMuKYbMOU4h1sJ-eqQ=.2b7c84f4-227c-4608-b60f-ac0d11a1ed1b@github.com>
Message-ID: <u0SbWMbgnorFs9dZcrOMflGF_RTf6sHeEWb1R84Z4oQ=.41011cc1-f239-4827-a30e-da41d77f5b4c@github.com>

On Wed, 1 Feb 2023 12:00:58 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Considering code like:
> 
> class C {
>     void m
>     {
>         return;
>     }
> }
> 
> 
> `void m` is wrapped in an erroneous tree (which is good), and if/when `Attr` is processing it in `visitErroneous`, it will create a new `Env` to attribute the erroneous part.
> 
> But, `Attr` will set a `returnResult` into the `Env`'s info - and that info is shared with the outter `Env`, so there will be a `returnResult` set after `visitErroneous`. `{ return ; }` is interpreted as an initializer, and there should be an error for the `return` there, but this error is missing, due to the set `returnResult`. This will then fail later in `Flow` with an exception:
> 
> 
> $ javac -XDshould-stop.at=FLOW -XDdev /tmp/C.java

This pull request has now been integrated.

Changeset: 522fa132
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/522fa1327422e49eaa172d43185b3d85b2561036
Stats:     108 lines in 3 files changed: 104 ins; 0 del; 4 mod

8301580: Error recovery does not clear returnResult

Reviewed-by: vromero

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

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

From abimpoudis at openjdk.org  Mon Feb  6 13:14:35 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 6 Feb 2023 13:14:35 GMT
Subject: RFR: 8301858: Verification error when compiling switch with record
 patterns
Message-ID: <cpGG6OTeBDYBx84stB4JJvw5SmhahmFnJanFpUclsn4=.32a30114-6747-4d65-93a4-783100726e26@github.com>

When unrolling/translating record patterns with an unconditional case, we were translating the last/innermost case to`case null, default` skipping the initialization of a bound variable `o` in the example below:

    switch (..) {
      case R1(Object o):
                      return meth_O(o); 
    }
    => 
    switch (..) {
       case R1: 
          switch(..) {
            case null, default:
                            return meth_O(o);
          }
    }

This PR addresses that by emitting the correct label instead of default.

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

Commit messages:
 - 8301858: Verification error when compiling switch with record patterns

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

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

From duke at openjdk.org  Mon Feb  6 15:02:51 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Mon, 6 Feb 2023 15:02:51 GMT
Subject: RFR: 8221580: Confusing diagnostic for assigning a static final
 field in a constructor
In-Reply-To: <VOJv0zjPJ5ubKy7RKH6Ekesk4PqDYR5ls4hmeLL2kqs=.1d1cf673-47bb-4bde-aaf0-702008c68dfd@github.com>
References: <VOJv0zjPJ5ubKy7RKH6Ekesk4PqDYR5ls4hmeLL2kqs=.1d1cf673-47bb-4bde-aaf0-702008c68dfd@github.com>
Message-ID: <Pvri8Y1N1-58sAR2pzagg0GmozG1giiY84YXuhCM99c=.a896219d-8120-459e-b497-99cd6641ddd6@github.com>

On Fri, 3 Feb 2023 17:33:34 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

> When a program attempts to assign a value to a final field, javac reports `cannot assign a value to final variable x`.
> 
> If the field is `static`, the exact same error message is used, which can be confusing, because no mention is made of the field's `static`ness.
> 
> This change does two things:
> * Refactor the error message so that arbitrary modifiers can be included, instead of hard-wiring `final`
> * Include both `static final` in the error message in the case of `static final` variables.
> 
> So for a `static final` field the error is now `cannot assign a value to static final variable x`.

Thanks for the review.

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

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

From duke at openjdk.org  Mon Feb  6 15:44:32 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Mon, 6 Feb 2023 15:44:32 GMT
Subject: RFR: 7167356: (javac) investigate failing tests in JavacParserTest
Message-ID: <gyJl4XBkQ7QrEouoHrk8DsA7r7a9Ztj1AmF1GVaxbFU=.c7aa6500-c694-4cfe-961b-0a8f2f56deff@github.com>

This bug, created back in 2012, notes that three of the unit `@Test`s in `parser/JavacParserTest.java` are disabled because the functionality they verify was not yet implemented correctly at that time.

That was a long time ago, and since then the functionality has been fixed and the tests are now working properly, so they can be enabled at long last.

The third test also needs to be adjusted in order to succeed. It was (for some reason) expecting that an `enum` constant's source position would be reported as offset -1, instead of its actual source position (in this case, 23).

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

Commit messages:
 - Correct and enable unit tests that are now working properly.

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

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

From iris at openjdk.org  Mon Feb  6 17:15:52 2023
From: iris at openjdk.org (Iris Clark)
Date: Mon, 6 Feb 2023 17:15:52 GMT
Subject: RFR: 8301813: Bad caret position in error message
In-Reply-To: <_y8teoHhWOcrJaQdxbnTob2lCmRDCJXAk_JO0bBQ56c=.ca22c38d-f070-4e61-a186-3145d68569d4@github.com>
References: <_y8teoHhWOcrJaQdxbnTob2lCmRDCJXAk_JO0bBQ56c=.ca22c38d-f070-4e61-a186-3145d68569d4@github.com>
Message-ID: <o9cLyywpgcY33_GZRFXQ2mD_rJPVIfJxaim52x-2kuI=.8f648814-748f-40ff-8417-3fe8f20fe942@github.com>

On Fri, 3 Feb 2023 22:56:58 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a trivial update to `DocCommentParser` and corresponding updates to tests, to fix the caret position in the two forms of the "no tag name found" error message.
> 
> The fix is simply to use the overload of `erroneous` that allows the preferred caret position to be specified. This overload was not available at the time the affected lines were originally written.
> 
> The "natural" place to test this is in the `doctree` tests (that is, `TagTest.java`) but that test is not set up for easy monitoring of the end-user visible caret, so a new doclet test is created for that. (`TestNoTagName.java`).   
> 
> BadPackageCommentTest.java is also affected. It is updated in a manner similar to that in a parallel PR for handling at-escapes. However, the changed caret position will eventually probably cause a minor change conflict that will need to be resolved.

Marked as reviewed by iris (Reviewer).

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

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

From vromero at openjdk.org  Mon Feb  6 17:43:52 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 6 Feb 2023 17:43:52 GMT
Subject: RFR: 8301858: Verification error when compiling switch with record
 patterns
In-Reply-To: <cpGG6OTeBDYBx84stB4JJvw5SmhahmFnJanFpUclsn4=.32a30114-6747-4d65-93a4-783100726e26@github.com>
References: <cpGG6OTeBDYBx84stB4JJvw5SmhahmFnJanFpUclsn4=.32a30114-6747-4d65-93a4-783100726e26@github.com>
Message-ID: <NyR__HfjZRf5uBHxZJKJIOE6-Oy_fuiSg4yVDSIjMaI=.d13b8168-2a08-479a-8454-20ecc3a82eb4@github.com>

On Mon, 6 Feb 2023 13:06:30 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> When unrolling/translating record patterns with an unconditional case, we were translating the last/innermost case to`case null, default` skipping the initialization of a bound variable `o` in the example below:
> 
>     switch (..) {
>       case R1(Object o):
>                       return meth_O(o); 
>     }
>     => 
>     switch (..) {
>        case R1: 
>           switch(..) {
>             case null, default:
>                             return meth_O(o);
>           }
>     }
> 
> This PR addresses that by emitting the correct label instead of default.

looks sensible

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

Marked as reviewed by vromero (Reviewer).

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

From duke at openjdk.org  Mon Feb  6 18:26:00 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Mon, 6 Feb 2023 18:26:00 GMT
Subject: Integrated: 8221580: Confusing diagnostic for assigning a static final
 field in a constructor
In-Reply-To: <VOJv0zjPJ5ubKy7RKH6Ekesk4PqDYR5ls4hmeLL2kqs=.1d1cf673-47bb-4bde-aaf0-702008c68dfd@github.com>
References: <VOJv0zjPJ5ubKy7RKH6Ekesk4PqDYR5ls4hmeLL2kqs=.1d1cf673-47bb-4bde-aaf0-702008c68dfd@github.com>
Message-ID: <o40v1e9WeruhMu1-dD_BkwtKiaMDIhxxbvmO0x5nfdM=.262b8830-6be2-49cb-986d-5716cba231ad@github.com>

On Fri, 3 Feb 2023 17:33:34 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

> When a program attempts to assign a value to a final field, javac reports `cannot assign a value to final variable x`.
> 
> If the field is `static`, the exact same error message is used, which can be confusing, because no mention is made of the field's `static`ness.
> 
> This change does two things:
> * Refactor the error message so that arbitrary modifiers can be included, instead of hard-wiring `final`
> * Include both `static final` in the error message in the case of `static final` variables.
> 
> So for a `static final` field the error is now `cannot assign a value to static final variable x`.

This pull request has now been integrated.

Changeset: 8c01b6e6
Author:    Archie L. Cobbs <archie.cobbs at gmail.com>
Committer: Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8c01b6e66b1ce9f9df5a1d12c8717a9e3322948a
Stats:     25 lines in 11 files changed: 10 ins; 0 del; 15 mod

8221580: Confusing diagnostic for assigning a static final field in a constructor

Reviewed-by: vromero

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

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

From vromero at openjdk.org  Mon Feb  6 18:28:50 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 6 Feb 2023 18:28:50 GMT
Subject: RFR: 7167356: (javac) investigate failing tests in JavacParserTest
In-Reply-To: <gyJl4XBkQ7QrEouoHrk8DsA7r7a9Ztj1AmF1GVaxbFU=.c7aa6500-c694-4cfe-961b-0a8f2f56deff@github.com>
References: <gyJl4XBkQ7QrEouoHrk8DsA7r7a9Ztj1AmF1GVaxbFU=.c7aa6500-c694-4cfe-961b-0a8f2f56deff@github.com>
Message-ID: <6KtXxixQyWgsShZ4XCi_Q_X5eV8gCbiI5LqGkltlp_I=.7499c374-027a-49f1-8a52-97c0f027ad49@github.com>

On Mon, 6 Feb 2023 15:35:29 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

> This bug, created back in 2012, notes that three of the unit `@Test`s in `parser/JavacParserTest.java` are disabled because the functionality they verify was not yet implemented correctly at that time.
> 
> That was a long time ago, and since then the functionality has been fixed and the tests are now working properly, so they can be enabled at long last.
> 
> The third test also needs to be adjusted in order to succeed. It was (for some reason) expecting that an `enum` constant's source position would be reported as offset -1, instead of its actual source position (in this case, 23).

looks good, thanks for fixing this

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

Marked as reviewed by vromero (Reviewer).

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

From jjg at openjdk.org  Mon Feb  6 18:44:01 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 6 Feb 2023 18:44:01 GMT
Subject: Integrated: 8301813: Bad caret position in error message
In-Reply-To: <_y8teoHhWOcrJaQdxbnTob2lCmRDCJXAk_JO0bBQ56c=.ca22c38d-f070-4e61-a186-3145d68569d4@github.com>
References: <_y8teoHhWOcrJaQdxbnTob2lCmRDCJXAk_JO0bBQ56c=.ca22c38d-f070-4e61-a186-3145d68569d4@github.com>
Message-ID: <WBRElvP3kTT4YxRUoZvfBILbHhLW8ZhLM-5lrkn8rs0=.402fb3cf-74c4-43ea-89df-170baa98510e@github.com>

On Fri, 3 Feb 2023 22:56:58 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a trivial update to `DocCommentParser` and corresponding updates to tests, to fix the caret position in the two forms of the "no tag name found" error message.
> 
> The fix is simply to use the overload of `erroneous` that allows the preferred caret position to be specified. This overload was not available at the time the affected lines were originally written.
> 
> The "natural" place to test this is in the `doctree` tests (that is, `TagTest.java`) but that test is not set up for easy monitoring of the end-user visible caret, so a new doclet test is created for that. (`TestNoTagName.java`).   
> 
> BadPackageCommentTest.java is also affected. It is updated in a manner similar to that in a parallel PR for handling at-escapes. However, the changed caret position will eventually probably cause a minor change conflict that will need to be resolved.

This pull request has now been integrated.

Changeset: d53ade12
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d53ade12a863cc9e9c2bf2528dd0f0f90416f779
Stats:     148 lines in 5 files changed: 134 ins; 6 del; 8 mod

8301813: Bad caret position in error message

Reviewed-by: iris

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

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

From jjg at openjdk.org  Mon Feb  6 19:00:02 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 6 Feb 2023 19:00:02 GMT
Subject: RFR: JDK-8301810: Bug in doctree DocCommentTester.compress [v2]
In-Reply-To: <u06shK1KvoC4Jfdj1DRzNuUAwTTc9igcXt2YIZ5v-d8=.0b364a28-49d2-42f5-add7-7614e571438c@github.com>
References: <u06shK1KvoC4Jfdj1DRzNuUAwTTc9igcXt2YIZ5v-d8=.0b364a28-49d2-42f5-add7-7614e571438c@github.com>
Message-ID: <P0uNrYOzKb08vxHVuyTMgs-Mss9AmyMmeV3rOM8A3mY=.a7a2996d-4220-43f9-a165-f8129808c933@github.com>

> Please review a minor but long-standing bug in the code to "compress" long strings in the `doctree` `DocCommentTester` class.
> 
> The primary change is in `DocCommentTester`, to fix the code, and make it somewhat more robust.  The change does break some golden output, in comments and files, so advantage is taken to increase the max size of compressed strings.

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

 - Merge remote-tracking branch 'upstream/master' into 8301810.doctree-doccommenttester-compress
 - JDK-8301810: Bug in doctree DocCommentTester.compress

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12418/files
  - new: https://git.openjdk.org/jdk/pull/12418/files/0e670849..08b359fa

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

  Stats: 3615 lines in 104 files changed: 2292 ins; 887 del; 436 mod
  Patch: https://git.openjdk.org/jdk/pull/12418.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12418/head:pull/12418

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

From jjg at openjdk.org  Mon Feb  6 19:11:30 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 6 Feb 2023 19:11:30 GMT
Subject: RFR: JDK-8300914: Allow `@` as an escape in documentation comments
 [v4]
In-Reply-To: <FuwqJLq_p2KGjWFYjms8z_Qvxbov1wlBFdgWDArxCb8=.b017e75e-2994-474c-b1cd-b1335ad1f274@github.com>
References: <FuwqJLq_p2KGjWFYjms8z_Qvxbov1wlBFdgWDArxCb8=.b017e75e-2994-474c-b1cd-b1335ad1f274@github.com>
Message-ID: <7QXQ-TTeHYwH_VFrcR2K12KVG7Yfxi-ZegdqGM9-urk=.c2346bf7-d9f2-495d-a2d6-db9b66194162@github.com>

> Please review a moderately simple update to permit the use of `@` as the escape character in a limited set of escape sequences.

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

 - Merge with upstream/master
 - Address review feedback
 - Merge with upstream/master
 - JDK-8301294: Allow `@` as an escape in documentation comments

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

Changes: https://git.openjdk.org/jdk/pull/12372/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12372&range=03
  Stats: 456 lines in 16 files changed: 436 ins; 0 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/12372.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12372/head:pull/12372

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

From jjg at openjdk.org  Mon Feb  6 19:33:06 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 6 Feb 2023 19:33:06 GMT
Subject: RFR: JDK-8300914: Allow `@` as an escape in documentation comments
 [v5]
In-Reply-To: <FuwqJLq_p2KGjWFYjms8z_Qvxbov1wlBFdgWDArxCb8=.b017e75e-2994-474c-b1cd-b1335ad1f274@github.com>
References: <FuwqJLq_p2KGjWFYjms8z_Qvxbov1wlBFdgWDArxCb8=.b017e75e-2994-474c-b1cd-b1335ad1f274@github.com>
Message-ID: <mJhUf6DQbU1z0AG99JG0O3n558jxvc1y7YZy-LIFlLI=.6c5bc311-f7b8-4b27-8d39-400e00abd1f8@github.com>

> Please review a moderately simple update to permit the use of `@` as the escape character in a limited set of escape sequences.

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

  Improve spec wording

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12372/files
  - new: https://git.openjdk.org/jdk/pull/12372/files/960a48a5..a8097057

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

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

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

From duke at openjdk.org  Mon Feb  6 20:31:01 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Mon, 6 Feb 2023 20:31:01 GMT
Subject: Integrated: 7167356: (javac) investigate failing tests in
 JavacParserTest
In-Reply-To: <gyJl4XBkQ7QrEouoHrk8DsA7r7a9Ztj1AmF1GVaxbFU=.c7aa6500-c694-4cfe-961b-0a8f2f56deff@github.com>
References: <gyJl4XBkQ7QrEouoHrk8DsA7r7a9Ztj1AmF1GVaxbFU=.c7aa6500-c694-4cfe-961b-0a8f2f56deff@github.com>
Message-ID: <okLHJfV29LFzBeOUqYYE_SLEYgXX_hCcHc-2B64PqzU=.06621c21-6cb0-4b93-b032-8ea35650aa49@github.com>

On Mon, 6 Feb 2023 15:35:29 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

> This bug, created back in 2012, notes that three of the unit `@Test`s in `parser/JavacParserTest.java` are disabled because the functionality they verify was not yet implemented correctly at that time.
> 
> That was a long time ago, and since then the functionality has been fixed and the tests are now working properly, so they can be enabled at long last.
> 
> The third test also needs to be adjusted in order to succeed. It was (for some reason) expecting that an `enum` constant's source position would be reported as offset -1, instead of its actual source position (in this case, 23).

This pull request has now been integrated.

Changeset: 07fb4f9a
Author:    Archie L. Cobbs <archie.cobbs at gmail.com>
Committer: Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/07fb4f9a0bb4ed9d0f359b85fe0b0c38503ab9a5
Stats:     8 lines in 1 file changed: 2 ins; 4 del; 2 mod

7167356: (javac) investigate failing tests in JavacParserTest

Reviewed-by: vromero

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

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

From duke at openjdk.org  Mon Feb  6 20:40:25 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Mon, 6 Feb 2023 20:40:25 GMT
Subject: RFR: 8027682: javac wrongly accepts semicolons in package and import
 decls
Message-ID: <bQN6VoWgHskZ_Wg9PgBhKWwUDYp5jlRGja_LkitHQY4=.1a7d2eec-a992-4cee-9eb0-68fe1821e276@github.com>

JLS [?7.3](https://docs.oracle.com/javase/specs/jls/se19/html/jls-7.html#jls-7.3) specifies that while a lone semi-colon is a valid _TopLevelClassOrInterfaceDeclaration_, it is not a valid _ImportDeclaration_. Therefore, if we see a lone semi-colon while looking for the next import statement we have to advance and accept a class declaration, and we can therefore no longer accept any further `import` statements.

However, the compiler was allowing this, for example:

package p; import X; ;;; import Y; class Foo {}

The bug is that the parser was switching out of "look for imports" mode after parsing a valid class declaration, but it was not switching out of "look for imports" mode after parsing a lone semi-colon.

The fix to `JavacParser.java` is easy, however it also requires these adjustments to unit tests:

* Test `tree/T6963934.java` must go away, because it is verifying a bug that only happens when the above bogus input is successfully parsed, and this can no longer happen.
* A bug in `lib/types/TypeHarness.java` was uncovered and fixed; it was inserting an extra semi-colon.
* The following bugs, which check invalid syntax within import statements, now generate different parse errors and therefor needed their "golden output" updated:
  * annotations/typeAnnotations/failures/AnnotatedImport.java
  * annotations/typeAnnotations/failures/AnnotatedPackage1.java
  * annotations/typeAnnotations/failures/AnnotatedPackage2.java

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

Commit messages:
 - Per JLS 7.3, do not accept a lone semi-colon as a valid ImportDeclaration.

Changes: https://git.openjdk.org/jdk/pull/12448/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12448&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8027682
  Stats: 70 lines in 6 files changed: 3 ins; 62 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/12448.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12448/head:pull/12448

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

From cushon at openjdk.org  Mon Feb  6 20:53:52 2023
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Mon, 6 Feb 2023 20:53:52 GMT
Subject: RFR: 8027682: javac wrongly accepts semicolons in package and
 import decls
In-Reply-To: <bQN6VoWgHskZ_Wg9PgBhKWwUDYp5jlRGja_LkitHQY4=.1a7d2eec-a992-4cee-9eb0-68fe1821e276@github.com>
References: <bQN6VoWgHskZ_Wg9PgBhKWwUDYp5jlRGja_LkitHQY4=.1a7d2eec-a992-4cee-9eb0-68fe1821e276@github.com>
Message-ID: <A-Bd_yViu29NJwMCkLmCvH04oYzytB80iJZeqsRAHVE=.bdf815d8-225d-4db6-99cc-97fc66dd93a4@github.com>

On Mon, 6 Feb 2023 20:32:27 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

> JLS [?7.3](https://docs.oracle.com/javase/specs/jls/se19/html/jls-7.html#jls-7.3) specifies that while a lone semi-colon is a valid _TopLevelClassOrInterfaceDeclaration_, it is not a valid _ImportDeclaration_. Therefore, if we see a lone semi-colon while looking for the next import statement we have to advance and accept a class declaration, and we can therefore no longer accept any further `import` statements.
> 
> However, the compiler was allowing this, for example:
> 
> package p; import X; ;;; import Y; class Foo {}
> 
> The bug is that the parser was switching out of "look for imports" mode after parsing a valid class declaration, but it was not switching out of "look for imports" mode after parsing a lone semi-colon.
> 
> The fix to `JavacParser.java` is easy, however it also requires these adjustments to unit tests:
> 
> * Test `tree/T6963934.java` must go away, because it is verifying a bug that only happens when the above bogus input is successfully parsed, and this can no longer happen.
> * A bug in `lib/types/TypeHarness.java` was uncovered and fixed; it was inserting an extra semi-colon.
> * The following bugs, which check invalid syntax within import statements, now generate different parse errors and therefor needed their "golden output" updated:
>   * annotations/typeAnnotations/failures/AnnotatedImport.java
>   * annotations/typeAnnotations/failures/AnnotatedPackage1.java
>   * annotations/typeAnnotations/failures/AnnotatedPackage2.java

I would be happy to see this fixed, but note that there's going to be some compatibility impact from this to existing programs containing extra `;`, and it probably warrants a CSR.

There was some discussion in [the original compiler-dev thread](https://mail.openjdk.org/pipermail/compiler-dev/2013-August/006973.html) about whether the right fix was to change javac, or change the spec.

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

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

From jjg at openjdk.org  Mon Feb  6 21:06:52 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 6 Feb 2023 21:06:52 GMT
Subject: RFR: 8027682: javac wrongly accepts semicolons in package and
 import decls
In-Reply-To: <bQN6VoWgHskZ_Wg9PgBhKWwUDYp5jlRGja_LkitHQY4=.1a7d2eec-a992-4cee-9eb0-68fe1821e276@github.com>
References: <bQN6VoWgHskZ_Wg9PgBhKWwUDYp5jlRGja_LkitHQY4=.1a7d2eec-a992-4cee-9eb0-68fe1821e276@github.com>
Message-ID: <fIHdMwmjLRnQnJLjLsci0DuFHrnXoO-0U8mdD1f9L8I=.3199cbdf-e3cc-4ecb-88bd-13c747557031@github.com>

On Mon, 6 Feb 2023 20:32:27 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

> JLS [?7.3](https://docs.oracle.com/javase/specs/jls/se19/html/jls-7.html#jls-7.3) specifies that while a lone semi-colon is a valid _TopLevelClassOrInterfaceDeclaration_, it is not a valid _ImportDeclaration_. Therefore, if we see a lone semi-colon while looking for the next import statement we have to advance and accept a class declaration, and we can therefore no longer accept any further `import` statements.
> 
> However, the compiler was allowing this, for example:
> 
> package p; import X; ;;; import Y; class Foo {}
> 
> The bug is that the parser was switching out of "look for imports" mode after parsing a valid class declaration, but it was not switching out of "look for imports" mode after parsing a lone semi-colon.
> 
> The fix to `JavacParser.java` is easy, however it also requires these adjustments to unit tests:
> 
> * Test `tree/T6963934.java` must go away, because it is verifying a bug that only happens when the above bogus input is successfully parsed, and this can no longer happen.
> * A bug in `lib/types/TypeHarness.java` was uncovered and fixed; it was inserting an extra semi-colon.
> * The following bugs, which check invalid syntax within import statements, now generate different parse errors and therefor needed their "golden output" updated:
>   * annotations/typeAnnotations/failures/AnnotatedImport.java
>   * annotations/typeAnnotations/failures/AnnotatedPackage1.java
>   * annotations/typeAnnotations/failures/AnnotatedPackage2.java

I would question whether this is the correct/best solution.

A different solution might be to look ahead for the next keyword (i.e. not-a-semi-colon).   If the next keyword is `import`, then you could report an error, ignore the semi-colon and carry on parsing.   In other words, look to improve the error recovery in these situations.  I'm reminded of a similar-but-different change a few years back to allow the compiler to parse (and reject) `if (expr) declaration` because it improved the error recovery.

And, maybe check whether we want to tweak the language rules to permit these semicolons, in the same way that we permit them between top-level declarations.

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

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

From duke at openjdk.org  Mon Feb  6 21:17:52 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Mon, 6 Feb 2023 21:17:52 GMT
Subject: RFR: 8027682: javac wrongly accepts semicolons in package and
 import decls
In-Reply-To: <bQN6VoWgHskZ_Wg9PgBhKWwUDYp5jlRGja_LkitHQY4=.1a7d2eec-a992-4cee-9eb0-68fe1821e276@github.com>
References: <bQN6VoWgHskZ_Wg9PgBhKWwUDYp5jlRGja_LkitHQY4=.1a7d2eec-a992-4cee-9eb0-68fe1821e276@github.com>
Message-ID: <dtz29IPotBwm63Q-eOnJR_XxFhqIMOjxvTEkvKuzonQ=.22cadcde-c3bb-440a-85ad-cd7274383a68@github.com>

On Mon, 6 Feb 2023 20:32:27 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

> JLS [?7.3](https://docs.oracle.com/javase/specs/jls/se19/html/jls-7.html#jls-7.3) specifies that while a lone semi-colon is a valid _TopLevelClassOrInterfaceDeclaration_, it is not a valid _ImportDeclaration_. Therefore, if we see a lone semi-colon while looking for the next import statement we have to advance and accept a class declaration, and we can therefore no longer accept any further `import` statements.
> 
> However, the compiler was allowing this, for example:
> 
> package p; import X; ;;; import Y; class Foo {}
> 
> The bug is that the parser was switching out of "look for imports" mode after parsing a valid class declaration, but it was not switching out of "look for imports" mode after parsing a lone semi-colon.
> 
> The fix to `JavacParser.java` is easy, however it also requires these adjustments to unit tests:
> 
> * Test `tree/T6963934.java` must go away, because it is verifying a bug that only happens when the above bogus input is successfully parsed, and this can no longer happen.
> * A bug in `lib/types/TypeHarness.java` was uncovered and fixed; it was inserting an extra semi-colon.
> * The following bugs, which check invalid syntax within import statements, now generate different parse errors and therefor needed their "golden output" updated:
>   * annotations/typeAnnotations/failures/AnnotatedImport.java
>   * annotations/typeAnnotations/failures/AnnotatedPackage1.java
>   * annotations/typeAnnotations/failures/AnnotatedPackage2.java

Thanks for the comments.

Agree that smarter error checking for the likely scenario of a spurious semi-colon would be an improvement.

I'm agnostic on what would be "best" - just trying to address some stale bugs.

If there is uncertainty about what the spec should be, but also no action, that obviously paralyzes progress. What do you guys recommend we do?

This bug will have its 10th birthday in October :)

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

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

From jjg at openjdk.org  Mon Feb  6 21:22:48 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 6 Feb 2023 21:22:48 GMT
Subject: RFR: 8027682: javac wrongly accepts semicolons in package and
 import decls
In-Reply-To: <dtz29IPotBwm63Q-eOnJR_XxFhqIMOjxvTEkvKuzonQ=.22cadcde-c3bb-440a-85ad-cd7274383a68@github.com>
References: <bQN6VoWgHskZ_Wg9PgBhKWwUDYp5jlRGja_LkitHQY4=.1a7d2eec-a992-4cee-9eb0-68fe1821e276@github.com>
 <dtz29IPotBwm63Q-eOnJR_XxFhqIMOjxvTEkvKuzonQ=.22cadcde-c3bb-440a-85ad-cd7274383a68@github.com>
Message-ID: <6KIybFgOWGOR17ioiHIP8ddTBffXsb0ELJET0Pkwtb4=.0ee4c798-5a84-40bc-90a5-6497fbb71914@github.com>

On Mon, 6 Feb 2023 21:14:38 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

> Thanks for the comments.
> 
> Agree that smarter error checking for the likely scenario of a spurious semi-colon would be an improvement.
> 
> I'm agnostic on what would be "best" - just trying to address some stale bugs.
> 
> If there is uncertainty about what the spec should be, but also no action, that obviously paralyzes progress. What do you guys recommend we do?
> 
> This bug will have its 10th birthday in October :)

I would suggest to go ahead with a solution to report and ignore excess semicolons, since changing JLS is a bigger deal that cannot be done here.   And even if we change JLS going forward, a solution to "report and ignore" excess semicolons might be worth back-porting.

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

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

From darcy at openjdk.org  Mon Feb  6 21:32:47 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 6 Feb 2023 21:32:47 GMT
Subject: RFR: 8027682: javac wrongly accepts semicolons in package and
 import decls
In-Reply-To: <A-Bd_yViu29NJwMCkLmCvH04oYzytB80iJZeqsRAHVE=.bdf815d8-225d-4db6-99cc-97fc66dd93a4@github.com>
References: <bQN6VoWgHskZ_Wg9PgBhKWwUDYp5jlRGja_LkitHQY4=.1a7d2eec-a992-4cee-9eb0-68fe1821e276@github.com>
 <A-Bd_yViu29NJwMCkLmCvH04oYzytB80iJZeqsRAHVE=.bdf815d8-225d-4db6-99cc-97fc66dd93a4@github.com>
Message-ID: <cKU0265zzzKouFE8wiXfv9JdaASRwdM18iwRv7VtOFc=.3cfd7fc4-ec14-47c2-b31b-1a041bc3f2aa@github.com>

On Mon, 6 Feb 2023 20:50:34 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> JLS [?7.3](https://docs.oracle.com/javase/specs/jls/se19/html/jls-7.html#jls-7.3) specifies that while a lone semi-colon is a valid _TopLevelClassOrInterfaceDeclaration_, it is not a valid _ImportDeclaration_. Therefore, if we see a lone semi-colon while looking for the next import statement we have to advance and accept a class declaration, and we can therefore no longer accept any further `import` statements.
>> 
>> However, the compiler was allowing this, for example:
>> 
>> package p; import X; ;;; import Y; class Foo {}
>> 
>> The bug is that the parser was switching out of "look for imports" mode after parsing a valid class declaration, but it was not switching out of "look for imports" mode after parsing a lone semi-colon.
>> 
>> The fix to `JavacParser.java` is easy, however it also requires these adjustments to unit tests:
>> 
>> * Test `tree/T6963934.java` must go away, because it is verifying a bug that only happens when the above bogus input is successfully parsed, and this can no longer happen.
>> * A bug in `lib/types/TypeHarness.java` was uncovered and fixed; it was inserting an extra semi-colon.
>> * The following bugs, which check invalid syntax within import statements, now generate different parse errors and therefor needed their "golden output" updated:
>>   * annotations/typeAnnotations/failures/AnnotatedImport.java
>>   * annotations/typeAnnotations/failures/AnnotatedPackage1.java
>>   * annotations/typeAnnotations/failures/AnnotatedPackage2.java
>
> I would be happy to see this fixed, but note that there's going to be some compatibility impact from this to existing programs containing extra `;`, and it probably warrants a CSR.
> 
> There was some discussion in [the original compiler-dev thread](https://mail.openjdk.org/pipermail/compiler-dev/2013-August/006973.html) about whether the right fix was to change javac, or change the spec.

If javac were to start rejecting previously accepted programs, even programs that violate the letter of the JLS, that would require a CSR, as @cushon noted.

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

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

From duke at openjdk.org  Mon Feb  6 21:32:49 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Mon, 6 Feb 2023 21:32:49 GMT
Subject: RFR: 8027682: javac wrongly accepts semicolons in package and
 import decls
In-Reply-To: <6KIybFgOWGOR17ioiHIP8ddTBffXsb0ELJET0Pkwtb4=.0ee4c798-5a84-40bc-90a5-6497fbb71914@github.com>
References: <bQN6VoWgHskZ_Wg9PgBhKWwUDYp5jlRGja_LkitHQY4=.1a7d2eec-a992-4cee-9eb0-68fe1821e276@github.com>
 <dtz29IPotBwm63Q-eOnJR_XxFhqIMOjxvTEkvKuzonQ=.22cadcde-c3bb-440a-85ad-cd7274383a68@github.com>
 <6KIybFgOWGOR17ioiHIP8ddTBffXsb0ELJET0Pkwtb4=.0ee4c798-5a84-40bc-90a5-6497fbb71914@github.com>
Message-ID: <gUMkq7nXZd1ZQonHHLCoyQGqH03wDZbZDVj9vv6IyrM=.99ff7acd-7a2c-49f6-a00f-fae933c861d6@github.com>

On Mon, 6 Feb 2023 21:20:20 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> I would suggest to go ahead with a solution to report and ignore excess semicolons, since changing JLS is a bigger deal that cannot be done here. And even if we change JLS going forward, a solution to "report and ignore" excess semicolons might be worth back-porting.

Sounds like a good plan - thanks!

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

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

From duke at openjdk.org  Tue Feb  7 00:01:47 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Tue, 7 Feb 2023 00:01:47 GMT
Subject: RFR: 8027682: javac wrongly accepts semicolons in package and
 import decls [v2]
In-Reply-To: <bQN6VoWgHskZ_Wg9PgBhKWwUDYp5jlRGja_LkitHQY4=.1a7d2eec-a992-4cee-9eb0-68fe1821e276@github.com>
References: <bQN6VoWgHskZ_Wg9PgBhKWwUDYp5jlRGja_LkitHQY4=.1a7d2eec-a992-4cee-9eb0-68fe1821e276@github.com>
Message-ID: <MNB0bXAypGlVyMHzXS7mal1CWGKnrlDM4WPc0_sSUm4=.c8a0751b-8960-441b-bb65-4641d1c9b246@github.com>

> JLS [?7.3](https://docs.oracle.com/javase/specs/jls/se19/html/jls-7.html#jls-7.3) specifies that while a lone semi-colon is a valid _TopLevelClassOrInterfaceDeclaration_, it is not a valid _ImportDeclaration_. Therefore, if we see a lone semi-colon while looking for the next import statement we have to advance and accept a class declaration, and we can therefore no longer accept any further `import` statements.
> 
> However, the compiler was allowing this, for example:
> 
> package p; import X; ;;; import Y; class Foo {}
> 
> The bug is that the parser was switching out of "look for imports" mode after parsing a valid class declaration, but it was not switching out of "look for imports" mode after parsing a lone semi-colon.
> 
> The fix to `JavacParser.java` is easy, however it also requires these adjustments to unit tests:
> 
> * Test `tree/T6963934.java` must go away, because it is verifying a bug that only happens when the above bogus input is successfully parsed, and this can no longer happen.
> * A bug in `lib/types/TypeHarness.java` was uncovered and fixed; it was inserting an extra semi-colon.
> * The following bugs, which check invalid syntax within import statements, now generate different parse errors and therefor needed their "golden output" updated:
>   * annotations/typeAnnotations/failures/AnnotatedImport.java
>   * annotations/typeAnnotations/failures/AnnotatedPackage1.java
>   * annotations/typeAnnotations/failures/AnnotatedPackage2.java

Archie L. Cobbs has updated the pull request incrementally with two additional commits since the last revision:

 - Fix some extraneous semi-colons that are now disallowed.
 - Give a more helpful error for spurious semi-colons before import statements.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12448/files
  - new: https://git.openjdk.org/jdk/pull/12448/files/adc35713..ac02179a

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

  Stats: 61 lines in 9 files changed: 49 ins; 2 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/12448.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12448/head:pull/12448

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

From jjg at openjdk.org  Tue Feb  7 00:08:25 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 7 Feb 2023 00:08:25 GMT
Subject: RFR: 8027682: javac wrongly accepts semicolons in package and
 import decls [v2]
In-Reply-To: <MNB0bXAypGlVyMHzXS7mal1CWGKnrlDM4WPc0_sSUm4=.c8a0751b-8960-441b-bb65-4641d1c9b246@github.com>
References: <bQN6VoWgHskZ_Wg9PgBhKWwUDYp5jlRGja_LkitHQY4=.1a7d2eec-a992-4cee-9eb0-68fe1821e276@github.com>
 <MNB0bXAypGlVyMHzXS7mal1CWGKnrlDM4WPc0_sSUm4=.c8a0751b-8960-441b-bb65-4641d1c9b246@github.com>
Message-ID: <ItQKkYYA0SJCWuFP_mtxkIyxMZgjlMs998Q2d2dplOY=.b809b2c5-da32-4111-82f8-4d645a03f6a3@github.com>

On Tue, 7 Feb 2023 00:01:47 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> JLS [?7.3](https://docs.oracle.com/javase/specs/jls/se19/html/jls-7.html#jls-7.3) specifies that while a lone semi-colon is a valid _TopLevelClassOrInterfaceDeclaration_, it is not a valid _ImportDeclaration_. Therefore, if we see a lone semi-colon while looking for the next import statement we have to advance and accept a class declaration, and we can therefore no longer accept any further `import` statements.
>> 
>> However, the compiler was allowing this, for example:
>> 
>> package p; import X; ;;; import Y; class Foo {}
>> 
>> The bug is that the parser was switching out of "look for imports" mode after parsing a valid class declaration, but it was not switching out of "look for imports" mode after parsing a lone semi-colon.
>> 
>> The fix to `JavacParser.java` is easy, however it also requires these adjustments to unit tests:
>> 
>> * Test `tree/T6963934.java` must go away, because it is verifying a bug that only happens when the above bogus input is successfully parsed, and this can no longer happen.
>> * A bug in `lib/types/TypeHarness.java` was uncovered and fixed; it was inserting an extra semi-colon.
>> * The following bugs, which check invalid syntax within import statements, now generate different parse errors and therefor needed their "golden output" updated:
>>   * annotations/typeAnnotations/failures/AnnotatedImport.java
>>   * annotations/typeAnnotations/failures/AnnotatedPackage1.java
>>   * annotations/typeAnnotations/failures/AnnotatedPackage2.java
>
> Archie L. Cobbs has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix some extraneous semi-colons that are now disallowed.
>  - Give a more helpful error for spurious semi-colons before import statements.

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

> 3828:             // but here we try to provide a more helpful error message if we encounter any.
> 3829:             // Do that by slurping in as many semi-colons as possible, and then seeing what
> 3830:             // comes after before deciding how best to handle them.

Maybe it's my fault for misleading you in the discussion, but the dictionary says that "semicolon" is not a hyphenated word.

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

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

From vromero at openjdk.org  Tue Feb  7 03:58:43 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 7 Feb 2023 03:58:43 GMT
Subject: RFR: 8027682: javac wrongly accepts semicolons in package and
 import decls
In-Reply-To: <gUMkq7nXZd1ZQonHHLCoyQGqH03wDZbZDVj9vv6IyrM=.99ff7acd-7a2c-49f6-a00f-fae933c861d6@github.com>
References: <bQN6VoWgHskZ_Wg9PgBhKWwUDYp5jlRGja_LkitHQY4=.1a7d2eec-a992-4cee-9eb0-68fe1821e276@github.com>
 <dtz29IPotBwm63Q-eOnJR_XxFhqIMOjxvTEkvKuzonQ=.22cadcde-c3bb-440a-85ad-cd7274383a68@github.com>
 <6KIybFgOWGOR17ioiHIP8ddTBffXsb0ELJET0Pkwtb4=.0ee4c798-5a84-40bc-90a5-6497fbb71914@github.com>
 <gUMkq7nXZd1ZQonHHLCoyQGqH03wDZbZDVj9vv6IyrM=.99ff7acd-7a2c-49f6-a00f-fae933c861d6@github.com>
Message-ID: <d-zO0o2wJlWtTOx1yJ5ansStDgdY-D4VAE1vM5IFKf4=.e2d939af-bf7a-46af-8591-c67de1812014@github.com>

On Mon, 6 Feb 2023 21:30:35 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>>> Thanks for the comments.
>>> 
>>> Agree that smarter error checking for the likely scenario of a spurious semi-colon would be an improvement.
>>> 
>>> I'm agnostic on what would be "best" - just trying to address some stale bugs.
>>> 
>>> If there is uncertainty about what the spec should be, but also no action, that obviously paralyzes progress. What do you guys recommend we do?
>>> 
>>> This bug will have its 10th birthday in October :)
>> 
>> I would suggest to go ahead with a solution to report and ignore excess semicolons, since changing JLS is a bigger deal that cannot be done here.   And even if we change JLS going forward, a solution to "report and ignore" excess semicolons might be worth back-porting.
>
>> I would suggest to go ahead with a solution to report and ignore excess semicolons, since changing JLS is a bigger deal that cannot be done here. And even if we change JLS going forward, a solution to "report and ignore" excess semicolons might be worth back-porting.
> 
> Sounds like a good plan - thanks!

@archiecobbs I have created the CSR: https://bugs.openjdk.org/browse/JDK-8301905 for you. I guess you are able to create it too but just in case

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

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

From vromero at openjdk.org  Tue Feb  7 04:18:42 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 7 Feb 2023 04:18:42 GMT
Subject: RFR: 8027682: javac wrongly accepts semicolons in package and
 import decls
In-Reply-To: <gUMkq7nXZd1ZQonHHLCoyQGqH03wDZbZDVj9vv6IyrM=.99ff7acd-7a2c-49f6-a00f-fae933c861d6@github.com>
References: <bQN6VoWgHskZ_Wg9PgBhKWwUDYp5jlRGja_LkitHQY4=.1a7d2eec-a992-4cee-9eb0-68fe1821e276@github.com>
 <dtz29IPotBwm63Q-eOnJR_XxFhqIMOjxvTEkvKuzonQ=.22cadcde-c3bb-440a-85ad-cd7274383a68@github.com>
 <6KIybFgOWGOR17ioiHIP8ddTBffXsb0ELJET0Pkwtb4=.0ee4c798-5a84-40bc-90a5-6497fbb71914@github.com>
 <gUMkq7nXZd1ZQonHHLCoyQGqH03wDZbZDVj9vv6IyrM=.99ff7acd-7a2c-49f6-a00f-fae933c861d6@github.com>
Message-ID: <xV3WTv2xOhloyFTBN8q3IGQVXX7c3rc7Dj0KKV9WXJk=.fadf3f1f-15dc-4771-8050-f3e807a1b97b@github.com>

On Mon, 6 Feb 2023 21:30:35 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>>> Thanks for the comments.
>>> 
>>> Agree that smarter error checking for the likely scenario of a spurious semi-colon would be an improvement.
>>> 
>>> I'm agnostic on what would be "best" - just trying to address some stale bugs.
>>> 
>>> If there is uncertainty about what the spec should be, but also no action, that obviously paralyzes progress. What do you guys recommend we do?
>>> 
>>> This bug will have its 10th birthday in October :)
>> 
>> I would suggest to go ahead with a solution to report and ignore excess semicolons, since changing JLS is a bigger deal that cannot be done here.   And even if we change JLS going forward, a solution to "report and ignore" excess semicolons might be worth back-porting.
>
>> I would suggest to go ahead with a solution to report and ignore excess semicolons, since changing JLS is a bigger deal that cannot be done here. And even if we change JLS going forward, a solution to "report and ignore" excess semicolons might be worth back-porting.
> 
> Sounds like a good plan - thanks!

@archiecobbs we use JavacParser::peekToken to look ahead, this method could be useful here

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

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

From abimpoudis at openjdk.org  Tue Feb  7 10:37:47 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Tue, 7 Feb 2023 10:37:47 GMT
Subject: RFR: 8301858: Verification error when compiling switch with record
 patterns
In-Reply-To: <cpGG6OTeBDYBx84stB4JJvw5SmhahmFnJanFpUclsn4=.32a30114-6747-4d65-93a4-783100726e26@github.com>
References: <cpGG6OTeBDYBx84stB4JJvw5SmhahmFnJanFpUclsn4=.32a30114-6747-4d65-93a4-783100726e26@github.com>
Message-ID: <dGpA9kXgXzYRWALaBzkyT980wMj2o7sLF8WFOKzLJhE=.7fb298c9-d478-449d-8bd8-004d20f8f40b@github.com>

On Mon, 6 Feb 2023 13:06:30 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> When unrolling/translating record patterns with an unconditional case, we were translating the last/innermost case to`case null, default` skipping the initialization of a bound variable `o` in the example below:
> 
>     switch (..) {
>       case R1(Object o):
>                       return meth_O(o); 
>     }
>     => 
>     switch (..) {
>        case R1: 
>           switch(..) {
>             case null, default:
>                             return meth_O(o);
>           }
>     }
> 
> This PR addresses that by emitting the correct label instead of default.

One test is failing. Do not integrate yet

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

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

From prappo at openjdk.org  Tue Feb  7 11:34:48 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 7 Feb 2023 11:34:48 GMT
Subject: RFR: JDK-8300914: Allow `@` as an escape in documentation comments
 [v5]
In-Reply-To: <mJhUf6DQbU1z0AG99JG0O3n558jxvc1y7YZy-LIFlLI=.6c5bc311-f7b8-4b27-8d39-400e00abd1f8@github.com>
References: <FuwqJLq_p2KGjWFYjms8z_Qvxbov1wlBFdgWDArxCb8=.b017e75e-2994-474c-b1cd-b1335ad1f274@github.com>
 <mJhUf6DQbU1z0AG99JG0O3n558jxvc1y7YZy-LIFlLI=.6c5bc311-f7b8-4b27-8d39-400e00abd1f8@github.com>
Message-ID: <FgtiavKZ7m78CkfLWTTbuaFu-Tov9Nu3lV0VHxmBXpM=.4a7a5fc6-5de5-4414-b3f0-d57c14a1bad3@github.com>

On Mon, 6 Feb 2023 19:33:06 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a moderately simple update to permit the use of `@` as the escape character in a limited set of escape sequences.
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve spec wording

src/jdk.compiler/share/classes/com/sun/source/doctree/EscapeTree.java line 54:

> 52:      *
> 53:      * <p>Note: this method returns the escaped character, not the original escape sequence.
> 54:      *

Please delete this newline.

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

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

From tvaleev at openjdk.org  Tue Feb  7 13:10:47 2023
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Tue, 7 Feb 2023 13:10:47 GMT
Subject: RFR: 8027682: javac wrongly accepts semicolons in package and
 import decls [v2]
In-Reply-To: <MNB0bXAypGlVyMHzXS7mal1CWGKnrlDM4WPc0_sSUm4=.c8a0751b-8960-441b-bb65-4641d1c9b246@github.com>
References: <bQN6VoWgHskZ_Wg9PgBhKWwUDYp5jlRGja_LkitHQY4=.1a7d2eec-a992-4cee-9eb0-68fe1821e276@github.com>
 <MNB0bXAypGlVyMHzXS7mal1CWGKnrlDM4WPc0_sSUm4=.c8a0751b-8960-441b-bb65-4641d1c9b246@github.com>
Message-ID: <nJap5cKX3w77kj6EJWW6h6sfhNkwoXf3R-hOlZksXB8=.1ab52abe-f9b2-4d3f-b604-0cf617480a84@github.com>

On Tue, 7 Feb 2023 00:01:47 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> JLS [?7.3](https://docs.oracle.com/javase/specs/jls/se19/html/jls-7.html#jls-7.3) specifies that while a lone semi-colon is a valid _TopLevelClassOrInterfaceDeclaration_, it is not a valid _ImportDeclaration_. Therefore, if we see a lone semi-colon while looking for the next import statement we have to advance and accept a class declaration, and we can therefore no longer accept any further `import` statements.
>> 
>> However, the compiler was allowing this, for example:
>> 
>> package p; import X; ;;; import Y; class Foo {}
>> 
>> The bug is that the parser was switching out of "look for imports" mode after parsing a valid class declaration, but it was not switching out of "look for imports" mode after parsing a lone semi-colon.
>> 
>> The fix to `JavacParser.java` is easy, however it also requires these adjustments to unit tests:
>> 
>> * Test `tree/T6963934.java` must go away, because it is verifying a bug that only happens when the above bogus input is successfully parsed, and this can no longer happen.
>> * A bug in `lib/types/TypeHarness.java` was uncovered and fixed; it was inserting an extra semi-colon.
>> * The following bugs, which check invalid syntax within import statements, now generate different parse errors and therefor needed their "golden output" updated:
>>   * annotations/typeAnnotations/failures/AnnotatedImport.java
>>   * annotations/typeAnnotations/failures/AnnotatedPackage1.java
>>   * annotations/typeAnnotations/failures/AnnotatedPackage2.java
>
> Archie L. Cobbs has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix some extraneous semi-colons that are now disallowed.
>  - Give a more helpful error for spurious semi-colons before import statements.

Just for information. I've search for the `import [\w.]+;;\s+import` regex across Java sources corpus. The whole corpus is ~31,600,000 files from ~245,000 repositories. The query matched 896 files from 434 repositories.

Here are particular examples:

https://github.com/openjdk/jdk/blob/09b8a1959771213cb982d062f0a913285e4a0c6e/test/jdk/com/sun/jndi/dns/Parser.java#L33 (in OpenJDK, it's still there!)

https://github.com/bpupadhyaya/openjdk-8/blob/45af329463a45955ea2759b89cb0ebfe40570c3f/jdk/src/macosx/classes/sun/font/CFont.java#L31 (ok, this one was fixed later)

https://github.com/mvpleung/QingTingRadio/blob/83c48010f596db82fe09c9f5619987be5e76f14c/QingTingFM/src/com/google/protobuf/GeneratedMessageLite.java#L3

https://github.com/wallysonlima/mypocket/blob/30038ad6a2b3f18ce0af17e7c4a0f07bbf5db8b8/app/src/main/java/wallyson/com/br/mypocket/view/SpendingYearActivity.java#L4

https://github.com/l33tnoob/MT65x2_kernel_lk/blob/f48b462fe90862b30ea067698167c0a55458eec3/mediatek/packages/apps/Stk1/src/com/android/stk/StkAppService.java#L112

https://github.com/alibaba/dragonwell17/blob/586085bb39516e39ffb616ece3e2ca60fd59d225/test/jdk/java/lang/constant/methodTypeDesc/ResolveConstantDesc.java#L38

https://github.com/ninethousand9000/ninehackv1/blob/6da59fb5d25c52fab5ed2978c298d3392133dc7d/src/main/java/me/ninethousand/ninehack/feature/features/client/HUD.java#L7

https://github.com/erincandescent/Impeller/blob/b4c30710975cb49a4223c9352fba032842e91a28/src/eu/e43/impeller/activity/SettingsActivity.java#L10

https://github.com/swarmcom/jSynapse/blob/70587ce0c16d4cb9e318d6cc0cfd414f2a6d4a84/src/main/java/org/swarmcom/jsynapse/service/accesstoken/AccessTokenServiceImpl.java#L21

https://github.com/ging/fiware-draco/blob/c0fe547f95a0e475aaa892ff8f72185901e88bcc/nifi-ngsi-bundle/nifi-ngsi-processors/src/main/java/org/apache/nifi/processors/ngsi/NGSIToPostgreSQL.java#L21

https://github.com/anyaudio/anyaudio-android-app/blob/31b7d033a5b7a303c786ea7f02849e302588b6f0/app/src/main/java/any/audio/Activity/UpdateThemedActivity.java#L10

https://github.com/HewlettPackard/mds/blob/1883702cbe11ae9866a486a938ffe306dda67fbe/java-api/src/com/hpl/mds/impl/TaskOptionImpl.java#L31

Some of them are outdated and was fixed later, some are Android-specific, so probably we don't care much, but there are also totally legitimate cases.

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

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

From mcimadamore at openjdk.org  Tue Feb  7 15:03:05 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 7 Feb 2023 15:03:05 GMT
Subject: RFR: 8295019: Cannot call a method with a parameter of a local
 class declared in a lambda [v5]
In-Reply-To: <9h1WIcQRVBsffUdwC0E48V86ie5qTOLq9e7jAA4Yo-0=.ca023245-8d99-42b6-b88f-0c1d82fc0280@github.com>
References: <RgTl0a5A7X51DERBJaYhKfiOgZmo-qbXUpWbLoZJwd8=.e869c7c9-fed7-478f-a974-f812b44ee277@github.com>
 <9h1WIcQRVBsffUdwC0E48V86ie5qTOLq9e7jAA4Yo-0=.ca023245-8d99-42b6-b88f-0c1d82fc0280@github.com>
Message-ID: <dnpbL1H4jeC21lOQ87GHyg_HxmaYiGrSLcnbntQZP98=.a2732616-b8f2-4d0a-93ee-c84f626b1bbe@github.com>

On Mon, 6 Feb 2023 04:04:10 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Very interesting and, a bit, tricky bug. So the compiler is rejecting code like:
>> 
>> class LocalClassDeclaredInsideLambdaTest {
>>     void run(Runnable r) {}
>> 
>>     void m() {
>>         run(() -> {
>>             class C {
>>                 static void takeC(C c) {}
>>                 static C giveC() {
>>                     return null;
>>                 }
>>             }
>>             C.takeC(C.giveC());
>>         });
>>     }
>> }
>> 
>> with error:
>> 
>> LocalClassInsideLambda.java:12: error: incompatible types: C cannot be converted to C
>>             C.takeC(C.giveC());
>>                            ^
>> Note: Some messages have been simplified; recompile with -Xdiags:verbose to get full output
>> 1 error
>> 
>> which is very misleading as the type seems to be the same. The issue here is that both the lambda and invocation `C.giveC()` are considered poly expressions. `C.giveC()` is not a poly expression but at the moment the compiler is analyzing if an invocation is a poly expression or not, it doesn't have enough information and errs on the safe side.
>> 
>> We have a cache at `com.sun.tools.javac.comp.ArgumentAttr`, see field `argumentTypeCache`, which stores the current deferred type of arguments considered poly expressions. The problem with this particular code is that inside of the lambda there is a class declaration and every time the lambda is attributed a new class type is created.
>> 
>> The lambda, and thus the expression `C.giveC()` are attributed twice. The first time we have an speculative attribution, as a result `argumentTypeCache` will have two entries, one for the lambda and one for `C.giveC()` but the type of `C` is the type created during speculative attribution on a copy of the original lambda tree, let's call it C1. Later on another pass the lambda is attributed `"for real"`, during the check phase. At this point the entry for the lambda in the cache pointed by `argumentTypeCache` has been removed but there is still the entry for `C.giveC()` which still refers to `C1`. So now in the `"for real"` attribution of the lambda which happens on the original tree, not in a copy, a new type for class `C` is created, let's call it `C2`. But when we get to the point where we need to attribute again `C.takeC(C.giveC())` invocation `C.takeC` is expecting `C2` but as `C.giveC()` is again considered a poly expression and an entry is found for it at the cache, the com
 piler reuses that entry which refers to `C1`. And unfortunately `C1 != C2` and thus the error is issued. So the solution I propose is to use a local cache for the speculative attribution of lambda expressions. This is a one liner fix, although an alternative solution could be to scan the lambda body and only use a local cache if a new type is defined inside the lambda, this could be a more optimal solution performance wise as we could save some attributions in some cases. Comments?
>> 
>> TIA
>
> Vicente Romero has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - moving the visitor closer to its client
>  - addressing review comments

Marked as reviewed by mcimadamore (Reviewer).

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

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

From prappo at openjdk.org  Tue Feb  7 15:47:15 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 7 Feb 2023 15:47:15 GMT
Subject: RFR: JDK-8301810: Bug in doctree DocCommentTester.compress [v2]
In-Reply-To: <P0uNrYOzKb08vxHVuyTMgs-Mss9AmyMmeV3rOM8A3mY=.a7a2996d-4220-43f9-a165-f8129808c933@github.com>
References: <u06shK1KvoC4Jfdj1DRzNuUAwTTc9igcXt2YIZ5v-d8=.0b364a28-49d2-42f5-add7-7614e571438c@github.com>
 <P0uNrYOzKb08vxHVuyTMgs-Mss9AmyMmeV3rOM8A3mY=.a7a2996d-4220-43f9-a165-f8129808c933@github.com>
Message-ID: <cp9B-2x-nUWBLGj12F5ErFeQtWu4HWauNXaNkXdFrws=.2f5ad184-b93a-490a-96a2-7b0bd06dcb04@github.com>

On Mon, 6 Feb 2023 19:00:02 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a minor but long-standing bug in the code to "compress" long strings in the `doctree` `DocCommentTester` class.
>> 
>> The primary change is in `DocCommentTester`, to fix the code, and make it somewhat more robust.  The change does break some golden output, in comments and files, so advantage is taken to increase the max size of compressed strings.
>
> Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into 8301810.doctree-doccommenttester-compress
>  - JDK-8301810: Bug in doctree DocCommentTester.compress

Looks good.

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

Marked as reviewed by prappo (Reviewer).

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

From duke at openjdk.org  Tue Feb  7 15:56:56 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Tue, 7 Feb 2023 15:56:56 GMT
Subject: RFR: 8027682: javac wrongly accepts semicolons in package and
 import decls [v2]
In-Reply-To: <ItQKkYYA0SJCWuFP_mtxkIyxMZgjlMs998Q2d2dplOY=.b809b2c5-da32-4111-82f8-4d645a03f6a3@github.com>
References: <bQN6VoWgHskZ_Wg9PgBhKWwUDYp5jlRGja_LkitHQY4=.1a7d2eec-a992-4cee-9eb0-68fe1821e276@github.com>
 <MNB0bXAypGlVyMHzXS7mal1CWGKnrlDM4WPc0_sSUm4=.c8a0751b-8960-441b-bb65-4641d1c9b246@github.com>
 <ItQKkYYA0SJCWuFP_mtxkIyxMZgjlMs998Q2d2dplOY=.b809b2c5-da32-4111-82f8-4d645a03f6a3@github.com>
Message-ID: <nqfAUa-07BVbamkwwFxYjdndFZSaSeygrM_X_gj_AV0=.d107a766-8566-4be2-83cf-9192d6355897@github.com>

On Tue, 7 Feb 2023 00:05:26 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Maybe it's my fault for misleading you in the discussion, but the dictionary says that "semicolon" is not a hyphenated word.

Nope, totally my fault. Apparently I've been spelling it wrong for years. Will fix.

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

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

From duke at openjdk.org  Tue Feb  7 16:05:40 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Tue, 7 Feb 2023 16:05:40 GMT
Subject: RFR: 8027682: javac wrongly accepts semicolons in package and
 import decls [v3]
In-Reply-To: <bQN6VoWgHskZ_Wg9PgBhKWwUDYp5jlRGja_LkitHQY4=.1a7d2eec-a992-4cee-9eb0-68fe1821e276@github.com>
References: <bQN6VoWgHskZ_Wg9PgBhKWwUDYp5jlRGja_LkitHQY4=.1a7d2eec-a992-4cee-9eb0-68fe1821e276@github.com>
Message-ID: <iq_jH_PtVYREIdZFu9yFNX5VIi9Yt1irIBadotVF5F4=.a555e61f-6cc9-4544-8971-df86bee4ce2f@github.com>

> JLS [?7.3](https://docs.oracle.com/javase/specs/jls/se19/html/jls-7.html#jls-7.3) specifies that while a lone semicolon is a valid _TopLevelClassOrInterfaceDeclaration_, it is not a valid _ImportDeclaration_. Therefore, if we see a lone semicolon while looking for the next import statement we have to advance and accept a class declaration, and we can therefore no longer accept any further `import` statements.
> 
> However, the compiler was allowing this, for example:
> 
> package p; import X; ;;; import Y; class Foo {}
> 
> The bug is that the parser was switching out of "look for imports" mode after parsing a valid class declaration, but it was not switching out of "look for imports" mode after parsing a lone semicolon.
> 
> The fix to `JavacParser.java` is easy, however it also requires these adjustments to unit tests:
> 
> * Test `tree/T6963934.java` must go away, because it is verifying a bug that only happens when the above bogus input is successfully parsed, and this can no longer happen.
> * A bug in `lib/types/TypeHarness.java` was uncovered and fixed; it was inserting an extra semicolon.
> * The following bugs, which check invalid syntax within import statements, now generate different parse errors and therefor needed their "golden output" updated:
>   * annotations/typeAnnotations/failures/AnnotatedImport.java
>   * annotations/typeAnnotations/failures/AnnotatedPackage1.java
>   * annotations/typeAnnotations/failures/AnnotatedPackage2.java

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

  Correct misspelling of "semicolon" (there is no dash).

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12448/files
  - new: https://git.openjdk.org/jdk/pull/12448/files/ac02179a..673a1f18

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

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

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

From duke at openjdk.org  Tue Feb  7 16:05:43 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Tue, 7 Feb 2023 16:05:43 GMT
Subject: RFR: 8027682: javac wrongly accepts semicolons in package and
 import decls
In-Reply-To: <xV3WTv2xOhloyFTBN8q3IGQVXX7c3rc7Dj0KKV9WXJk=.fadf3f1f-15dc-4771-8050-f3e807a1b97b@github.com>
References: <bQN6VoWgHskZ_Wg9PgBhKWwUDYp5jlRGja_LkitHQY4=.1a7d2eec-a992-4cee-9eb0-68fe1821e276@github.com>
 <dtz29IPotBwm63Q-eOnJR_XxFhqIMOjxvTEkvKuzonQ=.22cadcde-c3bb-440a-85ad-cd7274383a68@github.com>
 <6KIybFgOWGOR17ioiHIP8ddTBffXsb0ELJET0Pkwtb4=.0ee4c798-5a84-40bc-90a5-6497fbb71914@github.com>
 <gUMkq7nXZd1ZQonHHLCoyQGqH03wDZbZDVj9vv6IyrM=.99ff7acd-7a2c-49f6-a00f-fae933c861d6@github.com>
 <xV3WTv2xOhloyFTBN8q3IGQVXX7c3rc7Dj0KKV9WXJk=.fadf3f1f-15dc-4771-8050-f3e807a1b97b@github.com>
Message-ID: <n0PXyy4M-thxbNkEEpamw22NI8Q6okZTuP_3AEYPyxo=.866f8988-e827-497e-ab68-7dd9441421f9@github.com>

On Tue, 7 Feb 2023 04:15:40 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>>> I would suggest to go ahead with a solution to report and ignore excess semicolons, since changing JLS is a bigger deal that cannot be done here. And even if we change JLS going forward, a solution to "report and ignore" excess semicolons might be worth back-porting.
>> 
>> Sounds like a good plan - thanks!
>
> @archiecobbs we use JavacParser::peekToken to look ahead, this method could be useful here

@vicente-romero-oracle wrote:
> I have created the CSR

Thanks for doing that. I've updated it, hopefully that's sufficient.

> we use JavacParser::peekToken to look ahead, this method could be useful here

Thanks, I wasn't aware of that method. I don't think it helps here though... the issue is I needed to consume arbitrarily many semi-colons at once, so that N consecutive semi-colons only generate one error, but also keep track of their source code positions in case they actually turn out to be valid _TopLevelClassOrInterfaceDeclaration_(s).

@amaembo wrote:
> So we may estimate that about 0.2% of projects may have compilation error after this change.

Thanks, that's really helpful to know.. I've included this info in the CSR.

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

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

From vromero at openjdk.org  Tue Feb  7 16:27:26 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 7 Feb 2023 16:27:26 GMT
Subject: RFR: 8295019: Cannot call a method with a parameter of a local
 class declared in a lambda [v5]
In-Reply-To: <9h1WIcQRVBsffUdwC0E48V86ie5qTOLq9e7jAA4Yo-0=.ca023245-8d99-42b6-b88f-0c1d82fc0280@github.com>
References: <RgTl0a5A7X51DERBJaYhKfiOgZmo-qbXUpWbLoZJwd8=.e869c7c9-fed7-478f-a974-f812b44ee277@github.com>
 <9h1WIcQRVBsffUdwC0E48V86ie5qTOLq9e7jAA4Yo-0=.ca023245-8d99-42b6-b88f-0c1d82fc0280@github.com>
Message-ID: <RjySo4YqRRQcMXBogby9IBF2rJRxYPbh2q0U_v4q7z4=.96af34f3-25dc-4aaf-886c-671aa2852498@github.com>

On Mon, 6 Feb 2023 04:04:10 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Very interesting and, a bit, tricky bug. So the compiler is rejecting code like:
>> 
>> class LocalClassDeclaredInsideLambdaTest {
>>     void run(Runnable r) {}
>> 
>>     void m() {
>>         run(() -> {
>>             class C {
>>                 static void takeC(C c) {}
>>                 static C giveC() {
>>                     return null;
>>                 }
>>             }
>>             C.takeC(C.giveC());
>>         });
>>     }
>> }
>> 
>> with error:
>> 
>> LocalClassInsideLambda.java:12: error: incompatible types: C cannot be converted to C
>>             C.takeC(C.giveC());
>>                            ^
>> Note: Some messages have been simplified; recompile with -Xdiags:verbose to get full output
>> 1 error
>> 
>> which is very misleading as the type seems to be the same. The issue here is that both the lambda and invocation `C.giveC()` are considered poly expressions. `C.giveC()` is not a poly expression but at the moment the compiler is analyzing if an invocation is a poly expression or not, it doesn't have enough information and errs on the safe side.
>> 
>> We have a cache at `com.sun.tools.javac.comp.ArgumentAttr`, see field `argumentTypeCache`, which stores the current deferred type of arguments considered poly expressions. The problem with this particular code is that inside of the lambda there is a class declaration and every time the lambda is attributed a new class type is created.
>> 
>> The lambda, and thus the expression `C.giveC()` are attributed twice. The first time we have an speculative attribution, as a result `argumentTypeCache` will have two entries, one for the lambda and one for `C.giveC()` but the type of `C` is the type created during speculative attribution on a copy of the original lambda tree, let's call it C1. Later on another pass the lambda is attributed `"for real"`, during the check phase. At this point the entry for the lambda in the cache pointed by `argumentTypeCache` has been removed but there is still the entry for `C.giveC()` which still refers to `C1`. So now in the `"for real"` attribution of the lambda which happens on the original tree, not in a copy, a new type for class `C` is created, let's call it `C2`. But when we get to the point where we need to attribute again `C.takeC(C.giveC())` invocation `C.takeC` is expecting `C2` but as `C.giveC()` is again considered a poly expression and an entry is found for it at the cache, the com
 piler reuses that entry which refers to `C1`. And unfortunately `C1 != C2` and thus the error is issued. So the solution I propose is to use a local cache for the speculative attribution of lambda expressions. This is a one liner fix, although an alternative solution could be to scan the lambda body and only use a local cache if a new type is defined inside the lambda, this could be a more optimal solution performance wise as we could save some attributions in some cases. Comments?
>> 
>> TIA
>
> Vicente Romero has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - moving the visitor closer to its client
>  - addressing review comments

thanks for the review

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

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

From vromero at openjdk.org  Tue Feb  7 16:27:28 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 7 Feb 2023 16:27:28 GMT
Subject: Integrated: 8295019: Cannot call a method with a parameter of a local
 class declared in a lambda
In-Reply-To: <RgTl0a5A7X51DERBJaYhKfiOgZmo-qbXUpWbLoZJwd8=.e869c7c9-fed7-478f-a974-f812b44ee277@github.com>
References: <RgTl0a5A7X51DERBJaYhKfiOgZmo-qbXUpWbLoZJwd8=.e869c7c9-fed7-478f-a974-f812b44ee277@github.com>
Message-ID: <FAcz1DEoOj4Cejs1RqLzBObV6WsXESA21D73qf4IAR0=.9d0757d6-8c4d-442c-bfab-5f14daaa5e18@github.com>

On Tue, 31 Jan 2023 05:32:28 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Very interesting and, a bit, tricky bug. So the compiler is rejecting code like:
> 
> class LocalClassDeclaredInsideLambdaTest {
>     void run(Runnable r) {}
> 
>     void m() {
>         run(() -> {
>             class C {
>                 static void takeC(C c) {}
>                 static C giveC() {
>                     return null;
>                 }
>             }
>             C.takeC(C.giveC());
>         });
>     }
> }
> 
> with error:
> 
> LocalClassInsideLambda.java:12: error: incompatible types: C cannot be converted to C
>             C.takeC(C.giveC());
>                            ^
> Note: Some messages have been simplified; recompile with -Xdiags:verbose to get full output
> 1 error
> 
> which is very misleading as the type seems to be the same. The issue here is that both the lambda and invocation `C.giveC()` are considered poly expressions. `C.giveC()` is not a poly expression but at the moment the compiler is analyzing if an invocation is a poly expression or not, it doesn't have enough information and errs on the safe side.
> 
> We have a cache at `com.sun.tools.javac.comp.ArgumentAttr`, see field `argumentTypeCache`, which stores the current deferred type of arguments considered poly expressions. The problem with this particular code is that inside of the lambda there is a class declaration and every time the lambda is attributed a new class type is created.
> 
> The lambda, and thus the expression `C.giveC()` are attributed twice. The first time we have an speculative attribution, as a result `argumentTypeCache` will have two entries, one for the lambda and one for `C.giveC()` but the type of `C` is the type created during speculative attribution on a copy of the original lambda tree, let's call it C1. Later on another pass the lambda is attributed `"for real"`, during the check phase. At this point the entry for the lambda in the cache pointed by `argumentTypeCache` has been removed but there is still the entry for `C.giveC()` which still refers to `C1`. So now in the `"for real"` attribution of the lambda which happens on the original tree, not in a copy, a new type for class `C` is created, let's call it `C2`. But when we get to the point where we need to attribute again `C.takeC(C.giveC())` invocation `C.takeC` is expecting `C2` but as `C.giveC()` is again considered a poly expression and an entry is found for it at the cache, the comp
 iler reuses that entry which refers to `C1`. And unfortunately `C1 != C2` and thus the error is issued. So the solution I propose is to use a local cache for the speculative attribution of lambda expressions. This is a one liner fix, although an alternative solution could be to scan the lambda body and only use a local cache if a new type is defined inside the lambda, this could be a more optimal solution performance wise as we could save some attributions in some cases. Comments?
> 
> TIA

This pull request has now been integrated.

Changeset: a73d012c
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a73d012c727ecbd5fcf97a624fc969ba6305db5f
Stats:     124 lines in 2 files changed: 123 ins; 0 del; 1 mod

8295019: Cannot call a method with a parameter of a local class declared in a lambda

Reviewed-by: mcimadamore

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

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

From vromero at openjdk.org  Tue Feb  7 17:22:10 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 7 Feb 2023 17:22:10 GMT
Subject: RFR: 8027682: javac wrongly accepts semicolons in package and
 import decls [v3]
In-Reply-To: <iq_jH_PtVYREIdZFu9yFNX5VIi9Yt1irIBadotVF5F4=.a555e61f-6cc9-4544-8971-df86bee4ce2f@github.com>
References: <bQN6VoWgHskZ_Wg9PgBhKWwUDYp5jlRGja_LkitHQY4=.1a7d2eec-a992-4cee-9eb0-68fe1821e276@github.com>
 <iq_jH_PtVYREIdZFu9yFNX5VIi9Yt1irIBadotVF5F4=.a555e61f-6cc9-4544-8971-df86bee4ce2f@github.com>
Message-ID: <u4PCfr1t8qF_DOLh-7uhqjGnSiN2EjwuyEqZ_M1pz0o=.af7d9187-a441-4e2a-80dc-92170b7de126@github.com>

On Tue, 7 Feb 2023 16:05:40 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> JLS [?7.3](https://docs.oracle.com/javase/specs/jls/se19/html/jls-7.html#jls-7.3) specifies that while a lone semicolon is a valid _TopLevelClassOrInterfaceDeclaration_, it is not a valid _ImportDeclaration_. Therefore, if we see a lone semicolon while looking for the next import statement we have to advance and accept a class declaration, and we can therefore no longer accept any further `import` statements.
>> 
>> However, the compiler was allowing this, for example:
>> 
>> package p; import X; ;;; import Y; class Foo {}
>> 
>> The bug is that the parser was switching out of "look for imports" mode after parsing a valid class declaration, but it was not switching out of "look for imports" mode after parsing a lone semicolon.
>> 
>> The fix to `JavacParser.java` is easy, however it also requires these adjustments to unit tests:
>> 
>> * Test `tree/T6963934.java` must go away, because it is verifying a bug that only happens when the above bogus input is successfully parsed, and this can no longer happen.
>> * A bug in `lib/types/TypeHarness.java` was uncovered and fixed; it was inserting an extra semicolon.
>> * The following bugs, which check invalid syntax within import statements, now generate different parse errors and therefor needed their "golden output" updated:
>>   * annotations/typeAnnotations/failures/AnnotatedImport.java
>>   * annotations/typeAnnotations/failures/AnnotatedPackage1.java
>>   * annotations/typeAnnotations/failures/AnnotatedPackage2.java
>
> Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Correct misspelling of "semicolon" (there is no dash).

some comments on the CSR:

- Solution section
    I would remove comments that are implementation details. Probably a matter of style but I would simply go like:
    `Disallow extraneous semicolons prior to import statements.`
- Specification section
    I don't think that the links to the PR and the bug belong here as those are already linked to the CSR. I would mention the  related section of the spec and probably paste the specific text that applies here. I see the before and after behavior probably more in the `Solutions`

The comment about how many projects could be affected probably belongs to the `Compatibility Risk Description` field, which you can access by clicking on the `Edit` button, of the CSR or to a `Notes` additional section after the `Specification` section.

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

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

From prappo at openjdk.org  Tue Feb  7 17:38:05 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 7 Feb 2023 17:38:05 GMT
Subject: RFR: JDK-8300914: Allow `@` as an escape in documentation comments
 [v5]
In-Reply-To: <mJhUf6DQbU1z0AG99JG0O3n558jxvc1y7YZy-LIFlLI=.6c5bc311-f7b8-4b27-8d39-400e00abd1f8@github.com>
References: <FuwqJLq_p2KGjWFYjms8z_Qvxbov1wlBFdgWDArxCb8=.b017e75e-2994-474c-b1cd-b1335ad1f274@github.com>
 <mJhUf6DQbU1z0AG99JG0O3n558jxvc1y7YZy-LIFlLI=.6c5bc311-f7b8-4b27-8d39-400e00abd1f8@github.com>
Message-ID: <rT6v0U9f9ZkIXqJLKZPFfDYKxlwgxnJN7X4KPo4t9iE=.4ff133dc-8b24-48b6-ad3b-3e04c0715c5b@github.com>

On Mon, 6 Feb 2023 19:33:06 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a moderately simple update to permit the use of `@` as the escape character in a limited set of escape sequences.
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve spec wording

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Checker.java line 364:

> 362:     @Override @DefinedBy(Api.COMPILER_TREE)
> 363:     public Void visitEscape(EscapeTree tree, Void ignore) {
> 364:         hasNonWhitespaceText = true;

What's the significance of setting this flag here? It doesn't seem to be set in `visitEntity`, for example.

Anyway, when I commented L364 out, no tests failed.

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

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

From duke at openjdk.org  Tue Feb  7 17:43:29 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Tue, 7 Feb 2023 17:43:29 GMT
Subject: RFR: 8027682: javac wrongly accepts semicolons in package and
 import decls [v3]
In-Reply-To: <u4PCfr1t8qF_DOLh-7uhqjGnSiN2EjwuyEqZ_M1pz0o=.af7d9187-a441-4e2a-80dc-92170b7de126@github.com>
References: <bQN6VoWgHskZ_Wg9PgBhKWwUDYp5jlRGja_LkitHQY4=.1a7d2eec-a992-4cee-9eb0-68fe1821e276@github.com>
 <iq_jH_PtVYREIdZFu9yFNX5VIi9Yt1irIBadotVF5F4=.a555e61f-6cc9-4544-8971-df86bee4ce2f@github.com>
 <u4PCfr1t8qF_DOLh-7uhqjGnSiN2EjwuyEqZ_M1pz0o=.af7d9187-a441-4e2a-80dc-92170b7de126@github.com>
Message-ID: <dHWUyTaM3nyDJ7dgK9jSSC2me_XIfkRI9Z2TQrQz1HY=.92fde1cb-352f-4752-b3fa-05975ea83eb1@github.com>

On Tue, 7 Feb 2023 17:18:55 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> some comments on the CSR:

Thanks - updated.

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

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

From jjg at openjdk.org  Tue Feb  7 18:51:52 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 7 Feb 2023 18:51:52 GMT
Subject: Integrated: JDK-8301810: Bug in doctree DocCommentTester.compress
In-Reply-To: <u06shK1KvoC4Jfdj1DRzNuUAwTTc9igcXt2YIZ5v-d8=.0b364a28-49d2-42f5-add7-7614e571438c@github.com>
References: <u06shK1KvoC4Jfdj1DRzNuUAwTTc9igcXt2YIZ5v-d8=.0b364a28-49d2-42f5-add7-7614e571438c@github.com>
Message-ID: <mSn0w9LmN5azOiIodNamUSRpplHQrE97zycWmUw86ec=.59a620fe-181e-4dc7-99e4-b5ab8b33f169@github.com>

On Fri, 3 Feb 2023 20:18:29 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a minor but long-standing bug in the code to "compress" long strings in the `doctree` `DocCommentTester` class.
> 
> The primary change is in `DocCommentTester`, to fix the code, and make it somewhat more robust.  The change does break some golden output, in comments and files, so advantage is taken to increase the max size of compressed strings.

This pull request has now been integrated.

Changeset: 74485a3f
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/74485a3f231695aab1f27b38f2f658a92a3fcc99
Stats:     22 lines in 13 files changed: 4 ins; 0 del; 18 mod

8301810: Bug in doctree DocCommentTester.compress

Reviewed-by: prappo

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

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

From jjg at openjdk.org  Tue Feb  7 19:17:14 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 7 Feb 2023 19:17:14 GMT
Subject: RFR: JDK-8300914: Allow `@` as an escape in documentation comments
 [v6]
In-Reply-To: <FuwqJLq_p2KGjWFYjms8z_Qvxbov1wlBFdgWDArxCb8=.b017e75e-2994-474c-b1cd-b1335ad1f274@github.com>
References: <FuwqJLq_p2KGjWFYjms8z_Qvxbov1wlBFdgWDArxCb8=.b017e75e-2994-474c-b1cd-b1335ad1f274@github.com>
Message-ID: <cLY9uxQYJktml7PoQEObQat-w3A1mmbaLilfq5Es-gk=.4036fb96-b058-442b-b396-5380f3fd1c5d@github.com>

> Please review a moderately simple update to permit the use of `@` as the escape character in a limited set of escape sequences.

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

 - post-merge fix
 - Merge remote-tracking branch 'upstream/master' into 8300914.at-escapes
 - Improve spec wording
 - Merge with upstream/master
 - Address review feedback
 - Merge with upstream/master
 - JDK-8301294: Allow `@` as an escape in documentation comments

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

Changes: https://git.openjdk.org/jdk/pull/12372/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12372&range=05
  Stats: 456 lines in 16 files changed: 436 ins; 0 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/12372.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12372/head:pull/12372

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

From jjg at openjdk.org  Tue Feb  7 19:42:39 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 7 Feb 2023 19:42:39 GMT
Subject: RFR: JDK-8298405: Support Markdown in the standard doclet [v5]
In-Reply-To: <ltVVuz_1JTacO6uHQATm0UPq7e0PmZpqDkVUepejnDY=.2650c47e-737f-46f6-936b-47cab371b848@github.com>
References: <ltVVuz_1JTacO6uHQATm0UPq7e0PmZpqDkVUepejnDY=.2650c47e-737f-46f6-936b-47cab371b848@github.com>
Message-ID: <bWvzhyK4bUryCNyNvVij-H555g2F-OmCHIQL7T0ELYg=.f88f6270-e6d9-4cba-97e8-c5c4eeb1e927@github.com>

> Support for Markdown comments in the standard doclet.
> 
> To enable Markdown in a comment, start the comment with `/**md` followed by whitespace.  The syntax is as defined for CommonMark.
> 
> The work is in 3 parts:
> 
> 1. Update the Compiler Tree API to support Markdown tree nodes, containing strings of (uninterpreted) Markdown source code.
> 2. Import commonmark-java into the `jdk.javadoc` module, to be able to convert Markdown strings to HTML.
> 3. Update the standard doclet, to leverage the preceding two parts, to translate Markdown in documentation comments to `Content` nodes.
> 
> There are new tests both for the low level work in the Compiler Tree API, and for the overall high-level work in the doclet.
> 
> Background info: https://mail.openjdk.org/pipermail/javadoc-dev/2023-January/005563.html

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

 - Merge with upstream/master
 - Rename MarkdownTree to RawTextTree
 - Merge with upstream/master
 - Update copyright years
 - Rename FFFC variable
   Share Markdown parser and renderer in instance of MarkdownHandler
 - Move CommonMark to new internal module.
   Add legal header to imported CommonMark source files
   Always use Text nodes inside AttributeTree values
   Unwrap <p> from "simple" paragraphs
 - Always use Text nodes inside AttributeTree values
 - Update to CommonMark 0.21.
 - fix whitespace
 - JDK-8298405: Markdown support in the standard doclet

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

Changes: https://git.openjdk.org/jdk/pull/11701/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11701&range=04
  Stats: 15676 lines in 145 files changed: 15385 ins; 111 del; 180 mod
  Patch: https://git.openjdk.org/jdk/pull/11701.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11701/head:pull/11701

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

From duke at openjdk.org  Tue Feb  7 19:51:51 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Tue, 7 Feb 2023 19:51:51 GMT
Subject: RFR: 8027682: javac wrongly accepts semicolons in package and
 import decls [v4]
In-Reply-To: <bQN6VoWgHskZ_Wg9PgBhKWwUDYp5jlRGja_LkitHQY4=.1a7d2eec-a992-4cee-9eb0-68fe1821e276@github.com>
References: <bQN6VoWgHskZ_Wg9PgBhKWwUDYp5jlRGja_LkitHQY4=.1a7d2eec-a992-4cee-9eb0-68fe1821e276@github.com>
Message-ID: <cdmEJqw4Mlo6C_nZgCh821M2363M1aIJM3IyZ7skW2M=.ba9484bf-2072-43ff-a8b8-d58cb2298a8e@github.com>

> JLS [?7.3](https://docs.oracle.com/javase/specs/jls/se19/html/jls-7.html#jls-7.3) specifies that while a lone semicolon is a valid _TopLevelClassOrInterfaceDeclaration_, it is not a valid _ImportDeclaration_. Therefore, if we see a lone semicolon while looking for the next import statement we have to advance and accept a class declaration, and we can therefore no longer accept any further `import` statements.
> 
> However, the compiler was allowing this, for example:
> 
> package p; import X; ;;; import Y; class Foo {}
> 
> The bug is that the parser was switching out of "look for imports" mode after parsing a valid class declaration, but it was not switching out of "look for imports" mode after parsing a lone semicolon.
> 
> The fix to `JavacParser.java` is easy, however it also requires these adjustments to unit tests:
> 
> * Test `tree/T6963934.java` must go away, because it is verifying a bug that only happens when the above bogus input is successfully parsed, and this can no longer happen.
> * A bug in `lib/types/TypeHarness.java` was uncovered and fixed; it was inserting an extra semicolon.
> * The following bugs, which check invalid syntax within import statements, now generate different parse errors and therefor needed their "golden output" updated:
>   * annotations/typeAnnotations/failures/AnnotatedImport.java
>   * annotations/typeAnnotations/failures/AnnotatedPackage1.java
>   * annotations/typeAnnotations/failures/AnnotatedPackage2.java

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

  Adjust unit test to accomodate spelling change in previous commit.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12448/files
  - new: https://git.openjdk.org/jdk/pull/12448/files/673a1f18..7abe59dd

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

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

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

From jjg at openjdk.org  Tue Feb  7 20:01:40 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 7 Feb 2023 20:01:40 GMT
Subject: RFR: JDK-8300914: Allow `@` as an escape in documentation comments
 [v5]
In-Reply-To: <rT6v0U9f9ZkIXqJLKZPFfDYKxlwgxnJN7X4KPo4t9iE=.4ff133dc-8b24-48b6-ad3b-3e04c0715c5b@github.com>
References: <FuwqJLq_p2KGjWFYjms8z_Qvxbov1wlBFdgWDArxCb8=.b017e75e-2994-474c-b1cd-b1335ad1f274@github.com>
 <mJhUf6DQbU1z0AG99JG0O3n558jxvc1y7YZy-LIFlLI=.6c5bc311-f7b8-4b27-8d39-400e00abd1f8@github.com>
 <rT6v0U9f9ZkIXqJLKZPFfDYKxlwgxnJN7X4KPo4t9iE=.4ff133dc-8b24-48b6-ad3b-3e04c0715c5b@github.com>
Message-ID: <QW9ffgsgTbqyfV38s9Heh2S9yDkPKeDwn0HucTEd9OY=.9bff3f88-e8d3-4ac3-b7ed-da47ad3af651@github.com>

On Tue, 7 Feb 2023 17:33:02 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improve spec wording
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Checker.java line 364:
> 
>> 362:     @Override @DefinedBy(Api.COMPILER_TREE)
>> 363:     public Void visitEscape(EscapeTree tree, Void ignore) {
>> 364:         hasNonWhitespaceText = true;
> 
> What's the significance of setting this flag here? It doesn't seem to be set in `visitEntity`, for example.
> 
> Anyway, when I commented L364 out, no tests failed.

It's part of the HTML checking, for [palpable content](https://html.spec.whatwg.org/dev/dom.html#palpable-content)

Some HTML nodes, typically "containers" like `<table>` `<tr>` `<ul>` etc just permit child nodes and whitespace, but no non-white text.  The code here is establishing that the escape characters are treated as non-whitespace characters in any enclosing context.

It is a useful/relevant observation that entities don't set the flag.   I'd have to dig deeper to see if all entities are treated as palpable content in HTML ... the questionable ones being entities like zero-width-space, non-breaking-space etc.  It would be "less wrong" to assume that all entities are not whitespace than to not set the flag at all.

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

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

From vromero at openjdk.org  Tue Feb  7 20:36:14 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 7 Feb 2023 20:36:14 GMT
Subject: RFR: 8027682: javac wrongly accepts semicolons in package and
 import decls [v3]
In-Reply-To: <dHWUyTaM3nyDJ7dgK9jSSC2me_XIfkRI9Z2TQrQz1HY=.92fde1cb-352f-4752-b3fa-05975ea83eb1@github.com>
References: <bQN6VoWgHskZ_Wg9PgBhKWwUDYp5jlRGja_LkitHQY4=.1a7d2eec-a992-4cee-9eb0-68fe1821e276@github.com>
 <iq_jH_PtVYREIdZFu9yFNX5VIi9Yt1irIBadotVF5F4=.a555e61f-6cc9-4544-8971-df86bee4ce2f@github.com>
 <u4PCfr1t8qF_DOLh-7uhqjGnSiN2EjwuyEqZ_M1pz0o=.af7d9187-a441-4e2a-80dc-92170b7de126@github.com>
 <dHWUyTaM3nyDJ7dgK9jSSC2me_XIfkRI9Z2TQrQz1HY=.92fde1cb-352f-4752-b3fa-05975ea83eb1@github.com>
Message-ID: <QrNUtXOVHhRH-430KwvFjn50BL3mqSfEQbeIfwHzcLc=.bb3426fc-cc41-4459-a780-28aa03774114@github.com>

On Tue, 7 Feb 2023 17:40:25 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

> > some comments on the CSR:
> 
> Thanks - updated.

thanks, the CSR looks good to me

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

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

From duke at openjdk.org  Tue Feb  7 21:32:23 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Tue, 7 Feb 2023 21:32:23 GMT
Subject: RFR: 8180387: com.sun.source.util.JavacTask should have a protected
 constructor.
Message-ID: <lq04YMXJ7VA9ysvHpFn-1L9oXUFV-0fkZ8_MvfuxBGw=.9111b78e-41d5-4314-96d6-726a5afcac05@github.com>

Standard practice is for constructors in `abstract` classes to be `protected` rather than `public` because they can't be used except from subclasses.

[JDK-8180387](https://bugs.openjdk.org/browse/JDK-8180387) was filed to address a particular instance of this phenomenon in the class `com.sun.source.util.JavacTask`.

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

Commit messages:
 - Make default constructor for abstract class JavacTask protected.

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

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

From jjg at openjdk.org  Tue Feb  7 21:39:48 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 7 Feb 2023 21:39:48 GMT
Subject: RFR: JDK-8300914: Allow `@` as an escape in documentation comments
 [v5]
In-Reply-To: <FgtiavKZ7m78CkfLWTTbuaFu-Tov9Nu3lV0VHxmBXpM=.4a7a5fc6-5de5-4414-b3f0-d57c14a1bad3@github.com>
References: <FuwqJLq_p2KGjWFYjms8z_Qvxbov1wlBFdgWDArxCb8=.b017e75e-2994-474c-b1cd-b1335ad1f274@github.com>
 <mJhUf6DQbU1z0AG99JG0O3n558jxvc1y7YZy-LIFlLI=.6c5bc311-f7b8-4b27-8d39-400e00abd1f8@github.com>
 <FgtiavKZ7m78CkfLWTTbuaFu-Tov9Nu3lV0VHxmBXpM=.4a7a5fc6-5de5-4414-b3f0-d57c14a1bad3@github.com>
Message-ID: <Pfo42fksmGkYn8QHbHWdFZVVdkGvVEdzHyvafNMfgEY=.e5ca423a-087e-40c8-b1f2-336a392c4bac@github.com>

On Tue, 7 Feb 2023 11:14:16 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improve spec wording
>
> src/jdk.compiler/share/classes/com/sun/source/doctree/EscapeTree.java line 54:
> 
>> 52:      *
>> 53:      * <p>Note: this method returns the escaped character, not the original escape sequence.
>> 54:      *
> 
> Please delete this newline.

done

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

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

From jjg at openjdk.org  Tue Feb  7 22:18:25 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 7 Feb 2023 22:18:25 GMT
Subject: RFR: JDK-8300914: Allow `@` as an escape in documentation comments
 [v7]
In-Reply-To: <FuwqJLq_p2KGjWFYjms8z_Qvxbov1wlBFdgWDArxCb8=.b017e75e-2994-474c-b1cd-b1335ad1f274@github.com>
References: <FuwqJLq_p2KGjWFYjms8z_Qvxbov1wlBFdgWDArxCb8=.b017e75e-2994-474c-b1cd-b1335ad1f274@github.com>
Message-ID: <rGyjvKkFDQiGwrTvJCq7Imq6P2QJaJoHDb49dlTsKBM=.32bbc3fc-e158-405b-8b35-22d1004edbc1@github.com>

> Please review a moderately simple update to permit the use of `@` as the escape character in a limited set of escape sequences.

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

  Address review feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12372/files
  - new: https://git.openjdk.org/jdk/pull/12372/files/9de8f669..74eb771b

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

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

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

From jjg at openjdk.org  Tue Feb  7 23:30:47 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 7 Feb 2023 23:30:47 GMT
Subject: RFR: JDK-8298405: Support Markdown in the standard doclet [v5]
In-Reply-To: <bWvzhyK4bUryCNyNvVij-H555g2F-OmCHIQL7T0ELYg=.f88f6270-e6d9-4cba-97e8-c5c4eeb1e927@github.com>
References: <ltVVuz_1JTacO6uHQATm0UPq7e0PmZpqDkVUepejnDY=.2650c47e-737f-46f6-936b-47cab371b848@github.com>
 <bWvzhyK4bUryCNyNvVij-H555g2F-OmCHIQL7T0ELYg=.f88f6270-e6d9-4cba-97e8-c5c4eeb1e927@github.com>
Message-ID: <gZPN3zGKhswrqNEigTUcKqo1Czo1oE_0MufxBcdUBUI=.9c306e79-bef3-46e8-876b-64d6e546076e@github.com>

On Tue, 7 Feb 2023 19:42:39 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Support for Markdown comments in the standard doclet.
>> 
>> To enable Markdown in a comment, start the comment with `/**md` followed by whitespace.  The syntax is as defined for CommonMark.
>> 
>> The work is in 3 parts:
>> 
>> 1. Update the Compiler Tree API to support Markdown tree nodes, containing strings of (uninterpreted) Markdown source code.
>> 2. Import commonmark-java into the `jdk.javadoc` module, to be able to convert Markdown strings to HTML.
>> 3. Update the standard doclet, to leverage the preceding two parts, to translate Markdown in documentation comments to `Content` nodes.
>> 
>> There are new tests both for the low level work in the Compiler Tree API, and for the overall high-level work in the doclet.
>> 
>> Background info: https://mail.openjdk.org/pipermail/javadoc-dev/2023-January/005563.html
>
> Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
> 
>  - Merge with upstream/master
>  - Rename MarkdownTree to RawTextTree
>  - Merge with upstream/master
>  - Update copyright years
>  - Rename FFFC variable
>    Share Markdown parser and renderer in instance of MarkdownHandler
>  - Move CommonMark to new internal module.
>    Add legal header to imported CommonMark source files
>    Always use Text nodes inside AttributeTree values
>    Unwrap <p> from "simple" paragraphs
>  - Always use Text nodes inside AttributeTree values
>  - Update to CommonMark 0.21.
>  - fix whitespace
>  - JDK-8298405: Markdown support in the standard doclet

FYI, draft JEP: https://openjdk.org/jeps/8299906

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

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

From jjg at openjdk.org  Tue Feb  7 23:34:46 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 7 Feb 2023 23:34:46 GMT
Subject: RFR: JDK-8298405: Support Markdown in the standard doclet [v3]
In-Reply-To: <9ifr0XLxi6tBlCg3vlO3mgVyFH3b7tj5hPXGHE5IVWg=.70aa6be1-7d63-4e50-94f4-afb524596b84@github.com>
References: <ltVVuz_1JTacO6uHQATm0UPq7e0PmZpqDkVUepejnDY=.2650c47e-737f-46f6-936b-47cab371b848@github.com>
 <dwV8Gr0Fy5uLJ49x2m_vCREXS_dBdfHu1I6CUbwES10=.7fc366ea-79f2-4e55-b4a0-5f3d9e899213@github.com>
 <9ifr0XLxi6tBlCg3vlO3mgVyFH3b7tj5hPXGHE5IVWg=.70aa6be1-7d63-4e50-94f4-afb524596b84@github.com>
Message-ID: <ZxdsVCQzGsZglE3upJ9s0tMRcmqToKVQc2ZHus_Ii9k=.8a12d972-a818-40f6-b5d0-e8e46add9d9a@github.com>

On Tue, 31 Jan 2023 06:47:55 GMT, ExE Boss <duke at openjdk.org> wrote:

> There?should probably?be an?option to?make **Markdown** the?default.

That would lead to configuration complexity in any environment that had to support different kinds of comments in different libraries/modules/packages/files

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

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

From jjg at openjdk.org  Wed Feb  8 00:00:52 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 8 Feb 2023 00:00:52 GMT
Subject: RFR: JDK-8298405: Support Markdown in the standard doclet [v2]
In-Reply-To: <ojc28C8ocX8-Bl8G9YpkuaD2el00tjBhWEaShMd6bbk=.946fbab2-e895-4237-808a-9b5fb26d21ee@github.com>
References: <ltVVuz_1JTacO6uHQATm0UPq7e0PmZpqDkVUepejnDY=.2650c47e-737f-46f6-936b-47cab371b848@github.com>
 <2bFoIv0Kj1LGy3YGyZGQNQVJ0Ue8Y-26B7oyZoqnjH8=.4e68efb1-f6d8-42c3-abf0-881b872886e2@github.com>
 <ojc28C8ocX8-Bl8G9YpkuaD2el00tjBhWEaShMd6bbk=.946fbab2-e895-4237-808a-9b5fb26d21ee@github.com>
Message-ID: <v44fne_qknm8aZXUc3QhHwc0BNXUjm1BAZIE5mmtpIY=.156262c3-31be-480d-a820-f8684e5dac5a@github.com>

On Sat, 21 Jan 2023 11:55:15 GMT, Wim Deblauwe <duke at openjdk.org> wrote:

> Is the work here done in a way that asciidoc ( https://docs.asciidoctor.org/ ) support is also possible?

Yes, and no. But mostly no.

Yes, in the sense that there are aspects of this work that might allow [asciidoclet](https://docs.asciidoctor.org/asciidoclet/latest/) to be enhanced.

No, in the sense that the proposal does not include the Standard Doclet supporting pluggable backends for different markup languages, and I don't think we want to go there, at least to begin with. I think it is more interesting to focus on getting broader support across the ecosystem for a limited set of markup languages than an open-ended set.

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

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

From maurizio.cimadamore at oracle.com  Wed Feb  8 01:57:29 2023
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Wed, 8 Feb 2023 01:57:29 +0000
Subject: [External] : Re: Error examples page
In-Reply-To: <CA+NR86gm4gcZ+1nhYmAY2orUEhiOxjqtACPZ-GgA22g9JzYAQA@mail.gmail.com>
References: <CA+NR86hzKmTDQQm93jU+g-KmE-f9h807AnzqPAFPnY9UJEV+Vw@mail.gmail.com>
 <d13c8ca2-9602-8656-33fa-2eabcae9611a@oracle.com>
 <71606e79-2d79-68e8-deb5-d2e79066392c@oracle.com>
 <CA+NR86gD81zb0ssocFgtbdAO3NtGz=T_eMngwT42ZBsqhudAwQ@mail.gmail.com>
 <86f1c26f-1756-4d8e-ae08-d2bbf4edea8a@oracle.com>
 <CA+NR86gf=zrhzKrvTtGggcPKkojqS3QqC0qEjPgzCa2mqogrfg@mail.gmail.com>
 <CA+NR86huXFfVZiPQM-6Q=44ezDQxPQqyq8cetGDV+ddSKhKpsw@mail.gmail.com>
 <bbeec72f-04e1-709c-cb4e-e173f5b15f06@oracle.com>
 <CA+NR86gm4gcZ+1nhYmAY2orUEhiOxjqtACPZ-GgA22g9JzYAQA@mail.gmail.com>
Message-ID: <7205be7f-9227-6578-1b76-a9db8afce2c9@oracle.com>

Hi,
there are two classes of errors that are hard. The first, as your 
example demonstrates, has to do with parser errors. When parsing it is 
hard to recover from errors. Javac tries to do its best, but if you are 
parsing a production, and you find a token that is unexpected for that 
production, it is not clear what should happen next. I mean, an error 
should be reported - but what then? Javac tries to figure out where to 
start parsing again - in some cases this can be done with some success 
(e.g. finding the matching closing brace, parens, etc.). In other cases 
it's harder, and it can lead to pathological situations such as the ones 
you describe. Some of these issues might be made worse by actual bugs 
(so it is possible that in the case of "expected class" there's an 
actual issue with javac - would be nice to have a reproducer).

The other class of errors that are hard are errors related to overload 
resolution and inference. The problem there is that the error has to 
cover so much ground (too much). When you have an overload resolution 
failure, you can, at least in the general case, have many overload 
candidates, each of which fails for a different reason (which might be 
interesting or not). If there's inference, the reason as to why a 
candidate is not applicable might be obscure (e.g. incompatible bounds 
on an inference variable), and if you have nested or chained generic 
method calls, things tend to explode pretty quickly, so when your 
typical stream chain fails to type it's hard to understand exactly what 
needs to be fixed - often because the error typicall shows up in the 
wrong place. For instance, you might get an error message when you call 
`toList()` on a stream and assign it to a `List<String>` - but the real 
problem is that the type of the stream is not `Stream<String>` as you 
expect: something sent inference down the wrong path in an earlier call 
in the method chain, which caused the stream type to become 
`Stream<Object>`.

These things can (and should!) be improved, but there's a limit on how 
much you can improve things when working with the command line 
interface. For instance, when diagnosing inference issues inside an IDE, 
I find myself hoovering on each component of the call chain, or try to 
use auto-complete after each subexpression, to have a rough idea of what 
the type might be at that point. Even doing that is not always possible: 
methods that are generic in their return type can be "influenced" by 
their surrounding context, so breaking up a method chain can sometimes 
result in changes to how a subexpression is typed. So... it's an hard 
problem - and the limited visual aids a terminal offer, combined with 
the lack of interaction makes these issues particularly pesky. Other 
langauges have explored the idea of a type debugger [1] - although I 
don't know what's the state of these initiatives.

Cheers
Maurizio

[1] - https://infoscience.epfl.ch/record/179877?ln=en



On 04/02/2023 03:48, Ethan McCue wrote:
> 1. The error messages that the student got were not helpful for them 
> seeing their error. I don't have their original code so I can't dive 
> in to why and say "ah, we could obviously make this case better", but 
> I choose to believe there was some way to not vomit "class, interface, 
> enum, or record expected" nine times.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230208/fd074eb5/attachment.htm>

From vromero at openjdk.org  Wed Feb  8 06:00:46 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 8 Feb 2023 06:00:46 GMT
Subject: RFR: 8180387: com.sun.source.util.JavacTask should have a
 protected constructor.
In-Reply-To: <lq04YMXJ7VA9ysvHpFn-1L9oXUFV-0fkZ8_MvfuxBGw=.9111b78e-41d5-4314-96d6-726a5afcac05@github.com>
References: <lq04YMXJ7VA9ysvHpFn-1L9oXUFV-0fkZ8_MvfuxBGw=.9111b78e-41d5-4314-96d6-726a5afcac05@github.com>
Message-ID: <iM0p856eODTuYxKM7ThO4eW8C86rbnr8wzEXLSB8y-0=.75975e85-051e-4eae-9ad9-060eddfc2d30@github.com>

On Tue, 7 Feb 2023 21:25:28 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

> Standard practice is for constructors in `abstract` classes to be `protected` rather than `public` because they can't be used except from subclasses.
> 
> [JDK-8180387](https://bugs.openjdk.org/browse/JDK-8180387) was filed to address a particular instance of this phenomenon in the class `com.sun.source.util.JavacTask`.

looks good

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

Marked as reviewed by vromero (Reviewer).

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

From duke at openjdk.org  Wed Feb  8 07:54:54 2023
From: duke at openjdk.org (SUN Guoyun)
Date: Wed, 8 Feb 2023 07:54:54 GMT
Subject: RFR: 8292647: javac/lambda/T8031967.java fails with
 StackOverflowError when use -XX:TieredStopAtLevel=3 on aarch64 and LoongArch
In-Reply-To: <20nOuTrdhVz3ikgxbOy3JTS5aH8So5tKA8QiR08oCj4=.23dc3532-19a2-4169-ab43-d336a2564e90@github.com>
References: <8Wo5jMV1FDBTdaz0O8PRwmSMUEqzQeLckldsJybpceg=.01580f6c-3290-4276-8d36-8e408035982c@github.com>
 <2QdKMzJakUEcPEFRUtzeDtDo35ew4G-fN8gQ7YnFLA8=.c56f7817-cae8-434d-b76b-19f013dab34a@github.com>
 <20nOuTrdhVz3ikgxbOy3JTS5aH8So5tKA8QiR08oCj4=.23dc3532-19a2-4169-ab43-d336a2564e90@github.com>
Message-ID: <6Slp6F7U1IZtvhsuOZYiVFTZtCyYkN1N3Mi_7YqgAr8=.184ccbdd-ccc2-4de0-9c02-804636e32464@github.com>

On Mon, 22 Aug 2022 03:21:46 GMT, SUN Guoyun <duke at openjdk.org> wrote:

> I'm not at all sure about this one. It may be a bug. Before committing this patch we should find out why AArch64 and LoongArch are consuming more stack than others. 10M of stack is huge.

@theRealAph  I tested and found that some large methods use more spill code on LoongArch64 and AArch64 architectures than  x86_64 architectures, which results in larger stack space requests.

<pre><code class="cpp">
// src/hotspot/share/c1/c1_FrameMap.cpp

279 ByteSize FrameMap::sp_offset_for_monitor_base(const int index) const {          
280   int end_of_spills = align_up(first_available_sp_in_frame + _reserved_argument_area_size, (int)sizeof(double)) +
281     _num_spills * spill_slot_size_in_bytes;                                     
282   int offset = align_up(end_of_spills, HeapWordSize) + index * (int)sizeof(BasicObjectLock);
283   return in_ByteSize(offset);                                                   
284 }  
</code></pre>

Here, var `_num_spills` is sometimes larger on loongarch64/aarch64 than x86_64, then framesize is larger. 
So I think using more stack space on loongarch64/aarch64 is the best solution.

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

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

From duke at openjdk.org  Wed Feb  8 08:32:00 2023
From: duke at openjdk.org (SUN Guoyun)
Date: Wed, 8 Feb 2023 08:32:00 GMT
Subject: RFR: 8292647: javac/lambda/T8031967.java fails with
 StackOverflowError when use -XX:TieredStopAtLevel=3 on aarch64 and LoongArch
 [v2]
In-Reply-To: <8Wo5jMV1FDBTdaz0O8PRwmSMUEqzQeLckldsJybpceg=.01580f6c-3290-4276-8d36-8e408035982c@github.com>
References: <8Wo5jMV1FDBTdaz0O8PRwmSMUEqzQeLckldsJybpceg=.01580f6c-3290-4276-8d36-8e408035982c@github.com>
Message-ID: <yYn96PZShddUilJ4HIG_I4iOGe1kuT9HYs8wQ_hXl8c=.95e49c9c-aaac-4ab1-8e0d-f9f34aa3fd31@github.com>

> make images run-test TEST=tools/javac/lambda/T8031967.java will fails with StackOverflowError when I use args JTREG="VM_OPTIONS=-XX:TieredStopAtLevel=3" on aarch64 and LoongArch. So the stack size `-Xss10m` needs to be increased to improve the robustness of the testcase.

SUN Guoyun has updated the pull request incrementally with one additional commit since the last revision:

  8292647: javac/lambda/T8031967.java fails with StackOverflowError when use -XX:TieredStopAtLevel=3 on aarch64 and LoongArch

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9934/files
  - new: https://git.openjdk.org/jdk/pull/9934/files/fdd211b4..6431c58e

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

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

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

From duke at openjdk.org  Wed Feb  8 09:21:30 2023
From: duke at openjdk.org (SUN Guoyun)
Date: Wed, 8 Feb 2023 09:21:30 GMT
Subject: RFR: 8292647: javac/lambda/T8031967.java fails with
 StackOverflowError when use -XX:TieredStopAtLevel=3 on aarch64 and LoongArch
 [v3]
In-Reply-To: <8Wo5jMV1FDBTdaz0O8PRwmSMUEqzQeLckldsJybpceg=.01580f6c-3290-4276-8d36-8e408035982c@github.com>
References: <8Wo5jMV1FDBTdaz0O8PRwmSMUEqzQeLckldsJybpceg=.01580f6c-3290-4276-8d36-8e408035982c@github.com>
Message-ID: <z639fAXA8bpE1ZETMJpJW0kETKOu_CcPU8MSGA2Q9Fs=.44a4ea2a-b533-478f-a36c-c18b3040bba2@github.com>

> make images run-test TEST=tools/javac/lambda/T8031967.java will fails with StackOverflowError when I use args JTREG="VM_OPTIONS=-XX:TieredStopAtLevel=3" on aarch64 and LoongArch. So the stack size `-Xss10m` needs to be increased to improve the robustness of the testcase.

SUN Guoyun 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 'openjdk:master' into 8292647
 - 8292647: javac/lambda/T8031967.java fails with StackOverflowError when use -XX:TieredStopAtLevel=3 on aarch64 and LoongArch
 - 8292647: javac/lambda/T8031967.java fails with StackOverflowError when use -XX:TieredStopAtLevel=3 on aarch64 and LoongArch

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9934/files
  - new: https://git.openjdk.org/jdk/pull/9934/files/6431c58e..0336d8fb

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

  Stats: 607777 lines in 9066 files changed: 302882 ins; 202110 del; 102785 mod
  Patch: https://git.openjdk.org/jdk/pull/9934.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9934/head:pull/9934

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

From prappo at openjdk.org  Wed Feb  8 10:18:50 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 8 Feb 2023 10:18:50 GMT
Subject: RFR: JDK-8298405: Support Markdown in the standard doclet [v5]
In-Reply-To: <bWvzhyK4bUryCNyNvVij-H555g2F-OmCHIQL7T0ELYg=.f88f6270-e6d9-4cba-97e8-c5c4eeb1e927@github.com>
References: <ltVVuz_1JTacO6uHQATm0UPq7e0PmZpqDkVUepejnDY=.2650c47e-737f-46f6-936b-47cab371b848@github.com>
 <bWvzhyK4bUryCNyNvVij-H555g2F-OmCHIQL7T0ELYg=.f88f6270-e6d9-4cba-97e8-c5c4eeb1e927@github.com>
Message-ID: <wA0HPh3XWqVNYDll5_NQ6A0CUrkgzA-_53OyCC_130M=.b9cb6d38-0639-4681-8894-e22b9522620f@github.com>

On Tue, 7 Feb 2023 19:42:39 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Support for Markdown comments in the standard doclet.
>> 
>> To enable Markdown in a comment, start the comment with `/**md` followed by whitespace.  The syntax is as defined for CommonMark.
>> 
>> The work is in 3 parts:
>> 
>> 1. Update the Compiler Tree API to support Markdown tree nodes, containing strings of (uninterpreted) Markdown source code.
>> 2. Import commonmark-java into the `jdk.javadoc` module, to be able to convert Markdown strings to HTML.
>> 3. Update the standard doclet, to leverage the preceding two parts, to translate Markdown in documentation comments to `Content` nodes.
>> 
>> There are new tests both for the low level work in the Compiler Tree API, and for the overall high-level work in the doclet.
>> 
>> Background info: https://mail.openjdk.org/pipermail/javadoc-dev/2023-January/005563.html
>
> Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
> 
>  - Merge with upstream/master
>  - Rename MarkdownTree to RawTextTree
>  - Merge with upstream/master
>  - Update copyright years
>  - Rename FFFC variable
>    Share Markdown parser and renderer in instance of MarkdownHandler
>  - Move CommonMark to new internal module.
>    Add legal header to imported CommonMark source files
>    Always use Text nodes inside AttributeTree values
>    Unwrap <p> from "simple" paragraphs
>  - Always use Text nodes inside AttributeTree values
>  - Update to CommonMark 0.21.
>  - fix whitespace
>  - JDK-8298405: Markdown support in the standard doclet

@jimisola, not sure if you've noticed it, but your comment was hidden: https://github.com/openjdk/jdk/pull/11701#issuecomment-1422061278. To make the comment visible and response possible, consider accepting TOU suggested by the bot. Thanks.

Have you seen that notification from the bot? Regardless, the bot might need to use a better message/format for such communication.

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

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

From duke at openjdk.org  Wed Feb  8 11:12:48 2023
From: duke at openjdk.org (Wim Deblauwe)
Date: Wed, 8 Feb 2023 11:12:48 GMT
Subject: RFR: JDK-8298405: Support Markdown in the standard doclet [v5]
In-Reply-To: <bWvzhyK4bUryCNyNvVij-H555g2F-OmCHIQL7T0ELYg=.f88f6270-e6d9-4cba-97e8-c5c4eeb1e927@github.com>
References: <ltVVuz_1JTacO6uHQATm0UPq7e0PmZpqDkVUepejnDY=.2650c47e-737f-46f6-936b-47cab371b848@github.com>
 <bWvzhyK4bUryCNyNvVij-H555g2F-OmCHIQL7T0ELYg=.f88f6270-e6d9-4cba-97e8-c5c4eeb1e927@github.com>
Message-ID: <3ZXp4YaXmHl0PwayYYjz9rlr2IHdsxcD-zEmGMo6wtU=.4cb22628-ef18-4809-9d6e-31515f3ed908@github.com>

On Tue, 7 Feb 2023 19:42:39 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Support for Markdown comments in the standard doclet.
>> 
>> To enable Markdown in a comment, start the comment with `/**md` followed by whitespace.  The syntax is as defined for CommonMark.
>> 
>> The work is in 3 parts:
>> 
>> 1. Update the Compiler Tree API to support Markdown tree nodes, containing strings of (uninterpreted) Markdown source code.
>> 2. Import commonmark-java into the `jdk.javadoc` module, to be able to convert Markdown strings to HTML.
>> 3. Update the standard doclet, to leverage the preceding two parts, to translate Markdown in documentation comments to `Content` nodes.
>> 
>> There are new tests both for the low level work in the Compiler Tree API, and for the overall high-level work in the doclet.
>> 
>> Background info: https://mail.openjdk.org/pipermail/javadoc-dev/2023-January/005563.html
>
> Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
> 
>  - Merge with upstream/master
>  - Rename MarkdownTree to RawTextTree
>  - Merge with upstream/master
>  - Update copyright years
>  - Rename FFFC variable
>    Share Markdown parser and renderer in instance of MarkdownHandler
>  - Move CommonMark to new internal module.
>    Add legal header to imported CommonMark source files
>    Always use Text nodes inside AttributeTree values
>    Unwrap <p> from "simple" paragraphs
>  - Always use Text nodes inside AttributeTree values
>  - Update to CommonMark 0.21.
>  - fix whitespace
>  - JDK-8298405: Markdown support in the standard doclet

I had the same issue with not noticing the question from the bot. I think the main problem is that there is no email notification of that message. So unless you manually check the ticket, you don't notice it.

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

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

From prappo at openjdk.org  Wed Feb  8 11:56:47 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 8 Feb 2023 11:56:47 GMT
Subject: RFR: JDK-8300914: Allow `@` as an escape in documentation comments
 [v7]
In-Reply-To: <rGyjvKkFDQiGwrTvJCq7Imq6P2QJaJoHDb49dlTsKBM=.32bbc3fc-e158-405b-8b35-22d1004edbc1@github.com>
References: <FuwqJLq_p2KGjWFYjms8z_Qvxbov1wlBFdgWDArxCb8=.b017e75e-2994-474c-b1cd-b1335ad1f274@github.com>
 <rGyjvKkFDQiGwrTvJCq7Imq6P2QJaJoHDb49dlTsKBM=.32bbc3fc-e158-405b-8b35-22d1004edbc1@github.com>
Message-ID: <HN4cckaWWwNVS6AlOAhUX0wHBKWtvpLOMfSveLCVxHk=.d1a3b811-c823-4334-8db1-03a99ec4224f@github.com>

On Tue, 7 Feb 2023 22:18:25 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a moderately simple update to permit the use of `@` as the escape character in a limited set of escape sequences.
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review feedback

Looks good, but see the comment on caret positioning in one of the tests below.

test/langtools/tools/doclint/HtmlTagsTest.out line 51:

> 49: HtmlTagsTest.java:75: error: text not allowed in <ul> element
> 50:      * <ul> *@/ <li> ... </li> </ul>
> 51:            ^

That's weird caret positioning.

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

Marked as reviewed by prappo (Reviewer).

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

From abimpoudis at openjdk.org  Wed Feb  8 13:19:22 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 8 Feb 2023 13:19:22 GMT
Subject: RFR: 8301858: Verification error when compiling switch with record
 patterns [v2]
In-Reply-To: <cpGG6OTeBDYBx84stB4JJvw5SmhahmFnJanFpUclsn4=.32a30114-6747-4d65-93a4-783100726e26@github.com>
References: <cpGG6OTeBDYBx84stB4JJvw5SmhahmFnJanFpUclsn4=.32a30114-6747-4d65-93a4-783100726e26@github.com>
Message-ID: <Rl1JHeUl7l0AOS6YEPWKb_wrvYmAkPYX78Q3bp5EoM4=.655927e2-7773-4aab-8fca-9eaf2f7dd442@github.com>

> When unrolling/translating record patterns with an unconditional case, we were translating the last/innermost case to`case null, default` skipping the initialization of a bound variable `o` in the example below:
> 
>     switch (..) {
>       case R1(Object o):
>                       return meth_O(o); 
>     }
>     => 
>     switch (..) {
>        case R1: 
>           switch(..) {
>             case null, default:
>                             return meth_O(o);
>           }
>     }
> 
> This PR addresses that by emitting the correct label instead of default.

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

  Fix unrolling with cases that have null and unconditional
  
  Co-authored-by: Jan Lahoda <jan.lahoda at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12438/files
  - new: https://git.openjdk.org/jdk/pull/12438/files/14f8cd9a..f9d51d99

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

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

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

From ihse at openjdk.org  Wed Feb  8 13:24:54 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 8 Feb 2023 13:24:54 GMT
Subject: RFR: JDK-8298405: Support Markdown in the standard doclet [v5]
In-Reply-To: <3ZXp4YaXmHl0PwayYYjz9rlr2IHdsxcD-zEmGMo6wtU=.4cb22628-ef18-4809-9d6e-31515f3ed908@github.com>
References: <ltVVuz_1JTacO6uHQATm0UPq7e0PmZpqDkVUepejnDY=.2650c47e-737f-46f6-936b-47cab371b848@github.com>
 <bWvzhyK4bUryCNyNvVij-H555g2F-OmCHIQL7T0ELYg=.f88f6270-e6d9-4cba-97e8-c5c4eeb1e927@github.com>
 <3ZXp4YaXmHl0PwayYYjz9rlr2IHdsxcD-zEmGMo6wtU=.4cb22628-ef18-4809-9d6e-31515f3ed908@github.com>
Message-ID: <D7Pkj54a7MQ1KnVqps4DXijjWR9L-XpRn4GocRz7AII=.216aa1d5-f4f0-4764-a354-88cc483210cd@github.com>

On Wed, 8 Feb 2023 11:09:49 GMT, Wim Deblauwe <duke at openjdk.org> wrote:

>> Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
>> 
>>  - Merge with upstream/master
>>  - Rename MarkdownTree to RawTextTree
>>  - Merge with upstream/master
>>  - Update copyright years
>>  - Rename FFFC variable
>>    Share Markdown parser and renderer in instance of MarkdownHandler
>>  - Move CommonMark to new internal module.
>>    Add legal header to imported CommonMark source files
>>    Always use Text nodes inside AttributeTree values
>>    Unwrap <p> from "simple" paragraphs
>>  - Always use Text nodes inside AttributeTree values
>>  - Update to CommonMark 0.21.
>>  - fix whitespace
>>  - JDK-8298405: Markdown support in the standard doclet
>
> I had the same issue with not noticing the question from the bot. I think the main problem is that there is no email notification of that message. So unless you manually check the ticket, you don't notice it.

@wimdeblauwe Let's not turn this PR into a discussion about Skara (the Github bots of OpenJDK), but just a short explanation: There is no way we can get the email address of a random user on Github coming by and making a comment; users emails are generally not available through Github for privacy reasons. So we just can't do that.

However, we *do* tag the user, and they should get a Github notification for that. If they have "send email on notification" turned on, they will get an email as well.

But I think the message could perhaps be a bit more explicit about their original content being hidden. This is not immediately clear if you just read the start of the message. I'll open an enhancement request on Skara for that.

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

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

From abimpoudis at openjdk.org  Wed Feb  8 14:29:10 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 8 Feb 2023 14:29:10 GMT
Subject: RFR: 8301858: Verification error when compiling switch with record
 patterns [v3]
In-Reply-To: <cpGG6OTeBDYBx84stB4JJvw5SmhahmFnJanFpUclsn4=.32a30114-6747-4d65-93a4-783100726e26@github.com>
References: <cpGG6OTeBDYBx84stB4JJvw5SmhahmFnJanFpUclsn4=.32a30114-6747-4d65-93a4-783100726e26@github.com>
Message-ID: <NzGBgLN8rCU7G-nM3VX8_nnexwMTh8aGrvKuuJBBn_M=.b38ed621-6d50-49cf-a0d0-211208a8c712@github.com>

> When unrolling/translating record patterns with an unconditional case, we were translating the last/innermost case to`case null, default` skipping the initialization of a bound variable `o` in the example below:
> 
>     switch (..) {
>       case R1(Object o):
>                       return meth_O(o); 
>     }
>     => 
>     switch (..) {
>        case R1: 
>           switch(..) {
>             case null, default:
>                             return meth_O(o);
>           }
>     }
> 
> This PR addresses that by emitting the correct label instead of default.

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

  Fix unrolling with cases that have null and unconditional
  
  Co-authored-by: Jan Lahoda <jan.lahoda at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12438/files
  - new: https://git.openjdk.org/jdk/pull/12438/files/f9d51d99..e77384cd

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

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

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

From abimpoudis at openjdk.org  Wed Feb  8 15:00:53 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 8 Feb 2023 15:00:53 GMT
Subject: RFR: 8301858: Verification error when compiling switch with record
 patterns [v3]
In-Reply-To: <NzGBgLN8rCU7G-nM3VX8_nnexwMTh8aGrvKuuJBBn_M=.b38ed621-6d50-49cf-a0d0-211208a8c712@github.com>
References: <cpGG6OTeBDYBx84stB4JJvw5SmhahmFnJanFpUclsn4=.32a30114-6747-4d65-93a4-783100726e26@github.com>
 <NzGBgLN8rCU7G-nM3VX8_nnexwMTh8aGrvKuuJBBn_M=.b38ed621-6d50-49cf-a0d0-211208a8c712@github.com>
Message-ID: <CSoA3mrQ3e-Nz_ZhPCLYPZMC367MD8I129EQ0cvKX18=.f3e272fd-1c58-49c4-8f48-1021ce62f10d@github.com>

On Wed, 8 Feb 2023 14:29:10 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> When unrolling/translating record patterns with an unconditional case, we were translating the last/innermost case to`case null, default` skipping the initialization of a bound variable `o` in the example below:
>> 
>>     switch (..) {
>>       case R1(Object o):
>>                       return meth_O(o); 
>>     }
>>     => 
>>     switch (..) {
>>        case R1: 
>>           switch(..) {
>>             case null, default:
>>                             return meth_O(o);
>>           }
>>     }
>> 
>> This PR addresses that by emitting the correct label instead of default.
>
> Aggelos Biboudis has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   Fix unrolling with cases that have null and unconditional
>   
>   Co-authored-by: Jan Lahoda <jan.lahoda at oracle.com>

So the minimization of the failing test was this:

    private String test(P p) {
        return switch (p) {
            case P(R(A a1, A b1), R(A a2, A b2)) -> "";
            case P(R(A a1, A b1), R(A a2, B b2)) -> "";
            case P(R(A a1, A b1), R(B a2, A b2)) -> "";
            case P(R(A a1, A b1), R(B a2, B b2)) -> "";
            case P(R(A a1, B b1), R(A a2, A b2)) -> "";
            case P(R(A a1, B b1), R(A a2, B b2)) -> "";
            case P(N a, N b) -> "other";
        };
    }
    
During the desugaring of this switch, the emission of the last case was not using the right binding. The local variable `a` was emitted for the necessary `null` check but we were not using the correct one. As a result, this was crashing the backend.

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

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

From jjg at openjdk.org  Wed Feb  8 22:01:02 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 8 Feb 2023 22:01:02 GMT
Subject: RFR: JDK-8300914: Allow `@` as an escape in documentation comments
 [v7]
In-Reply-To: <HN4cckaWWwNVS6AlOAhUX0wHBKWtvpLOMfSveLCVxHk=.d1a3b811-c823-4334-8db1-03a99ec4224f@github.com>
References: <FuwqJLq_p2KGjWFYjms8z_Qvxbov1wlBFdgWDArxCb8=.b017e75e-2994-474c-b1cd-b1335ad1f274@github.com>
 <rGyjvKkFDQiGwrTvJCq7Imq6P2QJaJoHDb49dlTsKBM=.32bbc3fc-e158-405b-8b35-22d1004edbc1@github.com>
 <HN4cckaWWwNVS6AlOAhUX0wHBKWtvpLOMfSveLCVxHk=.d1a3b811-c823-4334-8db1-03a99ec4224f@github.com>
Message-ID: <rlyMYyxUMY2DcPYerd9sRPqiJ6LHm4mGDv9dUP771TU=.5d916d61-e94c-49d6-990a-716253ad8d2e@github.com>

On Wed, 8 Feb 2023 10:56:56 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review feedback
>
> test/langtools/tools/doclint/HtmlTagsTest.out line 51:
> 
>> 49: HtmlTagsTest.java:75: error: text not allowed in <ul> element
>> 50:      * <ul> *@/ <li> ... </li> </ul>
>> 51:            ^
> 
> That's weird caret positioning.

It's pointing to the beginning of the text node. I guess it should point to the the first non-white character in that text node. Let's handle that separately.

See [JDK-8302104](https://bugs.openjdk.org/browse/JDK-8302104)

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

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

From jjg at openjdk.org  Wed Feb  8 22:01:06 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 8 Feb 2023 22:01:06 GMT
Subject: Integrated: JDK-8300914: Allow `@` as an escape in documentation
 comments
In-Reply-To: <FuwqJLq_p2KGjWFYjms8z_Qvxbov1wlBFdgWDArxCb8=.b017e75e-2994-474c-b1cd-b1335ad1f274@github.com>
References: <FuwqJLq_p2KGjWFYjms8z_Qvxbov1wlBFdgWDArxCb8=.b017e75e-2994-474c-b1cd-b1335ad1f274@github.com>
Message-ID: <QnyqXC0bhpnWTYzghEnSan-i-Zgia3qFRpKgRMSwEnk=.b16e0ac9-f3b8-48b6-a1f8-fb9c8f1afe89@github.com>

On Wed, 1 Feb 2023 19:16:17 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a moderately simple update to permit the use of `@` as the escape character in a limited set of escape sequences.

This pull request has now been integrated.

Changeset: 873558ee
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/873558ee80d741469ade030c732091bead431c46
Stats:     543 lines in 22 files changed: 518 ins; 0 del; 25 mod

8300914: Allow `@` as an escape in documentation comments

Reviewed-by: prappo

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

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

From jjg at openjdk.org  Wed Feb  8 22:20:44 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 8 Feb 2023 22:20:44 GMT
Subject: RFR: JDK-8298405: Support Markdown in the standard doclet [v6]
In-Reply-To: <ltVVuz_1JTacO6uHQATm0UPq7e0PmZpqDkVUepejnDY=.2650c47e-737f-46f6-936b-47cab371b848@github.com>
References: <ltVVuz_1JTacO6uHQATm0UPq7e0PmZpqDkVUepejnDY=.2650c47e-737f-46f6-936b-47cab371b848@github.com>
Message-ID: <oC4ZnXHBqxFGpsp-LoFCaBYkO95hKu6SJopjPCu0N1w=.1ad255bb-f2c7-4b59-a903-7d8184b3b474@github.com>

> Support for Markdown comments in the standard doclet.
> 
> To enable Markdown in a comment, start the comment with `/**md` followed by whitespace.  The syntax is as defined for CommonMark.
> 
> The work is in 3 parts:
> 
> 1. Update the Compiler Tree API to support Markdown tree nodes, containing strings of (uninterpreted) Markdown source code.
> 2. Import commonmark-java into the `jdk.javadoc` module, to be able to convert Markdown strings to HTML.
> 3. Update the standard doclet, to leverage the preceding two parts, to translate Markdown in documentation comments to `Content` nodes.
> 
> There are new tests both for the low level work in the Compiler Tree API, and for the overall high-level work in the doclet.
> 
> Background info: https://mail.openjdk.org/pipermail/javadoc-dev/2023-January/005563.html

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

 - Merge with upstream/master
 - Merge with upstream/master
 - Rename MarkdownTree to RawTextTree
 - Merge with upstream/master
 - Update copyright years
 - Rename FFFC variable
   Share Markdown parser and renderer in instance of MarkdownHandler
 - Move CommonMark to new internal module.
   Add legal header to imported CommonMark source files
   Always use Text nodes inside AttributeTree values
   Unwrap <p> from "simple" paragraphs
 - Always use Text nodes inside AttributeTree values
 - Update to CommonMark 0.21.
 - fix whitespace
 - ... and 1 more: https://git.openjdk.org/jdk/compare/873558ee...59719f19

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

Changes: https://git.openjdk.org/jdk/pull/11701/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11701&range=05
  Stats: 15687 lines in 146 files changed: 15384 ins; 111 del; 192 mod
  Patch: https://git.openjdk.org/jdk/pull/11701.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11701/head:pull/11701

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

From jjg at openjdk.org  Wed Feb  8 23:32:27 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 8 Feb 2023 23:32:27 GMT
Subject: RFR: JDK-8298405: Support Markdown in the standard doclet [v7]
In-Reply-To: <ltVVuz_1JTacO6uHQATm0UPq7e0PmZpqDkVUepejnDY=.2650c47e-737f-46f6-936b-47cab371b848@github.com>
References: <ltVVuz_1JTacO6uHQATm0UPq7e0PmZpqDkVUepejnDY=.2650c47e-737f-46f6-936b-47cab371b848@github.com>
Message-ID: <L0_Ei1bTc-gWLNiYIQRA8XPF6X4tLBhLbQ2fnzWUbNY=.dbab6e4a-2ba1-4ad2-88a0-3bbab11dcd84@github.com>

> Support for Markdown comments in the standard doclet.
> 
> To enable Markdown in a comment, start the comment with `/**md` followed by whitespace.  The syntax is as defined for CommonMark.
> 
> The work is in 3 parts:
> 
> 1. Update the Compiler Tree API to support Markdown tree nodes, containing strings of (uninterpreted) Markdown source code.
> 2. Import commonmark-java into the `jdk.javadoc` module, to be able to convert Markdown strings to HTML.
> 3. Update the standard doclet, to leverage the preceding two parts, to translate Markdown in documentation comments to `Content` nodes.
> 
> There are new tests both for the low level work in the Compiler Tree API, and for the overall high-level work in the doclet.
> 
> Background info: https://mail.openjdk.org/pipermail/javadoc-dev/2023-January/005563.html

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

  Revert changes to Object.hashCode

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11701/files
  - new: https://git.openjdk.org/jdk/pull/11701/files/59719f19..e1f2958f

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

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

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

From vromero at openjdk.org  Thu Feb  9 04:14:42 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 9 Feb 2023 04:14:42 GMT
Subject: RFR: 8027682: javac wrongly accepts semicolons in package and
 import decls [v4]
In-Reply-To: <cdmEJqw4Mlo6C_nZgCh821M2363M1aIJM3IyZ7skW2M=.ba9484bf-2072-43ff-a8b8-d58cb2298a8e@github.com>
References: <bQN6VoWgHskZ_Wg9PgBhKWwUDYp5jlRGja_LkitHQY4=.1a7d2eec-a992-4cee-9eb0-68fe1821e276@github.com>
 <cdmEJqw4Mlo6C_nZgCh821M2363M1aIJM3IyZ7skW2M=.ba9484bf-2072-43ff-a8b8-d58cb2298a8e@github.com>
Message-ID: <BtpuCEu4tnq4ih7a5HVq491h5FwmQYOVOweHevwjrCo=.c2934d87-c3c8-4ba6-bc46-1cd9e9744b02@github.com>

On Tue, 7 Feb 2023 19:51:51 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> JLS [?7.3](https://docs.oracle.com/javase/specs/jls/se19/html/jls-7.html#jls-7.3) specifies that while a lone semicolon is a valid _TopLevelClassOrInterfaceDeclaration_, it is not a valid _ImportDeclaration_. Therefore, if we see a lone semicolon while looking for the next import statement we have to advance and accept a class declaration, and we can therefore no longer accept any further `import` statements.
>> 
>> However, the compiler was allowing this, for example:
>> 
>> package p; import X; ;;; import Y; class Foo {}
>> 
>> The bug is that the parser was switching out of "look for imports" mode after parsing a valid class declaration, but it was not switching out of "look for imports" mode after parsing a lone semicolon.
>> 
>> The fix to `JavacParser.java` is easy, however it also requires these adjustments to unit tests:
>> 
>> * Test `tree/T6963934.java` must go away, because it is verifying a bug that only happens when the above bogus input is successfully parsed, and this can no longer happen.
>> * A bug in `lib/types/TypeHarness.java` was uncovered and fixed; it was inserting an extra semicolon.
>> * The following bugs, which check invalid syntax within import statements, now generate different parse errors and therefor needed their "golden output" updated:
>>   * annotations/typeAnnotations/failures/AnnotatedImport.java
>>   * annotations/typeAnnotations/failures/AnnotatedPackage1.java
>>   * annotations/typeAnnotations/failures/AnnotatedPackage2.java
>
> Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust unit test to accomodate spelling change in previous commit.

I was playing with this test case:


import java.util.NO;
    ;
import java.io.NO;

only the new `extraneous semicolon` error is reported but the compiler doesn't report the fact that there is no class named NO inside of `java.util` or `java.io` I think that those other errors should be reported too

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

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

From duke at openjdk.org  Thu Feb  9 08:40:50 2023
From: duke at openjdk.org (SUN Guoyun)
Date: Thu, 9 Feb 2023 08:40:50 GMT
Subject: RFR: 8292647: javac/lambda/T8031967.java fails with
 StackOverflowError when use -XX:TieredStopAtLevel=3 on aarch64 and LoongArch
 [v3]
In-Reply-To: <z639fAXA8bpE1ZETMJpJW0kETKOu_CcPU8MSGA2Q9Fs=.44a4ea2a-b533-478f-a36c-c18b3040bba2@github.com>
References: <8Wo5jMV1FDBTdaz0O8PRwmSMUEqzQeLckldsJybpceg=.01580f6c-3290-4276-8d36-8e408035982c@github.com>
 <z639fAXA8bpE1ZETMJpJW0kETKOu_CcPU8MSGA2Q9Fs=.44a4ea2a-b533-478f-a36c-c18b3040bba2@github.com>
Message-ID: <xZLJZTc-deyyysNf-HSKWVBO45UR2VtfVHzzHCeTGgA=.c2162173-957d-4d43-bb21-088baeda5e3d@github.com>

On Wed, 8 Feb 2023 09:21:30 GMT, SUN Guoyun <duke at openjdk.org> wrote:

>> make images run-test TEST=tools/javac/lambda/T8031967.java will fails with StackOverflowError when I use args JTREG="VM_OPTIONS=-XX:TieredStopAtLevel=3" on aarch64 and LoongArch. So the stack size `-Xss10m` needs to be increased to improve the robustness of the testcase.
>
> SUN Guoyun 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 'openjdk:master' into 8292647
>  - 8292647: javac/lambda/T8031967.java fails with StackOverflowError when use -XX:TieredStopAtLevel=3 on aarch64 and LoongArch
>  - 8292647: javac/lambda/T8031967.java fails with StackOverflowError when use -XX:TieredStopAtLevel=3 on aarch64 and LoongArch

Please help review this patch again, thank you all.

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

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

From ngasson at openjdk.org  Thu Feb  9 14:56:18 2023
From: ngasson at openjdk.org (Nick Gasson)
Date: Thu, 9 Feb 2023 14:56:18 GMT
Subject: RFR: 8292647: javac/lambda/T8031967.java fails with
 StackOverflowError when use -XX:TieredStopAtLevel=3 on aarch64 and LoongArch
 [v3]
In-Reply-To: <z639fAXA8bpE1ZETMJpJW0kETKOu_CcPU8MSGA2Q9Fs=.44a4ea2a-b533-478f-a36c-c18b3040bba2@github.com>
References: <8Wo5jMV1FDBTdaz0O8PRwmSMUEqzQeLckldsJybpceg=.01580f6c-3290-4276-8d36-8e408035982c@github.com>
 <z639fAXA8bpE1ZETMJpJW0kETKOu_CcPU8MSGA2Q9Fs=.44a4ea2a-b533-478f-a36c-c18b3040bba2@github.com>
Message-ID: <RVCm9sHYc6RbO_2RNo2BHFjrpnaCUS1h8YyW3SIEw_Y=.7dabe91a-6962-4c12-8b21-ecded667284f@github.com>

On Wed, 8 Feb 2023 09:21:30 GMT, SUN Guoyun <duke at openjdk.org> wrote:

>> make images run-test TEST=tools/javac/lambda/T8031967.java will fails with StackOverflowError when I use args JTREG="VM_OPTIONS=-XX:TieredStopAtLevel=3" on aarch64 and LoongArch. So the stack size `-Xss10m` needs to be increased to improve the robustness of the testcase.
>
> SUN Guoyun 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 'openjdk:master' into 8292647
>  - 8292647: javac/lambda/T8031967.java fails with StackOverflowError when use -XX:TieredStopAtLevel=3 on aarch64 and LoongArch
>  - 8292647: javac/lambda/T8031967.java fails with StackOverflowError when use -XX:TieredStopAtLevel=3 on aarch64 and LoongArch

How can I reproduce this? I tried `make test TEST=tools/javac/lambda/T8031967.java JTREG="VM_OPTIONS=-XX:TieredStopAtLevel=3"` several times on a fastdebug build but it didn't fail.

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

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

From duke at openjdk.org  Thu Feb  9 15:01:20 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Thu, 9 Feb 2023 15:01:20 GMT
Subject: RFR: 8027682: javac wrongly accepts semicolons in package and
 import decls [v4]
In-Reply-To: <BtpuCEu4tnq4ih7a5HVq491h5FwmQYOVOweHevwjrCo=.c2934d87-c3c8-4ba6-bc46-1cd9e9744b02@github.com>
References: <bQN6VoWgHskZ_Wg9PgBhKWwUDYp5jlRGja_LkitHQY4=.1a7d2eec-a992-4cee-9eb0-68fe1821e276@github.com>
 <cdmEJqw4Mlo6C_nZgCh821M2363M1aIJM3IyZ7skW2M=.ba9484bf-2072-43ff-a8b8-d58cb2298a8e@github.com>
 <BtpuCEu4tnq4ih7a5HVq491h5FwmQYOVOweHevwjrCo=.c2934d87-c3c8-4ba6-bc46-1cd9e9744b02@github.com>
Message-ID: <db4TxUMPzvtYQWIoqTLoSvkQ2jzJkpvKbg3Gg7co0Tk=.d22ff2b4-b160-4812-934a-ca0900b89188@github.com>

On Thu, 9 Feb 2023 04:11:52 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> the new extraneous semicolon error is reported but the compiler doesn't report the fact that there is no class named NO inside of java.util or java.io I think that those other errors should be reported too

Hmm, this seems like an orthogonal issue to me.

In other words, the problem you're describing already exists, and it's just being uncovered by this change.

For example, if you compile this class:

import java.util.NO;
while
import java.io.NO;

you get this result:

Test.java:2: error: class, interface, enum, or record expected
while
^
1 error


If you compile this class:

import java.util.NO;
(
import java.io.NO;

you get this result:

Test.java:2: error: class, interface, enum, or record expected
(
^
1 error

The fact that a syntax error inhibits resolution of imported package names is happening somewhere else downstream in the compiler.

I'm not opposed to fixing that, but it seems like it should be filed as a separate issue, because (as the above examples show) it's a more general problem than just with extra semicolons.

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

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

From vromero at openjdk.org  Thu Feb  9 15:51:33 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 9 Feb 2023 15:51:33 GMT
Subject: RFR: 8301858: Verification error when compiling switch with record
 patterns [v3]
In-Reply-To: <NzGBgLN8rCU7G-nM3VX8_nnexwMTh8aGrvKuuJBBn_M=.b38ed621-6d50-49cf-a0d0-211208a8c712@github.com>
References: <cpGG6OTeBDYBx84stB4JJvw5SmhahmFnJanFpUclsn4=.32a30114-6747-4d65-93a4-783100726e26@github.com>
 <NzGBgLN8rCU7G-nM3VX8_nnexwMTh8aGrvKuuJBBn_M=.b38ed621-6d50-49cf-a0d0-211208a8c712@github.com>
Message-ID: <Qu6BP1UfF9sKO4R4-lEb_sQmcfJ-EaOm5PWSa4dhivo=.17f746d7-09dc-4a0b-99bd-a6f41e688851@github.com>

On Wed, 8 Feb 2023 14:29:10 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> When unrolling/translating record patterns with an unconditional case, we were translating the last/innermost case to`case null, default` skipping the initialization of a bound variable `o` in the example below:
>> 
>>     switch (..) {
>>       case R1(Object o):
>>                       return meth_O(o); 
>>     }
>>     => 
>>     switch (..) {
>>        case R1: 
>>           switch(..) {
>>             case null, default:
>>                             return meth_O(o);
>>           }
>>     }
>> 
>> This PR addresses that by emitting the correct label instead of default.
>
> Aggelos Biboudis has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   Fix unrolling with cases that have null and unconditional
>   
>   Co-authored-by: Jan Lahoda <jan.lahoda at oracle.com>

looks good

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

Marked as reviewed by vromero (Reviewer).

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

From abimpoudis at openjdk.org  Thu Feb  9 16:06:56 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 9 Feb 2023 16:06:56 GMT
Subject: Integrated: 8301858: Verification error when compiling switch with
 record patterns
In-Reply-To: <cpGG6OTeBDYBx84stB4JJvw5SmhahmFnJanFpUclsn4=.32a30114-6747-4d65-93a4-783100726e26@github.com>
References: <cpGG6OTeBDYBx84stB4JJvw5SmhahmFnJanFpUclsn4=.32a30114-6747-4d65-93a4-783100726e26@github.com>
Message-ID: <Zf2fbhEoiMt6gYmJRjpRgN7kvCXJz5IXQ-pYxNnfI7k=.9effa22a-52f1-4fc0-8ff3-22491fe2a996@github.com>

On Mon, 6 Feb 2023 13:06:30 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> When unrolling/translating record patterns with an unconditional case, we were translating the last/innermost case to`case null, default` skipping the initialization of a bound variable `o` in the example below:
> 
>     switch (..) {
>       case R1(Object o):
>                       return meth_O(o); 
>     }
>     => 
>     switch (..) {
>        case R1: 
>           switch(..) {
>             case null, default:
>                             return meth_O(o);
>           }
>     }
> 
> This PR addresses that by emitting the correct label instead of default.

This pull request has now been integrated.

Changeset: 3b05a94c
Author:    Aggelos Biboudis <abimpoudis at openjdk.org>
Committer: Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3b05a94c36e5d54693694c2e9950eca42626962b
Stats:     17 lines in 2 files changed: 13 ins; 0 del; 4 mod

8301858: Verification error when compiling switch with record patterns

Reviewed-by: vromero

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

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

From vromero at openjdk.org  Thu Feb  9 18:35:47 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 9 Feb 2023 18:35:47 GMT
Subject: RFR: 8027682: javac wrongly accepts semicolons in package and
 import decls [v4]
In-Reply-To: <cdmEJqw4Mlo6C_nZgCh821M2363M1aIJM3IyZ7skW2M=.ba9484bf-2072-43ff-a8b8-d58cb2298a8e@github.com>
References: <bQN6VoWgHskZ_Wg9PgBhKWwUDYp5jlRGja_LkitHQY4=.1a7d2eec-a992-4cee-9eb0-68fe1821e276@github.com>
 <cdmEJqw4Mlo6C_nZgCh821M2363M1aIJM3IyZ7skW2M=.ba9484bf-2072-43ff-a8b8-d58cb2298a8e@github.com>
Message-ID: <KLKxSZXgX4YgKKhdBT246Xpo3Asq0CsUdowcqmr5Nls=.04b999cb-30e0-4e40-9d88-2bbded93d9e1@github.com>

On Tue, 7 Feb 2023 19:51:51 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> JLS [?7.3](https://docs.oracle.com/javase/specs/jls/se19/html/jls-7.html#jls-7.3) specifies that while a lone semicolon is a valid _TopLevelClassOrInterfaceDeclaration_, it is not a valid _ImportDeclaration_. Therefore, if we see a lone semicolon while looking for the next import statement we have to advance and accept a class declaration, and we can therefore no longer accept any further `import` statements.
>> 
>> However, the compiler was allowing this, for example:
>> 
>> package p; import X; ;;; import Y; class Foo {}
>> 
>> The bug is that the parser was switching out of "look for imports" mode after parsing a valid class declaration, but it was not switching out of "look for imports" mode after parsing a lone semicolon.
>> 
>> The fix to `JavacParser.java` is easy, however it also requires these adjustments to unit tests:
>> 
>> * Test `tree/T6963934.java` must go away, because it is verifying a bug that only happens when the above bogus input is successfully parsed, and this can no longer happen.
>> * A bug in `lib/types/TypeHarness.java` was uncovered and fixed; it was inserting an extra semicolon.
>> * The following bugs, which check invalid syntax within import statements, now generate different parse errors and therefor needed their "golden output" updated:
>>   * annotations/typeAnnotations/failures/AnnotatedImport.java
>>   * annotations/typeAnnotations/failures/AnnotatedPackage1.java
>>   * annotations/typeAnnotations/failures/AnnotatedPackage2.java
>
> Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust unit test to accomodate spelling change in previous commit.

> > the new extraneous semicolon error is reported but the compiler doesn't report the fact that there is no class named NO inside of java.util or java.io I think that those other errors should be reported too
> 
> Hmm, this seems like an orthogonal issue to me.
> 
> In other words, the problem you're describing already exists, and it's just being uncovered by this change.
> 
> For example, if you compile this class:
> 
> ```java
> import java.util.NO;
> while
> import java.io.NO;
> ```
> 
> you get this result:
> 
> ```
> Test.java:2: error: class, interface, enum, or record expected
> while
> ^
> 1 error
> ```
> 
> If you compile this class:
> 
> ```java
> import java.util.NO;
> (
> import java.io.NO;
> ```
> 
> you get this result:
> 
> ```
> Test.java:2: error: class, interface, enum, or record expected
> (
> ^
> 1 error
> ```
> 
> The fact that a syntax error inhibits resolution of imported package names is happening somewhere else downstream in the compiler.
> 
> I'm not opposed to fixing that, but it seems like it should be filed as a separate issue, because (as the above examples show) it's a more general problem than just with extra semicolons.

yep you are right, my bad, nvm

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

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

From archie.cobbs at gmail.com  Thu Feb  9 19:04:09 2023
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Thu, 9 Feb 2023 13:04:09 -0600
Subject: NameClashSameErasureNoOverride1.java
Message-ID: <CANSoFxuk0nmLXae=QzkfXy4H96rZTA3ZRJXraG=XHvQDOYoE4A@mail.gmail.com>

We have this unit test diags/examples/NameClashSameErasureNoOverride1.java:

// key: compiler.err.name.clash.same.erasure.no.override.1

public class NameClashSameErasureNoOverride1 {

    interface I<X> {
        void m(X l);
    }

    class A {
        void m(Object l) {}
    }

    class B extends A implements I<Integer> {
        public void m(Integer l) {}
    }
}

This program is NOT supposed to compile, but rather fail with "name clash:
... two methods with the same erasure, yet neither overrides the other".

It seems like the erasure of A.m() is m(Object) and the erasure of B.m() is
m(Integer) - and these are not the same, so there's no clash.

What am I missing?

Thanks,
-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230209/f64e7a13/attachment.htm>

From forax at univ-mlv.fr  Thu Feb  9 19:09:00 2023
From: forax at univ-mlv.fr (Remi Forax)
Date: Thu, 9 Feb 2023 20:09:00 +0100 (CET)
Subject: NameClashSameErasureNoOverride1.java
In-Reply-To: <CANSoFxuk0nmLXae=QzkfXy4H96rZTA3ZRJXraG=XHvQDOYoE4A@mail.gmail.com>
References: <CANSoFxuk0nmLXae=QzkfXy4H96rZTA3ZRJXraG=XHvQDOYoE4A@mail.gmail.com>
Message-ID: <1288349805.16234507.1675969740349.JavaMail.zimbra@u-pem.fr>

> From: "Archie Cobbs" <archie.cobbs at gmail.com>
> To: "compiler-dev" <compiler-dev at openjdk.java.net>
> Sent: Thursday, February 9, 2023 8:04:09 PM
> Subject: NameClashSameErasureNoOverride1.java

> We have this unit test diags/examples/NameClashSameErasureNoOverride1.java:

> // key: compiler.err.name.clash.same.erasure.no.override.1

> public class NameClashSameErasureNoOverride1 {

> interface I<X> {
> void m(X l);
> }

> class A {
> void m(Object l) {}
> }

> class B extends A implements I<Integer> {
> public void m(Integer l) {}
> }
> }

> This program is NOT supposed to compile, but rather fail with "name clash: ...
> two methods with the same erasure, yet neither overrides the other".

> It seems like the erasure of A.m() is m(Object) and the erasure of B.m() is
> m(Integer) - and these are not the same, so there's no clash.

> What am I missing?

bridges :) 

class B is erased to 

class B extends A implements I { 
public /*bridge*/ void m(Object o) { 
m((Integer) o); 
} 
public void m(Integer l) {} 
} 

> Thanks,
> -Archie

R?mi 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230209/b4b9003c/attachment.htm>

From archie.cobbs at gmail.com  Thu Feb  9 19:20:33 2023
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Thu, 9 Feb 2023 13:20:33 -0600
Subject: NameClashSameErasureNoOverride1.java
In-Reply-To: <1288349805.16234507.1675969740349.JavaMail.zimbra@u-pem.fr>
References: <CANSoFxuk0nmLXae=QzkfXy4H96rZTA3ZRJXraG=XHvQDOYoE4A@mail.gmail.com>
 <1288349805.16234507.1675969740349.JavaMail.zimbra@u-pem.fr>
Message-ID: <CANSoFxs4yEYmCwy9W9ubnFNWtJ8_WX+5u0phDN=Ye6i1YKrPkQ@mail.gmail.com>

On Thu, Feb 9, 2023 at 1:09 PM Remi Forax <forax at univ-mlv.fr> wrote:

>
> It seems like the erasure of A.m() is m(Object) and the erasure of B.m()
> is m(Integer) - and these are not the same, so there's no clash.
>
> What am I missing?
>
>
> bridges :)
>

Ah - thanks!

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230209/642b794f/attachment-0001.htm>

From duke at openjdk.org  Thu Feb  9 21:07:32 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Thu, 9 Feb 2023 21:07:32 GMT
Subject: RFR: 5059679: name clash not reported for interface inheritance
Message-ID: <8BPz14cNrwLKfIHO77rNKeIgFacHtkC-aCbqCkN1tA0=.97031bcd-6f2d-4276-98c5-e0cbe6d79985@github.com>

Consider this input:

public class NarrowingNameClash {

    public interface Upper<T> {
        void method(T param);
    }

    public interface Lower<R> extends Upper<Class<R>> {
        void method(Class<?> param);        // erasure name clash here
    }
}

This violates ?8.4.8.3 because `method(Class<R>)` and `method(Class<?>)` have the same erasure. However, the compiler is not reporting an error in this case.

Here's my understanding of the bug... (reviewer please double-check this :)

?8.4.8.3 "Requirements in Overriding and Hiding" says:

It is a compile-time error if a class or interface C has a member method m1 and there exists a method m2 declared in C or a superclass or superinterface of C, A, such that all of the following are true:

* m1 and m2 have the same name.
* m2 is accessible (?6.6) from C.
* The signature of m1 is not a subsignature (?8.4.2) of the signature of m2 as a member of the supertype of C that names A.
* The declared signature of m1 or some method m1 overrides (directly or indirectly) has the same erasure as the declared signature of m2 or some method m2 overrides (directly or indirectly).

Method `method(Class<R>)` is inherited by `Lower` from `Upper` and is therefore a member of `Lower`. Note that upon inheritance its parameter `T` is reinterpreted as `Class<R>` in the context of `Lower`'s generic parameterization.

Let C = `Lower`, A = `Upper`, m1 = `method(Class<R>)` and m2 = `method(Class<?>)`.

The compiler is comparing the erasures of `method(T)`, which is "some method m1 overrides", and m2 = `method(Class<?>)`, and these are different, so no bug is reported.

That comparison is appropriate, however, what it also needs to do is compare the erasures of m1 and m2, which are both `method(Class)`.

In a nutshell: within the context of `Lower`, the method `method(Class<R>)` inherited from `Upper`, when erased, has a different signature from its original form `method(T)` in `Upper`, when erased. The possibility of this different form was not being taken into account in the compiler.

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

Commit messages:
 - Fix bug where certain erasure name clashes were not being detected.

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

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

From forax at univ-mlv.fr  Thu Feb  9 21:58:08 2023
From: forax at univ-mlv.fr (Remi Forax)
Date: Thu, 9 Feb 2023 22:58:08 +0100 (CET)
Subject: RFR: 5059679: name clash not reported for interface inheritance
In-Reply-To: <8BPz14cNrwLKfIHO77rNKeIgFacHtkC-aCbqCkN1tA0=.97031bcd-6f2d-4276-98c5-e0cbe6d79985@github.com>
References: <8BPz14cNrwLKfIHO77rNKeIgFacHtkC-aCbqCkN1tA0=.97031bcd-6f2d-4276-98c5-e0cbe6d79985@github.com>
Message-ID: <1689806125.16268779.1675979888297.JavaMail.zimbra@u-pem.fr>



----- Original Message -----
> From: "Archie L. Cobbs" <duke at openjdk.org>
> To: "compiler-dev" <compiler-dev at openjdk.org>
> Sent: Thursday, February 9, 2023 10:07:32 PM
> Subject: RFR: 5059679: name clash not reported for interface inheritance

> Consider this input:
> 
> public class NarrowingNameClash {
> 
>    public interface Upper<T> {
>        void method(T param);
>    }
> 
>    public interface Lower<R> extends Upper<Class<R>> {
>        void method(Class<?> param);        // erasure name clash here
>    }
> }
> 
> This violates ?8.4.8.3 because `method(Class<R>)` and `method(Class<?>)` have
> the same erasure. However, the compiler is not reporting an error in this case.
> 
> Here's my understanding of the bug... (reviewer please double-check this :)

It's maybe a spec bug because you can still have a raw class that implement both interfaces.
(if the class is raw, all the hierarchy is raw so you can implement Lower and Upper (both raw classes) at the same time).

Something like

  class Foo implements Upper, Lower {
    void m(Object o) { ... }
    void m(Class c) { ... }
  }

R?mi


> 
> ?8.4.8.3 "Requirements in Overriding and Hiding" says:
> 
> It is a compile-time error if a class or interface C has a member method m1 and
> there exists a method m2 declared in C or a superclass or superinterface of C,
> A, such that all of the following are true:
> 
> * m1 and m2 have the same name.
> * m2 is accessible (?6.6) from C.
> * The signature of m1 is not a subsignature (?8.4.2) of the signature of m2 as a
> member of the supertype of C that names A.
> * The declared signature of m1 or some method m1 overrides (directly or
> indirectly) has the same erasure as the declared signature of m2 or some method
> m2 overrides (directly or indirectly).
> 
> Method `method(Class<R>)` is inherited by `Lower` from `Upper` and is therefore
> a member of `Lower`. Note that upon inheritance its parameter `T` is
> reinterpreted as `Class<R>` in the context of `Lower`'s generic
> parameterization.
> 
> Let C = `Lower`, A = `Upper`, m1 = `method(Class<R>)` and m2 =
> `method(Class<?>)`.
> 
> The compiler is comparing the erasures of `method(T)`, which is "some method m1
> overrides", and m2 = `method(Class<?>)`, and these are different, so no bug is
> reported.
> 
> That comparison is appropriate, however, what it also needs to do is compare the
> erasures of m1 and m2, which are both `method(Class)`.
> 
> In a nutshell: within the context of `Lower`, the method `method(Class<R>)`
> inherited from `Upper`, when erased, has a different signature from its
> original form `method(T)` in `Upper`, when erased. The possibility of this
> different form was not being taken into account in the compiler.
> 
> -------------
> 
> Commit messages:
> - Fix bug where certain erasure name clashes were not being detected.
> 
> Changes: https://git.openjdk.org/jdk/pull/12503/files
> Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12503&range=00
>  Issue: https://bugs.openjdk.org/browse/JDK-5059679
>  Stats: 23 lines in 3 files changed: 22 ins; 0 del; 1 mod
>  Patch: https://git.openjdk.org/jdk/pull/12503.diff
>  Fetch: git fetch https://git.openjdk.org/jdk pull/12503/head:pull/12503
> 
> PR: https://git.openjdk.org/jdk/pull/12503

From archie.cobbs at gmail.com  Thu Feb  9 22:49:08 2023
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Thu, 9 Feb 2023 16:49:08 -0600
Subject: RFR: 5059679: name clash not reported for interface inheritance
In-Reply-To: <1689806125.16268779.1675979888297.JavaMail.zimbra@u-pem.fr>
References: <8BPz14cNrwLKfIHO77rNKeIgFacHtkC-aCbqCkN1tA0=.97031bcd-6f2d-4276-98c5-e0cbe6d79985@github.com>
 <1689806125.16268779.1675979888297.JavaMail.zimbra@u-pem.fr>
Message-ID: <CANSoFxube_St-Za7ggLLkC1Ezan5m9uZZBPNA2Ez3JvbQOPJRA@mail.gmail.com>

On Thu, Feb 9, 2023 at 3:59 PM Remi Forax <forax at univ-mlv.fr> wrote:

> > public class NarrowingNameClash {
> >
> >    public interface Upper<T> {
> >        void method(T param);
> >    }
> >
> >    public interface Lower<R> extends Upper<Class<R>> {
> >        void method(Class<?> param);        // erasure name clash here
> >    }
> > }
> >
> > This violates ?8.4.8.3 because `method(Class<R>)` and `method(Class<?>)`
> have
> > the same erasure. However, the compiler is not reporting an error in
> this case.
> >
> > Here's my understanding of the bug... (reviewer please double-check this
> :)
>
> It's maybe a spec bug because you can still have a raw class that
> implement both interfaces.
>

Apologies... I'm not completely getting what you're saying.

The point here is that "NarrowingNameClash" itself should not compile,
so... ?

-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230209/669903b0/attachment.htm>

From forax at univ-mlv.fr  Thu Feb  9 23:34:37 2023
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Fri, 10 Feb 2023 00:34:37 +0100 (CET)
Subject: RFR: 5059679: name clash not reported for interface inheritance
In-Reply-To: <CANSoFxube_St-Za7ggLLkC1Ezan5m9uZZBPNA2Ez3JvbQOPJRA@mail.gmail.com>
References: <8BPz14cNrwLKfIHO77rNKeIgFacHtkC-aCbqCkN1tA0=.97031bcd-6f2d-4276-98c5-e0cbe6d79985@github.com>
 <1689806125.16268779.1675979888297.JavaMail.zimbra@u-pem.fr>
 <CANSoFxube_St-Za7ggLLkC1Ezan5m9uZZBPNA2Ez3JvbQOPJRA@mail.gmail.com>
Message-ID: <897186294.16280066.1675985677234.JavaMail.zimbra@u-pem.fr>

> From: "Archie Cobbs" <archie.cobbs at gmail.com>
> To: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Archie L. Cobbs" <duke at openjdk.org>, "compiler-dev"
> <compiler-dev at openjdk.org>
> Sent: Thursday, February 9, 2023 11:49:08 PM
> Subject: Re: RFR: 5059679: name clash not reported for interface inheritance

> On Thu, Feb 9, 2023 at 3:59 PM Remi Forax < [ mailto:forax at univ-mlv.fr |
> forax at univ-mlv.fr ] > wrote:

>> > public class NarrowingNameClash {

>> > public interface Upper<T> {
>> > void method(T param);
>> > }

>> > public interface Lower<R> extends Upper<Class<R>> {
>> > void method(Class<?> param); // erasure name clash here
>> > }
>> > }

>> > This violates ?8.4.8.3 because `method(Class<R>)` and `method(Class<?>)` have
>> > the same erasure. However, the compiler is not reporting an error in this case.

>> > Here's my understanding of the bug... (reviewer please double-check this :)

>> It's maybe a spec bug because you can still have a raw class that implement both
>> interfaces.

> Apologies... I'm not completely getting what you're saying.

> The point here is that "NarrowingNameClash" itself should not compile, so... ?

The idea is that an interface should not compile only if all possible classes that implements that interface, here Lower will not compile, 
so the compiler can report the issue earlier when Lower is declared. 
But here, there is at least one class that implements Lower and compiles. 

> -Archie

R?mi 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230210/5d29309b/attachment-0001.htm>

From archie.cobbs at gmail.com  Fri Feb 10 01:20:27 2023
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Thu, 9 Feb 2023 19:20:27 -0600
Subject: RFR: 5059679: name clash not reported for interface inheritance
In-Reply-To: <897186294.16280066.1675985677234.JavaMail.zimbra@u-pem.fr>
References: <8BPz14cNrwLKfIHO77rNKeIgFacHtkC-aCbqCkN1tA0=.97031bcd-6f2d-4276-98c5-e0cbe6d79985@github.com>
 <1689806125.16268779.1675979888297.JavaMail.zimbra@u-pem.fr>
 <CANSoFxube_St-Za7ggLLkC1Ezan5m9uZZBPNA2Ez3JvbQOPJRA@mail.gmail.com>
 <897186294.16280066.1675985677234.JavaMail.zimbra@u-pem.fr>
Message-ID: <CANSoFxupHBFFBcXRJwC1BJgMMgD11RH=-xtcAxmq8bQ-qBFynQ@mail.gmail.com>

On Thu, Feb 9, 2023 at 5:34 PM <forax at univ-mlv.fr> wrote:

>
> ------------------------------
>
> *From: *"Archie Cobbs" <archie.cobbs at gmail.com>
> *To: *"Remi Forax" <forax at univ-mlv.fr>
> *Cc: *"Archie L. Cobbs" <duke at openjdk.org>, "compiler-dev" <
> compiler-dev at openjdk.org>
> *Sent: *Thursday, February 9, 2023 11:49:08 PM
> *Subject: *Re: RFR: 5059679: name clash not reported for interface
> inheritance
>
> On Thu, Feb 9, 2023 at 3:59 PM Remi Forax <forax at univ-mlv.fr> wrote:
>
>> > public class NarrowingNameClash {
>> >
>> >    public interface Upper<T> {
>> >        void method(T param);
>> >    }
>> >
>> >    public interface Lower<R> extends Upper<Class<R>> {
>> >        void method(Class<?> param);        // erasure name clash here
>> >    }
>> > }
>> >
>> > This violates ?8.4.8.3 because `method(Class<R>)` and
>> `method(Class<?>)` have
>> > the same erasure. However, the compiler is not reporting an error in
>> this case.
>> >
>> > Here's my understanding of the bug... (reviewer please double-check
>> this :)
>>
>> It's maybe a spec bug because you can still have a raw class that
>> implement both interfaces.
>>
>
> Apologies... I'm not completely getting what you're saying.
>
> The point here is that "NarrowingNameClash" itself should not compile,
> so... ?
>
>
> The idea is that an interface should not compile only if all possible
> classes that implements that interface, here Lower will not compile,
> so the compiler can report the issue earlier when Lower is declared.
> But here, there is at least one class that implements Lower and compiles.
>

Got it. I'm not sure what the "rule" is or if there really is one but I see
your point.

Maybe the thinking was "If the only way to use such an interface requires
using raw types then it's not worth it".

-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230209/0789b861/attachment.htm>

From duke at openjdk.org  Fri Feb 10 02:36:48 2023
From: duke at openjdk.org (SUN Guoyun)
Date: Fri, 10 Feb 2023 02:36:48 GMT
Subject: RFR: 8292647: javac/lambda/T8031967.java fails with
 StackOverflowError when use -XX:TieredStopAtLevel=3 on aarch64 and LoongArch
 [v3]
In-Reply-To: <z639fAXA8bpE1ZETMJpJW0kETKOu_CcPU8MSGA2Q9Fs=.44a4ea2a-b533-478f-a36c-c18b3040bba2@github.com>
References: <8Wo5jMV1FDBTdaz0O8PRwmSMUEqzQeLckldsJybpceg=.01580f6c-3290-4276-8d36-8e408035982c@github.com>
 <z639fAXA8bpE1ZETMJpJW0kETKOu_CcPU8MSGA2Q9Fs=.44a4ea2a-b533-478f-a36c-c18b3040bba2@github.com>
Message-ID: <5KCoVRYeqFnjNBJ6fFBuRZvN9opYfZVpy-RKVgh0qTY=.06416b36-fd4a-4f49-a5a9-979e3a94f642@github.com>

On Wed, 8 Feb 2023 09:21:30 GMT, SUN Guoyun <duke at openjdk.org> wrote:

>> make images run-test TEST=tools/javac/lambda/T8031967.java will fails with StackOverflowError when I use args JTREG="VM_OPTIONS=-XX:TieredStopAtLevel=3" on aarch64 and LoongArch. So the stack size `-Xss10m` needs to be increased to improve the robustness of the testcase.
>
> SUN Guoyun 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 'openjdk:master' into 8292647
>  - 8292647: javac/lambda/T8031967.java fails with StackOverflowError when use -XX:TieredStopAtLevel=3 on aarch64 and LoongArch
>  - 8292647: javac/lambda/T8031967.java fails with StackOverflowError when use -XX:TieredStopAtLevel=3 on aarch64 and LoongArch

I don't remember on which version I tested it for aarch64, I'll confirm again.

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

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

From gli at openjdk.org  Fri Feb 10 03:27:48 2023
From: gli at openjdk.org (Guoxiong Li)
Date: Fri, 10 Feb 2023 03:27:48 GMT
Subject: RFR: 8292647: javac/lambda/T8031967.java fails with
 StackOverflowError when use -XX:TieredStopAtLevel=3 on aarch64 and LoongArch
 [v3]
In-Reply-To: <z639fAXA8bpE1ZETMJpJW0kETKOu_CcPU8MSGA2Q9Fs=.44a4ea2a-b533-478f-a36c-c18b3040bba2@github.com>
References: <8Wo5jMV1FDBTdaz0O8PRwmSMUEqzQeLckldsJybpceg=.01580f6c-3290-4276-8d36-8e408035982c@github.com>
 <z639fAXA8bpE1ZETMJpJW0kETKOu_CcPU8MSGA2Q9Fs=.44a4ea2a-b533-478f-a36c-c18b3040bba2@github.com>
Message-ID: <mdUExOdJ5nZOhOLpRWdc3eX40fxlotEFQApkJwLYjzw=.1d49f543-366c-4b25-aac4-5466a96e565b@github.com>

On Wed, 8 Feb 2023 09:21:30 GMT, SUN Guoyun <duke at openjdk.org> wrote:

>> make images run-test TEST=tools/javac/lambda/T8031967.java will fails with StackOverflowError when I use args JTREG="VM_OPTIONS=-XX:TieredStopAtLevel=3" on aarch64 and LoongArch. So the stack size `-Xss10m` needs to be increased to improve the robustness of the testcase.
>
> SUN Guoyun 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 'openjdk:master' into 8292647
>  - 8292647: javac/lambda/T8031967.java fails with StackOverflowError when use -XX:TieredStopAtLevel=3 on aarch64 and LoongArch
>  - 8292647: javac/lambda/T8031967.java fails with StackOverflowError when use -XX:TieredStopAtLevel=3 on aarch64 and LoongArch

Seems like an issue about the JIT compiler. So it is good to CC hotspot-compiler mailing list.

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

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

From vromero at openjdk.org  Fri Feb 10 09:52:45 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 10 Feb 2023 09:52:45 GMT
Subject: RFR: 8027682: javac wrongly accepts semicolons in package and
 import decls [v4]
In-Reply-To: <cdmEJqw4Mlo6C_nZgCh821M2363M1aIJM3IyZ7skW2M=.ba9484bf-2072-43ff-a8b8-d58cb2298a8e@github.com>
References: <bQN6VoWgHskZ_Wg9PgBhKWwUDYp5jlRGja_LkitHQY4=.1a7d2eec-a992-4cee-9eb0-68fe1821e276@github.com>
 <cdmEJqw4Mlo6C_nZgCh821M2363M1aIJM3IyZ7skW2M=.ba9484bf-2072-43ff-a8b8-d58cb2298a8e@github.com>
Message-ID: <0bt1yAPNmgUaQhYy5YJRaDQbnbnD-XRl_WLt5P_m37c=.da51a7e5-9444-4978-b566-3e257bb6b208@github.com>

On Tue, 7 Feb 2023 19:51:51 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> JLS [?7.3](https://docs.oracle.com/javase/specs/jls/se19/html/jls-7.html#jls-7.3) specifies that while a lone semicolon is a valid _TopLevelClassOrInterfaceDeclaration_, it is not a valid _ImportDeclaration_. Therefore, if we see a lone semicolon while looking for the next import statement we have to advance and accept a class declaration, and we can therefore no longer accept any further `import` statements.
>> 
>> However, the compiler was allowing this, for example:
>> 
>> package p; import X; ;;; import Y; class Foo {}
>> 
>> The bug is that the parser was switching out of "look for imports" mode after parsing a valid class declaration, but it was not switching out of "look for imports" mode after parsing a lone semicolon.
>> 
>> The fix to `JavacParser.java` is easy, however it also requires these adjustments to unit tests:
>> 
>> * Test `tree/T6963934.java` must go away, because it is verifying a bug that only happens when the above bogus input is successfully parsed, and this can no longer happen.
>> * A bug in `lib/types/TypeHarness.java` was uncovered and fixed; it was inserting an extra semicolon.
>> * The following bugs, which check invalid syntax within import statements, now generate different parse errors and therefor needed their "golden output" updated:
>>   * annotations/typeAnnotations/failures/AnnotatedImport.java
>>   * annotations/typeAnnotations/failures/AnnotatedPackage1.java
>>   * annotations/typeAnnotations/failures/AnnotatedPackage2.java
>
> Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust unit test to accomodate spelling change in previous commit.

looks sensible

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

Marked as reviewed by vromero (Reviewer).

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

From duke at openjdk.org  Fri Feb 10 09:52:52 2023
From: duke at openjdk.org (SUN Guoyun)
Date: Fri, 10 Feb 2023 09:52:52 GMT
Subject: RFR: 8292647: javac/lambda/T8031967.java fails with
 StackOverflowError when use -XX:TieredStopAtLevel=3 on aarch64 and LoongArch
 [v3]
In-Reply-To: <z639fAXA8bpE1ZETMJpJW0kETKOu_CcPU8MSGA2Q9Fs=.44a4ea2a-b533-478f-a36c-c18b3040bba2@github.com>
References: <8Wo5jMV1FDBTdaz0O8PRwmSMUEqzQeLckldsJybpceg=.01580f6c-3290-4276-8d36-8e408035982c@github.com>
 <z639fAXA8bpE1ZETMJpJW0kETKOu_CcPU8MSGA2Q9Fs=.44a4ea2a-b533-478f-a36c-c18b3040bba2@github.com>
Message-ID: <Etm7GYv42AALe4NyIc5p1EVwOPiRRiukXwZRFtx4k7M=.35d76687-01c9-4f2a-9225-424766c53ef4@github.com>

On Wed, 8 Feb 2023 09:21:30 GMT, SUN Guoyun <duke at openjdk.org> wrote:

>> make images run-test TEST=tools/javac/lambda/T8031967.java will fails with StackOverflowError when I use args JTREG="VM_OPTIONS=-XX:TieredStopAtLevel=3" on aarch64 and LoongArch. So the stack size `-Xss10m` needs to be increased to improve the robustness of the testcase.
>
> SUN Guoyun 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 'openjdk:master' into 8292647
>  - 8292647: javac/lambda/T8031967.java fails with StackOverflowError when use -XX:TieredStopAtLevel=3 on aarch64 and LoongArch
>  - 8292647: javac/lambda/T8031967.java fails with StackOverflowError when use -XX:TieredStopAtLevel=3 on aarch64 and LoongArch

Sorry, I can't confirm which version reproduces the issue on aarch64. But the conclusion that aarch64 requires more stack space than x86_64 holds. i.e. `java.lang.Object::<init>` has a 0x30 stack size on x86_64 platforms, but 0x40 stack size on aarch64.

For x86_64
<pre><code class="shell">
----------------------------------- Assembly -----------------------------------
                                                                                
Compiled method (c1)      70    1       3       java.lang.Object::<init> (1 bytes)
...
[Verified Entry Point]                                                          
  0x00007fb8191cc740:   mov    %eax,-0x18000(%rsp)                              
  0x00007fb8191cc747:   push   %rbp                                             
  0x00007fb8191cc748:   sub    $0x30,%rsp    // stack size is 0x30

</code></pre>

For aarch64
<pre><code class="shell">
----------------------------------- Assembly -----------------------------------

Compiled method (c1)      64    1       3       java.lang.Object::<init> (1 bytes)
...
[Verified Entry Point]
  0x0000ffff9c22b980:   nop
  0x0000ffff9c22b984:   sub	x9, sp, #0x19, lsl #12
  0x0000ffff9c22b988:   str	xzr, [x9]
  0x0000ffff9c22b98c:   sub	sp, sp, #0x40          //stack size is 0x40, larger than x86_64
  0x0000ffff9c22b990:   stp	x29, x30, [sp, #48]
</code></pre>

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

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

From duke at openjdk.org  Fri Feb 10 09:57:53 2023
From: duke at openjdk.org (SUN Guoyun)
Date: Fri, 10 Feb 2023 09:57:53 GMT
Subject: RFR: 8292647: javac/lambda/T8031967.java fails with
 StackOverflowError when use -XX:TieredStopAtLevel=3 on aarch64 and LoongArch
 [v3]
In-Reply-To: <z639fAXA8bpE1ZETMJpJW0kETKOu_CcPU8MSGA2Q9Fs=.44a4ea2a-b533-478f-a36c-c18b3040bba2@github.com>
References: <8Wo5jMV1FDBTdaz0O8PRwmSMUEqzQeLckldsJybpceg=.01580f6c-3290-4276-8d36-8e408035982c@github.com>
 <z639fAXA8bpE1ZETMJpJW0kETKOu_CcPU8MSGA2Q9Fs=.44a4ea2a-b533-478f-a36c-c18b3040bba2@github.com>
Message-ID: <q_lQ14KzDmtGI9XdYiq_u_UrcVJFTabqotgV0I6c_Ko=.624cc1f8-1a73-4396-aa37-07e90ae0c01d@github.com>

On Wed, 8 Feb 2023 09:21:30 GMT, SUN Guoyun <duke at openjdk.org> wrote:

>> make images run-test TEST=tools/javac/lambda/T8031967.java will fails with StackOverflowError when I use args JTREG="VM_OPTIONS=-XX:TieredStopAtLevel=3" on aarch64 and LoongArch. So the stack size `-Xss10m` needs to be increased to improve the robustness of the testcase.
>
> SUN Guoyun 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 'openjdk:master' into 8292647
>  - 8292647: javac/lambda/T8031967.java fails with StackOverflowError when use -XX:TieredStopAtLevel=3 on aarch64 and LoongArch
>  - 8292647: javac/lambda/T8031967.java fails with StackOverflowError when use -XX:TieredStopAtLevel=3 on aarch64 and LoongArch

And I found the above difference comes from the different ways in which framesize is calculated.
<pre><code class="cpp">
// src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp

int LIR_Assembler::initial_frame_size_in_bytes() const {                        
  return in_bytes(frame_map()->framesize_in_bytes());                           
}
</code></pre>

<pre><code class="cpp">
// src/hotspot/cpu/x86/c1_LIRAssembler_x86.cpp

int LIR_Assembler::initial_frame_size_in_bytes() const {                        
  return (frame_map()->framesize() - (2*VMRegImpl::slots_per_word))  * VMRegImpl::stack_slot_size;
}  
</code></pre>

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

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

From ngasson at openjdk.org  Fri Feb 10 10:09:53 2023
From: ngasson at openjdk.org (Nick Gasson)
Date: Fri, 10 Feb 2023 10:09:53 GMT
Subject: RFR: 8292647: javac/lambda/T8031967.java fails with
 StackOverflowError when use -XX:TieredStopAtLevel=3 on aarch64 and LoongArch
 [v3]
In-Reply-To: <z639fAXA8bpE1ZETMJpJW0kETKOu_CcPU8MSGA2Q9Fs=.44a4ea2a-b533-478f-a36c-c18b3040bba2@github.com>
References: <8Wo5jMV1FDBTdaz0O8PRwmSMUEqzQeLckldsJybpceg=.01580f6c-3290-4276-8d36-8e408035982c@github.com>
 <z639fAXA8bpE1ZETMJpJW0kETKOu_CcPU8MSGA2Q9Fs=.44a4ea2a-b533-478f-a36c-c18b3040bba2@github.com>
Message-ID: <ohyH2PDtloPiTD7mLYwZefUjAItvQ-Y3DgxBlf5Q3cQ=.c8083468-1f95-4404-a75c-7042d9ec1cde@github.com>

On Wed, 8 Feb 2023 09:21:30 GMT, SUN Guoyun <duke at openjdk.org> wrote:

>> make images run-test TEST=tools/javac/lambda/T8031967.java will fails with StackOverflowError when I use args JTREG="VM_OPTIONS=-XX:TieredStopAtLevel=3" on aarch64 and LoongArch. So the stack size `-Xss10m` needs to be increased to improve the robustness of the testcase.
>
> SUN Guoyun 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 'openjdk:master' into 8292647
>  - 8292647: javac/lambda/T8031967.java fails with StackOverflowError when use -XX:TieredStopAtLevel=3 on aarch64 and LoongArch
>  - 8292647: javac/lambda/T8031967.java fails with StackOverflowError when use -XX:TieredStopAtLevel=3 on aarch64 and LoongArch

I think the `- (2*VMRegImpl::slots_per_word)` in the x86 version is accounting for the stack space consumed by `push %rbp` and the `call` instruction which pushes the return address to the stack. So in both cases the stack frame is 0x40 bytes in total.

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

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

From jlaskey at openjdk.org  Fri Feb 10 13:37:37 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 10 Feb 2023 13:37:37 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v35]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <qigcd9_Ho_hqmU70v4acg_P88mhLEFg3F95h8YcLEOM=.0fc23f0f-9fbb-4533-a25c-a26e9d3b9a07@github.com>

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

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

 - Merge branch 'master' into 8285932
 - Update to JDK 21
 - Merge branch 'master' into 8285932
 - Merge branch 'master' into 8285932
 - FormatProcessor changes
 - Update @since
 - Requested changes #12
 - Seal Digits
 - Requested changes #11
 - Typo
 - ... and 40 more: https://git.openjdk.org/jdk/compare/c8ace482...264120a9

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

Changes: https://git.openjdk.org/jdk/pull/10889/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=34
  Stats: 9519 lines in 81 files changed: 9356 ins; 28 del; 135 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10889/head:pull/10889

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

From jlaskey at openjdk.org  Fri Feb 10 13:41:10 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 10 Feb 2023 13:41:10 GMT
Subject: RFR: JDK-8296322 javac: use methods to manage parser mode flags
 [v2]
In-Reply-To: <ODFF2ZvoTnzinMhSyLSQhmooIdRCAeZZaIb5-CorxRY=.92702ced-aacc-4362-8815-28d54747b991@github.com>
References: <ODFF2ZvoTnzinMhSyLSQhmooIdRCAeZZaIb5-CorxRY=.92702ced-aacc-4362-8815-28d54747b991@github.com>
Message-ID: <w49eZiSetILAwHKi4SIIf6joD-9swwd2nIyPsvYsZY0=.cc79507c-4087-435b-9154-9c3eca3edbcf@github.com>

> Manage parser mode flags using methods for easy of reading and maintenance.

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

 - Merge branch 'master' into 8296322
 - JDK-8296322 javac: use methods to manage parser mode flags

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10981/files
  - new: https://git.openjdk.org/jdk/pull/10981/files/cc0989c0..faf18a62

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

  Stats: 260808 lines in 5800 files changed: 125648 ins; 81789 del; 53371 mod
  Patch: https://git.openjdk.org/jdk/pull/10981.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10981/head:pull/10981

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

From jlaskey at openjdk.org  Fri Feb 10 13:51:06 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 10 Feb 2023 13:51:06 GMT
Subject: RFR: JDK-8296322 javac: use methods to manage parser mode flags
 [v3]
In-Reply-To: <ODFF2ZvoTnzinMhSyLSQhmooIdRCAeZZaIb5-CorxRY=.92702ced-aacc-4362-8815-28d54747b991@github.com>
References: <ODFF2ZvoTnzinMhSyLSQhmooIdRCAeZZaIb5-CorxRY=.92702ced-aacc-4362-8815-28d54747b991@github.com>
Message-ID: <djOsJPWKXul-RDAJtzRhKfmnI451u6XPxMKGUNAXFjA=.46ae52a6-b912-47cc-9039-c7e2f269b776@github.com>

> Manage parser mode flags using methods for easy of reading and maintenance.

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

  Bring up to date

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10981/files
  - new: https://git.openjdk.org/jdk/pull/10981/files/faf18a62..4e4437cb

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

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

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

From jlaskey at openjdk.org  Fri Feb 10 14:27:17 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 10 Feb 2023 14:27:17 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v36]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <c3fzYf65-ppnmsSbC41mQMcksftq44h6USI6Jio0KSI=.2ba0037e-8a70-4420-8810-606b823e40bd@github.com>

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

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

  Bring up to date

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/264120a9..665cded9

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

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

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

From duke at openjdk.org  Fri Feb 10 15:16:19 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Fri, 10 Feb 2023 15:16:19 GMT
Subject: RFR: 8027682: javac wrongly accepts semicolons in package and
 import decls [v5]
In-Reply-To: <bQN6VoWgHskZ_Wg9PgBhKWwUDYp5jlRGja_LkitHQY4=.1a7d2eec-a992-4cee-9eb0-68fe1821e276@github.com>
References: <bQN6VoWgHskZ_Wg9PgBhKWwUDYp5jlRGja_LkitHQY4=.1a7d2eec-a992-4cee-9eb0-68fe1821e276@github.com>
Message-ID: <3lV4QNnSoikQ81CYC-F_dGk1LPOdEB_IRC4TUQn3BY8=.249af2b7-0ee3-4ca0-b616-d57acb47180d@github.com>

> JLS [?7.3](https://docs.oracle.com/javase/specs/jls/se19/html/jls-7.html#jls-7.3) specifies that while a lone semicolon is a valid _TopLevelClassOrInterfaceDeclaration_, it is not a valid _ImportDeclaration_. Therefore, if we see a lone semicolon while looking for the next import statement we have to advance and accept a class declaration, and we can therefore no longer accept any further `import` statements.
> 
> However, the compiler was allowing this, for example:
> 
> package p; import X; ;;; import Y; class Foo {}
> 
> The bug is that the parser was switching out of "look for imports" mode after parsing a valid class declaration, but it was not switching out of "look for imports" mode after parsing a lone semicolon.
> 
> The fix to `JavacParser.java` is easy, however it also requires these adjustments to unit tests:
> 
> * Test `tree/T6963934.java` must go away, because it is verifying a bug that only happens when the above bogus input is successfully parsed, and this can no longer happen.
> * A bug in `lib/types/TypeHarness.java` was uncovered and fixed; it was inserting an extra semicolon.
> * The following bugs, which check invalid syntax within import statements, now generate different parse errors and therefor needed their "golden output" updated:
>   * annotations/typeAnnotations/failures/AnnotatedImport.java
>   * annotations/typeAnnotations/failures/AnnotatedPackage1.java
>   * annotations/typeAnnotations/failures/AnnotatedPackage2.java

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

  Generate warnings instead of errors for source levels < 21.
  
  This improves backward compatibility as requested in the CSR (JDK-8301905).

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12448/files
  - new: https://git.openjdk.org/jdk/pull/12448/files/7abe59dd..979ed908

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

  Stats: 48 lines in 4 files changed: 43 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/12448.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12448/head:pull/12448

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

From vromero at openjdk.org  Fri Feb 10 16:45:46 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 10 Feb 2023 16:45:46 GMT
Subject: RFR: 8027682: javac wrongly accepts semicolons in package and
 import decls [v5]
In-Reply-To: <3lV4QNnSoikQ81CYC-F_dGk1LPOdEB_IRC4TUQn3BY8=.249af2b7-0ee3-4ca0-b616-d57acb47180d@github.com>
References: <bQN6VoWgHskZ_Wg9PgBhKWwUDYp5jlRGja_LkitHQY4=.1a7d2eec-a992-4cee-9eb0-68fe1821e276@github.com>
 <3lV4QNnSoikQ81CYC-F_dGk1LPOdEB_IRC4TUQn3BY8=.249af2b7-0ee3-4ca0-b616-d57acb47180d@github.com>
Message-ID: <v_UNs81rrOt8UPxvAId5K1KV-k0PWNLFwoiGGn6sROo=.a2cbf1b3-5b76-4cba-8e57-b29bf346f7ff@github.com>

On Fri, 10 Feb 2023 15:16:19 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> JLS [?7.3](https://docs.oracle.com/javase/specs/jls/se19/html/jls-7.html#jls-7.3) specifies that while a lone semicolon is a valid _TopLevelClassOrInterfaceDeclaration_, it is not a valid _ImportDeclaration_. Therefore, if we see a lone semicolon while looking for the next import statement we have to advance and accept a class declaration, and we can therefore no longer accept any further `import` statements.
>> 
>> However, the compiler was allowing this, for example:
>> 
>> package p; import X; ;;; import Y; class Foo {}
>> 
>> The bug is that the parser was switching out of "look for imports" mode after parsing a valid class declaration, but it was not switching out of "look for imports" mode after parsing a lone semicolon.
>> 
>> The fix to `JavacParser.java` is easy, however it also requires these adjustments to unit tests:
>> 
>> * Test `tree/T6963934.java` must go away, because it is verifying a bug that only happens when the above bogus input is successfully parsed, and this can no longer happen.
>> * A bug in `lib/types/TypeHarness.java` was uncovered and fixed; it was inserting an extra semicolon.
>> * The following bugs, which check invalid syntax within import statements, now generate different parse errors and therefor needed their "golden output" updated:
>>   * annotations/typeAnnotations/failures/AnnotatedImport.java
>>   * annotations/typeAnnotations/failures/AnnotatedPackage1.java
>>   * annotations/typeAnnotations/failures/AnnotatedPackage2.java
>
> Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Generate warnings instead of errors for source levels < 21.
>   
>   This improves backward compatibility as requested in the CSR (JDK-8301905).

test/langtools/tools/javac/diags/examples/ExtraneousSemiColonError.java line 29:

> 27: import java.util.Set;
> 28: 
> 29: class ExtraneousSemiColonError {

I think that we should have a dedicated test for the new feature, apart from the diagnostics oriented ones. The test could be executed twice once with option `-source 20` and once without it and provided two golden files accordingly.

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

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

From jlaskey at openjdk.org  Fri Feb 10 17:07:24 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 10 Feb 2023 17:07:24 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v37]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <3Cffq9T2VOO7KsFUbANnyixAkxi4Ztlojk9voEvmF1I=.2ed8c2bf-e704-4661-9185-102ac3f15e7a@github.com>

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

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

  CSR review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/665cded9..8f5ad0a4

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

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

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

From jlaskey at openjdk.org  Fri Feb 10 17:09:18 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 10 Feb 2023 17:09:18 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v38]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <eezyAvzaM0LdNnfM45CuWMrKf7UHrz2pihbMsQeGL3Q=.9ae6c576-ddcb-4129-ab33-2019ebbadbf3@github.com>

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

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

 - Merge branch 'master' into 8285932
 - CSR review
 - Bring up to date
 - Merge branch 'master' into 8285932
 - Update to JDK 21
 - Merge branch 'master' into 8285932
 - Merge branch 'master' into 8285932
 - FormatProcessor changes
 - Update @since
 - Requested changes #12
 - ... and 43 more: https://git.openjdk.org/jdk/compare/4539899c...5fab46c1

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

Changes: https://git.openjdk.org/jdk/pull/10889/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=37
  Stats: 9576 lines in 81 files changed: 9411 ins; 28 del; 137 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10889/head:pull/10889

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

From jlaskey at openjdk.org  Fri Feb 10 17:32:00 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 10 Feb 2023 17:32:00 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v39]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <tspvAWdHSt6tqlq1TtiLVEO2YywIAJaJWd19gMYsIm4=.6cf6fe32-6d09-46c9-af60-fb334f6cfdb7@github.com>

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

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

  Minor correction to javadoc

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/5fab46c1..5a031bda

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

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

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

From vromero at openjdk.org  Fri Feb 10 22:50:20 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 10 Feb 2023 22:50:20 GMT
Subject: RFR: 8207017: Type annotations on anonymous classes in initializer
 blocks not written to class file
Message-ID: <8oAI-F3E9-qQJtrSflKjYLHB08zHkGI_RlEFR3C7BsU=.8bb0ae4f-7ecb-4878-bf50-12ccfb556a02@github.com>

Javac is not writing type annotations applied to anonymous classes inside of instance or static initializers. Basically for code like:


import java.lang.annotation.*;

class X {

    @Retention(RetentionPolicy.RUNTIME)
    @Target(ElementType.TYPE_USE)
    public @interface TA {
        String value() default "empty";
    }

    {
        class Local {}
        new @TA("LocalInstanceInitializerAnnonymous") Local() {};
    }

    static {
        class Local {}
        new @TA("LocalStaticAnnonymous") Local() {};
    }
}

not type annotations are generated as attributes of methods <init> or <clinit>. This PR is fixing this issue. The annotations are currently generated if the anonymous class is declared inside an instance or static method. The issue is only with initializers,

TIA

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

Commit messages:
 - 8207017: Type annotations on anonymous classes in initializer blocks not written to class file

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

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

From duke at openjdk.org  Fri Feb 10 23:38:24 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Fri, 10 Feb 2023 23:38:24 GMT
Subject: RFR: 8027682: javac wrongly accepts semicolons in package and
 import decls [v6]
In-Reply-To: <bQN6VoWgHskZ_Wg9PgBhKWwUDYp5jlRGja_LkitHQY4=.1a7d2eec-a992-4cee-9eb0-68fe1821e276@github.com>
References: <bQN6VoWgHskZ_Wg9PgBhKWwUDYp5jlRGja_LkitHQY4=.1a7d2eec-a992-4cee-9eb0-68fe1821e276@github.com>
Message-ID: <XS02yk0As0lruxndUcAcACDwoYcTM80NPpWv3ZqV0dk=.465aeec4-7def-497b-9a4c-19c16dc3ec4b@github.com>

> JLS [?7.3](https://docs.oracle.com/javase/specs/jls/se19/html/jls-7.html#jls-7.3) specifies that while a lone semicolon is a valid _TopLevelClassOrInterfaceDeclaration_, it is not a valid _ImportDeclaration_. Therefore, if we see a lone semicolon while looking for the next import statement we have to advance and accept a class declaration, and we can therefore no longer accept any further `import` statements.
> 
> However, the compiler was allowing this, for example:
> 
> package p; import X; ;;; import Y; class Foo {}
> 
> The bug is that the parser was switching out of "look for imports" mode after parsing a valid class declaration, but it was not switching out of "look for imports" mode after parsing a lone semicolon.
> 
> The fix to `JavacParser.java` is easy, however it also requires these adjustments to unit tests:
> 
> * Test `tree/T6963934.java` must go away, because it is verifying a bug that only happens when the above bogus input is successfully parsed, and this can no longer happen.
> * A bug in `lib/types/TypeHarness.java` was uncovered and fixed; it was inserting an extra semicolon.
> * The following bugs, which check invalid syntax within import statements, now generate different parse errors and therefor needed their "golden output" updated:
>   * annotations/typeAnnotations/failures/AnnotatedImport.java
>   * annotations/typeAnnotations/failures/AnnotatedPackage1.java
>   * annotations/typeAnnotations/failures/AnnotatedPackage2.java

Archie L. Cobbs has updated the pull request incrementally with two additional commits since the last revision:

 - Add parser unit tests for extra import semicolon diagnostics.
 - Rename diagnostic example files for clarity.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12448/files
  - new: https://git.openjdk.org/jdk/pull/12448/files/979ed908..3ef2a6d7

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

  Stats: 22 lines in 5 files changed: 18 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/12448.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12448/head:pull/12448

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

From duke at openjdk.org  Fri Feb 10 23:38:28 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Fri, 10 Feb 2023 23:38:28 GMT
Subject: RFR: 8027682: javac wrongly accepts semicolons in package and
 import decls [v5]
In-Reply-To: <v_UNs81rrOt8UPxvAId5K1KV-k0PWNLFwoiGGn6sROo=.a2cbf1b3-5b76-4cba-8e57-b29bf346f7ff@github.com>
References: <bQN6VoWgHskZ_Wg9PgBhKWwUDYp5jlRGja_LkitHQY4=.1a7d2eec-a992-4cee-9eb0-68fe1821e276@github.com>
 <3lV4QNnSoikQ81CYC-F_dGk1LPOdEB_IRC4TUQn3BY8=.249af2b7-0ee3-4ca0-b616-d57acb47180d@github.com>
 <v_UNs81rrOt8UPxvAId5K1KV-k0PWNLFwoiGGn6sROo=.a2cbf1b3-5b76-4cba-8e57-b29bf346f7ff@github.com>
Message-ID: <9g02WXE60ykQnwDAjsDwrahWkB-_1ED_my1tNzP7YAI=.4a27640f-c883-40f2-bc96-1845df4375d1@github.com>

On Fri, 10 Feb 2023 16:41:36 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Generate warnings instead of errors for source levels < 21.
>>   
>>   This improves backward compatibility as requested in the CSR (JDK-8301905).
>
> test/langtools/tools/javac/diags/examples/ExtraneousSemiColonError.java line 29:
> 
>> 27: import java.util.Set;
>> 28: 
>> 29: class ExtraneousSemiColonError {
> 
> I think that we should have a dedicated test for the new feature, apart from the diagnostics oriented ones. The test could be executed twice once with option `-source 20` and once without it and provided two golden files accordingly.

Good idea - done. The regular unit tests are more precise.

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

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

From darcy at openjdk.org  Fri Feb 10 23:43:27 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 10 Feb 2023 23:43:27 GMT
Subject: RFR: 8027682: javac wrongly accepts semicolons in package and
 import decls [v6]
In-Reply-To: <XS02yk0As0lruxndUcAcACDwoYcTM80NPpWv3ZqV0dk=.465aeec4-7def-497b-9a4c-19c16dc3ec4b@github.com>
References: <bQN6VoWgHskZ_Wg9PgBhKWwUDYp5jlRGja_LkitHQY4=.1a7d2eec-a992-4cee-9eb0-68fe1821e276@github.com>
 <XS02yk0As0lruxndUcAcACDwoYcTM80NPpWv3ZqV0dk=.465aeec4-7def-497b-9a4c-19c16dc3ec4b@github.com>
Message-ID: <U5iPjUnTNZ38WtNbHPxZrJGDUu6LMgkjwcUuRcwhzqs=.9e65f724-b12e-4c5c-9ea7-b1dda7754721@github.com>

On Fri, 10 Feb 2023 23:38:24 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> JLS [?7.3](https://docs.oracle.com/javase/specs/jls/se19/html/jls-7.html#jls-7.3) specifies that while a lone semicolon is a valid _TopLevelClassOrInterfaceDeclaration_, it is not a valid _ImportDeclaration_. Therefore, if we see a lone semicolon while looking for the next import statement we have to advance and accept a class declaration, and we can therefore no longer accept any further `import` statements.
>> 
>> However, the compiler was allowing this, for example:
>> 
>> package p; import X; ;;; import Y; class Foo {}
>> 
>> The bug is that the parser was switching out of "look for imports" mode after parsing a valid class declaration, but it was not switching out of "look for imports" mode after parsing a lone semicolon.
>> 
>> The fix to `JavacParser.java` is easy, however it also requires these adjustments to unit tests:
>> 
>> * Test `tree/T6963934.java` must go away, because it is verifying a bug that only happens when the above bogus input is successfully parsed, and this can no longer happen.
>> * A bug in `lib/types/TypeHarness.java` was uncovered and fixed; it was inserting an extra semicolon.
>> * The following bugs, which check invalid syntax within import statements, now generate different parse errors and therefor needed their "golden output" updated:
>>   * annotations/typeAnnotations/failures/AnnotatedImport.java
>>   * annotations/typeAnnotations/failures/AnnotatedPackage1.java
>>   * annotations/typeAnnotations/failures/AnnotatedPackage2.java
>
> Archie L. Cobbs has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add parser unit tests for extra import semicolon diagnostics.
>  - Rename diagnostic example files for clarity.

test/langtools/tools/javac/diags/examples/ExtraImportSemicolonWarning.java line 26:

> 24: // key: compiler.warn.extraneous.semicolon
> 25: // key: compiler.warn.source.no.system.modules.path
> 26: // options: --source 20

Please use "--release 20" instead if possible.

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

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

From jlaskey at openjdk.org  Sat Feb 11 00:27:33 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Sat, 11 Feb 2023 00:27:33 GMT
Subject: Integrated: JDK-8296322 javac: use methods to manage parser mode flags
In-Reply-To: <ODFF2ZvoTnzinMhSyLSQhmooIdRCAeZZaIb5-CorxRY=.92702ced-aacc-4362-8815-28d54747b991@github.com>
References: <ODFF2ZvoTnzinMhSyLSQhmooIdRCAeZZaIb5-CorxRY=.92702ced-aacc-4362-8815-28d54747b991@github.com>
Message-ID: <hlWze3y3vf-B9LGM3IOF3zSM3z9oa9xb4LbqVTWK7yU=.484260ed-c4e0-4397-bef1-4c2f9e18da18@github.com>

On Fri, 4 Nov 2022 12:33:44 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> Manage parser mode flags using methods for easy of reading and maintenance.

This pull request has now been integrated.

Changeset: 98e98e90
Author:    Jim Laskey <jlaskey at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/98e98e9049be3a93ddf82d5d4d3044e0f1e4a640
Stats:     84 lines in 1 file changed: 17 ins; 0 del; 67 mod

8296322: javac: use methods to manage parser mode flags

Reviewed-by: mcimadamore

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

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

From duke at openjdk.org  Sat Feb 11 01:35:11 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Sat, 11 Feb 2023 01:35:11 GMT
Subject: RFR: 8027682: javac wrongly accepts semicolons in package and
 import decls [v7]
In-Reply-To: <bQN6VoWgHskZ_Wg9PgBhKWwUDYp5jlRGja_LkitHQY4=.1a7d2eec-a992-4cee-9eb0-68fe1821e276@github.com>
References: <bQN6VoWgHskZ_Wg9PgBhKWwUDYp5jlRGja_LkitHQY4=.1a7d2eec-a992-4cee-9eb0-68fe1821e276@github.com>
Message-ID: <EJcTXMxHgmSc2VCuKzSBXaldAgx8_tw_DrtpkXCk60w=.25054023-78ab-4a2b-9268-0c508ac1c143@github.com>

> JLS [?7.3](https://docs.oracle.com/javase/specs/jls/se19/html/jls-7.html#jls-7.3) specifies that while a lone semicolon is a valid _TopLevelClassOrInterfaceDeclaration_, it is not a valid _ImportDeclaration_. Therefore, if we see a lone semicolon while looking for the next import statement we have to advance and accept a class declaration, and we can therefore no longer accept any further `import` statements.
> 
> However, the compiler was allowing this, for example:
> 
> package p; import X; ;;; import Y; class Foo {}
> 
> The bug is that the parser was switching out of "look for imports" mode after parsing a valid class declaration, but it was not switching out of "look for imports" mode after parsing a lone semicolon.
> 
> The fix to `JavacParser.java` is easy, however it also requires these adjustments to unit tests:
> 
> * Test `tree/T6963934.java` must go away, because it is verifying a bug that only happens when the above bogus input is successfully parsed, and this can no longer happen.
> * A bug in `lib/types/TypeHarness.java` was uncovered and fixed; it was inserting an extra semicolon.
> * The following bugs, which check invalid syntax within import statements, now generate different parse errors and therefor needed their "golden output" updated:
>   * annotations/typeAnnotations/failures/AnnotatedImport.java
>   * annotations/typeAnnotations/failures/AnnotatedPackage1.java
>   * annotations/typeAnnotations/failures/AnnotatedPackage2.java

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

  Use --release instead of --source for unit tests.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12448/files
  - new: https://git.openjdk.org/jdk/pull/12448/files/3ef2a6d7..90671632

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

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

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

From duke at openjdk.org  Sat Feb 11 01:35:14 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Sat, 11 Feb 2023 01:35:14 GMT
Subject: RFR: 8027682: javac wrongly accepts semicolons in package and
 import decls [v6]
In-Reply-To: <U5iPjUnTNZ38WtNbHPxZrJGDUu6LMgkjwcUuRcwhzqs=.9e65f724-b12e-4c5c-9ea7-b1dda7754721@github.com>
References: <bQN6VoWgHskZ_Wg9PgBhKWwUDYp5jlRGja_LkitHQY4=.1a7d2eec-a992-4cee-9eb0-68fe1821e276@github.com>
 <XS02yk0As0lruxndUcAcACDwoYcTM80NPpWv3ZqV0dk=.465aeec4-7def-497b-9a4c-19c16dc3ec4b@github.com>
 <U5iPjUnTNZ38WtNbHPxZrJGDUu6LMgkjwcUuRcwhzqs=.9e65f724-b12e-4c5c-9ea7-b1dda7754721@github.com>
Message-ID: <supWYl1bdtPXB_50cMIrP7kUeVdHv8VCHOdWrS2DoLc=.ef9b4c33-d243-45b2-b427-be1018a0ff57@github.com>

On Fri, 10 Feb 2023 23:40:42 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Please use "--release 20" instead if possible.

Thanks - that works better.

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

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

From vromero at openjdk.org  Sat Feb 11 14:08:00 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Sat, 11 Feb 2023 14:08:00 GMT
Subject: RFR: 8208470: Type annotations on inner type that is an array
 component
Message-ID: <yLW354ZGwsnY12JSiQIPftjJIFo6F_wwNzkqX1JsCVM=.fe77d59c-2f3f-4ec5-9dad-0c8a9a235588@github.com>

As stated in the bug great description by Werner D.:

Considering this example:

import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;

@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.TYPE_USE, ElementType.TYPE_PARAMETER})
@interface TA {
  int value();
}

class ArrayOfInner {
  class Inner {}

  @TA(1) ArrayOfInner. @TA(2) Inner oi;
  @TA(3) ArrayOfInner. @TA(4) Inner [] oia;
  @TA(5) Inner i;
  @TA(6) Inner [] ia;
}

If compiled with javac 8, according to javap -v field ia has the annotation:

  ArrayOfInner$Inner[] ia;
    descriptor: [LArrayOfInner$Inner;
    flags: (0x0000)
    RuntimeVisibleTypeAnnotations:
      0: #10(#11=I#21): FIELD, location=[ARRAY, INNER_TYPE]
        TA(
          value=6
        )

if compiled with javac > 8 ia has the annotation:

  ArrayOfInner$Inner[] ia;
    descriptor: [LArrayOfInner$Inner;
    flags: (0x0000)
    RuntimeVisibleTypeAnnotations:
      0: #10(#11=I#21): FIELD, location=[ARRAY]
        TA(
          value=6
        )

Note the missing `INNER_TYPE` location. This PR is re-establishing the Java 8 behavior.

TIA

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

Commit messages:
 - 8208470: Type annotations on inner type that is an array component

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

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

From jlaskey at openjdk.org  Sat Feb 11 17:49:49 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Sat, 11 Feb 2023 17:49:49 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v40]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <rQog4uNSJmI3BjY7WzAKDkZPttL5RWlJDPPcKwec9aE=.3d2799ca-a8d2-4401-9b05-e6560da18cac@github.com>

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

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

 - Merge branch 'master' into 8285932
 - Minor correction to javadoc
 - Merge branch 'master' into 8285932
 - CSR review
 - Bring up to date
 - Merge branch 'master' into 8285932
 - Update to JDK 21
 - Merge branch 'master' into 8285932
 - Merge branch 'master' into 8285932
 - FormatProcessor changes
 - ... and 45 more: https://git.openjdk.org/jdk/compare/6f9f2b5d...95d219af

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

Changes: https://git.openjdk.org/jdk/pull/10889/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=39
  Stats: 9492 lines in 81 files changed: 9394 ins; 28 del; 70 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10889/head:pull/10889

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

From vromero at openjdk.org  Sat Feb 11 23:01:38 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Sat, 11 Feb 2023 23:01:38 GMT
Subject: RFR: 8208470: Type annotations on inner type that is an array
 component [v2]
In-Reply-To: <yLW354ZGwsnY12JSiQIPftjJIFo6F_wwNzkqX1JsCVM=.fe77d59c-2f3f-4ec5-9dad-0c8a9a235588@github.com>
References: <yLW354ZGwsnY12JSiQIPftjJIFo6F_wwNzkqX1JsCVM=.fe77d59c-2f3f-4ec5-9dad-0c8a9a235588@github.com>
Message-ID: <_G5oNn_Phfoi1L838O6IcuBbairwjA338wF7TojcVLg=.723e98b6-4438-4770-84dd-2c9a3f46538c@github.com>

> As stated in the bug great description by Werner D.:
> 
> Considering this example:
> 
> import java.lang.annotation.ElementType;
> import java.lang.annotation.Retention;
> import java.lang.annotation.RetentionPolicy;
> import java.lang.annotation.Target;
> 
> @Retention(RetentionPolicy.RUNTIME)
> @Target({ElementType.TYPE_USE, ElementType.TYPE_PARAMETER})
> @interface TA {
>   int value();
> }
> 
> class ArrayOfInner {
>   class Inner {}
> 
>   @TA(1) ArrayOfInner. @TA(2) Inner oi;
>   @TA(3) ArrayOfInner. @TA(4) Inner [] oia;
>   @TA(5) Inner i;
>   @TA(6) Inner [] ia;
> }
> 
> If compiled with javac 8, according to javap -v field ia has the annotation:
> 
>   ArrayOfInner$Inner[] ia;
>     descriptor: [LArrayOfInner$Inner;
>     flags: (0x0000)
>     RuntimeVisibleTypeAnnotations:
>       0: #10(#11=I#21): FIELD, location=[ARRAY, INNER_TYPE]
>         TA(
>           value=6
>         )
> 
> if compiled with javac > 8 ia has the annotation:
> 
>   ArrayOfInner$Inner[] ia;
>     descriptor: [LArrayOfInner$Inner;
>     flags: (0x0000)
>     RuntimeVisibleTypeAnnotations:
>       0: #10(#11=I#21): FIELD, location=[ARRAY]
>         TA(
>           value=6
>         )
> 
> Note the missing `INNER_TYPE` location. This PR is re-establishing the Java 8 behavior.
> 
> TIA

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

  adding bug number to regression test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12522/files
  - new: https://git.openjdk.org/jdk/pull/12522/files/91bef728..8cf99672

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

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

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

From vromero at openjdk.org  Sun Feb 12 03:59:05 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Sun, 12 Feb 2023 03:59:05 GMT
Subject: RFR: 8301374: NullPointerException in MemberEnter.checkReceiver
Message-ID: <A3AquAfyff2vjvd57yhJSjGVG_hhsJd9FLgdN7ldK_c=.b27034f0-ea10-424e-b38e-0ecaa2af40d9@github.com>

the following incorrect code is crashing javac:

public class X {
  interface F {
    void apply(E e);
  }
  enum E {
    ONE
  }

  F f = (E.ONE) -> {};   // E.ONE?
}

there are several issues the incorrect argument to this lambda expression. The proposed solution is to issue a syntax error for the missing parameter name. IMO, this error message would be correct here and this way the compiler fails fast instead of having to deal with an erroneous lambda later on to avoid a crash like the one we have now,

TIA

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

Commit messages:
 - 8301374: NullPointerException in MemberEnter.checkReceiver

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

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

From archie.cobbs at gmail.com  Mon Feb 13 18:28:52 2023
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Mon, 13 Feb 2023 12:28:52 -0600
Subject: Uncertainty about fix for JDK-5059679
Message-ID: <CANSoFxvP9jbu--DCr0C6SrYpSE=YCoH1uj6aRm1MV1f209Kg+Q@mail.gmail.com>

I've got a PR submitted <https://github.com/openjdk/jdk/pull/12503> to fix
JDK-5059679 but I'm having second thoughts and would appreciate some advice
from the spec experts on the list.

The bug essentially asks whether a program like this should compile
(currently, it does):

public class NarrowingNameClash2 {

    public abstract class Upper<T> {
        abstract void method(T param);
    }

    public abstract class Lower<R> extends Upper<Class<R>> {
        abstract void method(Class<?> param);   // name clash here???
    }
}

?8.4.8.3 "Requirements in Overriding and Hiding" says:

It is a compile-time error if a class or interface C has a member method m1
and there exists a method m2 declared in C or a superclass or
superinterface of C, A, such that all of the following are true:

   - m1 and m2 have the same name.
   - m2 is accessible (?6.6) from C.
   - The signature of m1 is not a subsignature (?8.4.2) of the signature of
   m2 as a member of the supertype of C that names A.
   - The declared signature of m1 or some method m1 overrides (directly or
   indirectly) has the same erasure as the declared signature of m2 or some
   method m2 overrides (directly or indirectly).

OK so in this case let:

   - C = A = Lower
   - m1 = Lower.method(Class<R>)
   - m2 = Lower.method(Class<?>)

Note that m1 is a member of C by virtue of ?8.2
<https://docs.oracle.com/javase/specs/jls/se19/html/jls-8.html#jls-8.2>
which states "The members of a class are... members inherited from its
direct superclass type (?8.1.4)".

Side note/question: Presumably when Upper.method(T) is inherited by Lower,
its type changes from void method(T) to void method(Class<R>) - correct? Is
this actually stated anywhere?

The first two criteria are easy:

   - m1 and m2 have the same name ?
   - m2 is accessible (?6.6) from C ?

Third criterion:

   - The signature of m1 is not a subsignature (?8.4.2) of the signature of
   m2 as a member of the supertype of C that names A.

For the signature of m1 to be a subsignature of the signature of m2, it
would have to equal the erasure of the signature of m2 as a member of C,
which would be void (Class). But the signature of m1 is void
method(Class<R>). So criterion #3 is met. ?

Fourth criterion:

   - The declared signature of m1 or some method m1 overrides (directly or
   indirectly) has the same erasure as the declared signature of m2 or some
   method m2 overrides (directly or indirectly).

Both methods erase to void method(Class). ?

OK so far so good (I think) and the above program should NOT compile and
therefore there is a bug.

Now consider the same thing except using interfaces:

public class NarrowingNameClash {

    public interface Upper<T> {
        void method(T param);
    }

    public interface Lower<R> extends Upper<Class<R>> {
        void method(Class<?> param);        // name clash here?
    }
}

According to my reading, interfaces do NOT inherit methods from
superinterfaces. So the above analysis fails, because the only candidates
would be m1 = Lower.method(Class<?>) and m2 = Upper.method(T), and those
don't erase to the same type.

So the second class using interfaces SHOULD compile successfully.

Does the above analysis sound correct?

Thanks,
-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230213/834c3538/attachment-0001.htm>

From alex.buckley at oracle.com  Mon Feb 13 21:15:49 2023
From: alex.buckley at oracle.com (Alex Buckley)
Date: Mon, 13 Feb 2023 13:15:49 -0800
Subject: Uncertainty about fix for JDK-5059679
In-Reply-To: <CANSoFxvP9jbu--DCr0C6SrYpSE=YCoH1uj6aRm1MV1f209Kg+Q@mail.gmail.com>
References: <CANSoFxvP9jbu--DCr0C6SrYpSE=YCoH1uj6aRm1MV1f209Kg+Q@mail.gmail.com>
Message-ID: <62c21e70-a41f-f96d-38de-092233b08805@oracle.com>

On 2/13/2023 10:28 AM, Archie Cobbs wrote:
> public class NarrowingNameClash2 {
> 
>  ? ? public abstract class Upper<T> {
>  ? ? ? ? abstract void method(T param);
>  ? ? }
> 
>  ? ? public abstract class Lower<R> extends Upper<Class<R>> {
>  ? ? ? ? abstract void method(Class<?> param); ? // name clash here???
>  ? ? }
> }

The core of all this is that method(Class<?>) in Lower<R> is not a 
subsignature of method(Class<R>) in Upper<Class<R>>.

This means that Lower<R> inherits method(Class<R>) from its direct 
superclass type Upper<Class<R>>. (See 8.4.8)

It's dangerous for Lower<R> to have method(Class<R>) and 
method(Class<?>) at the same time.

8.4.8.3 detects the problem.

The simple way to apply 8.4.8.3 is to set C = Lower and A = Upper, so 
that m1 = method(Class<?>) and m2 = method(Class<R>).

As you say, a compile-time error is due.

 > Side note/question: Presumably when Upper.method(T) is inherited by
 > Lower, its type changes from void method(T) to void method(Class<R>) -
 > correct? Is this actually stated anywhere?

8.2 says:

   The members of a class are all of the following:
     - Members inherited from its direct superclass type (?8.1.4) ...

The terminology of "class" versus "direct superclass type" is precise 
and deliberate. The members of the (generic) class Lower<R> include the 
members inherited from the direct superclass type of Lower<R>, which is 
Upper<Class<R>>. To be clear: Lower<R> is a (generic) class, 
Upper<Class<R>> is a (parameterized) type. The members inherited from 
Upper<Class<R>> will have R in their own signatures, not T.

If you added a flag to make javac enumerate the members of every generic 
class and every parameterized type seen in the program, it would be very 
useful.

> Now consider the same thing except using interfaces:
> 
> public class NarrowingNameClash {
> 
>  ? ? public interface Upper<T> {
>  ? ? ? ? void method(T param);
>  ? ? }
> 
>  ? ? public interface Lower<R> extends Upper<Class<R>> {
>  ? ? ? ? void method(Class<?> param); ? ? ? ?// name clash here?
>  ? ? }
> }
> 
> According to my reading, interfaces do NOT inherit methods from 
> superinterfaces. 

You might be thinking about the private methods and static methods of an 
interface, which are indeed not inherited by a subinterface. Abstract 
methods in an interface have always been inherited by a subinterface 
(see 9.1.3), unless of course they are overridden (see 9.2).

The interface Lower<R> inherits method(Class<R>) from its direct 
superinterface type Upper<Class<R>>. (See 9.4.1)

No overriding occurs in 9.4.1.1, so 9.4.1.2 has no requirements.

It's OK for Lower<R> to have method(Class<R>) and method(Class<?>) at 
the same time. 9.4.2 describes the situation. The methods are not 
override-equivalent. No compile-time error is due.

A class can implement Lower<SomeType> by declaring a concrete method 
`public void method(Class p)`. Whether an interface should allow more 
overloading of members than a class is a design discussion that I do not 
propose to revisit today.

Alex

From archie.cobbs at gmail.com  Mon Feb 13 22:56:47 2023
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Mon, 13 Feb 2023 16:56:47 -0600
Subject: Uncertainty about fix for JDK-5059679
In-Reply-To: <62c21e70-a41f-f96d-38de-092233b08805@oracle.com>
References: <CANSoFxvP9jbu--DCr0C6SrYpSE=YCoH1uj6aRm1MV1f209Kg+Q@mail.gmail.com>
 <62c21e70-a41f-f96d-38de-092233b08805@oracle.com>
Message-ID: <CANSoFxvymNhkTnQKFABPJeuSzz4bCh3mEeTmyib-sH4-ZRz86A@mail.gmail.com>

Hi Alex,

Thanks for the detailed answer. I'm still digesting it but first one quick
question:

On Mon, Feb 13, 2023 at 3:16 PM Alex Buckley <alex.buckley at oracle.com>
wrote:

> The simple way to apply 8.4.8.3 is to set C = Lower and A = Upper, so
> that m1 = method(Class<?>) and m2 = method(Class<R>).
>

That's what I thought at first, but I got hung up on this logic...

In that scenario, m2 is "a method m2 declared in a superinterface of C, A".
Then criterion 4 refers to "the same erasure as the declared signature of
m2".

Wouldn't then the declared signature of m2 be method(T)?

I can't find the definition of "declared signature" but I was thinking it's
the signature of the method's declaration... ? I guess my intuition is
wrong.

Thanks,
-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230213/bc6a464e/attachment.htm>

From daniel.smith at oracle.com  Tue Feb 14 01:06:00 2023
From: daniel.smith at oracle.com (Dan Smith)
Date: Tue, 14 Feb 2023 01:06:00 +0000
Subject: Uncertainty about fix for JDK-5059679
In-Reply-To: <CANSoFxvP9jbu--DCr0C6SrYpSE=YCoH1uj6aRm1MV1f209Kg+Q@mail.gmail.com>
References: <CANSoFxvP9jbu--DCr0C6SrYpSE=YCoH1uj6aRm1MV1f209Kg+Q@mail.gmail.com>
Message-ID: <D6A4B805-E2A3-4F87-BF09-FEF6AF0263AA@oracle.com>

On Feb 13, 2023, at 10:28 AM, Archie Cobbs <archie.cobbs at gmail.com> wrote:

  *   The signature of m1 is not a subsignature (?8.4.2) of the signature of m2 as a member of the supertype of C that names A.
  *   The declared signature of m1 or some method m1 overrides (directly or indirectly) has the same erasure as the declared signature of m2 or some method m2 overrides (directly or indirectly).

Note the distinction in these rules between

"signature of m2 as a member of the supertype of C that names A" (third rule)

and

"declared signature of m2" (fourth rule)

I would interpret the first to mean the signature '(Class<R>)->void', and the second to mean the signature '(T)->void'. Since the erasure of 'T' is 'Object', the fourth rule doesn't apply, and there's no error.

JLS isn't always clear about which of these two signatures it's talking about, but in this case, given the use of different phrases in the third and fourth rules, and the fact of javac's longstanding behavior, I think that's the intent.

(It makes sense, too, because the underlying problem is that you don't want the descriptors to clash in the class file. And they don't, because one has descriptor '(Object)V' and the other is '(Class)V'. Eventually, somebody might try to override something and need a bridge method that *would* clash, but in that case there would be another method for which this error check should apply.)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230214/6e6b1ce4/attachment-0001.htm>

From alex.buckley at oracle.com  Tue Feb 14 02:07:16 2023
From: alex.buckley at oracle.com (Alex Buckley)
Date: Mon, 13 Feb 2023 18:07:16 -0800
Subject: Uncertainty about fix for JDK-5059679
In-Reply-To: <D6A4B805-E2A3-4F87-BF09-FEF6AF0263AA@oracle.com>
References: <CANSoFxvP9jbu--DCr0C6SrYpSE=YCoH1uj6aRm1MV1f209Kg+Q@mail.gmail.com>
 <D6A4B805-E2A3-4F87-BF09-FEF6AF0263AA@oracle.com>
Message-ID: <f28520d5-8afa-4101-7910-9502d9c21402@oracle.com>

On 2/13/2023 5:06 PM, Dan Smith wrote:
>> On Feb 13, 2023, at 10:28 AM, Archie Cobbs <archie.cobbs at gmail.com> wrote:
>>
>>   * The signature of m1 is not a subsignature (?8.4.2) of the
>>     signature of m2 as a member of the supertype of C that names A.
>>   * The declared signature of m1 or some method m1 overrides (directly
>>     or indirectly) has the same erasure as the declared signature of
>>     m2 or some method m2 overrides (directly or indirectly).
>>
> Note the distinction in these rules between
> 
> "signature of m2 as a member of the supertype of C that names A" (third 
> rule)
> 
> and
> 
> "declared signature of m2" (fourth rule)
> 
> I would interpret the first to mean the signature '(Class<R>)->void', 
> and the second to mean the signature '(T)->void'. Since the erasure of 
> 'T' is 'Object', the fourth rule doesn't apply, and there's no error.

Right, I was headed in this direction too -- the choice of language in 
the different bullets was intended to be significant. I'm happy to agree 
that, after all, no compile-time error is due.


It's something of a surprise that Lower<R> can inherit method(Class<R>) 
_and_ declare method(Class<?>), given that declaring both methods in the 
same class is off-limits. You can even invoke them distinctly.

[ Make both abstract methods concrete; make Upper's method print 1; make 
Lower's method print 2; then add this:

   public static void main(String[] args) {
     Lower<String> a = new Lower<String>();

     Class<String> x = String.class;
     a.method(x);  // prints 1 -- invokevirtual Lower.method(Object)

     Class<?> y = String.class;
     a.method(y);  // prints 2 -- invokevirtual Lower.method(Class)
   }
]

We need to revisit Example 8.4.8.3-4. Erasure Affects Overriding to see 
if it adequately explains the scenario of methods that are different 
enough to not-override, but similar enough to erase (and thus illegal). 
More generally, there is a patchwork of examples -- in 8.4.2, and 
8.4.8.3-4, and 15.12.4.5-1, and now from Archie -- and there is common 
knowledge about erased class file contents, but there is no systematic 
explanation to connect it all up.

Alex

From duke at openjdk.org  Tue Feb 14 03:59:51 2023
From: duke at openjdk.org (SUN Guoyun)
Date: Tue, 14 Feb 2023 03:59:51 GMT
Subject: RFR: 8292647: javac/lambda/T8031967.java fails with
 StackOverflowError when use -XX:TieredStopAtLevel=3 on aarch64 and LoongArch
 [v3]
In-Reply-To: <z639fAXA8bpE1ZETMJpJW0kETKOu_CcPU8MSGA2Q9Fs=.44a4ea2a-b533-478f-a36c-c18b3040bba2@github.com>
References: <8Wo5jMV1FDBTdaz0O8PRwmSMUEqzQeLckldsJybpceg=.01580f6c-3290-4276-8d36-8e408035982c@github.com>
 <z639fAXA8bpE1ZETMJpJW0kETKOu_CcPU8MSGA2Q9Fs=.44a4ea2a-b533-478f-a36c-c18b3040bba2@github.com>
Message-ID: <usyiNE3RCkj-qo2UExR9JloZXqFrEiTklnXL_zTS300=.ba5e1b50-8af9-4277-b61e-3fe368e31f07@github.com>

On Wed, 8 Feb 2023 09:21:30 GMT, SUN Guoyun <duke at openjdk.org> wrote:

>> make images run-test TEST=tools/javac/lambda/T8031967.java will fails with StackOverflowError when I use args JTREG="VM_OPTIONS=-XX:TieredStopAtLevel=3" on aarch64 and LoongArch. So the stack size `-Xss10m` needs to be increased to improve the robustness of the testcase.
>
> SUN Guoyun 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 'openjdk:master' into 8292647
>  - 8292647: javac/lambda/T8031967.java fails with StackOverflowError when use -XX:TieredStopAtLevel=3 on aarch64 and LoongArch
>  - 8292647: javac/lambda/T8031967.java fails with StackOverflowError when use -XX:TieredStopAtLevel=3 on aarch64 and LoongArch

After https://github.com/openjdk/jdk/pull/12548, this test can be passed.

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

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

From jlahoda at openjdk.org  Tue Feb 14 14:17:52 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 14 Feb 2023 14:17:52 GMT
Subject: RFR: 8207017: Type annotations on anonymous classes in initializer
 blocks not written to class file
In-Reply-To: <8oAI-F3E9-qQJtrSflKjYLHB08zHkGI_RlEFR3C7BsU=.8bb0ae4f-7ecb-4878-bf50-12ccfb556a02@github.com>
References: <8oAI-F3E9-qQJtrSflKjYLHB08zHkGI_RlEFR3C7BsU=.8bb0ae4f-7ecb-4878-bf50-12ccfb556a02@github.com>
Message-ID: <Cp_01IlZGFU2gyEzog-5f70_qO2VI6Tw5251jBSSMLA=.36cc9ced-f25b-4acf-ab84-fe14eafe78d3@github.com>

On Fri, 10 Feb 2023 22:43:41 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Javac is not writing type annotations applied to anonymous classes inside of instance or static initializers. Basically for code like:
> 
> 
> import java.lang.annotation.*;
> 
> class X {
> 
>     @Retention(RetentionPolicy.RUNTIME)
>     @Target(ElementType.TYPE_USE)
>     public @interface TA {
>         String value() default "empty";
>     }
> 
>     {
>         class Local {}
>         new @TA("LocalInstanceInitializerAnnonymous") Local() {};
>     }
> 
>     static {
>         class Local {}
>         new @TA("LocalStaticAnnonymous") Local() {};
>     }
> }
> 
> not type annotations are generated as attributes of methods <init> or <clinit>. This PR is fixing this issue. The annotations are currently generated if the anonymous class is declared inside an instance or static method. The issue is only with initializers,
> 
> TIA

Seems sensible.

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

Marked as reviewed by jlahoda (Reviewer).

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

From vromero at openjdk.org  Tue Feb 14 14:31:03 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 14 Feb 2023 14:31:03 GMT
Subject: Integrated: 8207017: Type annotations on anonymous classes in
 initializer blocks not written to class file
In-Reply-To: <8oAI-F3E9-qQJtrSflKjYLHB08zHkGI_RlEFR3C7BsU=.8bb0ae4f-7ecb-4878-bf50-12ccfb556a02@github.com>
References: <8oAI-F3E9-qQJtrSflKjYLHB08zHkGI_RlEFR3C7BsU=.8bb0ae4f-7ecb-4878-bf50-12ccfb556a02@github.com>
Message-ID: <kwI7hseEWTl0E4Ud595L6NBlV5p_fVPiV4oixGCgC0s=.996753bc-26f4-49e5-b210-a44b8aa4a8f3@github.com>

On Fri, 10 Feb 2023 22:43:41 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Javac is not writing type annotations applied to anonymous classes inside of instance or static initializers. Basically for code like:
> 
> 
> import java.lang.annotation.*;
> 
> class X {
> 
>     @Retention(RetentionPolicy.RUNTIME)
>     @Target(ElementType.TYPE_USE)
>     public @interface TA {
>         String value() default "empty";
>     }
> 
>     {
>         class Local {}
>         new @TA("LocalInstanceInitializerAnnonymous") Local() {};
>     }
> 
>     static {
>         class Local {}
>         new @TA("LocalStaticAnnonymous") Local() {};
>     }
> }
> 
> not type annotations are generated as attributes of methods <init> or <clinit>. This PR is fixing this issue. The annotations are currently generated if the anonymous class is declared inside an instance or static method. The issue is only with initializers,
> 
> TIA

This pull request has now been integrated.

Changeset: 2ef001e0
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2ef001e09774fd0cce7a6bd917dd46033cf4c4d9
Stats:     29 lines in 2 files changed: 26 ins; 1 del; 2 mod

8207017: Type annotations on anonymous classes in initializer blocks not written to class file

Reviewed-by: jlahoda

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

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

From archie.cobbs at gmail.com  Tue Feb 14 15:53:01 2023
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Tue, 14 Feb 2023 09:53:01 -0600
Subject: Uncertainty about fix for JDK-5059679
In-Reply-To: <f28520d5-8afa-4101-7910-9502d9c21402@oracle.com>
References: <CANSoFxvP9jbu--DCr0C6SrYpSE=YCoH1uj6aRm1MV1f209Kg+Q@mail.gmail.com>
 <D6A4B805-E2A3-4F87-BF09-FEF6AF0263AA@oracle.com>
 <f28520d5-8afa-4101-7910-9502d9c21402@oracle.com>
Message-ID: <CANSoFxvJOSznceKx2jqS0PciSs5NR8LDCMKua-baqQ52jTfUCw@mail.gmail.com>

On Mon, Feb 13, 2023 at 8:07 PM Alex Buckley <alex.buckley at oracle.com>
wrote:

> On 2/13/2023 5:06 PM, Dan Smith wrote:
> >>   * The signature of m1 is not a subsignature (?8.4.2) of the
> >>     signature of m2 as a member of the supertype of C that names A.
> >>   * The declared signature of m1 or some method m1 overrides (directly
> >>     or indirectly) has the same erasure as the declared signature of
> >>     m2 or some method m2 overrides (directly or indirectly).
> >>
> > Note the distinction in these rules between "signature of m2 as a member
> of the
> > supertype of C that names A" (third rule) and "declared signature of m2"
> (fourth rule)
> >
> > I would interpret the first to mean the signature '(Class<R>)->void',
> > and the second to mean the signature '(T)->void'. Since the erasure of
> > 'T' is 'Object', the fourth rule doesn't apply, and there's no error.
>
> Right, I was headed in this direction too -- the choice of language in
> the different bullets was intended to be significant. I'm happy to agree
> that, after all, no compile-time error is due.
>

Thanks to you both for helping clarify this. I'll retract my PR and resolve
this issue as "Not a Bug".

-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230214/a6e1c35f/attachment.htm>

From jlahoda at openjdk.org  Tue Feb 14 16:04:13 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 14 Feb 2023 16:04:13 GMT
Subject: RFR: 8301374: NullPointerException in MemberEnter.checkReceiver
In-Reply-To: <A3AquAfyff2vjvd57yhJSjGVG_hhsJd9FLgdN7ldK_c=.b27034f0-ea10-424e-b38e-0ecaa2af40d9@github.com>
References: <A3AquAfyff2vjvd57yhJSjGVG_hhsJd9FLgdN7ldK_c=.b27034f0-ea10-424e-b38e-0ecaa2af40d9@github.com>
Message-ID: <UJDqvPO-DZfOHj2kP-C29uJAZLIUTikPNTxpM6LSJpU=.29776cc4-4009-4e91-b592-427a0cdc24fc@github.com>

On Sun, 12 Feb 2023 03:53:02 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> the following incorrect code is crashing javac:
> 
> public class X {
>   interface F {
>     void apply(E e);
>   }
>   enum E {
>     ONE
>   }
> 
>   F f = (E.ONE) -> {};   // E.ONE?
> }
> 
> there are several issues the incorrect argument to this lambda expression. The proposed solution is to issue a syntax error for the missing parameter name. IMO, this error message would be correct here and this way the compiler fails fast instead of having to deal with an erroneous lambda later on to avoid a crash like the one we have now,
> 
> TIA

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

> 3724:                 if (pn.hasTag(Tag.IDENT) && ((JCIdent)pn).name != names._this) {
> 3725:                     name = ((JCIdent)pn).name;
> 3726:                 } else if (lambdaParameter) {

I wonder if we could help the error recovery a little bit more, like e.g.:

                } else if (lambdaParameter && type == null) {
                    // we have a lambda parameter that is not an identifier this is a syntax error
                    type = pn;
                    name = names.empty;
                    reportSyntaxError(pos, Errors.Expected(IDENTIFIER));
                } else {


Which would keep the parsed thing as a type for the lambda parameter?

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

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

From duke at openjdk.org  Tue Feb 14 16:06:26 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Tue, 14 Feb 2023 16:06:26 GMT
Subject: RFR: 5059679: name clash not reported for interface inheritance
In-Reply-To: <8BPz14cNrwLKfIHO77rNKeIgFacHtkC-aCbqCkN1tA0=.97031bcd-6f2d-4276-98c5-e0cbe6d79985@github.com>
References: <8BPz14cNrwLKfIHO77rNKeIgFacHtkC-aCbqCkN1tA0=.97031bcd-6f2d-4276-98c5-e0cbe6d79985@github.com>
Message-ID: <d_qHdqkVdOiwJBX41Xq95V_aNT-Srxpy_AosJhyeGwU=.52a65d87-2cd7-4339-93c1-b5761ea18e04@github.com>

On Thu, 9 Feb 2023 21:01:10 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

> Consider this input:
> 
> public class NarrowingNameClash {
> 
>     public interface Upper<T> {
>         void method(T param);
>     }
> 
>     public interface Lower<R> extends Upper<Class<R>> {
>         void method(Class<?> param);        // erasure name clash here
>     }
> }
> 
> This violates ?8.4.8.3 because `method(Class<R>)` and `method(Class<?>)` have the same erasure. However, the compiler is not reporting an error in this case.
> 
> Here's my understanding of the bug... (reviewer please double-check this :)
> 
> ?8.4.8.3 "Requirements in Overriding and Hiding" says:
> 
> It is a compile-time error if a class or interface C has a member method m1 and there exists a method m2 declared in C or a superclass or superinterface of C, A, such that all of the following are true:
> 
> * m1 and m2 have the same name.
> * m2 is accessible (?6.6) from C.
> * The signature of m1 is not a subsignature (?8.4.2) of the signature of m2 as a member of the supertype of C that names A.
> * The declared signature of m1 or some method m1 overrides (directly or indirectly) has the same erasure as the declared signature of m2 or some method m2 overrides (directly or indirectly).
> 
> Method `method(Class<R>)` is inherited by `Lower` from `Upper` and is therefore a member of `Lower`. Note that upon inheritance its parameter `T` is reinterpreted as `Class<R>` in the context of `Lower`'s generic parameterization.
> 
> Let C = `Lower`, A = `Upper`, m1 = `method(Class<R>)` and m2 = `method(Class<?>)`.
> 
> The compiler is comparing the erasures of `method(T)`, which is "some method m1 overrides", and m2 = `method(Class<?>)`, and these are different, so no bug is reported.
> 
> That comparison is appropriate, however, what it also needs to do is compare the erasures of m1 and m2, which are both `method(Class)`.
> 
> In a nutshell: within the context of `Lower`, the method `method(Class<R>)` inherited from `Upper`, when erased, has a different signature from its original form `method(T)` in `Upper`, when erased. The possibility of this different form was not being taken into account in the compiler.

It has been determined that this bug is "Not an Issue". See [discussion thread on compiler-dev](https://mail.openjdk.org/pipermail/compiler-dev/2023-February/022135.html).

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

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

From duke at openjdk.org  Tue Feb 14 16:06:27 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Tue, 14 Feb 2023 16:06:27 GMT
Subject: Withdrawn: 5059679: name clash not reported for interface inheritance
In-Reply-To: <8BPz14cNrwLKfIHO77rNKeIgFacHtkC-aCbqCkN1tA0=.97031bcd-6f2d-4276-98c5-e0cbe6d79985@github.com>
References: <8BPz14cNrwLKfIHO77rNKeIgFacHtkC-aCbqCkN1tA0=.97031bcd-6f2d-4276-98c5-e0cbe6d79985@github.com>
Message-ID: <xHCvKe0ygoOFUTRjdzq1mPiMTXexzbMeRLTC25Gdhmk=.c46d3c4a-d0e9-474e-a712-b2da48ab178e@github.com>

On Thu, 9 Feb 2023 21:01:10 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

> Consider this input:
> 
> public class NarrowingNameClash {
> 
>     public interface Upper<T> {
>         void method(T param);
>     }
> 
>     public interface Lower<R> extends Upper<Class<R>> {
>         void method(Class<?> param);        // erasure name clash here
>     }
> }
> 
> This violates ?8.4.8.3 because `method(Class<R>)` and `method(Class<?>)` have the same erasure. However, the compiler is not reporting an error in this case.
> 
> Here's my understanding of the bug... (reviewer please double-check this :)
> 
> ?8.4.8.3 "Requirements in Overriding and Hiding" says:
> 
> It is a compile-time error if a class or interface C has a member method m1 and there exists a method m2 declared in C or a superclass or superinterface of C, A, such that all of the following are true:
> 
> * m1 and m2 have the same name.
> * m2 is accessible (?6.6) from C.
> * The signature of m1 is not a subsignature (?8.4.2) of the signature of m2 as a member of the supertype of C that names A.
> * The declared signature of m1 or some method m1 overrides (directly or indirectly) has the same erasure as the declared signature of m2 or some method m2 overrides (directly or indirectly).
> 
> Method `method(Class<R>)` is inherited by `Lower` from `Upper` and is therefore a member of `Lower`. Note that upon inheritance its parameter `T` is reinterpreted as `Class<R>` in the context of `Lower`'s generic parameterization.
> 
> Let C = `Lower`, A = `Upper`, m1 = `method(Class<R>)` and m2 = `method(Class<?>)`.
> 
> The compiler is comparing the erasures of `method(T)`, which is "some method m1 overrides", and m2 = `method(Class<?>)`, and these are different, so no bug is reported.
> 
> That comparison is appropriate, however, what it also needs to do is compare the erasures of m1 and m2, which are both `method(Class)`.
> 
> In a nutshell: within the context of `Lower`, the method `method(Class<R>)` inherited from `Upper`, when erased, has a different signature from its original form `method(T)` in `Upper`, when erased. The possibility of this different form was not being taken into account in the compiler.

This pull request has been closed without being integrated.

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

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

From vromero at openjdk.org  Tue Feb 14 16:32:08 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 14 Feb 2023 16:32:08 GMT
Subject: RFR: 8207017: Type annotations on anonymous classes in initializer
 blocks not written to class file
In-Reply-To: <Cp_01IlZGFU2gyEzog-5f70_qO2VI6Tw5251jBSSMLA=.36cc9ced-f25b-4acf-ab84-fe14eafe78d3@github.com>
References: <8oAI-F3E9-qQJtrSflKjYLHB08zHkGI_RlEFR3C7BsU=.8bb0ae4f-7ecb-4878-bf50-12ccfb556a02@github.com>
 <Cp_01IlZGFU2gyEzog-5f70_qO2VI6Tw5251jBSSMLA=.36cc9ced-f25b-4acf-ab84-fe14eafe78d3@github.com>
Message-ID: <DurcSnjUUSMVqHULZEWcNyugn1s0ZO4KFiWAPstwSCE=.33a314ed-69be-4ed1-ba09-3d7a8cb6840d@github.com>

On Tue, 14 Feb 2023 14:14:54 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Javac is not writing type annotations applied to anonymous classes inside of instance or static initializers. Basically for code like:
>> 
>> 
>> import java.lang.annotation.*;
>> 
>> class X {
>> 
>>     @Retention(RetentionPolicy.RUNTIME)
>>     @Target(ElementType.TYPE_USE)
>>     public @interface TA {
>>         String value() default "empty";
>>     }
>> 
>>     {
>>         class Local {}
>>         new @TA("LocalInstanceInitializerAnnonymous") Local() {};
>>     }
>> 
>>     static {
>>         class Local {}
>>         new @TA("LocalStaticAnnonymous") Local() {};
>>     }
>> }
>> 
>> not type annotations are generated as attributes of methods <init> or <clinit>. This PR is fixing this issue. The annotations are currently generated if the anonymous class is declared inside an instance or static method. The issue is only with initializers,
>> 
>> TIA
>
> Seems sensible.

@lahodaj thanks for the review

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

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

From andi at paulus.haus  Tue Feb 14 16:56:08 2023
From: andi at paulus.haus (Andreas Stadelmeier)
Date: Tue, 14 Feb 2023 17:56:08 +0100 (CET)
Subject: Bug Report - Type check involving wildcards not sound
In-Reply-To: <1952497529.912250.1676393546809@webmail.strato.com>
References: <1952497529.912250.1676393546809@webmail.strato.com>
Message-ID: <560791637.912870.1676393768539@webmail.strato.com>

Hello everybody,


I hope this is the right place. I just wanted to report a bug in the javac type-check.

My javac version: javac 19.0.1
My java version: OpenJDK Runtime Environment (build 19.0.1+10-Ubuntu-1ubuntu122.04)


Compiling the following program and running it leads to a runtime error.

I think this is an error, because javac should to declare this program not type correct during compilation time:


import java.util.Vector;


class Matrix<T> extends Vector<Vector<T>> {

    public static void main(String args[]) {
        Vector<Matrix<Integer>> vmInt=new Vector<Matrix<Integer>> ();
        vmInt.add(new Matrix<Integer>());
        Vector<? extends Matrix<?>> vm = vmInt;
	//The following assignment should not be possible:
        Vector<? extends Vector<Vector<?>>> vv = vm; 
        Vector<String> vS = new Vector<String>();
        vS.add("String");
	// adding Vector<String> to a Vector<Vector<Integer>>:
        vv.get(0).add(vS); 
                            
	//Runtime-Error:
        Integer notAnInteger = vmInt.get(0).get(0).get(0); 
    }
}


But there is no error during compilation. It generates a class file, which crashes when executed.
The following:
 javac Matrix.java
 java Matrix

spawns the error:

Exception in thread "main" java.lang.ClassCastException: class java.lang.String cannot be cast to class java.lang.Integer (java.lang.String and java.lang.Integer are in module java.base of loader 'bootstrap')
	at Matrix.main(Test.java:15)


Best Regards,
-Andi

From vromero at openjdk.org  Tue Feb 14 17:58:19 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 14 Feb 2023 17:58:19 GMT
Subject: RFR: 8301374: NullPointerException in MemberEnter.checkReceiver
 [v2]
In-Reply-To: <A3AquAfyff2vjvd57yhJSjGVG_hhsJd9FLgdN7ldK_c=.b27034f0-ea10-424e-b38e-0ecaa2af40d9@github.com>
References: <A3AquAfyff2vjvd57yhJSjGVG_hhsJd9FLgdN7ldK_c=.b27034f0-ea10-424e-b38e-0ecaa2af40d9@github.com>
Message-ID: <U1ZTVC2mDf8kZu9-18jBq69lgCzX95NLf85TiPGMWZQ=.93b05c67-8609-499c-b269-db6767880ff6@github.com>

> the following incorrect code is crashing javac:
> 
> public class X {
>   interface F {
>     void apply(E e);
>   }
>   enum E {
>     ONE
>   }
> 
>   F f = (E.ONE) -> {};   // E.ONE?
> }
> 
> there are several issues the incorrect argument to this lambda expression. The proposed solution is to issue a syntax error for the missing parameter name. IMO, this error message would be correct here and this way the compiler fails fast instead of having to deal with an erroneous lambda later on to avoid a crash like the one we have now,
> 
> TIA

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

  addressing review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12523/files
  - new: https://git.openjdk.org/jdk/pull/12523/files/62284265..04020e46

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

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

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

From vromero at openjdk.org  Tue Feb 14 17:58:19 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 14 Feb 2023 17:58:19 GMT
Subject: RFR: 8301374: NullPointerException in MemberEnter.checkReceiver
 [v2]
In-Reply-To: <UJDqvPO-DZfOHj2kP-C29uJAZLIUTikPNTxpM6LSJpU=.29776cc4-4009-4e91-b592-427a0cdc24fc@github.com>
References: <A3AquAfyff2vjvd57yhJSjGVG_hhsJd9FLgdN7ldK_c=.b27034f0-ea10-424e-b38e-0ecaa2af40d9@github.com>
 <UJDqvPO-DZfOHj2kP-C29uJAZLIUTikPNTxpM6LSJpU=.29776cc4-4009-4e91-b592-427a0cdc24fc@github.com>
Message-ID: <3vm8KNdVJkdoAK26X7JjSGueALIMhqO5ZW6uc0PvYA8=.c05d7853-09bc-42f3-88ea-9d2896fd0c4c@github.com>

On Tue, 14 Feb 2023 16:01:00 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   addressing review comments
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 3726:
> 
>> 3724:                 if (pn.hasTag(Tag.IDENT) && ((JCIdent)pn).name != names._this) {
>> 3725:                     name = ((JCIdent)pn).name;
>> 3726:                 } else if (lambdaParameter) {
> 
> I wonder if we could help the error recovery a little bit more, like e.g.:
> 
>                 } else if (lambdaParameter && type == null) {
>                     // we have a lambda parameter that is not an identifier this is a syntax error
>                     type = pn;
>                     name = names.empty;
>                     reportSyntaxError(pos, Errors.Expected(IDENTIFIER));
>                 } else {
> 
> 
> Which would keep the parsed thing as a type for the lambda parameter?

yep I like this suggestion. I have updated the PR accordingly, thanks!

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

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

From jlahoda at openjdk.org  Tue Feb 14 18:33:43 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 14 Feb 2023 18:33:43 GMT
Subject: RFR: 8208470: Type annotations on inner type that is an array
 component [v2]
In-Reply-To: <_G5oNn_Phfoi1L838O6IcuBbairwjA338wF7TojcVLg=.723e98b6-4438-4770-84dd-2c9a3f46538c@github.com>
References: <yLW354ZGwsnY12JSiQIPftjJIFo6F_wwNzkqX1JsCVM=.fe77d59c-2f3f-4ec5-9dad-0c8a9a235588@github.com>
 <_G5oNn_Phfoi1L838O6IcuBbairwjA338wF7TojcVLg=.723e98b6-4438-4770-84dd-2c9a3f46538c@github.com>
Message-ID: <0vrJwo7XresWZ3Q0agLFIGUxrmQBbixNIjJmZdb3wOg=.7a51cc61-2f91-4f4a-9aa0-f0437010930f@github.com>

On Sat, 11 Feb 2023 23:01:38 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> As stated in the bug great description by Werner D.:
>> 
>> Considering this example:
>> 
>> import java.lang.annotation.ElementType;
>> import java.lang.annotation.Retention;
>> import java.lang.annotation.RetentionPolicy;
>> import java.lang.annotation.Target;
>> 
>> @Retention(RetentionPolicy.RUNTIME)
>> @Target({ElementType.TYPE_USE, ElementType.TYPE_PARAMETER})
>> @interface TA {
>>   int value();
>> }
>> 
>> class ArrayOfInner {
>>   class Inner {}
>> 
>>   @TA(1) ArrayOfInner. @TA(2) Inner oi;
>>   @TA(3) ArrayOfInner. @TA(4) Inner [] oia;
>>   @TA(5) Inner i;
>>   @TA(6) Inner [] ia;
>> }
>> 
>> If compiled with javac 8, according to javap -v field ia has the annotation:
>> 
>>   ArrayOfInner$Inner[] ia;
>>     descriptor: [LArrayOfInner$Inner;
>>     flags: (0x0000)
>>     RuntimeVisibleTypeAnnotations:
>>       0: #10(#11=I#21): FIELD, location=[ARRAY, INNER_TYPE]
>>         TA(
>>           value=6
>>         )
>> 
>> if compiled with javac > 8 ia has the annotation:
>> 
>>   ArrayOfInner$Inner[] ia;
>>     descriptor: [LArrayOfInner$Inner;
>>     flags: (0x0000)
>>     RuntimeVisibleTypeAnnotations:
>>       0: #10(#11=I#21): FIELD, location=[ARRAY]
>>         TA(
>>           value=6
>>         )
>> 
>> Note the missing `INNER_TYPE` location. This PR is re-establishing the Java 8 behavior.
>> 
>> TIA
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adding bug number to regression test

As I read the patch, it replaces a loop which is supposed to inject the annotation into the deepest type with a recursive call (which then ensures the correct attributes are set). That seems reasonable to me, to the degree I can understand it.

It might be good to try to get Werner's or Michael Ernst's feedback/comment, just to be sure.

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

Marked as reviewed by jlahoda (Reviewer).

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

From jlahoda at openjdk.org  Tue Feb 14 18:34:44 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 14 Feb 2023 18:34:44 GMT
Subject: RFR: 8301374: NullPointerException in MemberEnter.checkReceiver
 [v2]
In-Reply-To: <U1ZTVC2mDf8kZu9-18jBq69lgCzX95NLf85TiPGMWZQ=.93b05c67-8609-499c-b269-db6767880ff6@github.com>
References: <A3AquAfyff2vjvd57yhJSjGVG_hhsJd9FLgdN7ldK_c=.b27034f0-ea10-424e-b38e-0ecaa2af40d9@github.com>
 <U1ZTVC2mDf8kZu9-18jBq69lgCzX95NLf85TiPGMWZQ=.93b05c67-8609-499c-b269-db6767880ff6@github.com>
Message-ID: <vwD78-fxiktE3f3pEtW53AbWmkGA7RP8l_QK139m5HE=.f43dbe14-daa4-405f-92a0-c735f90e34c2@github.com>

On Tue, 14 Feb 2023 17:58:19 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> the following incorrect code is crashing javac:
>> 
>> public class X {
>>   interface F {
>>     void apply(E e);
>>   }
>>   enum E {
>>     ONE
>>   }
>> 
>>   F f = (E.ONE) -> {};   // E.ONE?
>> }
>> 
>> there are several issues the incorrect argument to this lambda expression. The proposed solution is to issue a syntax error for the missing parameter name. IMO, this error message would be correct here and this way the compiler fails fast instead of having to deal with an erroneous lambda later on to avoid a crash like the one we have now,
>> 
>> TIA
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   addressing review comments

Looks good to me!

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

Marked as reviewed by jlahoda (Reviewer).

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

From vromero at openjdk.org  Tue Feb 14 19:02:50 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 14 Feb 2023 19:02:50 GMT
Subject: RFR: 8301374: NullPointerException in MemberEnter.checkReceiver
 [v2]
In-Reply-To: <vwD78-fxiktE3f3pEtW53AbWmkGA7RP8l_QK139m5HE=.f43dbe14-daa4-405f-92a0-c735f90e34c2@github.com>
References: <A3AquAfyff2vjvd57yhJSjGVG_hhsJd9FLgdN7ldK_c=.b27034f0-ea10-424e-b38e-0ecaa2af40d9@github.com>
 <U1ZTVC2mDf8kZu9-18jBq69lgCzX95NLf85TiPGMWZQ=.93b05c67-8609-499c-b269-db6767880ff6@github.com>
 <vwD78-fxiktE3f3pEtW53AbWmkGA7RP8l_QK139m5HE=.f43dbe14-daa4-405f-92a0-c735f90e34c2@github.com>
Message-ID: <yazxOvTu0KADMnca_IOcdh0KSRHYfYjvwv-Eca-m4x8=.9a395014-f528-449f-8ffd-390e344dc715@github.com>

On Tue, 14 Feb 2023 18:31:26 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   addressing review comments
>
> Looks good to me!

@lahodaj thanks for the review

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

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

From vromero at openjdk.org  Tue Feb 14 19:02:52 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 14 Feb 2023 19:02:52 GMT
Subject: Integrated: 8301374: NullPointerException in MemberEnter.checkReceiver
In-Reply-To: <A3AquAfyff2vjvd57yhJSjGVG_hhsJd9FLgdN7ldK_c=.b27034f0-ea10-424e-b38e-0ecaa2af40d9@github.com>
References: <A3AquAfyff2vjvd57yhJSjGVG_hhsJd9FLgdN7ldK_c=.b27034f0-ea10-424e-b38e-0ecaa2af40d9@github.com>
Message-ID: <Jrf-Sa75sQpc5Zwpau023QxwuW8mVjlb8VhAd4gjA4Q=.f88e9d9e-4e45-407d-b923-4d71d60b10c1@github.com>

On Sun, 12 Feb 2023 03:53:02 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> the following incorrect code is crashing javac:
> 
> public class X {
>   interface F {
>     void apply(E e);
>   }
>   enum E {
>     ONE
>   }
> 
>   F f = (E.ONE) -> {};   // E.ONE?
> }
> 
> there are several issues the incorrect argument to this lambda expression. The proposed solution is to issue a syntax error for the missing parameter name. IMO, this error message would be correct here and this way the compiler fails fast instead of having to deal with an erroneous lambda later on to avoid a crash like the one we have now,
> 
> TIA

This pull request has now been integrated.

Changeset: ca73f7e8
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ca73f7e80f4a7e3c3c2a68c957412618d042d101
Stats:     16 lines in 3 files changed: 14 ins; 0 del; 2 mod

8301374: NullPointerException in MemberEnter.checkReceiver

Reviewed-by: jlahoda

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

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

From vromero at openjdk.org  Tue Feb 14 19:58:43 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 14 Feb 2023 19:58:43 GMT
Subject: RFR: 8208470: Type annotations on inner type that is an array
 component [v2]
In-Reply-To: <0vrJwo7XresWZ3Q0agLFIGUxrmQBbixNIjJmZdb3wOg=.7a51cc61-2f91-4f4a-9aa0-f0437010930f@github.com>
References: <yLW354ZGwsnY12JSiQIPftjJIFo6F_wwNzkqX1JsCVM=.fe77d59c-2f3f-4ec5-9dad-0c8a9a235588@github.com>
 <_G5oNn_Phfoi1L838O6IcuBbairwjA338wF7TojcVLg=.723e98b6-4438-4770-84dd-2c9a3f46538c@github.com>
 <0vrJwo7XresWZ3Q0agLFIGUxrmQBbixNIjJmZdb3wOg=.7a51cc61-2f91-4f4a-9aa0-f0437010930f@github.com>
Message-ID: <qsThcgTX_vx5G2mrXXLhm6Pd7VwuOqFv2xbx370poVQ=.ac0e9009-9d05-484f-ba9b-f7c5137f554e@github.com>

On Tue, 14 Feb 2023 18:30:26 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> As I read the patch, it replaces a loop which is supposed to inject the annotation into the deepest type with a recursive call (which then ensures the correct attributes are set). That seems reasonable to me, to the degree I can understand it.
> 
> It might be good to try to get Werner's or Michael Ernst's feedback/comment, just to be sure.

right that's what the patch is doing. I can ask them but I wouldn't wait to have a reply from them before closing the issue

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

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

From jlahoda at openjdk.org  Wed Feb 15 13:22:28 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 15 Feb 2023 13:22:28 GMT
Subject: RFR: JDK-8302202: Incorrect desugaring of null-allowed nested patterns
Message-ID: <E-Jv1xFu4_33w3rXpwbfzeVeCRupcQ_XChtuwfxwFI4=.65a9ebe9-ef47-4659-a6cc-1386e24a00c9@github.com>

Considering code like:

    private String test1b(Object i) {
        return switch (i) {
            case R1(Object o) when o == null -> "R1(null)";
            case R1(Object o) -> "R1(!null)";
            default -> "default";
        };
    }


javac will try to factor-out the common prefix, i.e. `R1`, and produce something along these lines:

        switch (i) {
            case R1 $r:
                Object c = $r.c();
                switch (c) {
                    case Object o when o == null: yield "R1(null)";
                    case Object o: yield "R1(!null)";
                }
            default -> "default";
        };


The problem with this code is that both cases in the nested switch must match `null`, but the bootstrap protocol only allows one case to match `null` (the `SwitchBootstraps.typeSwitch` method will return `-1` for `null`). So this translation is broken, and will not match the first case if the component is `null`.

There are multiple ways to solve this problem, but the proposal here is change the way we accumulate the cases from which we factor out the common prefix, by stopping the accumulation after the first nullable case.

Another related issue is that when factoring out the common prefix, if the last case in the nested switch is has an unconditional pattern, but also has a guard, we need to generate a default to continue properly in the outer switch. Currently, the default is not generated when there's an unconditional pattern in the case, despite having a guard, and hence the case as a whole is not unconditional.

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

Commit messages:
 - JDK-8302202: Incorrect desugaring of null-allowed nested patterns

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

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

From duke at openjdk.org  Wed Feb 15 16:07:47 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Wed, 15 Feb 2023 16:07:47 GMT
Subject: RFR: 8302514: Misleading error generated when empty class file
 encountered
Message-ID: <D3Zz9uIVp9iFDip3Pr0f6_QFYv2NNwFPNdejD9sa8KI=.b3d36e86-5162-4658-b71e-c650b81f1643@github.com>

When javac encounters an empty class file, you get the following strange error referring to `java.lang.AutoCloseable`:

Test.java:3: error: cannot access Empty
        new Empty();
            ^
  bad class file: ./Empty.class
    class file contains wrong class: java.lang.AutoCloseable
    Please remove or make sure it appears in the correct subdirectory of the classpath.
1 error

This is a side effect of javac blindly reading past the end of the data in a data buffer. Further investigation revealed three distinct bugs in this area of the code:

1. There are several unchecked corner cases in `ByteBuffer` and `ArrayUtils` that could potentially lead to `ArrayIndexOutOfBoundsException`s and/or infinite loops. Instead we should "fail fast" on any attempt to read or allocate data out of bounds.
1. The method `ByteBuffer.appendStream()` assumes that the result from `InputStream.available()` is always accurate, but this is not guaranteed. As a result, class files could (in theory) be read incorrectly by the compiler, especially when they come from non-standard sources.
1. There is no systematic protection against truncated class files. Instead, depending on where exactly it is truncated, a truncated class file generates one of several possible different errors:
   * `index 25926 is not within pool size 13`
   * `bad constant pool tag: 0 at 28317`
   * `unexpected constant pool tag: 10 at 11`
   * `class file is invalid for class Empty`
   * `class file contains wrong class: java.lang.AutoCloseable`

This patch fixes issues 1 and 2, and addresses 3 by having `ByteBuffer` throw a new unchecked `UnderflowException` if ever data is read past the end of the buffer. Then `PoolReader`, `ClassReader`, and `ModuleNameReader` are updated to catch this exception and convert it into a bad class file error. As a result, truncated class files generate a consistent `class file truncated at offset X` error regardless of where they are truncated.

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

Commit messages:
 - Fix misleading error when empty an class file is encountered.
 - Fix bogus reliance on InputStream.available() in ByteBuffer.appendStream().
 - Tighten up handling of corner cases in ByteBuffer and ArrayUtils.

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

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

From maurizio.cimadamore at oracle.com  Wed Feb 15 16:11:21 2023
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Wed, 15 Feb 2023 16:11:21 +0000
Subject: Bug Report - Type check involving wildcards not sound
In-Reply-To: <560791637.912870.1676393768539@webmail.strato.com>
References: <1952497529.912250.1676393546809@webmail.strato.com>
 <560791637.912870.1676393768539@webmail.strato.com>
Message-ID: <07a335f6-f9d6-df36-d5ae-4308749d5a00@oracle.com>

Hi,
I agree this is a bug. It appears to be a duplicate of this:

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

I took the liberty of adding your test in there.

Cheers
Maurizio

On 14/02/2023 16:56, Andreas Stadelmeier wrote:
> Hello everybody,
>
>
> I hope this is the right place. I just wanted to report a bug in the javac type-check.
>
> My javac version: javac 19.0.1
> My java version: OpenJDK Runtime Environment (build 19.0.1+10-Ubuntu-1ubuntu122.04)
>
>
> Compiling the following program and running it leads to a runtime error.
>
> I think this is an error, because javac should to declare this program not type correct during compilation time:
>
>
> import java.util.Vector;
>
>
> class Matrix<T> extends Vector<Vector<T>> {
>
>      public static void main(String args[]) {
>          Vector<Matrix<Integer>> vmInt=new Vector<Matrix<Integer>> ();
>          vmInt.add(new Matrix<Integer>());
>          Vector<? extends Matrix<?>> vm = vmInt;
> 	//The following assignment should not be possible:
>          Vector<? extends Vector<Vector<?>>> vv = vm;
>          Vector<String> vS = new Vector<String>();
>          vS.add("String");
> 	// adding Vector<String> to a Vector<Vector<Integer>>:
>          vv.get(0).add(vS);
>                              
> 	//Runtime-Error:
>          Integer notAnInteger = vmInt.get(0).get(0).get(0);
>      }
> }
>
>
> But there is no error during compilation. It generates a class file, which crashes when executed.
> The following:
>   javac Matrix.java
>   java Matrix
>
> spawns the error:
>
> Exception in thread "main" java.lang.ClassCastException: class java.lang.String cannot be cast to class java.lang.Integer (java.lang.String and java.lang.Integer are in module java.base of loader 'bootstrap')
> 	at Matrix.main(Test.java:15)
>
>
> Best Regards,
> -Andi

From duke at openjdk.org  Wed Feb 15 16:23:54 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Wed, 15 Feb 2023 16:23:54 GMT
Subject: RFR: 8302514: Misleading error generated when empty class file
 encountered [v2]
In-Reply-To: <D3Zz9uIVp9iFDip3Pr0f6_QFYv2NNwFPNdejD9sa8KI=.b3d36e86-5162-4658-b71e-c650b81f1643@github.com>
References: <D3Zz9uIVp9iFDip3Pr0f6_QFYv2NNwFPNdejD9sa8KI=.b3d36e86-5162-4658-b71e-c650b81f1643@github.com>
Message-ID: <ssZiZIVhB-jkWWMTPUpoSp-A0Xt_u63OKpPzUNCzsiU=.a1513e6b-7986-40bc-bf2b-cbe01cae9ecb@github.com>

> When javac encounters an empty class file, you get the following strange error referring to `java.lang.AutoCloseable`:
> 
> Test.java:3: error: cannot access Empty
>         new Empty();
>             ^
>   bad class file: ./Empty.class
>     class file contains wrong class: java.lang.AutoCloseable
>     Please remove or make sure it appears in the correct subdirectory of the classpath.
> 1 error
> 
> This is a side effect of javac blindly reading past the end of the data in a data buffer. Further investigation revealed three distinct bugs in this area of the code:
> 
> 1. There are several unchecked corner cases in `ByteBuffer` and `ArrayUtils` that could potentially lead to `ArrayIndexOutOfBoundsException`s and/or infinite loops. Instead we should "fail fast" on any attempt to read or allocate data out of bounds.
> 1. The method `ByteBuffer.appendStream()` assumes that the result from `InputStream.available()` is always accurate, but this is not guaranteed. As a result, class files could (in theory) be read incorrectly by the compiler, especially when they come from non-standard sources.
> 1. There is no systematic protection against truncated class files. Instead, depending on where exactly it is truncated, a truncated class file generates one of several possible different errors:
>    * `index 25926 is not within pool size 13`
>    * `bad constant pool tag: 0 at 28317`
>    * `unexpected constant pool tag: 10 at 11`
>    * `class file is invalid for class Empty`
>    * `class file contains wrong class: java.lang.AutoCloseable`
> 
> This patch fixes issues 1 and 2, and addresses 3 by having `ByteBuffer` throw a new unchecked `UnderflowException` if ever data is read past the end of the buffer. Then `PoolReader`, `ClassReader`, and `ModuleNameReader` are updated to catch this exception and convert it into a bad class file error. As a result, truncated class files generate a consistent `class file truncated at offset X` error regardless of where they are truncated.

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

  Fix another ArrayUtils corner case created by previous fix.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12574/files
  - new: https://git.openjdk.org/jdk/pull/12574/files/0db96e30..22625db5

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

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

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

From maurizio.cimadamore at oracle.com  Wed Feb 15 16:28:06 2023
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Wed, 15 Feb 2023 16:28:06 +0000
Subject: Uncertainty about fix for JDK-5059679
In-Reply-To: <D6A4B805-E2A3-4F87-BF09-FEF6AF0263AA@oracle.com>
References: <CANSoFxvP9jbu--DCr0C6SrYpSE=YCoH1uj6aRm1MV1f209Kg+Q@mail.gmail.com>
 <D6A4B805-E2A3-4F87-BF09-FEF6AF0263AA@oracle.com>
Message-ID: <da484ece-c4bc-2f54-b129-c9d1b8747d8b@oracle.com>

On 14/02/2023 01:06, Dan Smith wrote:

> LS isn't always clear about which of these two signatures it's talking 
> about, but in this case, given the use of different phrases in the 
> third and fourth rules, and the fact of javac's longstanding behavior, 
> I think that's the intent.
>
> (It makes sense, too, because the underlying problem is that you don't 
> want the descriptors to clash in the class file. And they don't, 
> because one has descriptor '(Object)V' and the other is '(Class)V'. 
> Eventually, somebody might try to override something and need a bridge 
> method that *would* clash, but in that case there would be another 
> method for which this error check should apply.)

Exactly.

The checks in 8.4.8 are there to ensure you can?t accidentally override 
a bridge method. As Dan points out, the underlying descriptors are 
different here, so no real problem occurs. When writing the checks for 
8.4.8 I had to scan these rules multiple times - and I agree that some 
clarification could be in order here. I think reading them with the 
glasses of ?no accidental bridge method override? is generally a useful 
metaphore - and, since the JLS cannot speak about bridge methods, that 
results in a somewhat convoluted formulation of the rules.

The example Archie shown is one of those cases where there?s obviously 
something ?fishy? going on, but the compiler decides to go ahead with 
it, kicking the can down the road, to when the abstract class will 
become a concrete one. So, if a new class comes along, like this:

|class EvenLower<R> extends Lower<R> { void method(Class<?> c) { } } |

A problem will be reported - because the class will still need to 
implement |method(Class<R>)| - but of course if you try to do that, you 
will get a clash.

That said, your subclass can have a raw declaration:

|class EvenLower<R> extends Lower<R> { void method(Class c) { } } |

In which case everything is ok (beause |method(Class)| is a subsignature 
of the sharper |method(Class<R>)|).

Maurizio

?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230215/826659c7/attachment-0001.htm>

From alex.buckley at oracle.com  Wed Feb 15 17:04:35 2023
From: alex.buckley at oracle.com (Alex Buckley)
Date: Wed, 15 Feb 2023 09:04:35 -0800
Subject: Uncertainty about fix for JDK-5059679
In-Reply-To: <da484ece-c4bc-2f54-b129-c9d1b8747d8b@oracle.com>
References: <CANSoFxvP9jbu--DCr0C6SrYpSE=YCoH1uj6aRm1MV1f209Kg+Q@mail.gmail.com>
 <D6A4B805-E2A3-4F87-BF09-FEF6AF0263AA@oracle.com>
 <da484ece-c4bc-2f54-b129-c9d1b8747d8b@oracle.com>
Message-ID: <7e29ca51-9299-66b8-2fb6-04547abdaa6e@oracle.com>

On 2/15/2023 8:28 AM, Maurizio Cimadamore wrote:
> The example Archie shown is one of those cases where there?s obviously 
> something ?fishy? going on, but the compiler decides to go ahead with 
> it, kicking the can down the road, to when the abstract class will 
> become a concrete one. So, if a new class comes along, like this:
> 
> |class EvenLower<R> extends Lower<R> { void method(Class<?> c) { } } |
> 
> A problem will be reported - because the class will still need to 
> implement |method(Class<R>)| - but of course if you try to do that, you 
> will get a clash.
> 
> That said, your subclass can have a raw declaration:
> 
> |class EvenLower<R> extends Lower<R> { void method(Class c) { } } |
> 
> In which case everything is ok (beause |method(Class)| is a subsignature 
> of the sharper |method(Class<R>)|).

At which point this class-based scenario is more clearly seen as 
analogous to the interface-based scenario that Archie also gave, where 
you can only implement the subinterface Lower<R> by declaring a concrete 
method with a raw signature. The Java language is consistent in "kicking 
the can down the road", but the JLS doesn't offer the words to 
characterize how, when, or why the Java language works like this.

Alex

From vromero at openjdk.org  Wed Feb 15 20:28:58 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 15 Feb 2023 20:28:58 GMT
Subject: RFR: 8302514: Misleading error generated when empty class file
 encountered [v2]
In-Reply-To: <ssZiZIVhB-jkWWMTPUpoSp-A0Xt_u63OKpPzUNCzsiU=.a1513e6b-7986-40bc-bf2b-cbe01cae9ecb@github.com>
References: <D3Zz9uIVp9iFDip3Pr0f6_QFYv2NNwFPNdejD9sa8KI=.b3d36e86-5162-4658-b71e-c650b81f1643@github.com>
 <ssZiZIVhB-jkWWMTPUpoSp-A0Xt_u63OKpPzUNCzsiU=.a1513e6b-7986-40bc-bf2b-cbe01cae9ecb@github.com>
Message-ID: <HQW4l19SSt_OSxUmMhpKrIUGLaK7EUmV3wuF3Sq6VQI=.ceadfda2-e67f-47d5-af7c-5eab4d805e38@github.com>

On Wed, 15 Feb 2023 16:23:54 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> When javac encounters an empty class file, you get the following strange error referring to `java.lang.AutoCloseable`:
>> 
>> Test.java:3: error: cannot access Empty
>>         new Empty();
>>             ^
>>   bad class file: ./Empty.class
>>     class file contains wrong class: java.lang.AutoCloseable
>>     Please remove or make sure it appears in the correct subdirectory of the classpath.
>> 1 error
>> 
>> This is a side effect of javac blindly reading past the end of the data in a data buffer. Further investigation revealed three distinct bugs in this area of the code:
>> 
>> 1. There are several unchecked corner cases in `ByteBuffer` and `ArrayUtils` that could potentially lead to `ArrayIndexOutOfBoundsException`s and/or infinite loops. Instead we should "fail fast" on any attempt to read or allocate data out of bounds.
>> 1. The method `ByteBuffer.appendStream()` assumes that the result from `InputStream.available()` is always accurate, but this is not guaranteed. As a result, class files could (in theory) be read incorrectly by the compiler, especially when they come from non-standard sources.
>> 1. There is no systematic protection against truncated class files. Instead, depending on where exactly it is truncated, a truncated class file generates one of several possible different errors:
>>    * `index 25926 is not within pool size 13`
>>    * `bad constant pool tag: 0 at 28317`
>>    * `unexpected constant pool tag: 10 at 11`
>>    * `class file is invalid for class Empty`
>>    * `class file contains wrong class: java.lang.AutoCloseable`
>> 
>> This patch fixes issues 1 and 2, and addresses 3 by having `ByteBuffer` throw a new unchecked `UnderflowException` if ever data is read past the end of the buffer. Then `PoolReader`, `ClassReader`, and `ModuleNameReader` are updated to catch this exception and convert it into a bad class file error. As a result, truncated class files generate a consistent `class file truncated at offset X` error regardless of where they are truncated.
>
> Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix another ArrayUtils corner case created by previous fix.

looks sensible to me

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

Marked as reviewed by vromero (Reviewer).

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

From ljnelson at gmail.com  Thu Feb 16 00:37:41 2023
From: ljnelson at gmail.com (Laird Nelson)
Date: Wed, 15 Feb 2023 16:37:41 -0800
Subject: Question regarding type use annotation on method parameter type
Message-ID: <CAHNdxunKKizUVoRnZz8jWE0ENGxnz9Xz38b0qSH9vRfxBdg0yA@mail.gmail.com>

I hope this is the right list for this sort of thing and that I, a
non-compiler guy, am not wasting anyone's time. My question relates to the
javax.lang.model.* classes and the way they (do not) represent a particular
kind of type use annotation.

Consider the following contrived example, which compiles (if I've typed it
right):

@Retention(RetentionPolicy.RUNTIME)
@Target({ ElementType.TYPE_USE }) // note: deliberately not PARAMETER
public @interface A {}

public final class B {
    public static final void c(@A String s) {}
}


As far as I can tell, a representation of @A does not appear in any list of
AnnotationMirrors "reachable" from an ExecutableElement, including its
backing ExecutableType and the TypeMirrors representing the parameter type
usages and so on, representing B#c(String). Should it?

A representation of @A does appear in reflection, and it seems to in
MethodSymbol, and tools like Jandex also report it in what seems to be the
proper place. See
https://stackoverflow.com/questions/75454080/where-in-the-javax-lang-model-hierarchy-is-this-type-use-annotation-recorded
for a longer writeup if that's helpful.

I am happy to provide more details but if I'm in the wrong place or missed
something obvious I wanted to keep this short.

Thanks,
Laird
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230215/da97d7fa/attachment-0001.htm>

From alex.buckley at oracle.com  Thu Feb 16 01:07:07 2023
From: alex.buckley at oracle.com (Alex Buckley)
Date: Wed, 15 Feb 2023 17:07:07 -0800
Subject: Question regarding type use annotation on method parameter type
In-Reply-To: <CAHNdxunKKizUVoRnZz8jWE0ENGxnz9Xz38b0qSH9vRfxBdg0yA@mail.gmail.com>
References: <CAHNdxunKKizUVoRnZz8jWE0ENGxnz9Xz38b0qSH9vRfxBdg0yA@mail.gmail.com>
Message-ID: <27a5a775-3704-a656-845b-72e471ffa3c3@oracle.com>

On 2/15/2023 4:37 PM, Laird Nelson wrote:
> Consider the following contrived example, which compiles (if I've typed 
> it right):
> 
>     @Retention(RetentionPolicy.RUNTIME)
>     @Target({ ElementType.TYPE_USE }) // note: deliberately not PARAMETER
>     public @interface A {}
> 
>     public final class B {
>      ? ? public static final void c(@A String s) {}
>     }
> 
> As far as I can tell, a representation of @A does not appear in any list 
> of AnnotationMirrors?"reachable" from an ExecutableElement, including 
> its backing ExecutableType and the TypeMirrors representing the parameter 
> type usages and so on, representing B#c(String). Should it?

Via ExecutableElement::getParameters, the VariableElement which 
represents the declaration of formal parameter `s` should expose a 
TypeMirror for the type `@A String`.

That TypeMirror should expose `@A` via getAnnotation, 
getAnnotationMirrors, or getAnnotationsByType -- all of which say "Note 
that any annotations returned by this method are type annotations."

Alex

From ljnelson at gmail.com  Thu Feb 16 01:59:19 2023
From: ljnelson at gmail.com (Laird Nelson)
Date: Wed, 15 Feb 2023 17:59:19 -0800
Subject: Question regarding type use annotation on method parameter type
In-Reply-To: <27a5a775-3704-a656-845b-72e471ffa3c3@oracle.com>
References: <CAHNdxunKKizUVoRnZz8jWE0ENGxnz9Xz38b0qSH9vRfxBdg0yA@mail.gmail.com>
 <27a5a775-3704-a656-845b-72e471ffa3c3@oracle.com>
Message-ID: <CAHNdxumRjw7e0ERRuVe5fskRn4MTd7j4yg=vHvhCv=Jgm7Zayg@mail.gmail.com>

On Wed, Feb 15, 2023 at 5:07 PM Alex Buckley <alex.buckley at oracle.com>
wrote:

> Via ExecutableElement::getParameters, the VariableElement which
> represents the declaration of formal parameter `s` should expose a
> TypeMirror for the type `@A String`.
>

Thank you. That is exactly what I expected. It does not. Should I file a
bug?

Test code excerpted below:

Element e = elements.getTypeElement("B");
ExecutableElement c = (ExecutableElement)e.getEnclosedElements().get(1); //
0 is the implicit constructor; 1 is the c method
assert "c".equals(c.getSimpleName().toString()); // yep, got the right
method
VariableElement s = (VariableElement)c.getParameters().get(0);
assert "s".equals(s.getSimpleName().toString()); // yep, got the right
parameter
DeclaredType sAsType = (DeclaredType)s.asType();
assert !sAsType.getAnnotations().isEmpty(); // fails; it is empty

Thanks,
Laird
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230215/5a8a4e8a/attachment.htm>

From cushon at google.com  Thu Feb 16 03:57:16 2023
From: cushon at google.com (Liam Miller-Cushon)
Date: Wed, 15 Feb 2023 19:57:16 -0800
Subject: Question regarding type use annotation on method parameter type
In-Reply-To: <CAHNdxumRjw7e0ERRuVe5fskRn4MTd7j4yg=vHvhCv=Jgm7Zayg@mail.gmail.com>
References: <CAHNdxunKKizUVoRnZz8jWE0ENGxnz9Xz38b0qSH9vRfxBdg0yA@mail.gmail.com>
 <27a5a775-3704-a656-845b-72e471ffa3c3@oracle.com>
 <CAHNdxumRjw7e0ERRuVe5fskRn4MTd7j4yg=vHvhCv=Jgm7Zayg@mail.gmail.com>
Message-ID: <CAL4QsgsgqX2a-w+naSE2Wh+VpHDh-DxoBxhz=0m=Q73vSMbpmQ@mail.gmail.com>

Should `sAsType.getAnnotations()` be `sAsType.getAnnotationMirrors()`?

It works for me if B is being compiled from source as part of the same
compilation doing the annotation processing, but not if B is loaded from
the classpath, which is consistent with this known issue:
https://bugs.openjdk.org/browse/JDK-8225377

$ javac -processor P -implicit:none  -sourcepath : -parameters A.java B.java
Note: B.c(java.lang. at A String).s has annotations [@A]
Note: B.c(java.lang. at A String).s has annotations [@A]
$ javac -processor P -implicit:none  -sourcepath : -parameters A.java
Note: B.c(java.lang.String).s has annotations []
Note: B.c(java.lang.String).s has annotations []

=== A.java ===
import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;

@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.TYPE_USE})
public @interface A {}
=== B.java ===
public final class B {
  public static final void c(@A String s) {}
}
=== P.java ===
import java.util.Set;
import javax.annotation.processing.AbstractProcessor;
import javax.annotation.processing.RoundEnvironment;
import javax.annotation.processing.SupportedAnnotationTypes;
import javax.lang.model.SourceVersion;
import javax.lang.model.element.Element;
import javax.lang.model.element.ExecutableElement;
import javax.lang.model.element.TypeElement;
import javax.lang.model.element.VariableElement;
import javax.lang.model.type.TypeMirror;
import javax.lang.model.util.Elements;
import javax.tools.Diagnostic;

@SupportedAnnotationTypes("*")
public class P extends AbstractProcessor {
  @Override
  public SourceVersion getSupportedSourceVersion() {
    return SourceVersion.latestSupported();
  }

  @Override
  public boolean process(Set<? extends TypeElement> annotations,
RoundEnvironment roundEnv) {
    Elements elements = processingEnv.getElementUtils();
    Element e = elements.getTypeElement("B");
    ExecutableElement c = (ExecutableElement)
e.getEnclosedElements().get(1);
    VariableElement s = c.getParameters().get(0);
    TypeMirror sAsType = s.asType();
    processingEnv
        .getMessager()
        .printMessage(
            Diagnostic.Kind.NOTE,
            String.format(
                "%s.%s.%s has annotations [%s]", e, c, s,
sAsType.getAnnotationMirrors()));
    return false;
  }
}

On Wed, Feb 15, 2023 at 6:00 PM Laird Nelson <ljnelson at gmail.com> wrote:

> On Wed, Feb 15, 2023 at 5:07 PM Alex Buckley <alex.buckley at oracle.com>
> wrote:
>
>> Via ExecutableElement::getParameters, the VariableElement which
>> represents the declaration of formal parameter `s` should expose a
>> TypeMirror for the type `@A String`.
>>
>
> Thank you. That is exactly what I expected. It does not. Should I file a
> bug?
>
> Test code excerpted below:
>
> Element e = elements.getTypeElement("B");
> ExecutableElement c = (ExecutableElement)e.getEnclosedElements().get(1);
> // 0 is the implicit constructor; 1 is the c method
> assert "c".equals(c.getSimpleName().toString()); // yep, got the right
> method
> VariableElement s = (VariableElement)c.getParameters().get(0);
> assert "s".equals(s.getSimpleName().toString()); // yep, got the right
> parameter
> DeclaredType sAsType = (DeclaredType)s.asType();
> assert !sAsType.getAnnotations().isEmpty(); // fails; it is empty
>
> Thanks,
> Laird
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230215/2375ceb8/attachment-0001.htm>

From vromero at openjdk.org  Thu Feb 16 04:04:37 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 16 Feb 2023 04:04:37 GMT
Subject: Integrated: 8208470: Type annotations on inner type that is an array
 component
In-Reply-To: <yLW354ZGwsnY12JSiQIPftjJIFo6F_wwNzkqX1JsCVM=.fe77d59c-2f3f-4ec5-9dad-0c8a9a235588@github.com>
References: <yLW354ZGwsnY12JSiQIPftjJIFo6F_wwNzkqX1JsCVM=.fe77d59c-2f3f-4ec5-9dad-0c8a9a235588@github.com>
Message-ID: <mgQ_PN3u7K-yWFnvAuM6pxTUbEK6zNaK14V4IoTo_9w=.b4d70fc4-7ff3-48ed-80d5-f3717d4f58bf@github.com>

On Sat, 11 Feb 2023 14:02:13 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> As stated in the bug great description by Werner D.:
> 
> Considering this example:
> 
> import java.lang.annotation.ElementType;
> import java.lang.annotation.Retention;
> import java.lang.annotation.RetentionPolicy;
> import java.lang.annotation.Target;
> 
> @Retention(RetentionPolicy.RUNTIME)
> @Target({ElementType.TYPE_USE, ElementType.TYPE_PARAMETER})
> @interface TA {
>   int value();
> }
> 
> class ArrayOfInner {
>   class Inner {}
> 
>   @TA(1) ArrayOfInner. @TA(2) Inner oi;
>   @TA(3) ArrayOfInner. @TA(4) Inner [] oia;
>   @TA(5) Inner i;
>   @TA(6) Inner [] ia;
> }
> 
> If compiled with javac 8, according to javap -v field ia has the annotation:
> 
>   ArrayOfInner$Inner[] ia;
>     descriptor: [LArrayOfInner$Inner;
>     flags: (0x0000)
>     RuntimeVisibleTypeAnnotations:
>       0: #10(#11=I#21): FIELD, location=[ARRAY, INNER_TYPE]
>         TA(
>           value=6
>         )
> 
> if compiled with javac > 8 ia has the annotation:
> 
>   ArrayOfInner$Inner[] ia;
>     descriptor: [LArrayOfInner$Inner;
>     flags: (0x0000)
>     RuntimeVisibleTypeAnnotations:
>       0: #10(#11=I#21): FIELD, location=[ARRAY]
>         TA(
>           value=6
>         )
> 
> Note the missing `INNER_TYPE` location. This PR is re-establishing the Java 8 behavior.
> 
> TIA

This pull request has now been integrated.

Changeset: 1480d418
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1480d418e3b7d1f36ace24a043a273fca446eefa
Stats:     86 lines in 4 files changed: 33 ins; 43 del; 10 mod

8208470: Type annotations on inner type that is an array component

Co-authored-by: Bernard Blaser <bsrbnd at openjdk.org>
Reviewed-by: jlahoda

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

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

From ljnelson at gmail.com  Thu Feb 16 04:48:44 2023
From: ljnelson at gmail.com (Laird Nelson)
Date: Wed, 15 Feb 2023 20:48:44 -0800
Subject: Question regarding type use annotation on method parameter type
In-Reply-To: <CAL4QsgsgqX2a-w+naSE2Wh+VpHDh-DxoBxhz=0m=Q73vSMbpmQ@mail.gmail.com>
References: <CAHNdxunKKizUVoRnZz8jWE0ENGxnz9Xz38b0qSH9vRfxBdg0yA@mail.gmail.com>
 <27a5a775-3704-a656-845b-72e471ffa3c3@oracle.com>
 <CAHNdxumRjw7e0ERRuVe5fskRn4MTd7j4yg=vHvhCv=Jgm7Zayg@mail.gmail.com>
 <CAL4QsgsgqX2a-w+naSE2Wh+VpHDh-DxoBxhz=0m=Q73vSMbpmQ@mail.gmail.com>
Message-ID: <CAHNdxu=3ZE+SisvdiBTrbZVGDVSTePJ=HYnKTW5J0tPZWhHhig@mail.gmail.com>

On Wed, Feb 15, 2023 at 7:57 PM Liam Miller-Cushon <cushon at google.com>
wrote:

> Should `sAsType.getAnnotations()` be `sAsType.getAnnotationMirrors()`?
>

Yes; my bad.


> It works for me if B is being compiled from source as part of the same
> compilation doing the annotation processing, but not if B is loaded from
> the classpath, which is consistent with this known issue:
> https://bugs.openjdk.org/browse/JDK-8225377
>

 That is exactly the circumstance I am experiencing. Thanks for the bug
pointer and I'll be on my way.

Best,
Laird

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230215/6c2a788c/attachment.htm>

From vicente.romero at oracle.com  Thu Feb 16 12:04:46 2023
From: vicente.romero at oracle.com (Vicente Romero)
Date: Thu, 16 Feb 2023 07:04:46 -0500
Subject: Question regarding type use annotation on method parameter type
In-Reply-To: <CAL4QsgsgqX2a-w+naSE2Wh+VpHDh-DxoBxhz=0m=Q73vSMbpmQ@mail.gmail.com>
References: <CAHNdxunKKizUVoRnZz8jWE0ENGxnz9Xz38b0qSH9vRfxBdg0yA@mail.gmail.com>
 <27a5a775-3704-a656-845b-72e471ffa3c3@oracle.com>
 <CAHNdxumRjw7e0ERRuVe5fskRn4MTd7j4yg=vHvhCv=Jgm7Zayg@mail.gmail.com>
 <CAL4QsgsgqX2a-w+naSE2Wh+VpHDh-DxoBxhz=0m=Q73vSMbpmQ@mail.gmail.com>
Message-ID: <482a1fd2-39ad-aae1-f20f-ff72187b06eb@oracle.com>

Hi,

I have added the test case below to [1], will do some research on it,

Thanks,
Vicente

[1] https://bugs.openjdk.org/browse/JDK-8225377

On 2/15/23 22:57, Liam Miller-Cushon wrote:
> Should `sAsType.getAnnotations()` be `sAsType.getAnnotationMirrors()`?
>
> It works for me if B is being compiled from source as part of the same 
> compilation doing the annotation processing, but not if B is loaded 
> from the classpath, which is consistent?with this known issue: 
> https://bugs.openjdk.org/browse/JDK-8225377
>
> $ javac -processor P -implicit:none ?-sourcepath : -parameters A.java 
> B.java
> Note: B.c(java.lang. at A String).s has annotations [@A]
> Note: B.c(java.lang. at A String).s has annotations [@A]
> $ javac -processor P -implicit:none ?-sourcepath : -parameters A.java
> Note: B.c(java.lang.String).s has annotations []
> Note: B.c(java.lang.String).s has annotations []
>
> === A.java ===
> import java.lang.annotation.ElementType;
> import java.lang.annotation.Retention;
> import java.lang.annotation.RetentionPolicy;
> import java.lang.annotation.Target;
>
> @Retention(RetentionPolicy.RUNTIME)
> @Target({ElementType.TYPE_USE})
> public @interface A {}
> === B.java ===
> public final class B {
> ? public static final void c(@A String s) {}
> }
> === P.java ===
> import java.util.Set;
> import javax.annotation.processing.AbstractProcessor;
> import javax.annotation.processing.RoundEnvironment;
> import javax.annotation.processing.SupportedAnnotationTypes;
> import javax.lang.model.SourceVersion;
> import javax.lang.model.element.Element;
> import javax.lang.model.element.ExecutableElement;
> import javax.lang.model.element.TypeElement;
> import javax.lang.model.element.VariableElement;
> import javax.lang.model.type.TypeMirror;
> import javax.lang.model.util.Elements;
> import javax.tools.Diagnostic;
>
> @SupportedAnnotationTypes("*")
> public class P extends AbstractProcessor {
> ? @Override
> ? public SourceVersion getSupportedSourceVersion() {
> ? ? return SourceVersion.latestSupported();
> ? }
>
> ? @Override
> ? public boolean process(Set<? extends TypeElement> annotations, 
> RoundEnvironment roundEnv) {
> ? ? Elements elements = processingEnv.getElementUtils();
> ? ? Element e = elements.getTypeElement("B");
> ? ? ExecutableElement c = (ExecutableElement) 
> e.getEnclosedElements().get(1);
> ? ? VariableElement s = c.getParameters().get(0);
> ? ? TypeMirror sAsType = s.asType();
> ? ? processingEnv
> ? ? ? ? .getMessager()
> ? ? ? ? .printMessage(
> ? ? ? ? ? ? Diagnostic.Kind.NOTE,
> ? ? ? ? ? ? String.format(
> ? ? ? ? ? ? ? ? "%s.%s.%s has annotations [%s]", e, c, s, 
> sAsType.getAnnotationMirrors()));
> ? ? return false;
> ? }
> }
>
> On Wed, Feb 15, 2023 at 6:00 PM Laird Nelson <ljnelson at gmail.com> wrote:
>
>     On Wed, Feb 15, 2023 at 5:07 PM Alex Buckley
>     <alex.buckley at oracle.com> wrote:
>
>         Via ExecutableElement::getParameters, the VariableElement which
>         represents the declaration of formal parameter `s` should
>         expose a
>         TypeMirror for the type `@A String`.
>
>
>     Thank you. That is exactly what I expected. It does not. Should I
>     file a bug?
>
>     Test code excerpted below:
>
>     Element e = elements.getTypeElement("B");
>     ExecutableElement c =
>     (ExecutableElement)e.getEnclosedElements().get(1); // 0 is the
>     implicit constructor; 1 is the c method
>     assert "c".equals(c.getSimpleName().toString()); // yep, got the
>     right method
>     VariableElement s = (VariableElement)c.getParameters().get(0);
>     assert "s".equals(s.getSimpleName().toString()); // yep, got the
>     right parameter
>     DeclaredType sAsType = (DeclaredType)s.asType();
>     assert !sAsType.getAnnotations().isEmpty(); // fails; it is empty
>
>     Thanks,
>     Laird
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230216/51ccfec4/attachment-0001.htm>

From jwaters at openjdk.org  Thu Feb 16 14:51:42 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 16 Feb 2023 14:51:42 GMT
Subject: RFR: 8302514: Misleading error generated when empty class file
 encountered [v2]
In-Reply-To: <ssZiZIVhB-jkWWMTPUpoSp-A0Xt_u63OKpPzUNCzsiU=.a1513e6b-7986-40bc-bf2b-cbe01cae9ecb@github.com>
References: <D3Zz9uIVp9iFDip3Pr0f6_QFYv2NNwFPNdejD9sa8KI=.b3d36e86-5162-4658-b71e-c650b81f1643@github.com>
 <ssZiZIVhB-jkWWMTPUpoSp-A0Xt_u63OKpPzUNCzsiU=.a1513e6b-7986-40bc-bf2b-cbe01cae9ecb@github.com>
Message-ID: <_7zhAgIgadhGf9ynRx3mbfaaaA4QSXBNWRqTBO6xgL0=.64e8bb25-ac80-4c5d-81bf-247e8de01329@github.com>

On Wed, 15 Feb 2023 16:23:54 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> When javac encounters an empty class file, you get the following strange error referring to `java.lang.AutoCloseable`:
>> 
>> Test.java:3: error: cannot access Empty
>>         new Empty();
>>             ^
>>   bad class file: ./Empty.class
>>     class file contains wrong class: java.lang.AutoCloseable
>>     Please remove or make sure it appears in the correct subdirectory of the classpath.
>> 1 error
>> 
>> This is a side effect of javac blindly reading past the end of the data in a data buffer. Further investigation revealed three distinct bugs in this area of the code:
>> 
>> 1. There are several unchecked corner cases in `ByteBuffer` and `ArrayUtils` that could potentially lead to `ArrayIndexOutOfBoundsException`s and/or infinite loops. Instead we should "fail fast" on any attempt to read or allocate data out of bounds.
>> 1. The method `ByteBuffer.appendStream()` assumes that the result from `InputStream.available()` is always accurate, but this is not guaranteed. As a result, class files could (in theory) be read incorrectly by the compiler, especially when they come from non-standard sources.
>> 1. There is no systematic protection against truncated class files. Instead, depending on where exactly it is truncated, a truncated class file generates one of several possible different errors:
>>    * `index 25926 is not within pool size 13`
>>    * `bad constant pool tag: 0 at 28317`
>>    * `unexpected constant pool tag: 10 at 11`
>>    * `class file is invalid for class Empty`
>>    * `class file contains wrong class: java.lang.AutoCloseable`
>> 
>> This patch fixes issues 1 and 2, and addresses 3 by having `ByteBuffer` throw a new unchecked `UnderflowException` if ever data is read past the end of the buffer. Then `PoolReader`, `ClassReader`, and `ModuleNameReader` are updated to catch this exception and convert it into a bad class file error. As a result, truncated class files generate a consistent `class file truncated at offset X` error regardless of where they are truncated.
>
> Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix another ArrayUtils corner case created by previous fix.

Marked as reviewed by jwaters (Committer).

Sponsoring out of goodwill

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

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

From duke at openjdk.org  Thu Feb 16 14:51:44 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Thu, 16 Feb 2023 14:51:44 GMT
Subject: Integrated: 8302514: Misleading error generated when empty class file
 encountered
In-Reply-To: <D3Zz9uIVp9iFDip3Pr0f6_QFYv2NNwFPNdejD9sa8KI=.b3d36e86-5162-4658-b71e-c650b81f1643@github.com>
References: <D3Zz9uIVp9iFDip3Pr0f6_QFYv2NNwFPNdejD9sa8KI=.b3d36e86-5162-4658-b71e-c650b81f1643@github.com>
Message-ID: <6qSLjSZBZPaggfiEfGv1mXDj_pZHJxR5CdxBBdIiHc0=.c0349576-b2d5-4d98-9627-626827844efb@github.com>

On Wed, 15 Feb 2023 15:59:36 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

> When javac encounters an empty class file, you get the following strange error referring to `java.lang.AutoCloseable`:
> 
> Test.java:3: error: cannot access Empty
>         new Empty();
>             ^
>   bad class file: ./Empty.class
>     class file contains wrong class: java.lang.AutoCloseable
>     Please remove or make sure it appears in the correct subdirectory of the classpath.
> 1 error
> 
> This is a side effect of javac blindly reading past the end of the data in a data buffer. Further investigation revealed three distinct bugs in this area of the code:
> 
> 1. There are several unchecked corner cases in `ByteBuffer` and `ArrayUtils` that could potentially lead to `ArrayIndexOutOfBoundsException`s and/or infinite loops. Instead we should "fail fast" on any attempt to read or allocate data out of bounds.
> 1. The method `ByteBuffer.appendStream()` assumes that the result from `InputStream.available()` is always accurate, but this is not guaranteed. As a result, class files could (in theory) be read incorrectly by the compiler, especially when they come from non-standard sources.
> 1. There is no systematic protection against truncated class files. Instead, depending on where exactly it is truncated, a truncated class file generates one of several possible different errors:
>    * `index 25926 is not within pool size 13`
>    * `bad constant pool tag: 0 at 28317`
>    * `unexpected constant pool tag: 10 at 11`
>    * `class file is invalid for class Empty`
>    * `class file contains wrong class: java.lang.AutoCloseable`
> 
> This patch fixes issues 1 and 2, and addresses 3 by having `ByteBuffer` throw a new unchecked `UnderflowException` if ever data is read past the end of the buffer. Then `PoolReader`, `ClassReader`, and `ModuleNameReader` are updated to catch this exception and convert it into a bad class file error. As a result, truncated class files generate a consistent `class file truncated at offset X` error regardless of where they are truncated.

This pull request has now been integrated.

Changeset: a58fa6e7
Author:    Archie L. Cobbs <archie.cobbs at gmail.com>
Committer: Julian Waters <jwaters at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a58fa6e73e4594cfb0e46bdbebad48072771e5bd
Stats:     351 lines in 10 files changed: 306 ins; 0 del; 45 mod

8302514: Misleading error generated when empty class file encountered

Reviewed-by: vromero, jwaters

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

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

From duke at openjdk.org  Thu Feb 16 14:54:00 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Thu, 16 Feb 2023 14:54:00 GMT
Subject: RFR: 7176515: ExceptionInInitializerError for an enum with
 multiple switch statements [v9]
In-Reply-To: <FKWN191gv60Eb-KStj4-Q1YA_4D1Yo4HwBfYHeJzjaM=.1d06b7f6-91c5-42e2-983d-e2c061f3c650@github.com>
References: <FKWN191gv60Eb-KStj4-Q1YA_4D1Yo4HwBfYHeJzjaM=.1d06b7f6-91c5-42e2-983d-e2c061f3c650@github.com>
Message-ID: <no9Gh0lJ3DJ48nFVQTXJUwMnDyUKq1bme0AXKyUVk2k=.49bd05e4-24e8-467a-bf42-978c70396360@github.com>

> This patch is both a minor optimization and a fix for JDK-7176515.
> 
> JDK-7176515 relates to how javac handles `switch` statements on `Enum` values, which are effectively "syntactic sugar".
> 
> The simple approach would be to just get the enum's `ordinal()` value and then revert to a normal integer value switch on that. However, this snapshots the ordinal values at compile-time, and thus can fail if the `Enum` class is recompiled later.
> 
> Presumably to avoid that possibility (are there any other reasons?) the compiler instead uses a lookup table. This table is dynamically constructed at runtime by a static initializer in a synthetic class. This avoids the "stale ordinal" problem of the simple approach, but it also creates a potential class initialization loop if there happens to an `Enum` switch inside an `Enum` class constructor, as demonstrated by the bug.
> 
> This patch makes the following change: If we are handling an `Enum` switch, and the `Enum` class we are switching on is also the class we are compiling, then just go with the simple approach, because the "stale ordinal" problem can't happen in this case so there's no need to build a runtime lookup table.
> 
> This results in two improvements:
> * It avoids building the lookup table for switches on self
> * It fixes JDK-7176515 as stated
> 
> Although the reproducing test case provided in JDK-7176515 gets fixed by this patch, the underlying issue is still there and can still be triggered with a slightly more complicated test case (included, but commented out).
> 
> So JDK-7176515 could be left open (or a new bug created) and a separate discussion had about how to "really" fix it.
> 
> Part of this discussion should be defining what that means, i.e., the boundaries of the bug. There are some scenarios that are basically impossible to fix, for example, two `Enum` classes whose constructors take as a parameter instances of the other `Enum` class and then switch on it. That cycle has nothing to do with how switches are handled.

Archie L. Cobbs 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 ten additional commits since the last revision:

 - Merge branch 'master' into JDK-7176515
 - Simplify code a bit by using Map.computeIfAbsent().
 - Update unit test after fixing 8299760.
 - Revert 2nd part of previous commit ("Put mapping tables for different...").
   
   This should go into a separate branch.
 - Further refinements to compiler-generated mappings tables for switched-on enums.
   
   - No mapping table needed for any Enum class within the same top level class.
   - Put mapping tables for different enum types into separate synthetic classes.
 - Merge branch 'master' into JDK-7176515
 - Merge branch 'master' into JDK-7176515
 - Give test a better name and don't rely on assertions being enabled.
 - Skip enum switch lookup tables when compiling the enum switch class.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10797/files
  - new: https://git.openjdk.org/jdk/pull/10797/files/53be679b..8987541c

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

  Stats: 126177 lines in 4278 files changed: 55096 ins; 29168 del; 41913 mod
  Patch: https://git.openjdk.org/jdk/pull/10797.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10797/head:pull/10797

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

From jjg at openjdk.org  Thu Feb 16 16:54:29 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 16 Feb 2023 16:54:29 GMT
Subject: RFR: 8296010: AssertionError in annotationTargetType [v4]
In-Reply-To: <C9bLN17IiFg9JJayGFja9yLqhGwDMLYAAYlyAF0HThI=.3c72c3ee-f98c-4e86-929c-ef29417a22c4@github.com>
References: <DvQdjvJhItRaHF_AkTkzwM7yvZ4DUvuahgM2a9C1LHQ=.c23bb346-eed7-4d54-99b5-42969bc55ccf@github.com>
 <C9bLN17IiFg9JJayGFja9yLqhGwDMLYAAYlyAF0HThI=.3c72c3ee-f98c-4e86-929c-ef29417a22c4@github.com>
Message-ID: <LrH6J47EBaICJ1HUCz0jgGhrBdveIwAx2sau1sJl8Lo=.a309c130-51f2-4572-8bf3-798a84da4f13@github.com>

On Wed, 1 Feb 2023 14:06:15 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> javac is crashing if a class file is forged so that an annotation can be applicable to an unknown target. It would be equivalent to the following declaration:
>> 
>> 
>> @Target({ElementType.FIELD, ElementType.NO_SUCH})
>> @interface A {}
>> 
>> if the compiler process this source it would issue a compiler error, indicating that symbol `NO_SUCH` cant be found. Currently our class reader just issues a warning and move on. This is OK as it could be that the loaded class won't be used anyway but if this annotation is actually applied to symbol as in:
>> 
>> 
>> class B {
>>     @A Object o;
>> }
>> 
>> then this to my understanding should be a compilation error. Currently javac is crashing and this is not acceptable, so this PR is fixing this issue so that a compilation error is issued instead.
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor update

Approved, with a minor suggestion to tweak the error message.

src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties line 160:

> 158: # 0: type, 1: name
> 159: compiler.err.annotation.unrecognized.attribute.name=\
> 160:     annotation @{0} has an unrecognizable attribute named ''{1}''

"unrecognizable" seems a strange word here;  would "unknown" be a better word?

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

Marked as reviewed by jjg (Reviewer).

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

From vromero at openjdk.org  Thu Feb 16 17:49:26 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 16 Feb 2023 17:49:26 GMT
Subject: RFR: JDK-8302202: Incorrect desugaring of null-allowed nested
 patterns
In-Reply-To: <E-Jv1xFu4_33w3rXpwbfzeVeCRupcQ_XChtuwfxwFI4=.65a9ebe9-ef47-4659-a6cc-1386e24a00c9@github.com>
References: <E-Jv1xFu4_33w3rXpwbfzeVeCRupcQ_XChtuwfxwFI4=.65a9ebe9-ef47-4659-a6cc-1386e24a00c9@github.com>
Message-ID: <5om9VsN6JORmS0tLDeCwN2twa6W5WBDow9JsxgHA5O8=.d408b6fd-749c-4841-ae9c-f540499d7f9e@github.com>

On Wed, 15 Feb 2023 13:16:10 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Considering code like:
> 
>     private String test1b(Object i) {
>         return switch (i) {
>             case R1(Object o) when o == null -> "R1(null)";
>             case R1(Object o) -> "R1(!null)";
>             default -> "default";
>         };
>     }
> 
> 
> javac will try to factor-out the common prefix, i.e. `R1`, and produce something along these lines:
> 
>         switch (i) {
>             case R1 $r:
>                 Object c = $r.c();
>                 switch (c) {
>                     case Object o when o == null: yield "R1(null)";
>                     case Object o: yield "R1(!null)";
>                 }
>             default -> "default";
>         };
> 
> 
> The problem with this code is that both cases in the nested switch must match `null`, but the bootstrap protocol only allows one case to match `null` (the `SwitchBootstraps.typeSwitch` method will return `-1` for `null`). So this translation is broken, and will not match the first case if the component is `null`.
> 
> There are multiple ways to solve this problem, but the proposal here is change the way we accumulate the cases from which we factor out the common prefix, by stopping the accumulation after the first nullable case.
> 
> Another related issue is that when factoring out the common prefix, if the last case in the nested switch is has an unconditional pattern, but also has a guard, we need to generate a default to continue properly in the outer switch. Currently, the default is not generated when there's an unconditional pattern in the case, despite having a guard, and hence the case as a whole is not unconditional.

looks sensible

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

Marked as reviewed by vromero (Reviewer).

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

From duke at openjdk.org  Thu Feb 16 17:56:16 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Thu, 16 Feb 2023 17:56:16 GMT
Subject: RFR: 7016187: `javac -h` could generate conflict .h for inner class
 and class name with '_'
Message-ID: <TjKjaZLrq5AnmfxbBfv7Yr29TRkl7p_egrz8AzCTGf8=.c5953e6d-6ff2-4a4f-8327-a3cc956a3e0b@github.com>

Consider these two classes:

public class Foo_Bar {
    public static native void method();
}


public class Foo {
    public static class Bar {
        public static native void method();
    }
}

If you run `javac -h` to generate native header files, classes `Foo_Bar` and `Foo$Bar` will want to generate the same native header file `Foo_Bar.h`.

Currently, javac does not detect this situation, so in effect you get a "last writer wins" situation.

This patch causes compilation to fail instead in this case with an error like this:

Foo.java:2: error: error while writing Bar: native header file collision between Foo_Bar and Foo$Bar (both generate Foo_Bar.h)
    public static class Bar {
                  ^
1 error

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

Commit messages:
 - Fail "-h" compilation if two classes generate the same native header file.

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

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

From vromero at openjdk.org  Thu Feb 16 18:31:29 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 16 Feb 2023 18:31:29 GMT
Subject: RFR: 8296010: AssertionError in annotationTargetType [v4]
In-Reply-To: <LrH6J47EBaICJ1HUCz0jgGhrBdveIwAx2sau1sJl8Lo=.a309c130-51f2-4572-8bf3-798a84da4f13@github.com>
References: <DvQdjvJhItRaHF_AkTkzwM7yvZ4DUvuahgM2a9C1LHQ=.c23bb346-eed7-4d54-99b5-42969bc55ccf@github.com>
 <C9bLN17IiFg9JJayGFja9yLqhGwDMLYAAYlyAF0HThI=.3c72c3ee-f98c-4e86-929c-ef29417a22c4@github.com>
 <LrH6J47EBaICJ1HUCz0jgGhrBdveIwAx2sau1sJl8Lo=.a309c130-51f2-4572-8bf3-798a84da4f13@github.com>
Message-ID: <b7WV5VSuFvVckJ0QBrxrjifJh92sE0ZaQHdf5zKrGWg=.f0d04778-fdb6-45e8-a450-c01994133c2d@github.com>

On Thu, 16 Feb 2023 16:48:32 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   minor update
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties line 160:
> 
>> 158: # 0: type, 1: name
>> 159: compiler.err.annotation.unrecognized.attribute.name=\
>> 160:     annotation @{0} has an unrecognizable attribute named ''{1}''
> 
> "unrecognizable" seems a strange word here;  would "unknown" be a better word?

sure will fix, thanks for the review

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

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

From vromero at openjdk.org  Thu Feb 16 19:11:02 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 16 Feb 2023 19:11:02 GMT
Subject: RFR: 8296010: AssertionError in annotationTargetType [v5]
In-Reply-To: <DvQdjvJhItRaHF_AkTkzwM7yvZ4DUvuahgM2a9C1LHQ=.c23bb346-eed7-4d54-99b5-42969bc55ccf@github.com>
References: <DvQdjvJhItRaHF_AkTkzwM7yvZ4DUvuahgM2a9C1LHQ=.c23bb346-eed7-4d54-99b5-42969bc55ccf@github.com>
Message-ID: <85ls9hZRJmwcInPWv3-qV8tc-atv2ahYO8AtK2Z_MiQ=.da45a4c0-1bb5-42f9-8ac7-1022373000c5@github.com>

> javac is crashing if a class file is forged so that an annotation can be applicable to an unknown target. It would be equivalent to the following declaration:
> 
> 
> @Target({ElementType.FIELD, ElementType.NO_SUCH})
> @interface A {}
> 
> if the compiler process this source it would issue a compiler error, indicating that symbol `NO_SUCH` cant be found. Currently our class reader just issues a warning and move on. This is OK as it could be that the loaded class won't be used anyway but if this annotation is actually applied to symbol as in:
> 
> 
> class B {
>     @A Object o;
> }
> 
> then this to my understanding should be a compilation error. Currently javac is crashing and this is not acceptable, so this PR is fixing this issue so that a compilation error is issued instead.

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

  updating error message

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12241/files
  - new: https://git.openjdk.org/jdk/pull/12241/files/80014873..12bfce67

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

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

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

From vromero at openjdk.org  Thu Feb 16 19:11:03 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 16 Feb 2023 19:11:03 GMT
Subject: Integrated: 8296010: AssertionError in annotationTargetType
In-Reply-To: <DvQdjvJhItRaHF_AkTkzwM7yvZ4DUvuahgM2a9C1LHQ=.c23bb346-eed7-4d54-99b5-42969bc55ccf@github.com>
References: <DvQdjvJhItRaHF_AkTkzwM7yvZ4DUvuahgM2a9C1LHQ=.c23bb346-eed7-4d54-99b5-42969bc55ccf@github.com>
Message-ID: <_zcjZD1COA8jcfZEN7MsVTDURvOmaiyBKkJEQLrLvXA=.602e7f04-c029-4473-bb60-b1dc5e5c87aa@github.com>

On Fri, 27 Jan 2023 05:13:35 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> javac is crashing if a class file is forged so that an annotation can be applicable to an unknown target. It would be equivalent to the following declaration:
> 
> 
> @Target({ElementType.FIELD, ElementType.NO_SUCH})
> @interface A {}
> 
> if the compiler process this source it would issue a compiler error, indicating that symbol `NO_SUCH` cant be found. Currently our class reader just issues a warning and move on. This is OK as it could be that the loaded class won't be used anyway but if this annotation is actually applied to symbol as in:
> 
> 
> class B {
>     @A Object o;
> }
> 
> then this to my understanding should be a compilation error. Currently javac is crashing and this is not acceptable, so this PR is fixing this issue so that a compilation error is issued instead.

This pull request has now been integrated.

Changeset: de80dd9c
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/de80dd9c15cd3194ba8c512498d37a76c747e5fc
Stats:     230 lines in 8 files changed: 199 ins; 1 del; 30 mod

8296010: AssertionError in annotationTargetType

Reviewed-by: jjg

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

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

From duke at openjdk.org  Thu Feb 16 19:19:03 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Thu, 16 Feb 2023 19:19:03 GMT
Subject: RFR: 7033677: potential cast error in MemberEnter
Message-ID: <Y8st9ibTZLr_bFTbvipZCmHDkd5XvG-I038n9QhxaD8=.ae5bb57a-29ec-4ff6-90cb-973bd6277eaa@github.com>

In an `import` statement, the thing imported is always a `JCFieldAccess` (it's not legal in Java to import a simple name).

Therefore the type of `JCFieldAccess.qualid`, which is currently `JCTree`, is unnecessarily wide and can be narrowed to `JCFieldAccess`.

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

Commit messages:
 - Narrow the type of JCImport.qualid from JCTree to JCFieldAccess.

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

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

From vromero at openjdk.org  Thu Feb 16 19:48:28 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 16 Feb 2023 19:48:28 GMT
Subject: RFR: 7033677: potential cast error in MemberEnter
In-Reply-To: <Y8st9ibTZLr_bFTbvipZCmHDkd5XvG-I038n9QhxaD8=.ae5bb57a-29ec-4ff6-90cb-973bd6277eaa@github.com>
References: <Y8st9ibTZLr_bFTbvipZCmHDkd5XvG-I038n9QhxaD8=.ae5bb57a-29ec-4ff6-90cb-973bd6277eaa@github.com>
Message-ID: <ctecArI2YspGiz-aHb-3BPj_5Lg0_3Uf51p0wi3XjYg=.e4b3c4f4-c571-4797-9793-342c4d082eaf@github.com>

On Thu, 16 Feb 2023 19:12:23 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

> In an `import` statement, the thing imported is always a `JCFieldAccess` (it's not legal in Java to import a simple name).
> 
> Therefore the type of `JCFieldAccess.qualid`, which is currently `JCTree`, is unnecessarily wide and can be narrowed to `JCFieldAccess`.

not sure as the JLS, section: `7.5.1 Single-Type-Import Declarations` has this rule:


SingleTypeImportDeclaration:
    import TypeName ;

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

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

From duke at openjdk.org  Thu Feb 16 19:57:26 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Thu, 16 Feb 2023 19:57:26 GMT
Subject: RFR: 7033677: potential cast error in MemberEnter
In-Reply-To: <ctecArI2YspGiz-aHb-3BPj_5Lg0_3Uf51p0wi3XjYg=.e4b3c4f4-c571-4797-9793-342c4d082eaf@github.com>
References: <Y8st9ibTZLr_bFTbvipZCmHDkd5XvG-I038n9QhxaD8=.ae5bb57a-29ec-4ff6-90cb-973bd6277eaa@github.com>
 <ctecArI2YspGiz-aHb-3BPj_5Lg0_3Uf51p0wi3XjYg=.e4b3c4f4-c571-4797-9793-342c4d082eaf@github.com>
Message-ID: <nxOyKQHoD7mRKpcsFEPk9KRfofZjVlVAl8shCNh7B_E=.2e6d4040-1236-4763-a673-31e25f76a603@github.com>

On Thu, 16 Feb 2023 19:45:44 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> not sure as the JLS, section: `7.5.1 Single-Type-Import Declarations` has this rule:
> 
> ```
> SingleTypeImportDeclaration:
>     import TypeName ;
> ```

Yes - but it then says:

> The class or interface must be either a member of a named package, or a member of a class or interface whose outermost lexically enclosing class or interface declaration ([?8.1.3](https://docs.oracle.com/javase/specs/jls/se19/html/jls-8.html#jls-8.1.3)) is a member of a named package, or a compile-time error occurs.

Also, the parser won't accept a single identifier.

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

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

From vromero at openjdk.org  Thu Feb 16 20:13:27 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 16 Feb 2023 20:13:27 GMT
Subject: RFR: 7033677: potential cast error in MemberEnter
In-Reply-To: <nxOyKQHoD7mRKpcsFEPk9KRfofZjVlVAl8shCNh7B_E=.2e6d4040-1236-4763-a673-31e25f76a603@github.com>
References: <Y8st9ibTZLr_bFTbvipZCmHDkd5XvG-I038n9QhxaD8=.ae5bb57a-29ec-4ff6-90cb-973bd6277eaa@github.com>
 <ctecArI2YspGiz-aHb-3BPj_5Lg0_3Uf51p0wi3XjYg=.e4b3c4f4-c571-4797-9793-342c4d082eaf@github.com>
 <nxOyKQHoD7mRKpcsFEPk9KRfofZjVlVAl8shCNh7B_E=.2e6d4040-1236-4763-a673-31e25f76a603@github.com>
Message-ID: <neijce8AbxGqrJInnUlcvv5FXV8xclyYdVayuhHiFf8=.585a26ab-6512-455c-800b-59c93103cc67@github.com>

On Thu, 16 Feb 2023 19:55:04 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

> > not sure as the JLS, section: `7.5.1 Single-Type-Import Declarations` has this rule:
> > ```
> > SingleTypeImportDeclaration:
> >     import TypeName ;
> > ```
> 
> Yes - but it then says:
> 
> > The class or interface must be either a member of a named package, or a member of a class or interface whose outermost lexically enclosing class or interface declaration ([?8.1.3](https://docs.oracle.com/javase/specs/jls/se19/html/jls-8.html#jls-8.1.3)) is a member of a named package, or a compile-time error occurs.
> 
> Also, the parser won't accept a single identifier.

yep the parser won't accept it, I was just not sure if the spec was missing some clarification but yes that's text clarifies the issue

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

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

From vromero at openjdk.org  Thu Feb 16 20:17:27 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 16 Feb 2023 20:17:27 GMT
Subject: RFR: 7033677: potential cast error in MemberEnter
In-Reply-To: <Y8st9ibTZLr_bFTbvipZCmHDkd5XvG-I038n9QhxaD8=.ae5bb57a-29ec-4ff6-90cb-973bd6277eaa@github.com>
References: <Y8st9ibTZLr_bFTbvipZCmHDkd5XvG-I038n9QhxaD8=.ae5bb57a-29ec-4ff6-90cb-973bd6277eaa@github.com>
Message-ID: <LBZKeyiw9iYjUA68OYoyJIaxJlRehxwHEcf7xKsl4r8=.6fb99295-223e-48f7-9e0a-2c7555144d0a@github.com>

On Thu, 16 Feb 2023 19:12:23 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

> In an `import` statement, the thing imported is always a `JCFieldAccess` (it's not legal in Java to import a simple name).
> 
> Therefore the type of `JCFieldAccess.qualid`, which is currently `JCTree`, is unnecessarily wide and can be narrowed to `JCFieldAccess`.

looks good

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

Marked as reviewed by vromero (Reviewer).

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

From ljnelson at gmail.com  Thu Feb 16 21:31:06 2023
From: ljnelson at gmail.com (Laird Nelson)
Date: Thu, 16 Feb 2023 13:31:06 -0800
Subject: Is a TYPE_USE annotation stored as such in a class file?
Message-ID: <CAHNdxu=Jk=Vt3UD1+DZ=Lmg+1Dtmx4DG9SeDXrKrXWiCbB+e7w@mail.gmail.com>

Another TYPE_USE question. Consider:

@Retention(RetentionPolicy.RUNTIME)
@Target({ ElementType.TYPE_USE })
@interface A {}

@A class B{}

I am surprised to see @A in the returned array from
B.class.getAnnotations() since it is not an element annotation.

Furthermore, I do not see the string "RuntimeVisibleTypeAnnotations" in the
class file for B (which is why I'm writing to the compiler-dev list). I am
no VM/bytecode person but I would expect to see that if a runtime-visible
type use annotation is being recorded, yes? Although I do not see a place
in the target_info structure that would to my naive eyes be suitable for
this particular usage.

Is @A's usage here recorded in the wrong place as the wrong sort of thing?
This has a whiff of https://bugs.openjdk.org/browse/JDK-8030751 to it but I
wanted to confirm.

Thanks,
Laird
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230216/5bd92c23/attachment.htm>

From jlahoda at openjdk.org  Thu Feb 16 21:39:06 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 16 Feb 2023 21:39:06 GMT
Subject: RFR: 7033677: potential cast error in MemberEnter
In-Reply-To: <Y8st9ibTZLr_bFTbvipZCmHDkd5XvG-I038n9QhxaD8=.ae5bb57a-29ec-4ff6-90cb-973bd6277eaa@github.com>
References: <Y8st9ibTZLr_bFTbvipZCmHDkd5XvG-I038n9QhxaD8=.ae5bb57a-29ec-4ff6-90cb-973bd6277eaa@github.com>
Message-ID: <LeT_pI8l_h45BAKxcISOF1ZK1giUKCNKqTEs2mDtuhI=.17a3d8c2-dc72-42ed-bb44-771689481b33@github.com>

On Thu, 16 Feb 2023 19:12:23 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

> In an `import` statement, the thing imported is always a `JCFieldAccess` (it's not legal in Java to import a simple name).
> 
> Therefore the type of `JCFieldAccess.qualid`, which is currently `JCTree`, is unnecessarily wide and can be narrowed to `JCFieldAccess`.

Looks reasonable to me, but please note that `test/langtools/jdk/javadoc/tool/sampleapi/lib/sampleapi/generator/PackageGenerator.java` needs to be fixed as well - on line 280. (Please see the results from GitHub Actions.)

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

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

From duke at openjdk.org  Thu Feb 16 21:39:45 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Thu, 16 Feb 2023 21:39:45 GMT
Subject: RFR: 8302685: Some javac unit tests aren't reliably closing open files
Message-ID: <Gz1mh8dLxhqpmPWa3S9V_v-nR5aTC-l4JrEFINKl9Xg=.eab3b0c4-a3e9-44d6-b710-5ce7b354350d@github.com>

Some javac unit tests aren't reliably closing open files. Many were written prior to (or without utilizing) try-with-resources.

Leaving files and other resources open can cause problems during automated builds, etc.

This patch updates these tests to use try-with-resource.

Side note: there is at least one unit test that intentionally leaves a file open - `diags/examples/ProcUnclosedTypeFiles/processors/AnnoProc.java`.

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

Commit messages:
 - Use try-with-resources in unit tests to ensure files are closed.

Changes: https://git.openjdk.org/jdk/pull/12609/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12609&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8302685
  Stats: 445 lines in 58 files changed: 54 ins; 205 del; 186 mod
  Patch: https://git.openjdk.org/jdk/pull/12609.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12609/head:pull/12609

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

From cushon at google.com  Thu Feb 16 21:59:32 2023
From: cushon at google.com (Liam Miller-Cushon)
Date: Thu, 16 Feb 2023 13:59:32 -0800
Subject: Is a TYPE_USE annotation stored as such in a class file?
In-Reply-To: <CAHNdxu=Jk=Vt3UD1+DZ=Lmg+1Dtmx4DG9SeDXrKrXWiCbB+e7w@mail.gmail.com>
References: <CAHNdxu=Jk=Vt3UD1+DZ=Lmg+1Dtmx4DG9SeDXrKrXWiCbB+e7w@mail.gmail.com>
Message-ID: <CAL4QsgsZptH2Lm74g-nje8zwggrYJ+-qUay=0t0QwxfGMvJ6hA@mail.gmail.com>

I think this is deliberate and covered by
https://docs.oracle.com/javase/specs/jls/se19/html/jls-9.html#jls-9.7.4

A declaration annotation is ... an annotation that applies to a class,
> interface, or type parameter declaration, and whose annotation interface is
> applicable in type contexts


 But I'm not completely sure, and welcome corrections to my reading of the
spec :)

On Thu, Feb 16, 2023 at 1:31 PM Laird Nelson <ljnelson at gmail.com> wrote:

> Another TYPE_USE question. Consider:
>
> @Retention(RetentionPolicy.RUNTIME)
> @Target({ ElementType.TYPE_USE })
> @interface A {}
>
> @A class B{}
>
> I am surprised to see @A in the returned array from
> B.class.getAnnotations() since it is not an element annotation.
>
> Furthermore, I do not see the string "RuntimeVisibleTypeAnnotations" in
> the class file for B (which is why I'm writing to the compiler-dev list). I
> am no VM/bytecode person but I would expect to see that if a
> runtime-visible type use annotation is being recorded, yes? Although I do
> not see a place in the target_info structure that would to my naive eyes be
> suitable for this particular usage.
>
> Is @A's usage here recorded in the wrong place as the wrong sort of
> thing?  This has a whiff of https://bugs.openjdk.org/browse/JDK-8030751
> to it but I wanted to confirm.
>
> Thanks,
> Laird
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230216/e6ef7c49/attachment.htm>

From ljnelson at gmail.com  Thu Feb 16 22:33:01 2023
From: ljnelson at gmail.com (Laird Nelson)
Date: Thu, 16 Feb 2023 14:33:01 -0800
Subject: Is a TYPE_USE annotation stored as such in a class file?
In-Reply-To: <CAL4QsgsZptH2Lm74g-nje8zwggrYJ+-qUay=0t0QwxfGMvJ6hA@mail.gmail.com>
References: <CAHNdxu=Jk=Vt3UD1+DZ=Lmg+1Dtmx4DG9SeDXrKrXWiCbB+e7w@mail.gmail.com>
 <CAL4QsgsZptH2Lm74g-nje8zwggrYJ+-qUay=0t0QwxfGMvJ6hA@mail.gmail.com>
Message-ID: <CAHNdxum=L5StdWmoNbvRCsb7Bg9wo=OEJ6W2QkwAuqk18P258Q@mail.gmail.com>

On Thu, Feb 16, 2023 at 1:59 PM Liam Miller-Cushon <cushon at google.com>
wrote:

> I think this is deliberate and covered by
> https://docs.oracle.com/javase/specs/jls/se19/html/jls-9.html#jls-9.7.4
>
> A declaration annotation is ... an annotation that applies to a class,
>> interface, or type parameter declaration, and whose annotation interface is
>> applicable in type contexts
>
>
But @A does not have ElementType.TYPE which is what I take to be the
manifestation of ?applicable in type contexts?. Maybe I?m wrong?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230216/5f1f03fe/attachment.htm>

From alex.buckley at oracle.com  Thu Feb 16 22:41:33 2023
From: alex.buckley at oracle.com (Alex Buckley)
Date: Thu, 16 Feb 2023 14:41:33 -0800
Subject: Is a TYPE_USE annotation stored as such in a class file?
In-Reply-To: <CAL4QsgsZptH2Lm74g-nje8zwggrYJ+-qUay=0t0QwxfGMvJ6hA@mail.gmail.com>
References: <CAHNdxu=Jk=Vt3UD1+DZ=Lmg+1Dtmx4DG9SeDXrKrXWiCbB+e7w@mail.gmail.com>
 <CAL4QsgsZptH2Lm74g-nje8zwggrYJ+-qUay=0t0QwxfGMvJ6hA@mail.gmail.com>
Message-ID: <7419cf15-41dc-4389-f06e-c88e1063fe17@oracle.com>

Correct. The `@A` in `@A class B {}` is a declaration annotation, hence 
appears in a RuntimeVisibleAnnotations attribute in B.class.

The next line in 9.7.4 is:

   A type annotation is an annotation that applies to a type
   (or any part of a type), and whose annotation interface is
   applicable in type contexts.

Since this `@A` doesn't apply to a type, it's not a type annotation, 
hence there is no RuntimeVisibleTypeAnnotations attribute.

The ability of a TYPE_USE annotation interface (`A`) to beget 
declaration annotations in certain locations is a feature rooted in the 
broader context of JSR 308, involving a desire to take older annotation 
interfaces (e.g., with target ElementType.TYPE) and write their 
annotations in both old (declaration) contexts and new (type) contexts.

Alex

On 2/16/2023 1:59 PM, Liam Miller-Cushon wrote:
> I think this is deliberate and covered by 
> https://docs.oracle.com/javase/specs/jls/se19/html/jls-9.html#jls-9.7.4 
> <https://docs.oracle.com/javase/specs/jls/se19/html/jls-9.html#jls-9.7.4>
> 
>     A declaration annotation is ... an annotation that applies to a
>     class, interface, or type parameter declaration, and whose
>     annotation interface is applicable in type contexts
> 
> 
>  ?But I'm not completely sure, and welcome corrections to my reading of 
> the spec :)
> 
> On Thu, Feb 16, 2023 at 1:31 PM Laird Nelson <ljnelson at gmail.com 
> <mailto:ljnelson at gmail.com>> wrote:
> 
>     Another TYPE_USE question. Consider:
> 
>     @Retention(RetentionPolicy.RUNTIME)
>     @Target({ ElementType.TYPE_USE })
>     @interface A {}
> 
>     @A class B{}
> 
>     I am surprised to see?@A in the returned array from
>     B.class.getAnnotations() since it is not an element annotation.
> 
>     Furthermore, I do not see the string?"RuntimeVisibleTypeAnnotations"
>     in the class file for B (which is why I'm writing to the
>     compiler-dev list). I am no VM/bytecode person but I would expect to
>     see that if a runtime-visible type use annotation is being recorded,
>     yes? Although I do not see a place in the target_info structure that
>     would to my naive eyes be suitable for this particular usage.
> 
>     Is @A's usage here recorded in the wrong place as the wrong sort of
>     thing?? This has a whiff of
>     https://bugs.openjdk.org/browse/JDK-8030751
>     <https://bugs.openjdk.org/browse/JDK-8030751> to it but I wanted to
>     confirm.
> 
>     Thanks,
>     Laird
> 

From alex.buckley at oracle.com  Thu Feb 16 22:43:22 2023
From: alex.buckley at oracle.com (Alex Buckley)
Date: Thu, 16 Feb 2023 14:43:22 -0800
Subject: Is a TYPE_USE annotation stored as such in a class file?
In-Reply-To: <CAHNdxum=L5StdWmoNbvRCsb7Bg9wo=OEJ6W2QkwAuqk18P258Q@mail.gmail.com>
References: <CAHNdxu=Jk=Vt3UD1+DZ=Lmg+1Dtmx4DG9SeDXrKrXWiCbB+e7w@mail.gmail.com>
 <CAL4QsgsZptH2Lm74g-nje8zwggrYJ+-qUay=0t0QwxfGMvJ6hA@mail.gmail.com>
 <CAHNdxum=L5StdWmoNbvRCsb7Bg9wo=OEJ6W2QkwAuqk18P258Q@mail.gmail.com>
Message-ID: <5adc8681-b015-f591-84bd-68b8d8a51444@oracle.com>

On 2/16/2023 2:33 PM, Laird Nelson wrote:
> On Thu, Feb 16, 2023 at 1:59 PM Liam Miller-Cushon <cushon at google.com 
> <mailto:cushon at google.com>> wrote:
> 
>     I think this is deliberate and covered by
>     https://docs.oracle.com/javase/specs/jls/se19/html/jls-9.html#jls-9.7.4 <https://docs.oracle.com/javase/specs/jls/se19/html/jls-9.html#jls-9.7.4>
> 
>         A declaration annotation is ... an annotation that applies to a
>         class, interface, or type parameter declaration, and whose
>         annotation interface is applicable in type contexts
> 
> 
> But @A does not have ElementType.TYPE which is what I take to be the 
> manifestation of ?applicable in type contexts?. Maybe I?m wrong?

The annotation interface A has ElementType.TYPE_USE === applicable in 
type contexts (9.6.4.1).

Alex

From ljnelson at gmail.com  Thu Feb 16 22:46:31 2023
From: ljnelson at gmail.com (Laird Nelson)
Date: Thu, 16 Feb 2023 14:46:31 -0800
Subject: Is a TYPE_USE annotation stored as such in a class file?
In-Reply-To: <5adc8681-b015-f591-84bd-68b8d8a51444@oracle.com>
References: <CAHNdxu=Jk=Vt3UD1+DZ=Lmg+1Dtmx4DG9SeDXrKrXWiCbB+e7w@mail.gmail.com>
 <CAL4QsgsZptH2Lm74g-nje8zwggrYJ+-qUay=0t0QwxfGMvJ6hA@mail.gmail.com>
 <CAHNdxum=L5StdWmoNbvRCsb7Bg9wo=OEJ6W2QkwAuqk18P258Q@mail.gmail.com>
 <5adc8681-b015-f591-84bd-68b8d8a51444@oracle.com>
Message-ID: <CAHNdxunPm1NJke103Q5YtpX7g-3BciuQXwe0KFs=Aq+sz_3uyg@mail.gmail.com>

On Thu, Feb 16, 2023 at 2:43 PM Alex Buckley <alex.buckley at oracle.com>
wrote:

> The annotation interface A has ElementType.TYPE_USE === applicable in
> type contexts (9.6.4.1).
>

If you have the time and for my own learning: which of the 17 type contexts
in 4.11 (
https://docs.oracle.com/javase/specs/jls/se19/html/jls-4.html#jls-4.11) is:

class B

...such that @A is applicable in it?

Thanks,
Laird
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230216/3cef3e16/attachment.htm>

From ljnelson at gmail.com  Thu Feb 16 22:54:33 2023
From: ljnelson at gmail.com (Laird Nelson)
Date: Thu, 16 Feb 2023 14:54:33 -0800
Subject: Is a TYPE_USE annotation stored as such in a class file?
In-Reply-To: <7419cf15-41dc-4389-f06e-c88e1063fe17@oracle.com>
References: <CAHNdxu=Jk=Vt3UD1+DZ=Lmg+1Dtmx4DG9SeDXrKrXWiCbB+e7w@mail.gmail.com>
 <CAL4QsgsZptH2Lm74g-nje8zwggrYJ+-qUay=0t0QwxfGMvJ6hA@mail.gmail.com>
 <7419cf15-41dc-4389-f06e-c88e1063fe17@oracle.com>
Message-ID: <CAHNdxumQ8ctLBWQxBoc7yRZ=xR96xcz9+Jgw_qP=E2YfRq_hUQ@mail.gmail.com>

On Thu, Feb 16, 2023 at 2:41 PM Alex Buckley <alex.buckley at oracle.com>
wrote:

> Correct. The `@A` in `@A class B {}` is a declaration annotation, hence
> appears in a RuntimeVisibleAnnotations attribute in B.class.
>
> The next line in 9.7.4 is:
>
>    A type annotation is an annotation that applies to a type
>    (or any part of a type), and whose annotation interface is
>    applicable in type contexts.
>
> Since this `@A` doesn't apply to a type, it's not a type annotation,
> hence there is no RuntimeVisibleTypeAnnotations attribute.
>

How very interesting. So in pragmatic terms, merely looking at an
annotation's @Target annotation does not, by itself, tell you all the
places it could be used or where it might show up reflectively. I learn
something new every day. Thanks for your patience and time.

Best,
Laird
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230216/04043451/attachment.htm>

From alex.buckley at oracle.com  Thu Feb 16 23:01:46 2023
From: alex.buckley at oracle.com (Alex Buckley)
Date: Thu, 16 Feb 2023 15:01:46 -0800
Subject: [External] : Re: Is a TYPE_USE annotation stored as such in a
 class file?
In-Reply-To: <CAHNdxunPm1NJke103Q5YtpX7g-3BciuQXwe0KFs=Aq+sz_3uyg@mail.gmail.com>
References: <CAHNdxu=Jk=Vt3UD1+DZ=Lmg+1Dtmx4DG9SeDXrKrXWiCbB+e7w@mail.gmail.com>
 <CAL4QsgsZptH2Lm74g-nje8zwggrYJ+-qUay=0t0QwxfGMvJ6hA@mail.gmail.com>
 <CAHNdxum=L5StdWmoNbvRCsb7Bg9wo=OEJ6W2QkwAuqk18P258Q@mail.gmail.com>
 <5adc8681-b015-f591-84bd-68b8d8a51444@oracle.com>
 <CAHNdxunPm1NJke103Q5YtpX7g-3BciuQXwe0KFs=Aq+sz_3uyg@mail.gmail.com>
Message-ID: <ea4626a5-2a75-a5ce-bbc0-b2269c1d9c46@oracle.com>

On 2/16/2023 2:46 PM, Laird Nelson wrote:
> On Thu, Feb 16, 2023 at 2:43 PM Alex Buckley <alex.buckley at oracle.com 
> <mailto:alex.buckley at oracle.com>> wrote:
> 
>     The annotation interface A has ElementType.TYPE_USE === applicable in
>     type contexts (9.6.4.1).
> 
> If you have the time and for my own learning: which of the 17 type 
> contexts in 4.11 
> (https://docs.oracle.com/javase/specs/jls/se19/html/jls-4.html#jls-4.11 
> <https://docs.oracle.com/javase/specs/jls/se19/html/jls-4.html#jls-4.11>) is:
> 
> class B
> 
> ...such that?@A is applicable in it?

The declaration `class B {}` is not a type context.

Here is the annotation `@A` being applied in some type contexts:

   class B extends    @A Foo {}
   class B implements @A Bar {}
   class B<@A T extends @A Number> {}

These applications of `@A` are legal -- they are _type annotations_ -- 
because they're applying to types (a.k.a. type uses -- of Foo, Bar, T, 
Number) and the annotation interface `A` is applicable in type contexts.

In contrast, you are applying `@A` to a declaration, `class B {}`. Your 
application of `@A` is legal - it is a _declaration annotation_ -- because:

   A declaration annotation is ... an annotation that applies to a class,
   interface, or type parameter declaration, and whose annotation
   interface is applicable in type contexts (?4.11).

That is, `A` being applicable in type contexts means `@A` can be applied 
very, very widely.

Alex

From ljnelson at gmail.com  Thu Feb 16 23:09:21 2023
From: ljnelson at gmail.com (Laird Nelson)
Date: Thu, 16 Feb 2023 15:09:21 -0800
Subject: [External] : Re: Is a TYPE_USE annotation stored as such in a
 class file?
In-Reply-To: <ea4626a5-2a75-a5ce-bbc0-b2269c1d9c46@oracle.com>
References: <CAHNdxu=Jk=Vt3UD1+DZ=Lmg+1Dtmx4DG9SeDXrKrXWiCbB+e7w@mail.gmail.com>
 <CAL4QsgsZptH2Lm74g-nje8zwggrYJ+-qUay=0t0QwxfGMvJ6hA@mail.gmail.com>
 <CAHNdxum=L5StdWmoNbvRCsb7Bg9wo=OEJ6W2QkwAuqk18P258Q@mail.gmail.com>
 <5adc8681-b015-f591-84bd-68b8d8a51444@oracle.com>
 <CAHNdxunPm1NJke103Q5YtpX7g-3BciuQXwe0KFs=Aq+sz_3uyg@mail.gmail.com>
 <ea4626a5-2a75-a5ce-bbc0-b2269c1d9c46@oracle.com>
Message-ID: <CAHNdxukWcx4_k8j5M_r7g7K98+W8KRhHNu0+moHcdCVrfJPhPA@mail.gmail.com>

On Thu, Feb 16, 2023 at 3:01 PM Alex Buckley <alex.buckley at oracle.com>
wrote:

> In contrast, you are applying `@A` to a declaration, `class B {}`. Your
> application of `@A` is legal - it is a _declaration annotation_ -- because:
>
>    A declaration annotation is ... an annotation that applies to a class,
>    interface, or type parameter declaration, and whose annotation
>    interface is applicable in type contexts (?4.11).
>
> That is, `A` being applicable in type contexts means `@A` can be applied
> very, very widely.
>

Thank you for the explanation, I think I understand now. TYPE_USE is in
pragmatic terms a superset of some other ElementTypes (such as TYPE; maybe
others; haven't thought it through) given that annotations so annotated can
be applied not just in type contexts but in (some? probably not all?)
declaration contexts as well.  There is, in other words (check me on
this?), no effective difference at all between @Target({ ElementType.TYPE,
ElementType.TYPE_USE }) and @Target({ ElementType.TYPE_USE }).

L
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230216/1e3e1808/attachment.htm>

From alex.buckley at oracle.com  Thu Feb 16 23:10:06 2023
From: alex.buckley at oracle.com (Alex Buckley)
Date: Thu, 16 Feb 2023 15:10:06 -0800
Subject: Is a TYPE_USE annotation stored as such in a class file?
In-Reply-To: <CAHNdxumQ8ctLBWQxBoc7yRZ=xR96xcz9+Jgw_qP=E2YfRq_hUQ@mail.gmail.com>
References: <CAHNdxu=Jk=Vt3UD1+DZ=Lmg+1Dtmx4DG9SeDXrKrXWiCbB+e7w@mail.gmail.com>
 <CAL4QsgsZptH2Lm74g-nje8zwggrYJ+-qUay=0t0QwxfGMvJ6hA@mail.gmail.com>
 <7419cf15-41dc-4389-f06e-c88e1063fe17@oracle.com>
 <CAHNdxumQ8ctLBWQxBoc7yRZ=xR96xcz9+Jgw_qP=E2YfRq_hUQ@mail.gmail.com>
Message-ID: <a615ffc1-08ed-f98a-dd6d-701ded5c6ff2@oracle.com>

On 2/16/2023 2:54 PM, Laird Nelson wrote:
> How very interesting. So in pragmatic terms, merely looking at an 
> annotation's?@Target annotation does not, by itself, tell you all the 
> places it could be used or where it might show up reflectively. I learn 
> something new every day. Thanks for your patience and time.

Looking at an annotation interface `A`'s @Target meta-annotation 
absolutely does tell you all the places that the annotation `@A` may 
appear. Everything about this is checked at compile time -- it has to be 
deterministic.

For example, from `@Target(TYPE_USE)`, you can deduce that `@A` may 
appear on type uses, on class declarations, on interface declarations, 
and on type parameter declarations.

Alex

From duke at openjdk.org  Thu Feb 16 23:12:08 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Thu, 16 Feb 2023 23:12:08 GMT
Subject: RFR: 7033677: potential cast error in MemberEnter [v2]
In-Reply-To: <Y8st9ibTZLr_bFTbvipZCmHDkd5XvG-I038n9QhxaD8=.ae5bb57a-29ec-4ff6-90cb-973bd6277eaa@github.com>
References: <Y8st9ibTZLr_bFTbvipZCmHDkd5XvG-I038n9QhxaD8=.ae5bb57a-29ec-4ff6-90cb-973bd6277eaa@github.com>
Message-ID: <stmeK9jviXQySdPzle86Kk7lw3N1mUaINlpPv--iwjs=.bbe46895-8016-4335-b43e-0645f1c1ab36@github.com>

> In an `import` statement, the thing imported is always a `JCFieldAccess` (it's not legal in Java to import a simple name).
> 
> Therefore the type of `JCFieldAccess.qualid`, which is currently `JCTree`, is unnecessarily wide and can be narrowed to `JCFieldAccess`.

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

  Fix Javadoc generator build broken by previous commit.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12606/files
  - new: https://git.openjdk.org/jdk/pull/12606/files/6fdc874d..391d7d18

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

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

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

From duke at openjdk.org  Thu Feb 16 23:12:19 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Thu, 16 Feb 2023 23:12:19 GMT
Subject: RFR: 7033677: potential cast error in MemberEnter
In-Reply-To: <LeT_pI8l_h45BAKxcISOF1ZK1giUKCNKqTEs2mDtuhI=.17a3d8c2-dc72-42ed-bb44-771689481b33@github.com>
References: <Y8st9ibTZLr_bFTbvipZCmHDkd5XvG-I038n9QhxaD8=.ae5bb57a-29ec-4ff6-90cb-973bd6277eaa@github.com>
 <LeT_pI8l_h45BAKxcISOF1ZK1giUKCNKqTEs2mDtuhI=.17a3d8c2-dc72-42ed-bb44-771689481b33@github.com>
Message-ID: <1a66HVeK1n4UrbWXBR9HTB5FdBpkbsezgqhhT-Zc8N8=.7b8e5a09-2ca1-4157-9799-767c25adbe6c@github.com>

On Thu, 16 Feb 2023 21:29:41 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Looks reasonable to me, but please note that `test/langtools/jdk/javadoc/tool/sampleapi/lib/sampleapi/generator/PackageGenerator.java` needs to be fixed as well

Oops - thanks. Should be fixed now.

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

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

From ljnelson at gmail.com  Thu Feb 16 23:18:14 2023
From: ljnelson at gmail.com (Laird Nelson)
Date: Thu, 16 Feb 2023 15:18:14 -0800
Subject: Is a TYPE_USE annotation stored as such in a class file?
In-Reply-To: <a615ffc1-08ed-f98a-dd6d-701ded5c6ff2@oracle.com>
References: <CAHNdxu=Jk=Vt3UD1+DZ=Lmg+1Dtmx4DG9SeDXrKrXWiCbB+e7w@mail.gmail.com>
 <CAL4QsgsZptH2Lm74g-nje8zwggrYJ+-qUay=0t0QwxfGMvJ6hA@mail.gmail.com>
 <7419cf15-41dc-4389-f06e-c88e1063fe17@oracle.com>
 <CAHNdxumQ8ctLBWQxBoc7yRZ=xR96xcz9+Jgw_qP=E2YfRq_hUQ@mail.gmail.com>
 <a615ffc1-08ed-f98a-dd6d-701ded5c6ff2@oracle.com>
Message-ID: <CAHNdxunQu4tCnn7ZKionJ2CzeNQ0VYARuMMPimZTL9TggcW2kQ@mail.gmail.com>

On Thu, Feb 16, 2023 at 3:10 PM Alex Buckley <alex.buckley at oracle.com>
wrote:

> Looking at an annotation interface `A`'s @Target meta-annotation
> absolutely does tell you all the places that the annotation `@A` may
> appear. Everything about this is checked at compile time -- it has to be
> deterministic.
>
> For example, from `@Target(TYPE_USE)`, you can deduce that `@A` may
> appear on type uses, on class declarations, on interface declarations,
> and on type parameter declarations.
>

Let me put it a different way: what does annotating my annotation
with @Target({ ElementType.TYPE, ElementType.TYPE_PARAMETER,
ElementType.TYPE_USE }) accomplish that simply annotating it with @Target({
ElementType.TYPE_USE }) does not?

Thanks,
Laird
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230216/daf2c390/attachment.htm>

From alex.buckley at oracle.com  Thu Feb 16 23:30:33 2023
From: alex.buckley at oracle.com (Alex Buckley)
Date: Thu, 16 Feb 2023 15:30:33 -0800
Subject: [External] : Re: Is a TYPE_USE annotation stored as such in a
 class file?
In-Reply-To: <ea4626a5-2a75-a5ce-bbc0-b2269c1d9c46@oracle.com>
References: <CAHNdxu=Jk=Vt3UD1+DZ=Lmg+1Dtmx4DG9SeDXrKrXWiCbB+e7w@mail.gmail.com>
 <CAL4QsgsZptH2Lm74g-nje8zwggrYJ+-qUay=0t0QwxfGMvJ6hA@mail.gmail.com>
 <CAHNdxum=L5StdWmoNbvRCsb7Bg9wo=OEJ6W2QkwAuqk18P258Q@mail.gmail.com>
 <5adc8681-b015-f591-84bd-68b8d8a51444@oracle.com>
 <CAHNdxunPm1NJke103Q5YtpX7g-3BciuQXwe0KFs=Aq+sz_3uyg@mail.gmail.com>
 <ea4626a5-2a75-a5ce-bbc0-b2269c1d9c46@oracle.com>
Message-ID: <dee40eda-7d9f-4614-6563-1e2b61cc664f@oracle.com>

On 2/16/2023 3:01 PM, Alex Buckley wrote:
> Here is the annotation `@A` being applied in some type contexts:
> 
>  ? class B extends??? @A Foo {}
>  ? class B implements @A Bar {}
>  ? class B<@A T extends @A Number> {} >
> These applications of `@A` are legal -- they are _type annotations_ -- 
> because they're applying to types (a.k.a. type uses -- of Foo, Bar, T, 
> Number) and the annotation interface `A` is applicable in type contexts.

Laird has kindly pointed out that I made an error: The T above is not a 
type use at all, but rather a declaration of a type parameter, so the 
annotation `@A` in `class B<@A T ...>` appears in a declaration context, 
and is a declaration annotation rather than a type annotation.

Alex

From alex.buckley at oracle.com  Thu Feb 16 23:36:29 2023
From: alex.buckley at oracle.com (Alex Buckley)
Date: Thu, 16 Feb 2023 15:36:29 -0800
Subject: Is a TYPE_USE annotation stored as such in a class file?
In-Reply-To: <CAHNdxunQu4tCnn7ZKionJ2CzeNQ0VYARuMMPimZTL9TggcW2kQ@mail.gmail.com>
References: <CAHNdxu=Jk=Vt3UD1+DZ=Lmg+1Dtmx4DG9SeDXrKrXWiCbB+e7w@mail.gmail.com>
 <CAL4QsgsZptH2Lm74g-nje8zwggrYJ+-qUay=0t0QwxfGMvJ6hA@mail.gmail.com>
 <7419cf15-41dc-4389-f06e-c88e1063fe17@oracle.com>
 <CAHNdxumQ8ctLBWQxBoc7yRZ=xR96xcz9+Jgw_qP=E2YfRq_hUQ@mail.gmail.com>
 <a615ffc1-08ed-f98a-dd6d-701ded5c6ff2@oracle.com>
 <CAHNdxunQu4tCnn7ZKionJ2CzeNQ0VYARuMMPimZTL9TggcW2kQ@mail.gmail.com>
Message-ID: <a340ea75-0a3c-389d-929c-6daa784c386e@oracle.com>

On 2/16/2023 3:18 PM, Laird Nelson wrote:
> On Thu, Feb 16, 2023 at 3:10 PM Alex Buckley <alex.buckley at oracle.com 
> <mailto:alex.buckley at oracle.com>> wrote:
> 
>     Looking at an annotation interface `A`'s @Target meta-annotation
>     absolutely does tell you all the places that the annotation `@A` may
>     appear. Everything about this is checked at compile time -- it has
>     to be deterministic.
> 
>     For example, from `@Target(TYPE_USE)`, you can deduce that `@A` may
>     appear on type uses, on class declarations, on interface declarations,
>     and on type parameter declarations.
> 
> 
> Let me put it a different way: what does annotating my annotation 
> with?@Target({ ElementType.TYPE, ElementType.TYPE_PARAMETER, 
> ElementType.TYPE_USE }) accomplish that simply annotating it 
> with?@Target({ ElementType.TYPE_USE }) does not?

It communicates intent more fully to a third-party checker system that 
inspects annotations throughout a program and may apply custom rules 
depending on the specified @Target. For example, a TYPE_USE-only 
annotation that appears on a class declaration is legal in the Java 
language, but may raise semantic issues for a checker, which can be 
addressed by adding TYPE to TYPE_USE in the @Target.

Alex

From darcy at openjdk.org  Fri Feb 17 04:22:30 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 17 Feb 2023 04:22:30 GMT
Subject: RFR: 8302685: Some javac unit tests aren't reliably closing open
 files
In-Reply-To: <Gz1mh8dLxhqpmPWa3S9V_v-nR5aTC-l4JrEFINKl9Xg=.eab3b0c4-a3e9-44d6-b710-5ce7b354350d@github.com>
References: <Gz1mh8dLxhqpmPWa3S9V_v-nR5aTC-l4JrEFINKl9Xg=.eab3b0c4-a3e9-44d6-b710-5ce7b354350d@github.com>
Message-ID: <pp_-7ZbFGyAphQOqo7rTT61CIY7riwJ85EKmGW52yRM=.086b64b5-97bf-4aa2-8d26-927a51fcc208@github.com>

On Thu, 16 Feb 2023 21:32:44 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

> Some javac unit tests aren't reliably closing open files. Many were written prior to (or without utilizing) try-with-resources.
> 
> Leaving files and other resources open can cause problems during automated builds, etc.
> 
> This patch updates these tests to use try-with-resource.
> 
> Side note: there is at least one unit test that intentionally leaves a file open - `diags/examples/ProcUnclosedTypeFiles/processors/AnnoProc.java`.

Looks fine; however, another engineer who works in the langtools area should look over the changes too.

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

Marked as reviewed by darcy (Reviewer).

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

From jlahoda at openjdk.org  Fri Feb 17 09:23:18 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 17 Feb 2023 09:23:18 GMT
Subject: RFR: 7033677: potential cast error in MemberEnter [v2]
In-Reply-To: <stmeK9jviXQySdPzle86Kk7lw3N1mUaINlpPv--iwjs=.bbe46895-8016-4335-b43e-0645f1c1ab36@github.com>
References: <Y8st9ibTZLr_bFTbvipZCmHDkd5XvG-I038n9QhxaD8=.ae5bb57a-29ec-4ff6-90cb-973bd6277eaa@github.com>
 <stmeK9jviXQySdPzle86Kk7lw3N1mUaINlpPv--iwjs=.bbe46895-8016-4335-b43e-0645f1c1ab36@github.com>
Message-ID: <7AGrg8VrD9yEEyz7C1qS6gw21xxp11-CX7rdXPAvVZo=.ace08021-50ee-4512-9092-659d5bab22fc@github.com>

On Thu, 16 Feb 2023 23:12:08 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> In an `import` statement, the thing imported is always a `JCFieldAccess` (it's not legal in Java to import a simple name).
>> 
>> Therefore the type of `JCFieldAccess.qualid`, which is currently `JCTree`, is unnecessarily wide and can be narrowed to `JCFieldAccess`.
>
> Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix Javadoc generator build broken by previous commit.

Looks good to me.

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

Marked as reviewed by jlahoda (Reviewer).

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

From abimpoudis at openjdk.org  Fri Feb 17 10:59:51 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Fri, 17 Feb 2023 10:59:51 GMT
Subject: RFR: JDK-8302202: Incorrect desugaring of null-allowed nested
 patterns
In-Reply-To: <E-Jv1xFu4_33w3rXpwbfzeVeCRupcQ_XChtuwfxwFI4=.65a9ebe9-ef47-4659-a6cc-1386e24a00c9@github.com>
References: <E-Jv1xFu4_33w3rXpwbfzeVeCRupcQ_XChtuwfxwFI4=.65a9ebe9-ef47-4659-a6cc-1386e24a00c9@github.com>
Message-ID: <1C4LrRNJaGr7Bxki3YqBxOThJsG0ULp7-810DhsnSu0=.916e3028-ed50-4d3f-b9a3-8e362a7f9ebe@github.com>

On Wed, 15 Feb 2023 13:16:10 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Considering code like:
> 
>     private String test1b(Object i) {
>         return switch (i) {
>             case R1(Object o) when o == null -> "R1(null)";
>             case R1(Object o) -> "R1(!null)";
>             default -> "default";
>         };
>     }
> 
> 
> javac will try to factor-out the common prefix, i.e. `R1`, and produce something along these lines:
> 
>         switch (i) {
>             case R1 $r:
>                 Object c = $r.c();
>                 switch (c) {
>                     case Object o when o == null: yield "R1(null)";
>                     case Object o: yield "R1(!null)";
>                 }
>             default -> "default";
>         };
> 
> 
> The problem with this code is that both cases in the nested switch must match `null`, but the bootstrap protocol only allows one case to match `null` (the `SwitchBootstraps.typeSwitch` method will return `-1` for `null`). So this translation is broken, and will not match the first case if the component is `null`.
> 
> There are multiple ways to solve this problem, but the proposal here is change the way we accumulate the cases from which we factor out the common prefix, by stopping the accumulation after the first nullable case.
> 
> Another related issue is that when factoring out the common prefix, if the last case in the nested switch is has an unconditional pattern, but also has a guard, we need to generate a default to continue properly in the outer switch. Currently, the default is not generated when there's an unconditional pattern in the case, despite having a guard, and hence the case as a whole is not unconditional.

After running some more examples, the patch looks good to me too ?

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

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

From jlahoda at openjdk.org  Fri Feb 17 13:16:20 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 17 Feb 2023 13:16:20 GMT
Subject: Integrated: JDK-8302202: Incorrect desugaring of null-allowed nested
 patterns
In-Reply-To: <E-Jv1xFu4_33w3rXpwbfzeVeCRupcQ_XChtuwfxwFI4=.65a9ebe9-ef47-4659-a6cc-1386e24a00c9@github.com>
References: <E-Jv1xFu4_33w3rXpwbfzeVeCRupcQ_XChtuwfxwFI4=.65a9ebe9-ef47-4659-a6cc-1386e24a00c9@github.com>
Message-ID: <M39XE2dp-xO3XkTPKlY3_2IRoYpwf3XQQq4MwGnyado=.1e46a76d-9465-4137-a07f-5109f8a66d64@github.com>

On Wed, 15 Feb 2023 13:16:10 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Considering code like:
> 
>     private String test1b(Object i) {
>         return switch (i) {
>             case R1(Object o) when o == null -> "R1(null)";
>             case R1(Object o) -> "R1(!null)";
>             default -> "default";
>         };
>     }
> 
> 
> javac will try to factor-out the common prefix, i.e. `R1`, and produce something along these lines:
> 
>         switch (i) {
>             case R1 $r:
>                 Object c = $r.c();
>                 switch (c) {
>                     case Object o when o == null: yield "R1(null)";
>                     case Object o: yield "R1(!null)";
>                 }
>             default -> "default";
>         };
> 
> 
> The problem with this code is that both cases in the nested switch must match `null`, but the bootstrap protocol only allows one case to match `null` (the `SwitchBootstraps.typeSwitch` method will return `-1` for `null`). So this translation is broken, and will not match the first case if the component is `null`.
> 
> There are multiple ways to solve this problem, but the proposal here is change the way we accumulate the cases from which we factor out the common prefix, by stopping the accumulation after the first nullable case.
> 
> Another related issue is that when factoring out the common prefix, if the last case in the nested switch is has an unconditional pattern, but also has a guard, we need to generate a default to continue properly in the outer switch. Currently, the default is not generated when there's an unconditional pattern in the case, despite having a guard, and hence the case as a whole is not unconditional.

This pull request has now been integrated.

Changeset: dc55a7fc
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/dc55a7fc877ab5ea4efbed90454194008143aeb4
Stats:     182 lines in 2 files changed: 174 ins; 2 del; 6 mod

8302202: Incorrect desugaring of null-allowed nested patterns

Reviewed-by: vromero

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

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

From duke at openjdk.org  Fri Feb 17 17:14:24 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Fri, 17 Feb 2023 17:14:24 GMT
Subject: Integrated: 7033677: potential cast error in MemberEnter
In-Reply-To: <Y8st9ibTZLr_bFTbvipZCmHDkd5XvG-I038n9QhxaD8=.ae5bb57a-29ec-4ff6-90cb-973bd6277eaa@github.com>
References: <Y8st9ibTZLr_bFTbvipZCmHDkd5XvG-I038n9QhxaD8=.ae5bb57a-29ec-4ff6-90cb-973bd6277eaa@github.com>
Message-ID: <hNMoIUBptqyHWZ6qDQ5Ko5G-0dY1wDnyr2DqdE3X0cA=.c9ff6902-2adb-4c05-97ae-2f30261f900b@github.com>

On Thu, 16 Feb 2023 19:12:23 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

> In an `import` statement, the thing imported is always a `JCFieldAccess` (it's not legal in Java to import a simple name).
> 
> Therefore the type of `JCFieldAccess.qualid`, which is currently `JCTree`, is unnecessarily wide and can be narrowed to `JCFieldAccess`.

This pull request has now been integrated.

Changeset: a917fb3f
Author:    Archie L. Cobbs <archie.cobbs at gmail.com>
Committer: Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a917fb3fcf0fe1a4c4de86c08ae4041462848b82
Stats:     24 lines in 8 files changed: 6 ins; 0 del; 18 mod

7033677: potential cast error in MemberEnter

Reviewed-by: vromero, jlahoda

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

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

From vromero at openjdk.org  Fri Feb 17 22:45:24 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 17 Feb 2023 22:45:24 GMT
Subject: RFR: 8302685: Some javac unit tests aren't reliably closing open
 files
In-Reply-To: <Gz1mh8dLxhqpmPWa3S9V_v-nR5aTC-l4JrEFINKl9Xg=.eab3b0c4-a3e9-44d6-b710-5ce7b354350d@github.com>
References: <Gz1mh8dLxhqpmPWa3S9V_v-nR5aTC-l4JrEFINKl9Xg=.eab3b0c4-a3e9-44d6-b710-5ce7b354350d@github.com>
Message-ID: <Qqdue5Lgfiog6dnSjfue7O6MX3b0FfBT0qNNwuKHxko=.06d05731-65d4-4a98-8ba0-2a87c0ec1956@github.com>

On Thu, 16 Feb 2023 21:32:44 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

> Some javac unit tests aren't reliably closing open files. Many were written prior to (or without utilizing) try-with-resources.
> 
> Leaving files and other resources open can cause problems during automated builds, etc.
> 
> This patch updates these tests to use try-with-resource.
> 
> Side note: there is at least one unit test that intentionally leaves a file open - `diags/examples/ProcUnclosedTypeFiles/processors/AnnoProc.java`.

lgtm

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

Marked as reviewed by vromero (Reviewer).

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

From darcy at openjdk.org  Fri Feb 17 23:00:28 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 17 Feb 2023 23:00:28 GMT
Subject: RFR: 8292275: javac does not emit SYNTHETIC and MANDATED flags for
 parameters by default [v2]
In-Reply-To: <6h4fb3uQb5CVMis_G5D7jDf-4EcPHveKtEIXF3mlvZw=.7a945163-3726-44cb-b884-c34318ecb5a3@github.com>
References: <cXBKN2YWuFVzdacmxsQvmYPy16bODPQvoyy_ovJ2EiM=.052011cd-598e-4bf7-bc10-3a2171f4b317@github.com>
 <usvSorj8frQuf8JoKs4V9DctbM5NQJqz2BMVyNY3c1Y=.15a3693f-2062-4edf-a381-a76b44101fa2@github.com>
 <6h4fb3uQb5CVMis_G5D7jDf-4EcPHveKtEIXF3mlvZw=.7a945163-3726-44cb-b884-c34318ecb5a3@github.com>
Message-ID: <vwDOMvhXQ-Ph14gzTTXaXBOAKgJlJoc_l7MEuCTcTyk=.074edc1b-8081-4025-8f75-34a370978c6d@github.com>

On Mon, 15 Aug 2022 17:33:46 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Hannes Greule has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add access flag based test
>
> CSR needed I guess

@vicente-romero-oracle , can you review the CSR for this? Thanks.

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

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

From vromero at openjdk.org  Fri Feb 17 23:17:25 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 17 Feb 2023 23:17:25 GMT
Subject: RFR: 7016187: `javac -h` could generate conflict .h for inner
 class and class name with '_'
In-Reply-To: <TjKjaZLrq5AnmfxbBfv7Yr29TRkl7p_egrz8AzCTGf8=.c5953e6d-6ff2-4a4f-8327-a3cc956a3e0b@github.com>
References: <TjKjaZLrq5AnmfxbBfv7Yr29TRkl7p_egrz8AzCTGf8=.c5953e6d-6ff2-4a4f-8327-a3cc956a3e0b@github.com>
Message-ID: <CG-DA1GjPNfMJJcMhYpgEx6Wm7Nn_FBwJYoET0CHLDQ=.b30e4f55-d51a-4e07-9913-795ef9a41b07@github.com>

On Thu, 16 Feb 2023 17:49:00 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

> Consider these two classes:
> 
> public class Foo_Bar {
>     public static native void method();
> }
> 
> 
> public class Foo {
>     public static class Bar {
>         public static native void method();
>     }
> }
> 
> If you run `javac -h` to generate native header files, classes `Foo_Bar` and `Foo$Bar` will want to generate the same native header file `Foo_Bar.h`.
> 
> Currently, javac does not detect this situation, so in effect you get a "last writer wins" situation.
> 
> This patch causes compilation to fail instead in this case with an error like this:
> 
> Foo.java:2: error: error while writing Bar: native header file collision between Foo_Bar and Foo$Bar (both generate Foo_Bar.h)
>     public static class Bar {
>                   ^
> 1 error

lgtm

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

Marked as reviewed by vromero (Reviewer).

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

From vromero at openjdk.org  Fri Feb 17 23:19:29 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 17 Feb 2023 23:19:29 GMT
Subject: RFR: 8292275: javac does not emit SYNTHETIC and MANDATED flags for
 parameters by default [v2]
In-Reply-To: <6h4fb3uQb5CVMis_G5D7jDf-4EcPHveKtEIXF3mlvZw=.7a945163-3726-44cb-b884-c34318ecb5a3@github.com>
References: <cXBKN2YWuFVzdacmxsQvmYPy16bODPQvoyy_ovJ2EiM=.052011cd-598e-4bf7-bc10-3a2171f4b317@github.com>
 <usvSorj8frQuf8JoKs4V9DctbM5NQJqz2BMVyNY3c1Y=.15a3693f-2062-4edf-a381-a76b44101fa2@github.com>
 <6h4fb3uQb5CVMis_G5D7jDf-4EcPHveKtEIXF3mlvZw=.7a945163-3726-44cb-b884-c34318ecb5a3@github.com>
Message-ID: <pj2IC-MxNa69wTj8tpNxY68B9vRNsPj1OZ4Myg-TD-8=.3b6be8f7-b131-4d4f-8c99-85fb9a4866f4@github.com>

On Mon, 15 Aug 2022 17:33:46 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Hannes Greule has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add access flag based test
>
> CSR needed I guess

> @vicente-romero-oracle , can you review the CSR for this? Thanks.

sure, taking a look now

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

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

From jjg at openjdk.org  Fri Feb 17 23:34:24 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 17 Feb 2023 23:34:24 GMT
Subject: RFR: 7016187: `javac -h` could generate conflict .h for inner
 class and class name with '_'
In-Reply-To: <TjKjaZLrq5AnmfxbBfv7Yr29TRkl7p_egrz8AzCTGf8=.c5953e6d-6ff2-4a4f-8327-a3cc956a3e0b@github.com>
References: <TjKjaZLrq5AnmfxbBfv7Yr29TRkl7p_egrz8AzCTGf8=.c5953e6d-6ff2-4a4f-8327-a3cc956a3e0b@github.com>
Message-ID: <Qp5hpb5ArmwaV1pngPe5dIYLOeOay6DO5GRPGLcM8Ok=.13ab7eb7-93ee-404d-9cb8-6e50ca35a41e@github.com>

On Thu, 16 Feb 2023 17:49:00 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

> Consider these two classes:
> 
> public class Foo_Bar {
>     public static native void method();
> }
> 
> 
> public class Foo {
>     public static class Bar {
>         public static native void method();
>     }
> }
> 
> If you run `javac -h` to generate native header files, classes `Foo_Bar` and `Foo$Bar` will want to generate the same native header file `Foo_Bar.h`.
> 
> Currently, javac does not detect this situation, so in effect you get a "last writer wins" situation.
> 
> This patch causes compilation to fail instead in this case with an error like this:
> 
> Foo.java:2: error: error while writing Bar: native header file collision between Foo_Bar and Foo$Bar (both generate Foo_Bar.h)
>     public static class Bar {
>                   ^
> 1 error

The JBS issue lists _two_ problem cases, of which this PR addresses one.

You should either fix both, or file a subsidiary issue for the part that is not covered here (if that is still an issue):

> It also does not handle the fields properly for O_I.class and O$I.class if both have same named fields. The generated field constant names are the same in the jni header file.

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

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

From duke at openjdk.org  Sat Feb 18 01:22:30 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Sat, 18 Feb 2023 01:22:30 GMT
Subject: RFR: 7016187: `javac -h` could generate conflict .h for inner
 class and class name with '_'
In-Reply-To: <TjKjaZLrq5AnmfxbBfv7Yr29TRkl7p_egrz8AzCTGf8=.c5953e6d-6ff2-4a4f-8327-a3cc956a3e0b@github.com>
References: <TjKjaZLrq5AnmfxbBfv7Yr29TRkl7p_egrz8AzCTGf8=.c5953e6d-6ff2-4a4f-8327-a3cc956a3e0b@github.com>
Message-ID: <88jLCv2N9jprPQiS8hfVdccJEvZmfDti-OZVXWB3eeE=.e34acd67-880a-479f-aa31-49807747fd7f@github.com>

On Thu, 16 Feb 2023 17:49:00 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

> Consider these two classes:
> 
> public class Foo_Bar {
>     public static native void method();
> }
> 
> 
> public class Foo {
>     public static class Bar {
>         public static native void method();
>     }
> }
> 
> If you run `javac -h` to generate native header files, classes `Foo_Bar` and `Foo$Bar` will want to generate the same native header file `Foo_Bar.h`.
> 
> Currently, javac does not detect this situation, so in effect you get a "last writer wins" situation.
> 
> This patch causes compilation to fail instead in this case with an error like this:
> 
> Foo.java:2: error: error while writing Bar: native header file collision between Foo_Bar and Foo$Bar (both generate Foo_Bar.h)
>     public static class Bar {
>                   ^
> 1 error

> The JBS issue lists two problem cases, of which this PR addresses one.

Thanks for the heads-up on that, admittedly I had totally forgotten about it. However I'm not sure whether there is anything to do beyond what's already being done to flag the filename conflict.

The second problem (as I understand it) is that the two header files will include C macro definitions for `static final` constants that end up having the same name. For example, if `Foo$Bar` has a `public static final int field = 123` and `Foo_Bar` has a `public static final int field = 456`, then one header file will have:

#undef Foo_Bar_field
#define Foo_Bar_field 123L

and the other will have:

#undef Foo_Bar_field
#define Foo_Bar_field 456L

But notice the JNI version of the class names (`Foo_Bar`) is a prefix of the macro name (`Foo_Bar_field`) and also the name of the header file (`Foo_Bar.h`) minus the `.h`. So it's not possible to have two field macro symbols conflict this way without there already being a header file conflict, and therefore the current changes will detect these field conflicts as well as a side-effect. Put another way, the field name conflicts are just a side-effect of the JNI class name conflicts.

Of course (and this is going beyond the reported bug) you could also have a field name conflict where the header file names don't conflict. For example:

public class Foo {
    public static final int Bar_field = 123;
}
public class Foo_Bar {
    public static final int field = 456;
}

and so you'd generate two different header files (with different names) that both define `Foo_Bar_field`:

#undef Foo_Bar_field
#define Foo_Bar_field 123L


#undef Foo_Bar_field
#define Foo_Bar_field 456L

But then you can still deal with it at the C/C++ level by including the headers in the right order, or including only one in each of two separate C/C++ files, etc. Yes, you would have to "know what you're doing" but I don't think there's enough justification for turning this case into an error at the javac compiler level. And in any case if you're writing JNI, you probably "know what you're doing" :)

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

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

From duke at openjdk.org  Sat Feb 18 02:07:18 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Sat, 18 Feb 2023 02:07:18 GMT
Subject: RFR: 8014021: TreeMaker.Params behaves inconsistently when the owning
 method has the same number of parameters as the number of parameter
 types requested
Message-ID: <BzhNJqqlKr5rhox4c1v1B2w6PBidy2Mgi-UyRs1EhSk=.ff2fdae6-3e08-46e4-83a0-adf1bafa0126@github.com>

The method `TreeMaker.Params` has what appears to be strange behavior: normally it creates parameters of the types passed in. However, if the given owner is a method, and the method happens to have the same number of parameters as the number of parameters requested, then the types of the owner method's parameters are used instead. This is weird and confusing.

What's really going on is that a method owner is _always_ being passed in, and when that method has parameters defined, there are _always_ exactly as many of them as there are types provided.

So what this method is really doing is just reusing the same symbols for the methods parameters if the method has them defined, otherwise creating the same number of placeholder parameters `x0`, `x1`, `x2`, etc.

This patch refactors this method and clarifies its usage to eliminate the confusion.

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

Commit messages:
 - Refactor TreeMaker.Params() to clarify its usage and purpose.

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

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

From vromero at openjdk.org  Sat Feb 18 05:09:23 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Sat, 18 Feb 2023 05:09:23 GMT
Subject: RFR: 8014021: TreeMaker.Params behaves inconsistently when the
 owning method has the same number of parameters as the number of parameter
 types requested
In-Reply-To: <BzhNJqqlKr5rhox4c1v1B2w6PBidy2Mgi-UyRs1EhSk=.ff2fdae6-3e08-46e4-83a0-adf1bafa0126@github.com>
References: <BzhNJqqlKr5rhox4c1v1B2w6PBidy2Mgi-UyRs1EhSk=.ff2fdae6-3e08-46e4-83a0-adf1bafa0126@github.com>
Message-ID: <zHV7C6ouzln0MY_6Q11xWNGaBRkQinAbT7f4qNQNeck=.ff072009-ea3e-43ed-b2c8-a4443cee8506@github.com>

On Sat, 18 Feb 2023 01:59:27 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

> The method `TreeMaker.Params` has what appears to be strange behavior: normally it creates parameters of the types passed in. However, if the given owner is a method, and the method happens to have the same number of parameters as the number of parameters requested, then the types of the owner method's parameters are used instead. This is weird and confusing.
> 
> What's really going on is that a method owner is _always_ being passed in, and when that method has parameters defined, there are _always_ exactly as many of them as there are types provided.
> 
> So what this method is really doing is just reusing the same symbols for the methods parameters if the method has them defined, otherwise creating the same number of placeholder parameters `x0`, `x1`, `x2`, etc.
> 
> This patch refactors this method and clarifies its usage to eliminate the confusion.

src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeMaker.java line 1071:

> 1069:      *  otherwse create placeholders x0, x1, ..., xn.
> 1070:      */
> 1071:     public List<JCVariableDecl> Params(MethodSymbol mth, List<Type> argtypes) {

why changing the order of the arguments in the method declaration?

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

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

From jjg at openjdk.org  Sat Feb 18 06:06:22 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Sat, 18 Feb 2023 06:06:22 GMT
Subject: RFR: 8014021: TreeMaker.Params behaves inconsistently when the
 owning method has the same number of parameters as the number of parameter
 types requested
In-Reply-To: <BzhNJqqlKr5rhox4c1v1B2w6PBidy2Mgi-UyRs1EhSk=.ff2fdae6-3e08-46e4-83a0-adf1bafa0126@github.com>
References: <BzhNJqqlKr5rhox4c1v1B2w6PBidy2Mgi-UyRs1EhSk=.ff2fdae6-3e08-46e4-83a0-adf1bafa0126@github.com>
Message-ID: <UaWLkUcvgTHDjxlReswHs1NzhVIqp2zXZh-zWXyEuwU=.a7f0ba8e-c1fa-4fda-b84c-8b4dfb45eb88@github.com>

On Sat, 18 Feb 2023 01:59:27 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

> The method `TreeMaker.Params` has what appears to be strange behavior: normally it creates parameters of the types passed in. However, if the given owner is a method, and the method happens to have the same number of parameters as the number of parameters requested, then the types of the owner method's parameters are used instead. This is weird and confusing.
> 
> What's really going on is that a method owner is _always_ being passed in, and when that method has parameters defined, there are _always_ exactly as many of them as there are types provided.
> 
> So what this method is really doing is just reusing the same symbols for the methods parameters if the method has them defined, otherwise creating the same number of placeholder parameters `x0`, `x1`, `x2`, etc.
> 
> This patch refactors this method and clarifies its usage to eliminate the confusion.

This doesn't seem to address the concern expressed in the JBS issue about it being a weird dual use. It just seems to be a partial cleanup in the same area.

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

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

From duke at openjdk.org  Sat Feb 18 16:15:24 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Sat, 18 Feb 2023 16:15:24 GMT
Subject: RFR: 8014021: TreeMaker.Params behaves inconsistently when the
 owning method has the same number of parameters as the number of parameter
 types requested
In-Reply-To: <zHV7C6ouzln0MY_6Q11xWNGaBRkQinAbT7f4qNQNeck=.ff072009-ea3e-43ed-b2c8-a4443cee8506@github.com>
References: <BzhNJqqlKr5rhox4c1v1B2w6PBidy2Mgi-UyRs1EhSk=.ff2fdae6-3e08-46e4-83a0-adf1bafa0126@github.com>
 <zHV7C6ouzln0MY_6Q11xWNGaBRkQinAbT7f4qNQNeck=.ff072009-ea3e-43ed-b2c8-a4443cee8506@github.com>
Message-ID: <DC2yKUjzbVk6lCQdp1Ky3uWdTribDorVvURPDsa8O40=.76ceb3ba-8099-4688-89f4-627b14fdc44c@github.com>

On Sat, 18 Feb 2023 05:06:12 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> The method `TreeMaker.Params` has what appears to be strange behavior: normally it creates parameters of the types passed in. However, if the given owner is a method, and the method happens to have the same number of parameters as the number of parameters requested, then the types of the owner method's parameters are used instead. This is weird and confusing.
>> 
>> What's really going on is that a method owner is _always_ being passed in, and when that method has parameters defined, there are _always_ exactly as many of them as there are types provided.
>> 
>> So what this method is really doing is just reusing the same symbols for the methods parameters if the method has them defined, otherwise creating the same number of placeholder parameters `x0`, `x1`, `x2`, etc.
>> 
>> This patch refactors this method and clarifies its usage to eliminate the confusion.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeMaker.java line 1071:
> 
>> 1069:      *  otherwse create placeholders x0, x1, ..., xn.
>> 1070:      */
>> 1071:     public List<JCVariableDecl> Params(MethodSymbol mth, List<Type> argtypes) {
> 
> why changing the order of the arguments in the method declaration?

The thought was this: we are adding new preconditions to an existing method. All uses of this method in the JDK itself have been verified to already satisfy these preconditions, but there could (in theory) be other uses outside of the JDK that don't. By changing the method signature, any such uses will no longer compile, instead of silently becoming invalid.

Just trying to be conservative, in other words. But maybe this is too hypothetical, in which case I'm happy to switch it back.

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

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

From duke at openjdk.org  Sat Feb 18 16:39:34 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Sat, 18 Feb 2023 16:39:34 GMT
Subject: RFR: 8014021: TreeMaker.Params behaves inconsistently when the
 owning method has the same number of parameters as the number of parameter
 types requested [v2]
In-Reply-To: <BzhNJqqlKr5rhox4c1v1B2w6PBidy2Mgi-UyRs1EhSk=.ff2fdae6-3e08-46e4-83a0-adf1bafa0126@github.com>
References: <BzhNJqqlKr5rhox4c1v1B2w6PBidy2Mgi-UyRs1EhSk=.ff2fdae6-3e08-46e4-83a0-adf1bafa0126@github.com>
Message-ID: <2JrIh8PxT5_AnnmdkKC42a5bKFUbyqTn8WVVMbqkI5I=.6777d968-0dbe-4918-9129-69a5a19cae60@github.com>

> The method `TreeMaker.Params` has what appears to be strange behavior: normally it creates parameters of the types passed in. However, if the given owner is a method, and the method happens to have the same number of parameters as the number of parameters requested, then the types of the owner method's parameters are used instead. This is weird and confusing.
> 
> What's really going on is that a method owner is _always_ being passed in, and when that method has parameters defined, there are _always_ exactly as many of them as there are types provided.
> 
> So what this method is really doing is just reusing the same symbols for the methods parameters if the method has them defined, otherwise creating the same number of placeholder parameters `x0`, `x1`, `x2`, etc.
> 
> This patch refactors this method and clarifies its usage to eliminate the confusion.

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

  Create two variants of TreeMaker.Params() for the two different use cases.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12627/files
  - new: https://git.openjdk.org/jdk/pull/12627/files/8a74f794..8a08b187

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

  Stats: 26 lines in 2 files changed: 12 ins; 6 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/12627.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12627/head:pull/12627

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

From duke at openjdk.org  Sat Feb 18 16:39:35 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Sat, 18 Feb 2023 16:39:35 GMT
Subject: RFR: 8014021: TreeMaker.Params behaves inconsistently when the
 owning method has the same number of parameters as the number of parameter
 types requested
In-Reply-To: <UaWLkUcvgTHDjxlReswHs1NzhVIqp2zXZh-zWXyEuwU=.a7f0ba8e-c1fa-4fda-b84c-8b4dfb45eb88@github.com>
References: <BzhNJqqlKr5rhox4c1v1B2w6PBidy2Mgi-UyRs1EhSk=.ff2fdae6-3e08-46e4-83a0-adf1bafa0126@github.com>
 <UaWLkUcvgTHDjxlReswHs1NzhVIqp2zXZh-zWXyEuwU=.a7f0ba8e-c1fa-4fda-b84c-8b4dfb45eb88@github.com>
Message-ID: <8L64tBCaPMSZRLa-Zw-4-1F5Gb6a5GPoQXBQlMUWOmQ=.28402e1c-6c1c-4461-a180-4b7f2e6bcf18@github.com>

On Sat, 18 Feb 2023 06:03:18 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> This doesn't seem to address the concern expressed in the JBS issue about it being a weird dual use. It just seems to be a partial cleanup in the same area.

It's no longer a weird dual use - now it's just a dual use :)

Kidding aside, the method is in fact being used with both scenarios. So the other option would be to create two variants of the method for the two scenarios, at the expense of having the caller choose which one. But looking at it now this only needs to happen in one place, so I agree this would be even better - thanks.

Updated in 8a08b1877b0.

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

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

From vromero at openjdk.org  Sat Feb 18 18:26:25 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Sat, 18 Feb 2023 18:26:25 GMT
Subject: RFR: 8014021: TreeMaker.Params behaves inconsistently when the
 owning method has the same number of parameters as the number of parameter
 types requested [v2]
In-Reply-To: <2JrIh8PxT5_AnnmdkKC42a5bKFUbyqTn8WVVMbqkI5I=.6777d968-0dbe-4918-9129-69a5a19cae60@github.com>
References: <BzhNJqqlKr5rhox4c1v1B2w6PBidy2Mgi-UyRs1EhSk=.ff2fdae6-3e08-46e4-83a0-adf1bafa0126@github.com>
 <2JrIh8PxT5_AnnmdkKC42a5bKFUbyqTn8WVVMbqkI5I=.6777d968-0dbe-4918-9129-69a5a19cae60@github.com>
Message-ID: <Z0lrrWoMpxvHMD_3QhKvFk63MC08m0zGMghDsP0lh5w=.f2b53fb3-516a-4b81-a00f-4eb5a8be1dc4@github.com>

On Sat, 18 Feb 2023 16:39:34 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> The method `TreeMaker.Params` has what appears to be strange behavior: normally it creates parameters of the types passed in. However, if the given owner is a method, and the method happens to have the same number of parameters as the number of parameters requested, then the types of the owner method's parameters are used instead. This is weird and confusing.
>> 
>> What's really going on is that a method owner is _always_ being passed in, and when that method has parameters defined, there are _always_ exactly as many of them as there are types provided.
>> 
>> So what this method is really doing is just reusing the same symbols for the methods parameters if the method has them defined, otherwise creating the same number of placeholder parameters `x0`, `x1`, `x2`, etc.
>> 
>> This patch refactors this method and clarifies its usage to eliminate the confusion.
>
> Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Create two variants of TreeMaker.Params() for the two different use cases.

looks good

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

Marked as reviewed by vromero (Reviewer).

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

From duke at openjdk.org  Sat Feb 18 19:24:25 2023
From: duke at openjdk.org (Hannes Greule)
Date: Sat, 18 Feb 2023 19:24:25 GMT
Subject: RFR: 8292275: javac does not emit SYNTHETIC and MANDATED flags for
 parameters by default [v2]
In-Reply-To: <pj2IC-MxNa69wTj8tpNxY68B9vRNsPj1OZ4Myg-TD-8=.3b6be8f7-b131-4d4f-8c99-85fb9a4866f4@github.com>
References: <cXBKN2YWuFVzdacmxsQvmYPy16bODPQvoyy_ovJ2EiM=.052011cd-598e-4bf7-bc10-3a2171f4b317@github.com>
 <usvSorj8frQuf8JoKs4V9DctbM5NQJqz2BMVyNY3c1Y=.15a3693f-2062-4edf-a381-a76b44101fa2@github.com>
 <6h4fb3uQb5CVMis_G5D7jDf-4EcPHveKtEIXF3mlvZw=.7a945163-3726-44cb-b884-c34318ecb5a3@github.com>
 <pj2IC-MxNa69wTj8tpNxY68B9vRNsPj1OZ4Myg-TD-8=.3b6be8f7-b131-4d4f-8c99-85fb9a4866f4@github.com>
Message-ID: <niKqsYZs35dqvjRmlNMICQpN8iwXYZD_5V51AC_RHrw=.6b4ec741-b720-45cf-8bd7-cf66c85ad98b@github.com>

On Fri, 17 Feb 2023 23:16:52 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> CSR needed I guess
>
>> @vicente-romero-oracle , can you review the CSR for this? Thanks.
> 
> sure, I added some suggestions in a comment in the CSR

@vicente-romero-oracle thank you for the feedback. As I don't have a JBS account, I can't incorporate it myself. @TheShermanTanker could you do that for me as you created the CSR? Thanks.

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

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

From vromero at openjdk.org  Sun Feb 19 04:06:27 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Sun, 19 Feb 2023 04:06:27 GMT
Subject: RFR: 8292275: javac does not emit SYNTHETIC and MANDATED flags for
 parameters by default [v2]
In-Reply-To: <pj2IC-MxNa69wTj8tpNxY68B9vRNsPj1OZ4Myg-TD-8=.3b6be8f7-b131-4d4f-8c99-85fb9a4866f4@github.com>
References: <cXBKN2YWuFVzdacmxsQvmYPy16bODPQvoyy_ovJ2EiM=.052011cd-598e-4bf7-bc10-3a2171f4b317@github.com>
 <usvSorj8frQuf8JoKs4V9DctbM5NQJqz2BMVyNY3c1Y=.15a3693f-2062-4edf-a381-a76b44101fa2@github.com>
 <6h4fb3uQb5CVMis_G5D7jDf-4EcPHveKtEIXF3mlvZw=.7a945163-3726-44cb-b884-c34318ecb5a3@github.com>
 <pj2IC-MxNa69wTj8tpNxY68B9vRNsPj1OZ4Myg-TD-8=.3b6be8f7-b131-4d4f-8c99-85fb9a4866f4@github.com>
Message-ID: <7sO9lIqHflWjNVdXxFVWdLkUBW0d6P1P8qnvRmEbKj8=.e4b05cec-7457-4fcb-a382-eddb3292992d@github.com>

On Fri, 17 Feb 2023 23:16:52 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> CSR needed I guess
>
>> @vicente-romero-oracle , can you review the CSR for this? Thanks.
> 
> sure, I added some suggestions in a comment in the CSR

> @vicente-romero-oracle thank you for the feedback. As I don't have a JBS account, I can't incorporate it myself. @TheShermanTanker could you do that for me as you created the CSR? Thanks.

I will incorporate the changes to the CSR, please let me know if you have any suggestions

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

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

From duke at openjdk.org  Sun Feb 19 07:07:26 2023
From: duke at openjdk.org (Hannes Greule)
Date: Sun, 19 Feb 2023 07:07:26 GMT
Subject: RFR: 8292275: javac does not emit SYNTHETIC and MANDATED flags for
 parameters by default [v2]
In-Reply-To: <7sO9lIqHflWjNVdXxFVWdLkUBW0d6P1P8qnvRmEbKj8=.e4b05cec-7457-4fcb-a382-eddb3292992d@github.com>
References: <cXBKN2YWuFVzdacmxsQvmYPy16bODPQvoyy_ovJ2EiM=.052011cd-598e-4bf7-bc10-3a2171f4b317@github.com>
 <usvSorj8frQuf8JoKs4V9DctbM5NQJqz2BMVyNY3c1Y=.15a3693f-2062-4edf-a381-a76b44101fa2@github.com>
 <6h4fb3uQb5CVMis_G5D7jDf-4EcPHveKtEIXF3mlvZw=.7a945163-3726-44cb-b884-c34318ecb5a3@github.com>
 <pj2IC-MxNa69wTj8tpNxY68B9vRNsPj1OZ4Myg-TD-8=.3b6be8f7-b131-4d4f-8c99-85fb9a4866f4@github.com>
 <7sO9lIqHflWjNVdXxFVWdLkUBW0d6P1P8qnvRmEbKj8=.e4b05cec-7457-4fcb-a382-eddb3292992d@github.com>
Message-ID: <OcXJC3tiEHRR2w-IuQ0f3P3Gah1y5-zL1B9RD_UDjFc=.f55fe855-e0b1-4fa8-ac3f-69c24b4183d2@github.com>

On Sun, 19 Feb 2023 04:03:19 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> I will incorporate the changes to the CSR, please let me know if you have any suggestions

THanks again. I don't have any more suggestions.

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

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

From davidalayachew at gmail.com  Sun Feb 19 11:55:32 2023
From: davidalayachew at gmail.com (David Alayachew)
Date: Sun, 19 Feb 2023 06:55:32 -0500
Subject: Could someone take another look at my submitted bug regarding class
 names?
Message-ID: <CAA9v-_Pg5NiiR0gsJTzd5t0QPn5Oi0r3Lc=nJFQVYKGAPrSWEg@mail.gmail.com>

Hello Compiler-Dev Team,

I have seen a lot of recent discussions about class names and how the
compiler should generate them (or fail with an error). Seeing that, I
wanted to query the group and see if anyone has the bandwidth to look at
this and give some insight.

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

The developer assigned labeled it as an enhancement, but I don't see how. I
reached out to the developer and tried to contest it, but received no
response.

Could someone take another look at this bug and give me some insight on
what this bug should be classified as and why?

Thank you for your time and help!
David Alayachew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230219/48555a1d/attachment.htm>

From archie.cobbs at gmail.com  Sun Feb 19 20:35:43 2023
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Sun, 19 Feb 2023 14:35:43 -0600
Subject: Could someone take another look at my submitted bug regarding
 class names?
In-Reply-To: <CAA9v-_Pg5NiiR0gsJTzd5t0QPn5Oi0r3Lc=nJFQVYKGAPrSWEg@mail.gmail.com>
References: <CAA9v-_Pg5NiiR0gsJTzd5t0QPn5Oi0r3Lc=nJFQVYKGAPrSWEg@mail.gmail.com>
Message-ID: <CANSoFxtSbxoLTZo+eaXMdqXZOc+sRZ7c=MV=08fm6wAQWGC_ZA@mail.gmail.com>

On Sun, Feb 19, 2023 at 5:56 AM David Alayachew <davidalayachew at gmail.com>
wrote:

> I have seen a lot of recent discussions about class names and how the
> compiler should generate them (or fail with an error). Seeing that, I
> wanted to query the group and see if anyone has the bandwidth to look at
> this and give some insight.
>
> https://bugs.openjdk.org/browse/JDK-8287885
>

This is not just a problem for inner classes and not just for Windows. I
can reproduce this on my Macbook (which has case-preserving but
case-insensitive filesystem by default) as well:

$ cat a/Foo.java
public class Foo {
    public static void main(String[] args) {
        System.out.println("Foo");
    }
}
$ cat b/FOO.java
public class FOO {
    public static void main(String[] args) {
        System.out.println("FOO");
    }
}
$ javac -d classes {a,b}/*.java
$ ls classes/
Foo.class
$ java -cp classes Foo
Error: Could not find or load main class Foo
Caused by: java.lang.NoClassDefFoundError: FOO (wrong name: Foo)

As the example above shows, just fixing the problem for inner class names
would only be a partial fix.

And of course, this is not just a problem for the compiler, but also the
runtime... i.e., you can't load both Foo.class and FOO.class from the same
directory. But (in contrast to compilation) that problem you can easily
address by putting your classes into a JAR file, etc.

So just brainstorming here... what would it take to fix this?

One could imagine adding a flag like "-dzip classes.zip" which would write
the classes to a ZIP file instead of the filesystem.

So fixing this is do-able but not trivial.. it would take some work to e.g.
create a ZIP file implementation of JavacFileManager, etc.

-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230219/4d169956/attachment.htm>

From duke at openjdk.org  Sun Feb 19 23:59:13 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Sun, 19 Feb 2023 23:59:13 GMT
Subject: RFR: 8026369: javac potentially ambiguous overload warning needs an
 improved scheme
Message-ID: <IMxp3iCK--jYJ5Ia04i6QPYfnCHQobVcsmlI5aJXdqc=.892abcb8-7f2a-4fe9-aea2-1b1d41098a6d@github.com>

This bug relates to the "potentially ambiguous overload" warning which is enabled by `-Xlint:overloads`.

The warning detects certain ambiguities that can cause problems for lambdas. For example, consider the interface `Spliterator.OfInt`, which declares these two methods:

void forEachRemaining(Consumer<? super Integer> action);
void forEachRemaining(IntConsumer action);

Both methods have the same name, same number of parameters, and take a lambda with the same "shape" in the same argument position. This causes an ambiguity in any code that wants to do this:

    spliterator.forEachRemaining(x -> { ... });

That code won't compile; instead, you'll get this error:

Ambiguity.java:4: error: reference to forEachRemaining is ambiguous
        spliterator.forEachRemaining(x -> { });
                   ^
  both method forEachRemaining(IntConsumer) in OfInt and method forEachRemaining(Consumer<? super Integer>) in OfInt match


The problem reported by the bug is that the warning fails to detect ambiguities which are created purely by inheritance, for example:

interface ConsumerOfInteger {
    void foo(Consumer<Integer> c);
}

interface IntegerConsumer {
    void foo(IntConsumer c);
}

// We should get a warning here...
interface Test extends ConsumerOfInteger, IntegerConsumer {
}


The cause of the bug is that ambiguities are detected on a per-method basis, by checking whether a method is part of an ambiguity pair when we visit that method. So if the methods in an ambiguity pair are inherited from two distinct supertypes, we'll miss the ambiguity.

To fix the problem, we need to look for ambiguities on a per-class level, checking all pairs of methods. However, it's not that simple - we only want to "blame" a class when that class itself, and not some supertype, is responsible for creating the ambiguity. For example, any interface extending `Spliterator.OfInt` will automatically inherit the two ambiguities mentioned above, but these are not the interface's fault so to speak so no warning should be generated. Making things more complicated is the fact that methods can be overridden and declared in generic classes so they only conflict in some subtypes, etc.

So we generate the warning when there are two methods m1 and m2 in a class C such that:

* m1 and m2 consitiute a "potentially ambiguous overload" (using the same definition as before)
* There is no direct supertype T of C such that m1 and m2, or some methods they override, both exist in T and constitute a "potentially ambiguous overload" as members of T
* We haven't already generated a warning for either m1 or m2 in class C

If either method is declared in C, we locate the warning there, but when both methods are inherited, there's no method declaration to point at so the warning is instead located at the class declaration.

I noticed a couple of other minor bugs; these are also being fixed here:

(1) For inherited methods, the method signatures were being reported as they are declared, rather than in the context of the class being visited. As a result, when a methods is inherited from a generic supertype, the ambiguity is less clear. Here's an example:

interface Upper<T> {
    void foo(T c);
}

interface Lower extends Upper<IntConsumer> {
    void foo(Consumer<Integer> c);
}

Currently, the error is reported as:

warning: [overloads] foo(Consumer<Integer>) in Lower is potentially ambiguous with foo(T) in Upper

Reporting the method signatures in the context of the class being visited makes the ambiguity clearer:

warning: [overloads] foo(Consumer<Integer>) in Lower is potentially ambiguous with foo(IntConsumer) in Upper


(2) When a method is identified as part of an ambiguous pair, we were setting a `POTENTIALLY_AMBIGUOUS` flag on it. This caused it to be forever excluded from future warnings. For methods that are declared in the class we're visiting, this makes sense, but it doesn't make sense for inherited methods, because it disqualifies them from participating in the analysis of any other class that also inherits them.

As a result, for a class like the one below, the compiler was only generating one warning instead of three:

public interface SuperIface {
    void foo(Consumer<Integer> c);
}

public interface I1 extends SuperIface { 
    void foo(IntConsumer c);        // warning was generated here
}   

public interface I2 extends SuperIface { 
    void foo(IntConsumer c);        // no warning was generated here
}   

public interface I3 extends SuperIface { 
    void foo(IntConsumer c);        // no warning was generated here
}   


With this patch the `POTENTIALLY_AMBIGUOUS` flag is no longer needed. I wasn't sure whether to renumber all the subsequent flags, or just leave an empty placeholder, so I chose the latter.

Finally, this fix uncovers new warnings in `java.base` and `java.desktop`, so these are now suppressed in the patch.

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

Commit messages:
 - Fix incomplete detection of potentially ambiguous method declarations.

Changes: https://git.openjdk.org/jdk/pull/12645/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12645&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8026369
  Stats: 356 lines in 18 files changed: 280 ins; 36 del; 40 mod
  Patch: https://git.openjdk.org/jdk/pull/12645.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12645/head:pull/12645

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

From duke at openjdk.org  Mon Feb 20 02:01:11 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Mon, 20 Feb 2023 02:01:11 GMT
Subject: RFR: 8029301: Confusing error message for array creation method
 reference
Message-ID: <5hjAQ5_IubT-sYrNAm_L6ZfH9aQCLq8tkt_lNj7f0U4=.7121a235-88cd-41c4-ae96-ec02fbe78db7@github.com>

The error for an invalid constructor reference of an array type looks like this:

Test.java:3: error: incompatible types: invalid constructor reference
        Runnable r = String[]::new;
                     ^
    constructor Array in class Array cannot be applied to given types
      required: int
      found:    no arguments
      reason: actual and formal argument lists differ in length

The phrase "constructor Array in class Array" is somewhat confusing.

This is a simple patch to reword this type of error to look like this instead:

Test.java:3: error: incompatible types: invalid constructor reference
        Runnable r = String[]::new;
                     ^
    cannot create array from given types
      required: int
      found:    no arguments
      reason:   actual and formal argument lists differ in length

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

Commit messages:
 - Improve error referring to "constructor Array in class Array".

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

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

From davidalayachew at gmail.com  Mon Feb 20 03:04:45 2023
From: davidalayachew at gmail.com (David Alayachew)
Date: Sun, 19 Feb 2023 22:04:45 -0500
Subject: Could someone take another look at my submitted bug regarding
 class names?
In-Reply-To: <CANSoFxtSbxoLTZo+eaXMdqXZOc+sRZ7c=MV=08fm6wAQWGC_ZA@mail.gmail.com>
References: <CAA9v-_Pg5NiiR0gsJTzd5t0QPn5Oi0r3Lc=nJFQVYKGAPrSWEg@mail.gmail.com>
 <CANSoFxtSbxoLTZo+eaXMdqXZOc+sRZ7c=MV=08fm6wAQWGC_ZA@mail.gmail.com>
Message-ID: <CAA9v-_Os4Mhr8JYx8c8oK7B1TA54X7=puFd8D1=g25bvV=3XnQ@mail.gmail.com>

Hello Archie,

Thank you for your response.

> I can reproduce this on my Macbook
> (which has case-preserving but
> case-insensitive filesystem by default)
> as well

Thank you very much for pointing this out. I figured this behaviour would
exist on other OS' but didn't have a Mac to test. Knowing now that this
exists on 2 major OS', especially as a default setting, really makes this
bug even more painful in my eyes.

> As the example above shows, just fixing
> the problem for inner class names would
> only be a partial fix.

Great catch. Yes, this problem extends far outside of local classes, so we
may need a better solution than what I proposed here --->
https://bugs.openjdk.org/browse/JDK-8287885?focusedCommentId=14506844&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14506844

> And of course, this is not just a problem
> for the compiler, but also the runtime...

And not only that, but (echoing my bug submission) if you have more than 2
classes whose names are equal aside from casing, you still only get one
error. Meaning, if you make 3 classes whose names differ only in casing,
your program will fail at the first failed attempt to find the class. You
fix the name for class 2, recompile all classes with no warnings, rerun,
and then get hit with the same error for class 3, whose filename is still
equal except for casing.

> One could imagine adding a flag like
> "-dzip classes.zip" which would write the
> classes to a ZIP file instead of the
> filesystem.

I see what you're getting at. Regardless of the OS, .zip files always
respect case, and therefore, you could bypass this problem for all OS' by
simply interfacing with a file format that can't run into this problem.

One potential benefit that this solution brings (though I am very ignorant
about it) is that Java has many tools that allow it to easily interface
with .zip files, so a lot of the infrastructure may already be there to
make this change. Again, I speak from ignorance here, so this could just be
woefully wrong.

> So just brainstorming here... what would
> it take to fix this?

As I see it, the entire problem boils down to the compiler trying to be
case-sensitive, while the file storage location (the underlying OS) is
case-insensitive (but with a name that retains its original casing).

Maybe I am naive, but why not add a signifier/suffix to the resulting
.class file name to differentiate? Java already does this. Going back to my
local classes example, if 2 local classes have the exact same name (where
even the cases are the same), javac will call them Abc.java and Abc$1.java,
or something like that. The point is, appending a signifier at the end is
apparently good enough for the compiler to be able to tell which class to
load when we run the compiled code. Would that not be an effective solution
here too? Of course, I don't know the internal logic that allows us to see
Abc$1.java and know that we have the right class.

> So fixing this is do-able but not trivial

I see what you mean. One thing that may be helpful as an intermediate goal
would be to emit a warning/error on compile when running into this. At
least then, we can minimize the impact of developers unexpectedly running
into this during runtime. In the meantime, a more complex and long term
solution can be developed.

Thank you again for your time and insight!
David Alayachew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230219/84db3e92/attachment.htm>

From archie.cobbs at gmail.com  Mon Feb 20 04:45:06 2023
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Sun, 19 Feb 2023 22:45:06 -0600
Subject: Could someone take another look at my submitted bug regarding
 class names?
In-Reply-To: <CAA9v-_Os4Mhr8JYx8c8oK7B1TA54X7=puFd8D1=g25bvV=3XnQ@mail.gmail.com>
References: <CAA9v-_Pg5NiiR0gsJTzd5t0QPn5Oi0r3Lc=nJFQVYKGAPrSWEg@mail.gmail.com>
 <CANSoFxtSbxoLTZo+eaXMdqXZOc+sRZ7c=MV=08fm6wAQWGC_ZA@mail.gmail.com>
 <CAA9v-_Os4Mhr8JYx8c8oK7B1TA54X7=puFd8D1=g25bvV=3XnQ@mail.gmail.com>
Message-ID: <CANSoFxsW7-oe=j2qiFb=W11qx8kf+-rYZyBdd=AL5VbnantF5Q@mail.gmail.com>

On Sun, Feb 19, 2023 at 9:04 PM David Alayachew <davidalayachew at gmail.com>
wrote:

> Maybe I am naive, but why not add a signifier/suffix to the resulting
> .class file name to differentiate? Java already does this. Going back to my
> local classes example, if 2 local classes have the exact same name (where
> even the cases are the same), javac will call them Abc.java and Abc$1.java,
> or something like that. The point is, appending a signifier at the end is
> apparently good enough for the compiler to be able to tell which class to
> load when we run the compiled code. Would that not be an effective solution
> here too?
>

That would work for synthetic inner classes. It still doesn't solve the
larger problem though.

> So fixing this is do-able but not trivial
>
> I see what you mean. One thing that may be helpful as an intermediate goal
> would be to emit a warning/error on compile when running into this. At
> least then, we can minimize the impact of developers unexpectedly running
> into this during runtime. In the meantime, a more complex and long term
> solution can be developed.
>

Even a warning is non-trivial. It's normal to overwrite existing class
files, so you couldn't rely on checking whether the file already existed.
The file manager would have to keep track of every class file that it has
written out so it could detect when a clash occurs, or something like that.

Also note that what exactly case-insensitive means depends on your choice
of Locale (see also this link <https://stackoverflow.com/q/8899929/263801>).
That may or may not matter depending on the approach.

-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230219/8e573e71/attachment-0001.htm>

From jlahoda at openjdk.org  Mon Feb 20 11:08:29 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 20 Feb 2023 11:08:29 GMT
Subject: RFR: 8014021: TreeMaker.Params behaves inconsistently when the
 owning method has the same number of parameters as the number of parameter
 types requested [v2]
In-Reply-To: <2JrIh8PxT5_AnnmdkKC42a5bKFUbyqTn8WVVMbqkI5I=.6777d968-0dbe-4918-9129-69a5a19cae60@github.com>
References: <BzhNJqqlKr5rhox4c1v1B2w6PBidy2Mgi-UyRs1EhSk=.ff2fdae6-3e08-46e4-83a0-adf1bafa0126@github.com>
 <2JrIh8PxT5_AnnmdkKC42a5bKFUbyqTn8WVVMbqkI5I=.6777d968-0dbe-4918-9129-69a5a19cae60@github.com>
Message-ID: <W5J1B1XwyT9GKcZVJ1bvgGc2slxfHZD2S8NyQXNGzqM=.06011ed0-19bb-4a23-8f31-88002d9846cc@github.com>

On Sat, 18 Feb 2023 16:39:34 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> The method `TreeMaker.Params` has what appears to be strange behavior: normally it creates parameters of the types passed in. However, if the given owner is a method, and the method happens to have the same number of parameters as the number of parameters requested, then the types of the owner method's parameters are used instead. This is weird and confusing.
>> 
>> What's really going on is that a method owner is _always_ being passed in, and when that method has parameters defined, there are _always_ exactly as many of them as there are types provided.
>> 
>> So what this method is really doing is just reusing the same symbols for the methods parameters if the method has them defined, otherwise creating the same number of placeholder parameters `x0`, `x1`, `x2`, etc.
>> 
>> This patch refactors this method and clarifies its usage to eliminate the confusion.
>
> Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Create two variants of TreeMaker.Params() for the two different use cases.

LGTM

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

Marked as reviewed by jlahoda (Reviewer).

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

From davidalayachew at gmail.com  Mon Feb 20 13:27:33 2023
From: davidalayachew at gmail.com (David Alayachew)
Date: Mon, 20 Feb 2023 08:27:33 -0500
Subject: Could someone take another look at my submitted bug regarding
 class names?
In-Reply-To: <CANSoFxsW7-oe=j2qiFb=W11qx8kf+-rYZyBdd=AL5VbnantF5Q@mail.gmail.com>
References: <CAA9v-_Pg5NiiR0gsJTzd5t0QPn5Oi0r3Lc=nJFQVYKGAPrSWEg@mail.gmail.com>
 <CANSoFxtSbxoLTZo+eaXMdqXZOc+sRZ7c=MV=08fm6wAQWGC_ZA@mail.gmail.com>
 <CAA9v-_Os4Mhr8JYx8c8oK7B1TA54X7=puFd8D1=g25bvV=3XnQ@mail.gmail.com>
 <CANSoFxsW7-oe=j2qiFb=W11qx8kf+-rYZyBdd=AL5VbnantF5Q@mail.gmail.com>
Message-ID: <CAA9v-_MVVVip4v_VmGb311dWM9wWBOJESWk8dwD0fhQ0w9Y_=w@mail.gmail.com>

Hello Archie,

Thank you for your response.

> Also note that what exactly
> case-insensitive means depends on your
> choice of Locale (see also this link
<https://stackoverflow.com/q/8899929/263801>). That
> may or may not matter depending on the
> approach.

Good catch, ty. From what I have read, it seems like java class names must
be limited to a very small set of ASCII characters, and even within that
set, there are more restrictions. Based on that, and the fact that class
names must match their created .class file names (with the exception of the
aforementioned suffixes/signifiers), I think we should be good for either
of our suggested solutions. Unless I misunderstand Locale and it's impacts?


> Even a warning is non-trivial. It's normal
> to overwrite existing class files, so you
> couldn't rely on checking whether the file
> already existed. The file manager would
> have to keep track of every class file that
> it has written out so it could detect when
> a clash occurs, or something like that.

Fair point. And furthermore, that tracking you are describing is likely
what would be needed if we want the compiler to be robust enough to handle
these valid class names without making a .zip file.

> That would work for synthetic inner
> classes. It still doesn't solve the larger
> problem though.

I'm not following.

To my understanding, $ is a valid character in Java class names and .class
filenames. It is also strongly discouraged for developers to intentionally
name their classes like that. Reason being that the compiler wants to use
that character for handling things like Abc$1.java like I mentioned before.

So, when we compile our classes using javac, the compiler checks for name
conflicts between all provided java classes (keeping in mind the casing and
how it plays with OS'), then generates a unique suffix for all
"conflicting" class names.

Then, you name each "conflicting" class name with their respective class
name + suffix, and then you literally put in Abc$1 as the explicit class
inside of the .class files. That way, during runtime, we know which class
is referencing which .class file, and vice versa.

Let's use your code as an example. You wrote the following execution.

---
$ javac -d classes {a,b}/*.java
$ ls classes/
Foo.class
---

As you showed previously, the above will fail at runtime because only one
.class file was generated.

I am suggesting this behaviour instead.

---
$ javac -d classes {a,b}/*.java
$ ls classes/
FOO$1.class Foo$2.class
---

Now, each class file is unique, regardless of OS casing. And if we were to
open up these 2 class files, they wouldn't reference each other using Foo
and FOO - they would use FOO$1 and Foo$2. That way, they know where exactly
what .class file to reference, as there is only one match.

Would that not work as a solution for both of our scenarios?

Thank you for time and insight!
David Alayachew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230220/5eee957d/attachment.htm>

From davidalayachew at gmail.com  Mon Feb 20 13:29:38 2023
From: davidalayachew at gmail.com (David Alayachew)
Date: Mon, 20 Feb 2023 08:29:38 -0500
Subject: Could someone take another look at my submitted bug regarding
 class names?
In-Reply-To: <CAA9v-_MVVVip4v_VmGb311dWM9wWBOJESWk8dwD0fhQ0w9Y_=w@mail.gmail.com>
References: <CAA9v-_Pg5NiiR0gsJTzd5t0QPn5Oi0r3Lc=nJFQVYKGAPrSWEg@mail.gmail.com>
 <CANSoFxtSbxoLTZo+eaXMdqXZOc+sRZ7c=MV=08fm6wAQWGC_ZA@mail.gmail.com>
 <CAA9v-_Os4Mhr8JYx8c8oK7B1TA54X7=puFd8D1=g25bvV=3XnQ@mail.gmail.com>
 <CANSoFxsW7-oe=j2qiFb=W11qx8kf+-rYZyBdd=AL5VbnantF5Q@mail.gmail.com>
 <CAA9v-_MVVVip4v_VmGb311dWM9wWBOJESWk8dwD0fhQ0w9Y_=w@mail.gmail.com>
Message-ID: <CAA9v-_OOXbX8Xjk0-YftqjNSAGbhPVFUdd_BcJxAUz_cSfBprQ@mail.gmail.com>

> Reason being that the compiler wants to
> use that character for handling things like
> Abc$1.java like I mentioned before.

Whoops. I meant to say Abc$1.class

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230220/4522c7fc/attachment.htm>

From jonathan.gibbons at oracle.com  Mon Feb 20 15:51:33 2023
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 20 Feb 2023 07:51:33 -0800
Subject: Could someone take another look at my submitted bug regarding
 class names?
In-Reply-To: <CANSoFxsW7-oe=j2qiFb=W11qx8kf+-rYZyBdd=AL5VbnantF5Q@mail.gmail.com>
References: <CAA9v-_Pg5NiiR0gsJTzd5t0QPn5Oi0r3Lc=nJFQVYKGAPrSWEg@mail.gmail.com>
 <CANSoFxtSbxoLTZo+eaXMdqXZOc+sRZ7c=MV=08fm6wAQWGC_ZA@mail.gmail.com>
 <CAA9v-_Os4Mhr8JYx8c8oK7B1TA54X7=puFd8D1=g25bvV=3XnQ@mail.gmail.com>
 <CANSoFxsW7-oe=j2qiFb=W11qx8kf+-rYZyBdd=AL5VbnantF5Q@mail.gmail.com>
Message-ID: <46dc83ce-37ff-8b91-091c-384597b4f34c@oracle.com>


On 2/19/23 8:45 PM, Archie Cobbs wrote:
> On Sun, Feb 19, 2023 at 9:04 PM David Alayachew 
> <davidalayachew at gmail.com> wrote:
>
>     Maybe I am naive, but why not add a signifier/suffix to the
>     resulting .class file name to differentiate? Java already does
>     this. Going back to my local classes example, if 2 local classes
>     have the exact same name (where even the cases are the same),
>     javac will call them Abc.java and Abc$1.java, or something like
>     that. The point is, appending a signifier at the end is apparently
>     good enough for the compiler to be able to tell which class to
>     load when we run the compiled code. Would that not be an effective
>     solution here too?
>
>
> That would work for synthetic inner classes. It still doesn't solve 
> the larger problem though.
>
>     >?So fixing this is do-able but not trivial
>
>     I see what you mean. One thing that may be helpful as an
>     intermediate goal would be to emit a warning/error on compile when
>     running into this. At least then, we can minimize the impact of
>     developers unexpectedly running into this during runtime. In the
>     meantime, a more complex and long term solution can be developed.
>
> Even a warning is non-trivial. It's normal to overwrite existing class 
> files, so you couldn't rely on checking whether the file already 
> existed. The file manager would have to keep track of every class file 
> that it has written out so it could detect when a clash occurs, or 
> something like that.

Even that is not enough; the files may be written by different 
compilations. The file manager would potentially read the contents of 
every file before overwriting it, to decide whether to generate a message.

-- Jon



>
> Also note that what exactly case-insensitive means depends on your 
> choice of Locale (see also this link 
> <https://stackoverflow.com/q/8899929/263801>). That may or may not 
> matter depending on the approach.
>
> -Archie
>
> -- 
> Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230220/9a8c1131/attachment-0001.htm>

From jonathan.gibbons at oracle.com  Mon Feb 20 16:06:30 2023
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 20 Feb 2023 08:06:30 -0800
Subject: Could someone take another look at my submitted bug regarding
 class names?
In-Reply-To: <CAA9v-_Pg5NiiR0gsJTzd5t0QPn5Oi0r3Lc=nJFQVYKGAPrSWEg@mail.gmail.com>
References: <CAA9v-_Pg5NiiR0gsJTzd5t0QPn5Oi0r3Lc=nJFQVYKGAPrSWEg@mail.gmail.com>
Message-ID: <17b50909-d168-06e2-91e9-805bdc9a573e@oracle.com>


On 2/19/23 3:55 AM, David Alayachew wrote:
> Hello Compiler-Dev Team,
>
> I have seen a lot of recent discussions about class names and how the 
> compiler should generate them (or fail with an error). Seeing that, I 
> wanted to query the group and see if anyone has the bandwidth to look 
> at this and give some insight.
>
> https://bugs.openjdk.org/browse/JDK-8287885
>
> The developer assigned labeled it as an enhancement, but I don't see 
> how. I reached out to the developer and tried to contest it, but 
> received no response.
>
> Could someone take another look at this bug and give me some insight 
> on what this bug should be classified as and why?
>
> Thank you for your time and help!
> David Alayachew


JLS 2 contained the following text suggesting that file names could be 
encoded in some way:

---
A package name component or class name might contain a character that 
cannot correctly appear in a host file system's ordinary directory name, 
such as a Unicode character on a system that allows only ASCII 
characters in file names. As a convention, the character can be escaped 
by using, say, the @ character followed by four hexadecimal digits 
giving the numeric value of the character, as in the \uxxxx escape 
(?3.3), so that the package name:

children.activities.crafts.papierM\u00e2ch\u00e9

which can also be written using full Unicode as:

children.activities.crafts.papierM?ch?

might be mapped to the directory name:

children/activities/crafts/papierM at 00e2ch@00e9

If the @ character is not a valid character in a file name for some 
given host file system, then some other character that is not valid in a 
identifier could be used instead.

---


However, the text is not in JLS 3 and that ship has effectively sailed. 
Changing the filename usage would be an incompatible change of seismic 
proportions across the entire ecosystem.

-- Jon


From ethan at mccue.dev  Mon Feb 20 16:10:54 2023
From: ethan at mccue.dev (Ethan McCue)
Date: Mon, 20 Feb 2023 11:10:54 -0500
Subject: Could someone take another look at my submitted bug regarding
 class names?
In-Reply-To: <46dc83ce-37ff-8b91-091c-384597b4f34c@oracle.com>
References: <CAA9v-_Pg5NiiR0gsJTzd5t0QPn5Oi0r3Lc=nJFQVYKGAPrSWEg@mail.gmail.com>
 <CANSoFxtSbxoLTZo+eaXMdqXZOc+sRZ7c=MV=08fm6wAQWGC_ZA@mail.gmail.com>
 <CAA9v-_Os4Mhr8JYx8c8oK7B1TA54X7=puFd8D1=g25bvV=3XnQ@mail.gmail.com>
 <CANSoFxsW7-oe=j2qiFb=W11qx8kf+-rYZyBdd=AL5VbnantF5Q@mail.gmail.com>
 <46dc83ce-37ff-8b91-091c-384597b4f34c@oracle.com>
Message-ID: <CA+NR86jrBN32iAeHjEG_aHHmJAYdaGB7Tfd6N_P1CFKvG0QYKw@mail.gmail.com>

If a tool needs to have an opinion about how multiple compiler runs should
interact, that feels like it's edging closer to a build tool than a
compiler.

On Mon, Feb 20, 2023, 10:52 AM Jonathan Gibbons <jonathan.gibbons at oracle.com>
wrote:

>
> On 2/19/23 8:45 PM, Archie Cobbs wrote:
>
> On Sun, Feb 19, 2023 at 9:04 PM David Alayachew <davidalayachew at gmail.com>
> wrote:
>
>> Maybe I am naive, but why not add a signifier/suffix to the resulting
>> .class file name to differentiate? Java already does this. Going back to my
>> local classes example, if 2 local classes have the exact same name (where
>> even the cases are the same), javac will call them Abc.java and Abc$1.java,
>> or something like that. The point is, appending a signifier at the end is
>> apparently good enough for the compiler to be able to tell which class to
>> load when we run the compiled code. Would that not be an effective solution
>> here too?
>>
>
> That would work for synthetic inner classes. It still doesn't solve the
> larger problem though.
>
> > So fixing this is do-able but not trivial
>>
>> I see what you mean. One thing that may be helpful as an intermediate
>> goal would be to emit a warning/error on compile when running into this. At
>> least then, we can minimize the impact of developers unexpectedly running
>> into this during runtime. In the meantime, a more complex and long term
>> solution can be developed.
>>
>
> Even a warning is non-trivial. It's normal to overwrite existing class
> files, so you couldn't rely on checking whether the file already existed.
> The file manager would have to keep track of every class file that it has
> written out so it could detect when a clash occurs, or something like that.
>
> Even that is not enough; the files may be written by different
> compilations. The file manager would potentially read the contents of every
> file before overwriting it, to decide whether to generate a message.
>
> -- Jon
>
>
>
>
> Also note that what exactly case-insensitive means depends on your choice
> of Locale (see also this link <https://stackoverflow.com/q/8899929/263801>).
> That may or may not matter depending on the approach.
>
> -Archie
>
> --
> Archie L. Cobbs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230220/26152284/attachment.htm>

From archie.cobbs at gmail.com  Mon Feb 20 16:14:12 2023
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Mon, 20 Feb 2023 10:14:12 -0600
Subject: Could someone take another look at my submitted bug regarding
 class names?
In-Reply-To: <CAA9v-_MVVVip4v_VmGb311dWM9wWBOJESWk8dwD0fhQ0w9Y_=w@mail.gmail.com>
References: <CAA9v-_Pg5NiiR0gsJTzd5t0QPn5Oi0r3Lc=nJFQVYKGAPrSWEg@mail.gmail.com>
 <CANSoFxtSbxoLTZo+eaXMdqXZOc+sRZ7c=MV=08fm6wAQWGC_ZA@mail.gmail.com>
 <CAA9v-_Os4Mhr8JYx8c8oK7B1TA54X7=puFd8D1=g25bvV=3XnQ@mail.gmail.com>
 <CANSoFxsW7-oe=j2qiFb=W11qx8kf+-rYZyBdd=AL5VbnantF5Q@mail.gmail.com>
 <CAA9v-_MVVVip4v_VmGb311dWM9wWBOJESWk8dwD0fhQ0w9Y_=w@mail.gmail.com>
Message-ID: <CANSoFxvccRLmyJO9tY3WrVXm1MKaGBfxTrre+-XPh=fTJvvRKg@mail.gmail.com>

On Mon, Feb 20, 2023 at 7:27 AM David Alayachew <davidalayachew at gmail.com>
wrote:

> > Also note that what exactly
> > case-insensitive means depends on your
> > choice of Locale (see also this link
> <https://stackoverflow.com/q/8899929/263801>). That
> > may or may not matter depending on the
> > approach.
>
> Good catch, ty. From what I have read, it seems like java class names must
> be limited to a very small set of ASCII characters
>

Nope...

$ cat D?c?r?b?l?.java
public class D?c?r?b?l? { }
$ javac -d classes D?c?r?b?l?.java
$ ls classes/
De?ce?re?be?le?.class

I am suggesting this behaviour instead.
>
> ---
> $ javac -d classes {a,b}/*.java
> $ ls classes/
> FOO$1.class Foo$2.class
> ---
>
> Now, each class file is unique, regardless of OS casing. And if we were to
> open up these 2 class files, they wouldn't reference each other using Foo
> and FOO - they would use FOO$1 and Foo$2. That way, they know where exactly
> what .class file to reference, as there is only one match.
>
> Would that not work as a solution for both of our scenarios?
>

Sorry I should have been clearer... yes your idea would solve the problem,
but at the expense of backward compatibility. That makes it a non-starter.
As Jon points out that would be "an incompatible change of seismic
proportions".

Your idea *can* be done in a compatible way for local classes. Here's a
sample patch
<https://github.com/openjdk/jdk/compare/master...archiecobbs:jdk:JDK-8287885>.
This would be a limited, tactical change that doesn't solve the whole
problem but addresses the ASCII-only narrow case in the bug.

-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230220/6e0fd989/attachment-0001.htm>

From ethan at mccue.dev  Mon Feb 20 16:39:09 2023
From: ethan at mccue.dev (Ethan McCue)
Date: Mon, 20 Feb 2023 11:39:09 -0500
Subject: Could someone take another look at my submitted bug regarding
 class names?
In-Reply-To: <CANSoFxvccRLmyJO9tY3WrVXm1MKaGBfxTrre+-XPh=fTJvvRKg@mail.gmail.com>
References: <CAA9v-_Pg5NiiR0gsJTzd5t0QPn5Oi0r3Lc=nJFQVYKGAPrSWEg@mail.gmail.com>
 <CANSoFxtSbxoLTZo+eaXMdqXZOc+sRZ7c=MV=08fm6wAQWGC_ZA@mail.gmail.com>
 <CAA9v-_Os4Mhr8JYx8c8oK7B1TA54X7=puFd8D1=g25bvV=3XnQ@mail.gmail.com>
 <CANSoFxsW7-oe=j2qiFb=W11qx8kf+-rYZyBdd=AL5VbnantF5Q@mail.gmail.com>
 <CAA9v-_MVVVip4v_VmGb311dWM9wWBOJESWk8dwD0fhQ0w9Y_=w@mail.gmail.com>
 <CANSoFxvccRLmyJO9tY3WrVXm1MKaGBfxTrre+-XPh=fTJvvRKg@mail.gmail.com>
Message-ID: <CA+NR86gpNfrLOVfSzmn_BFn9C=NvcoaPftXqq_YRCQwxoN=Zfw@mail.gmail.com>

To throw a unicode wrench in the mix.

    class cafe\u0301 {

    }

    class caf\u00e9 {

    }

    public class Main {
        public static void main(String[] args) {
            var a = new cafe\u0301();
            var b = new caf\u00e9();

            System.out.println(a);
            System.out.println(b);
        }
    }

I seem to only get one caf?.class file out in the end.

On Mon, Feb 20, 2023 at 11:15 AM Archie Cobbs <archie.cobbs at gmail.com>
wrote:

>
>
> On Mon, Feb 20, 2023 at 7:27 AM David Alayachew <davidalayachew at gmail.com>
> wrote:
>
>> > Also note that what exactly
>> > case-insensitive means depends on your
>> > choice of Locale (see also this link
>> <https://stackoverflow.com/q/8899929/263801>). That
>> > may or may not matter depending on the
>> > approach.
>>
>> Good catch, ty. From what I have read, it seems like java class names
>> must be limited to a very small set of ASCII characters
>>
>
> Nope...
>
> $ cat D?c?r?b?l?.java
> public class D?c?r?b?l? { }
> $ javac -d classes D?c?r?b?l?.java
> $ ls classes/
> De?ce?re?be?le?.class
>
> I am suggesting this behaviour instead.
>>
>> ---
>> $ javac -d classes {a,b}/*.java
>> $ ls classes/
>> FOO$1.class Foo$2.class
>> ---
>>
>> Now, each class file is unique, regardless of OS casing. And if we were
>> to open up these 2 class files, they wouldn't reference each other using
>> Foo and FOO - they would use FOO$1 and Foo$2. That way, they know where
>> exactly what .class file to reference, as there is only one match.
>>
>> Would that not work as a solution for both of our scenarios?
>>
>
> Sorry I should have been clearer... yes your idea would solve the problem,
> but at the expense of backward compatibility. That makes it a non-starter.
> As Jon points out that would be "an incompatible change of seismic
> proportions".
>
> Your idea *can* be done in a compatible way for local classes. Here's a
> sample patch
> <https://github.com/openjdk/jdk/compare/master...archiecobbs:jdk:JDK-8287885>.
> This would be a limited, tactical change that doesn't solve the whole
> problem but addresses the ASCII-only narrow case in the bug.
>
> -Archie
>
> --
> Archie L. Cobbs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230220/72070741/attachment.htm>

From archie.cobbs at gmail.com  Mon Feb 20 17:54:47 2023
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Mon, 20 Feb 2023 11:54:47 -0600
Subject: Could someone take another look at my submitted bug regarding
 class names?
In-Reply-To: <CA+NR86gpNfrLOVfSzmn_BFn9C=NvcoaPftXqq_YRCQwxoN=Zfw@mail.gmail.com>
References: <CAA9v-_Pg5NiiR0gsJTzd5t0QPn5Oi0r3Lc=nJFQVYKGAPrSWEg@mail.gmail.com>
 <CANSoFxtSbxoLTZo+eaXMdqXZOc+sRZ7c=MV=08fm6wAQWGC_ZA@mail.gmail.com>
 <CAA9v-_Os4Mhr8JYx8c8oK7B1TA54X7=puFd8D1=g25bvV=3XnQ@mail.gmail.com>
 <CANSoFxsW7-oe=j2qiFb=W11qx8kf+-rYZyBdd=AL5VbnantF5Q@mail.gmail.com>
 <CAA9v-_MVVVip4v_VmGb311dWM9wWBOJESWk8dwD0fhQ0w9Y_=w@mail.gmail.com>
 <CANSoFxvccRLmyJO9tY3WrVXm1MKaGBfxTrre+-XPh=fTJvvRKg@mail.gmail.com>
 <CA+NR86gpNfrLOVfSzmn_BFn9C=NvcoaPftXqq_YRCQwxoN=Zfw@mail.gmail.com>
Message-ID: <CANSoFxuu_VGDCT2rvexysVxu2iuYbE1y6w-+EH8suJ0HZFsoTg@mail.gmail.com>

On Mon, Feb 20, 2023 at 10:39 AM Ethan McCue <ethan at mccue.dev> wrote:

> To throw a unicode wrench in the mix.
>

Hah!

Here's the root cause:

$ cat FileSystem.java
import java.nio.file.*;
public class FileSystem {

    public static void main(String[] args) {
        String s = "cafe\u0301";
        showUTF(s);
        String t = FileSystems.getDefault().getPath(s).toString();
        showUTF(t);
    }

    public static void showUTF(String s) {
        StringBuilder buf = new StringBuilder(s.length() * 3);
        for (int i = 0; i < s.length(); i++) {
            if (i > 0)
                buf.append(' ');
            buf.append(String.format("%04x", (int)s.charAt(i)));
        }
        System.out.println(buf);
    }
}
$ javac FileSystem.java && java FileSystem
0063 0061 0066 0065 0301
0063 0061 0066 00e9

Looks like this happens on MacOS because
MacOSXFileSystem.normalizeNativePath() invokes
MacOSXNativeDispatcher.normalizepath().

Should this be considered a bug?

-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230220/c65630fa/attachment.htm>

From davidalayachew at gmail.com  Mon Feb 20 18:26:41 2023
From: davidalayachew at gmail.com (David Alayachew)
Date: Mon, 20 Feb 2023 13:26:41 -0500
Subject: Could someone take another look at my submitted bug regarding
 class names?
In-Reply-To: <CANSoFxvccRLmyJO9tY3WrVXm1MKaGBfxTrre+-XPh=fTJvvRKg@mail.gmail.com>
References: <CAA9v-_Pg5NiiR0gsJTzd5t0QPn5Oi0r3Lc=nJFQVYKGAPrSWEg@mail.gmail.com>
 <CANSoFxtSbxoLTZo+eaXMdqXZOc+sRZ7c=MV=08fm6wAQWGC_ZA@mail.gmail.com>
 <CAA9v-_Os4Mhr8JYx8c8oK7B1TA54X7=puFd8D1=g25bvV=3XnQ@mail.gmail.com>
 <CANSoFxsW7-oe=j2qiFb=W11qx8kf+-rYZyBdd=AL5VbnantF5Q@mail.gmail.com>
 <CAA9v-_MVVVip4v_VmGb311dWM9wWBOJESWk8dwD0fhQ0w9Y_=w@mail.gmail.com>
 <CANSoFxvccRLmyJO9tY3WrVXm1MKaGBfxTrre+-XPh=fTJvvRKg@mail.gmail.com>
Message-ID: <CAA9v-_PeFUFy9-RetcDPKDcrjX5KQWw7Y3PCuFDuEDAfTpyeWw@mail.gmail.com>

Hello Archie,

Thank you for your response.

> Nope...
>
> $ cat D?c?r?b?l?.java
> public class D?c?r?b?l? { }
> $ javac -d classes D?c?r?b?l?.java
> $ ls classes/
> De?ce?re?be?le?.class

Looks like I was misinforned. Thank you for showing the example.

> Your idea *can* be done in a compatible
> way for local classes. Here's a sample
<https://github.com/openjdk/jdk/compare/master...archiecobbs:jdk:JDK-8287885>
> patch
<https://github.com/openjdk/jdk/compare/master...archiecobbs:jdk:JDK-8287885>.
This would be a limited, tactical
> change that doesn't solve the whole
> problem but addresses the ASCII-only
> narrow case in the bug.

Thank you very much for linking this. And I understand what you are saying.
If my solution is only applicable to ASCII-only classes, then it is not a
great response to the larger problem. And that's ignoring the fact that you
provided a very good solution that sidesteps the problem entirely.

> yes your idea would solve the problem,
> but at the expense of backward
> compatibility.

Could you explain how the solution is backwards incompatible? I don't think
I understand.

> As Jon points out that would be "an
> incompatible change of seismic
> proportions".

I think I missed Jon's comment. Could you paste/link his comment here?

Thank you again for the help!
David Alayachew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230220/4d6dcd46/attachment-0001.htm>

From archie.cobbs at gmail.com  Mon Feb 20 18:31:55 2023
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Mon, 20 Feb 2023 12:31:55 -0600
Subject: Could someone take another look at my submitted bug regarding
 class names?
In-Reply-To: <CAA9v-_PeFUFy9-RetcDPKDcrjX5KQWw7Y3PCuFDuEDAfTpyeWw@mail.gmail.com>
References: <CAA9v-_Pg5NiiR0gsJTzd5t0QPn5Oi0r3Lc=nJFQVYKGAPrSWEg@mail.gmail.com>
 <CANSoFxtSbxoLTZo+eaXMdqXZOc+sRZ7c=MV=08fm6wAQWGC_ZA@mail.gmail.com>
 <CAA9v-_Os4Mhr8JYx8c8oK7B1TA54X7=puFd8D1=g25bvV=3XnQ@mail.gmail.com>
 <CANSoFxsW7-oe=j2qiFb=W11qx8kf+-rYZyBdd=AL5VbnantF5Q@mail.gmail.com>
 <CAA9v-_MVVVip4v_VmGb311dWM9wWBOJESWk8dwD0fhQ0w9Y_=w@mail.gmail.com>
 <CANSoFxvccRLmyJO9tY3WrVXm1MKaGBfxTrre+-XPh=fTJvvRKg@mail.gmail.com>
 <CAA9v-_PeFUFy9-RetcDPKDcrjX5KQWw7Y3PCuFDuEDAfTpyeWw@mail.gmail.com>
Message-ID: <CANSoFxs=y9fvVdzAVZz9S2fhXdeQMQNhFjon0yLr44JOnOVG5Q@mail.gmail.com>

On Mon, Feb 20, 2023 at 12:26 PM David Alayachew <davidalayachew at gmail.com>
wrote:

> > yes your idea would solve the problem, but at the expense of backward
> compatibility.
>
> Could you explain how the solution is backwards incompatible? I don't
> think I understand.
>

You're talking about changing the mapping that takes a Java class name and
returns the corresponding filename for that class' classfile in the
filesystem. This means classes that used to load successfully would
suddenly fail to load because the file would no longer be found.

Even if you tried to use some kind of fallback scheme, you'd still be
potentially creating filename clashes with other classes, etc.


> > As Jon points out that would be "an incompatible change of seismic
> proportions".
>
> I think I missed Jon's comment. Could you paste/link his comment here?
>

https://mail.openjdk.org/pipermail/compiler-dev/2023-February/022232.html

-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230220/02edd330/attachment.htm>

From archie.cobbs at gmail.com  Mon Feb 20 19:38:52 2023
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Mon, 20 Feb 2023 13:38:52 -0600
Subject: JDK-8030140 fixed now?
Message-ID: <CANSoFxuNPk8N0+7FdV7b-rtcA8iTNGAMaCQRx8B4rW97pVjWUA@mail.gmail.com>

I've been slowly trawling through the bug database resolving bugs that are
now fixed (aka janitorial scrubbing).

I believe JDK-8030140 <https://bugs.openjdk.org/browse/JDK-8030140> is now
fixed (thanks to clarifications in the JLS since it was filed) but it's a
little tricky so I thought I'd run it by the list to make sure my analysis
is correct.

Let me know if anyone thinks otherwise, otherwise I'll resolve it in a
couple of days. You would disagree if you think this is NOT a valid program:

    interface Iface {
        void m(Class arg);
    }

    class Super<T> {
        void m(T arg) {
        }
    }

    abstract class Foo extends Super<Class<String>> implements Iface {
        // no conflict here - two distinct methods are inherited
    }

Note this is similar to JDK-5059679
<https://bugs.openjdk.org/browse/JDK-5059679> discussed last week. I think
the same thing is happening here more or less.

Thanks,
-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230220/9a9cd1ff/attachment.htm>

From duke at openjdk.org  Mon Feb 20 20:57:18 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Mon, 20 Feb 2023 20:57:18 GMT
Subject: RFR: 8287885: Local classes cause ClassLoader error if the type names
 are similar but not same
Message-ID: <UunxL2H0Gf9ef0d4p3FRR3WjNSkzkTOSQwr8oirwp9g=.824550f6-8901-476a-9a56-350d68f9b107@github.com>

The compiler doesn't really support case-insensitive filesystems. However, we can still avoid name clashes for local classes because their names are synthesized with indexed names like`$1`, `$2`, etc.

So previously, a class like this:

public class Test {

    void method1() {
        enum ABC { A, B, C; };
    }

    void method2() {
        enum Abc { A, B, C; };
    } 
}

would generate these classfiles:

Test.class
Test$1ABC.class
Test$1Abc.class

the latter two of which clash on case-insensitive filesystems. After this patch, these non-clashing classfiles are generated instead:

Test.class
Test$1ABC.class
Test$2Abc.class


The only thing slightly wonky about this patch is that `clearLocalClassNameIndexes()` since local classes `ABC` and `Abc` share the same index, clearing either one clears both. But this is harmless, because these indexes are cleared in a batch, during a final "cleanup" step after processing the containing class.

To avoid any locale weirdness, we only collapse ASCII letters A-Z/a-z. So this is clearly a limited, tactical fix.

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

Commit messages:
 - Fix typo in comment.
 - Avoid local class classfile name clashes on case-insensitive filesystems.

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

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

From duke at openjdk.org  Mon Feb 20 23:55:24 2023
From: duke at openjdk.org (SWinxy)
Date: Mon, 20 Feb 2023 23:55:24 GMT
Subject: RFR: 8026369: javac potentially ambiguous overload warning needs
 an improved scheme
In-Reply-To: <IMxp3iCK--jYJ5Ia04i6QPYfnCHQobVcsmlI5aJXdqc=.892abcb8-7f2a-4fe9-aea2-1b1d41098a6d@github.com>
References: <IMxp3iCK--jYJ5Ia04i6QPYfnCHQobVcsmlI5aJXdqc=.892abcb8-7f2a-4fe9-aea2-1b1d41098a6d@github.com>
Message-ID: <xVTkB9-V5fVop5Mix7Gk29Ix3JCtAlBZeHR-064qaw0=.b3e9d5c2-4def-4410-8a59-c8c25049f7e4@github.com>

On Sun, 19 Feb 2023 23:52:52 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

> This bug relates to the "potentially ambiguous overload" warning which is enabled by `-Xlint:overloads`.
> 
> The warning detects certain ambiguities that can cause problems for lambdas. For example, consider the interface `Spliterator.OfInt`, which declares these two methods:
> 
> void forEachRemaining(Consumer<? super Integer> action);
> void forEachRemaining(IntConsumer action);
> 
> Both methods have the same name, same number of parameters, and take a lambda with the same "shape" in the same argument position. This causes an ambiguity in any code that wants to do this:
> 
>     spliterator.forEachRemaining(x -> { ... });
> 
> That code won't compile; instead, you'll get this error:
> 
> Ambiguity.java:4: error: reference to forEachRemaining is ambiguous
>         spliterator.forEachRemaining(x -> { });
>                    ^
>   both method forEachRemaining(IntConsumer) in OfInt and method forEachRemaining(Consumer<? super Integer>) in OfInt match
> 
> 
> The problem reported by the bug is that the warning fails to detect ambiguities which are created purely by inheritance, for example:
> 
> interface ConsumerOfInteger {
>     void foo(Consumer<Integer> c);
> }
> 
> interface IntegerConsumer {
>     void foo(IntConsumer c);
> }
> 
> // We should get a warning here...
> interface Test extends ConsumerOfInteger, IntegerConsumer {
> }
> 
> 
> The cause of the bug is that ambiguities are detected on a per-method basis, by checking whether a method is part of an ambiguity pair when we visit that method. So if the methods in an ambiguity pair are inherited from two distinct supertypes, we'll miss the ambiguity.
> 
> To fix the problem, we need to look for ambiguities on a per-class level, checking all pairs of methods. However, it's not that simple - we only want to "blame" a class when that class itself, and not some supertype, is responsible for creating the ambiguity. For example, any interface extending `Spliterator.OfInt` will automatically inherit the two ambiguities mentioned above, but these are not the interface's fault so to speak so no warning should be generated. Making things more complicated is the fact that methods can be overridden and declared in generic classes so they only conflict in some subtypes, etc.
> 
> So we generate the warning when there are two methods m1 and m2 in a class C such that:
> 
> * m1 and m2 consitiute a "potentially ambiguous overload" (using the same definition as before)
> * There is no direct supertype T of C such that m1 and m2, or some methods they override, both exist in T and constitute a "potentially ambiguous overload" as members of T
> * We haven't already generated a warning for either m1 or m2 in class C
> 
> If either method is declared in C, we locate the warning there, but when both methods are inherited, there's no method declaration to point at so the warning is instead located at the class declaration.
> 
> I noticed a couple of other minor bugs; these are also being fixed here:
> 
> (1) For inherited methods, the method signatures were being reported as they are declared, rather than in the context of the class being visited. As a result, when a methods is inherited from a generic supertype, the ambiguity is less clear. Here's an example:
> 
> interface Upper<T> {
>     void foo(T c);
> }
> 
> interface Lower extends Upper<IntConsumer> {
>     void foo(Consumer<Integer> c);
> }
> 
> Currently, the error is reported as:
> 
> warning: [overloads] foo(Consumer<Integer>) in Lower is potentially ambiguous with foo(T) in Upper
> 
> Reporting the method signatures in the context of the class being visited makes the ambiguity clearer:
> 
> warning: [overloads] foo(Consumer<Integer>) in Lower is potentially ambiguous with foo(IntConsumer) in Upper
> 
> 
> (2) When a method is identified as part of an ambiguous pair, we were setting a `POTENTIALLY_AMBIGUOUS` flag on it. This caused it to be forever excluded from future warnings. For methods that are declared in the class we're visiting, this makes sense, but it doesn't make sense for inherited methods, because it disqualifies them from participating in the analysis of any other class that also inherits them.
> 
> As a result, for a class like the one below, the compiler was only generating one warning instead of three:
> 
> public interface SuperIface {
>     void foo(Consumer<Integer> c);
> }
> 
> public interface I1 extends SuperIface { 
>     void foo(IntConsumer c);        // warning was generated here
> }   
> 
> public interface I2 extends SuperIface { 
>     void foo(IntConsumer c);        // no warning was generated here
> }   
> 
> public interface I3 extends SuperIface { 
>     void foo(IntConsumer c);        // no warning was generated here
> }   
> 
> 
> With this patch the `POTENTIALLY_AMBIGUOUS` flag is no longer needed. I wasn't sure whether to renumber all the subsequent flags, or just leave an empty placeholder, so I chose the latter.
> 
> Finally, this fix uncovers new warnings in `java.base` and `java.desktop`, so these are now suppressed in the patch.

In the `AWTEventMulticaster` class(es), which interfaces are causing the ambiguity?

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

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

From jjg at openjdk.org  Mon Feb 20 23:59:40 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 20 Feb 2023 23:59:40 GMT
Subject: Withdrawn: JDK-8298405: Support Markdown in the standard doclet
In-Reply-To: <ltVVuz_1JTacO6uHQATm0UPq7e0PmZpqDkVUepejnDY=.2650c47e-737f-46f6-936b-47cab371b848@github.com>
References: <ltVVuz_1JTacO6uHQATm0UPq7e0PmZpqDkVUepejnDY=.2650c47e-737f-46f6-936b-47cab371b848@github.com>
Message-ID: <46TVWaQbnC8pgz3OLrmsnGMW7wFRwR_duFRpiLuG_vM=.8696e476-2587-428f-8340-6c57a2cbaa91@github.com>

On Thu, 15 Dec 2022 23:47:45 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Support for Markdown comments in the standard doclet.
> 
> To enable Markdown in a comment, start the comment with `/**md` followed by whitespace.  The syntax is as defined for CommonMark.
> 
> The work is in 3 parts:
> 
> 1. Update the Compiler Tree API to support Markdown tree nodes, containing strings of (uninterpreted) Markdown source code.
> 2. Import commonmark-java into the `jdk.javadoc` module, to be able to convert Markdown strings to HTML.
> 3. Update the standard doclet, to leverage the preceding two parts, to translate Markdown in documentation comments to `Content` nodes.
> 
> There are new tests both for the low level work in the Compiler Tree API, and for the overall high-level work in the doclet.
> 
> Background info: https://mail.openjdk.org/pipermail/javadoc-dev/2023-January/005563.html

This pull request has been closed without being integrated.

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

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

From jlahoda at openjdk.org  Tue Feb 21 00:05:09 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 21 Feb 2023 00:05:09 GMT
Subject: RFR: 8299902: Support for MarkDown javadoc in JShell [v2]
In-Reply-To: <KuNsxDHHZPIsM0BeE6Au2Bc82b5OJEbC0UREsEYNFsE=.c7467a58-b510-464d-97a9-173510a85e2f@github.com>
References: <KuNsxDHHZPIsM0BeE6Au2Bc82b5OJEbC0UREsEYNFsE=.c7467a58-b510-464d-97a9-173510a85e2f@github.com>
Message-ID: <AjkClVS-xY-G2vLIJU0dMlCNUYnOURWntb01j_47GE8=.d4074837-a5f1-4db5-beee-6e697d5c8bb1@github.com>

> Adding support for MarkDown javadoc in the JShell

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 eight additional commits since the last revision:

 - Cleanup.
 - Post-merge updates.
 - Merge branch '8298405.doclet-markdown' into markdown-in-jshell
 - Update copyright years
 - Rename FFFC variable
   Share Markdown parser and renderer in instance of MarkdownHandler
 - Move CommonMark to new internal module.
   Add legal header to imported CommonMark source files
   Always use Text nodes inside AttributeTree values
   Unwrap <p> from "simple" paragraphs
 - Always use Text nodes inside AttributeTree values
 - Update to CommonMark 0.21.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11936/files
  - new: https://git.openjdk.org/jdk/pull/11936/files/89f51aa6..89f51aa6

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

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

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

From duke at openjdk.org  Tue Feb 21 01:21:47 2023
From: duke at openjdk.org (SUN Guoyun)
Date: Tue, 21 Feb 2023 01:21:47 GMT
Subject: RFR: 8292647: javac/lambda/T8031967.java fails with
 StackOverflowError when use -XX:TieredStopAtLevel=3 on aarch64 and LoongArch
 [v3]
In-Reply-To: <z639fAXA8bpE1ZETMJpJW0kETKOu_CcPU8MSGA2Q9Fs=.44a4ea2a-b533-478f-a36c-c18b3040bba2@github.com>
References: <8Wo5jMV1FDBTdaz0O8PRwmSMUEqzQeLckldsJybpceg=.01580f6c-3290-4276-8d36-8e408035982c@github.com>
 <z639fAXA8bpE1ZETMJpJW0kETKOu_CcPU8MSGA2Q9Fs=.44a4ea2a-b533-478f-a36c-c18b3040bba2@github.com>
Message-ID: <Jf3lTTrs4f6vWzJOwaq_aMYH00bvsQBNEUr28gmGQtQ=.1ed427cc-2095-4be2-ad74-bf9e81143e24@github.com>

On Wed, 8 Feb 2023 09:21:30 GMT, SUN Guoyun <duke at openjdk.org> wrote:

>> make images run-test TEST=tools/javac/lambda/T8031967.java will fails with StackOverflowError when I use args JTREG="VM_OPTIONS=-XX:TieredStopAtLevel=3" on aarch64 and LoongArch. So the stack size `-Xss10m` needs to be increased to improve the robustness of the testcase.
>
> SUN Guoyun 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 'openjdk:master' into 8292647
>  - 8292647: javac/lambda/T8031967.java fails with StackOverflowError when use -XX:TieredStopAtLevel=3 on aarch64 and LoongArch
>  - 8292647: javac/lambda/T8031967.java fails with StackOverflowError when use -XX:TieredStopAtLevel=3 on aarch64 and LoongArch

> After #12548, this test can be passed.

Thanks @theRealAph @nick-arm @lgxbslgx for review. As #12548 had merged, I close this PR.

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

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

From duke at openjdk.org  Tue Feb 21 01:42:41 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Tue, 21 Feb 2023 01:42:41 GMT
Subject: RFR: 8026369: javac potentially ambiguous overload warning needs
 an improved scheme [v2]
In-Reply-To: <IMxp3iCK--jYJ5Ia04i6QPYfnCHQobVcsmlI5aJXdqc=.892abcb8-7f2a-4fe9-aea2-1b1d41098a6d@github.com>
References: <IMxp3iCK--jYJ5Ia04i6QPYfnCHQobVcsmlI5aJXdqc=.892abcb8-7f2a-4fe9-aea2-1b1d41098a6d@github.com>
Message-ID: <NlqhxTe-Li08DSIjyYVn5HI9uIAvIHZE4IG0x8tQTQw=.0ae9928e-7814-4356-bf75-11bc4eefc6be@github.com>

> This bug relates to the "potentially ambiguous overload" warning which is enabled by `-Xlint:overloads`.
> 
> The warning detects certain ambiguities that can cause problems for lambdas. For example, consider the interface `Spliterator.OfInt`, which declares these two methods:
> 
> void forEachRemaining(Consumer<? super Integer> action);
> void forEachRemaining(IntConsumer action);
> 
> Both methods have the same name, same number of parameters, and take a lambda with the same "shape" in the same argument position. This causes an ambiguity in any code that wants to do this:
> 
>     spliterator.forEachRemaining(x -> { ... });
> 
> That code won't compile; instead, you'll get this error:
> 
> Ambiguity.java:4: error: reference to forEachRemaining is ambiguous
>         spliterator.forEachRemaining(x -> { });
>                    ^
>   both method forEachRemaining(IntConsumer) in OfInt and method forEachRemaining(Consumer<? super Integer>) in OfInt match
> 
> 
> The problem reported by the bug is that the warning fails to detect ambiguities which are created purely by inheritance, for example:
> 
> interface ConsumerOfInteger {
>     void foo(Consumer<Integer> c);
> }
> 
> interface IntegerConsumer {
>     void foo(IntConsumer c);
> }
> 
> // We should get a warning here...
> interface Test extends ConsumerOfInteger, IntegerConsumer {
> }
> 
> 
> The cause of the bug is that ambiguities are detected on a per-method basis, by checking whether a method is part of an ambiguity pair when we visit that method. So if the methods in an ambiguity pair are inherited from two distinct supertypes, we'll miss the ambiguity.
> 
> To fix the problem, we need to look for ambiguities on a per-class level, checking all pairs of methods. However, it's not that simple - we only want to "blame" a class when that class itself, and not some supertype, is responsible for creating the ambiguity. For example, any interface extending `Spliterator.OfInt` will automatically inherit the two ambiguities mentioned above, but these are not the interface's fault so to speak so no warning should be generated. Making things more complicated is the fact that methods can be overridden and declared in generic classes so they only conflict in some subtypes, etc.
> 
> So we generate the warning when there are two methods m1 and m2 in a class C such that:
> 
> * m1 and m2 consitiute a "potentially ambiguous overload" (using the same definition as before)
> * There is no direct supertype T of C such that m1 and m2, or some methods they override, both exist in T and constitute a "potentially ambiguous overload" as members of T
> * We haven't already generated a warning for either m1 or m2 in class C
> 
> If either method is declared in C, we locate the warning there, but when both methods are inherited, there's no method declaration to point at so the warning is instead located at the class declaration.
> 
> I noticed a couple of other minor bugs; these are also being fixed here:
> 
> (1) For inherited methods, the method signatures were being reported as they are declared, rather than in the context of the class being visited. As a result, when a methods is inherited from a generic supertype, the ambiguity is less clear. Here's an example:
> 
> interface Upper<T> {
>     void foo(T c);
> }
> 
> interface Lower extends Upper<IntConsumer> {
>     void foo(Consumer<Integer> c);
> }
> 
> Currently, the error is reported as:
> 
> warning: [overloads] foo(Consumer<Integer>) in Lower is potentially ambiguous with foo(T) in Upper
> 
> Reporting the method signatures in the context of the class being visited makes the ambiguity clearer:
> 
> warning: [overloads] foo(Consumer<Integer>) in Lower is potentially ambiguous with foo(IntConsumer) in Upper
> 
> 
> (2) When a method is identified as part of an ambiguous pair, we were setting a `POTENTIALLY_AMBIGUOUS` flag on it. This caused it to be forever excluded from future warnings. For methods that are declared in the class we're visiting, this makes sense, but it doesn't make sense for inherited methods, because it disqualifies them from participating in the analysis of any other class that also inherits them.
> 
> As a result, for a class like the one below, the compiler was only generating one warning instead of three:
> 
> public interface SuperIface {
>     void foo(Consumer<Integer> c);
> }
> 
> public interface I1 extends SuperIface { 
>     void foo(IntConsumer c);        // warning was generated here
> }   
> 
> public interface I2 extends SuperIface { 
>     void foo(IntConsumer c);        // no warning was generated here
> }   
> 
> public interface I3 extends SuperIface { 
>     void foo(IntConsumer c);        // no warning was generated here
> }   
> 
> 
> With this patch the `POTENTIALLY_AMBIGUOUS` flag is no longer needed. I wasn't sure whether to renumber all the subsequent flags, or just leave an empty placeholder, so I chose the latter.
> 
> Finally, this fix uncovers new warnings in `java.base` and `java.desktop`, so these are now suppressed in the patch.

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

  Remove @SuppressWarnings("overloads") annotations that were added but not needed.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12645/files
  - new: https://git.openjdk.org/jdk/pull/12645/files/591e220c..88a5f993

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

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

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

From duke at openjdk.org  Tue Feb 21 01:42:43 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Tue, 21 Feb 2023 01:42:43 GMT
Subject: RFR: 8026369: javac potentially ambiguous overload warning needs
 an improved scheme
In-Reply-To: <xVTkB9-V5fVop5Mix7Gk29Ix3JCtAlBZeHR-064qaw0=.b3e9d5c2-4def-4410-8a59-c8c25049f7e4@github.com>
References: <IMxp3iCK--jYJ5Ia04i6QPYfnCHQobVcsmlI5aJXdqc=.892abcb8-7f2a-4fe9-aea2-1b1d41098a6d@github.com>
 <xVTkB9-V5fVop5Mix7Gk29Ix3JCtAlBZeHR-064qaw0=.b3e9d5c2-4def-4410-8a59-c8c25049f7e4@github.com>
Message-ID: <YJgBr11LyHU8RSK4zrf_J_htDq3BwoPF3-lN7GghA8U=.6b265890-a328-4b5f-b0b5-4addbd8a9210@github.com>

On Mon, 20 Feb 2023 23:53:05 GMT, SWinxy <duke at openjdk.org> wrote:

> In the `AWTEventMulticaster` class(es), which interfaces are causing the ambiguity?

Ah - my apologies. Those got added during development but were not needed once all the bugs were worked out.

I've removed them and that will also eliminate `client` and `i18n` from review. Thanks!

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

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

From duke at openjdk.org  Tue Feb 21 05:28:43 2023
From: duke at openjdk.org (Jimisola Laursen)
Date: Tue, 21 Feb 2023 05:28:43 GMT
Subject: RFR: JDK-8298405: Support Markdown in the standard doclet [v5]
In-Reply-To: <bWvzhyK4bUryCNyNvVij-H555g2F-OmCHIQL7T0ELYg=.f88f6270-e6d9-4cba-97e8-c5c4eeb1e927@github.com>
References: <ltVVuz_1JTacO6uHQATm0UPq7e0PmZpqDkVUepejnDY=.2650c47e-737f-46f6-936b-47cab371b848@github.com>
 <bWvzhyK4bUryCNyNvVij-H555g2F-OmCHIQL7T0ELYg=.f88f6270-e6d9-4cba-97e8-c5c4eeb1e927@github.com>
Message-ID: <Fat680L5hh38hM_jl_6t6RB_MCDJXRxZtHOUb5vYRBw=.df472659-1c5f-4fa1-9e90-9ed469ee2e95@github.com>

On Tue, 7 Feb 2023 19:42:39 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Support for Markdown comments in the standard doclet.
>> 
>> To enable Markdown in a comment, start the comment with `/**md` followed by whitespace.  The syntax is as defined for CommonMark.
>> 
>> The work is in 3 parts:
>> 
>> 1. Update the Compiler Tree API to support Markdown tree nodes, containing strings of (uninterpreted) Markdown source code.
>> 2. Import commonmark-java into the `jdk.javadoc` module, to be able to convert Markdown strings to HTML.
>> 3. Update the standard doclet, to leverage the preceding two parts, to translate Markdown in documentation comments to `Content` nodes.
>> 
>> There are new tests both for the low level work in the Compiler Tree API, and for the overall high-level work in the doclet.
>> 
>> Background info: https://mail.openjdk.org/pipermail/javadoc-dev/2023-January/005563.html
>
> Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
> 
>  - Merge with upstream/master
>  - Rename MarkdownTree to RawTextTree
>  - Merge with upstream/master
>  - Update copyright years
>  - Rename FFFC variable
>    Share Markdown parser and renderer in instance of MarkdownHandler
>  - Move CommonMark to new internal module.
>    Add legal header to imported CommonMark source files
>    Always use Text nodes inside AttributeTree values
>    Unwrap <p> from "simple" paragraphs
>  - Always use Text nodes inside AttributeTree values
>  - Update to CommonMark 0.21.
>  - fix whitespace
>  - JDK-8298405: Markdown support in the standard doclet

Would also really like to see AsciiDoc support. Our development team use it for everything. Markdown is ok but AsciiDoc is much better for technical documentation.

What is necessary for AsciiDoc to be considered? Or rather, what is the process for it being taken into consideration?

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

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

From duke at openjdk.org  Tue Feb 21 05:28:43 2023
From: duke at openjdk.org (Jimisola Laursen)
Date: Tue, 21 Feb 2023 05:28:43 GMT
Subject: RFR: JDK-8298405: Support Markdown in the standard doclet [v5]
In-Reply-To: <wA0HPh3XWqVNYDll5_NQ6A0CUrkgzA-_53OyCC_130M=.b9cb6d38-0639-4681-8894-e22b9522620f@github.com>
References: <ltVVuz_1JTacO6uHQATm0UPq7e0PmZpqDkVUepejnDY=.2650c47e-737f-46f6-936b-47cab371b848@github.com>
 <bWvzhyK4bUryCNyNvVij-H555g2F-OmCHIQL7T0ELYg=.f88f6270-e6d9-4cba-97e8-c5c4eeb1e927@github.com>
 <wA0HPh3XWqVNYDll5_NQ6A0CUrkgzA-_53OyCC_130M=.b9cb6d38-0639-4681-8894-e22b9522620f@github.com>
Message-ID: <3sayfrVzDQA2eLhs1Spd-Yzwx_V12H2zU8dH6ZkwhKc=.ab2dbb32-74e9-49f7-993d-8368bc7f3222@github.com>

On Wed, 8 Feb 2023 10:16:12 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Have you seen that notification from the bot? Regardless, the bot might need to use a better message/format for such communication.

No, thanks. I missed that. Accepted now.

Great that this got implemented. Would have been even better with asciidoc support ?

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

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

From jjg at openjdk.org  Tue Feb 21 17:10:00 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 21 Feb 2023 17:10:00 GMT
Subject: RFR: JDK-8298405: Support Markdown in the standard doclet [v7]
In-Reply-To: <L0_Ei1bTc-gWLNiYIQRA8XPF6X4tLBhLbQ2fnzWUbNY=.dbab6e4a-2ba1-4ad2-88a0-3bbab11dcd84@github.com>
References: <ltVVuz_1JTacO6uHQATm0UPq7e0PmZpqDkVUepejnDY=.2650c47e-737f-46f6-936b-47cab371b848@github.com>
 <L0_Ei1bTc-gWLNiYIQRA8XPF6X4tLBhLbQ2fnzWUbNY=.dbab6e4a-2ba1-4ad2-88a0-3bbab11dcd84@github.com>
Message-ID: <kYSgsC4nPB3FutKh6PkZX1NN9KM0P4_wJrIr6O76HCo=.2237db66-faad-4e68-9331-11d224b04efc@github.com>

On Wed, 8 Feb 2023 23:32:27 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Support for Markdown comments in the standard doclet.
>> 
>> To enable Markdown in a comment, start the comment with `/**md` followed by whitespace.  The syntax is as defined for CommonMark.
>> 
>> The work is in 3 parts:
>> 
>> 1. Update the Compiler Tree API to support Markdown tree nodes, containing strings of (uninterpreted) Markdown source code.
>> 2. Import commonmark-java into the `jdk.javadoc` module, to be able to convert Markdown strings to HTML.
>> 3. Update the standard doclet, to leverage the preceding two parts, to translate Markdown in documentation comments to `Content` nodes.
>> 
>> There are new tests both for the low level work in the Compiler Tree API, and for the overall high-level work in the doclet.
>> 
>> Background info: https://mail.openjdk.org/pipermail/javadoc-dev/2023-January/005563.html
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert changes to Object.hashCode

FYI, the PR has been withdrawn for now, pending additional design discussions.

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

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

From archie.cobbs at gmail.com  Tue Feb 21 21:34:57 2023
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Tue, 21 Feb 2023 15:34:57 -0600
Subject: Bug labels documented?
Message-ID: <CANSoFxvk958nXmheA=v4e1Amt2N5zVp_eML5sJskCeTv0hMPtw@mail.gmail.com>

Are the issue tracker bug labels documented somewhere?

[image: Screenshot 2023-02-21 at 3.32.58 PM.png]

OK if not, just curious.

Thanks,
-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230221/bae2fdd9/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot 2023-02-21 at 3.32.58 PM.png
Type: image/png
Size: 97839 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230221/bae2fdd9/Screenshot2023-02-21at3.32.58PM-0001.png>

From roger.riggs at oracle.com  Tue Feb 21 21:37:46 2023
From: roger.riggs at oracle.com (Roger Riggs)
Date: Tue, 21 Feb 2023 16:37:46 -0500
Subject: Bug labels documented?
In-Reply-To: <CANSoFxvk958nXmheA=v4e1Amt2N5zVp_eML5sJskCeTv0hMPtw@mail.gmail.com>
References: <CANSoFxvk958nXmheA=v4e1Amt2N5zVp_eML5sJskCeTv0hMPtw@mail.gmail.com>
Message-ID: <9dab9aad-96ae-7947-d4e3-0d1b11d806a1@oracle.com>

Hi Archie,

There is this in the OpenJDK developers guide.

https://openjdk.org/guide/#jbs-labels

That should be a start.

Regards, Roger


On 2/21/23 4:34 PM, Archie Cobbs wrote:
> Are the issue tracker bug labels documented somewhere?
>
> Screenshot 2023-02-21 at 3.32.58 PM.png
>
> OK if not, just curious.
>
> Thanks,
> -Archie
>
> -- 
> Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230221/2e9f5d0a/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot 2023-02-21 at 3.32.58 PM.png
Type: image/png
Size: 97839 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230221/2e9f5d0a/Screenshot2023-02-21at3.32.58PM-0001.png>

From vicente.romero at oracle.com  Tue Feb 21 21:42:39 2023
From: vicente.romero at oracle.com (Vicente Romero)
Date: Tue, 21 Feb 2023 16:42:39 -0500
Subject: Bug labels documented?
In-Reply-To: <CANSoFxvk958nXmheA=v4e1Amt2N5zVp_eML5sJskCeTv0hMPtw@mail.gmail.com>
References: <CANSoFxvk958nXmheA=v4e1Amt2N5zVp_eML5sJskCeTv0hMPtw@mail.gmail.com>
Message-ID: <6d6edf58-7c97-953b-1f4f-c6031576c30a@oracle.com>

some of them are but not all unfortunately, when in doubt just ask. For 
example, usually use the noreg-* labels to indicate that for some reason 
a bug won't be including a regression test but I don't think this is 
explicitly documented anywhere,

Vicente

On 2/21/23 16:34, Archie Cobbs wrote:
> Are the issue tracker bug labels documented somewhere?
>
> Screenshot 2023-02-21 at 3.32.58 PM.png
>
> OK if not, just curious.
>
> Thanks,
> -Archie
>
> -- 
> Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230221/eccff700/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot 2023-02-21 at 3.32.58 PM.png
Type: image/png
Size: 97839 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230221/eccff700/Screenshot2023-02-21at3.32.58PM-0001.png>

From archie.cobbs at gmail.com  Tue Feb 21 22:20:14 2023
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Tue, 21 Feb 2023 16:20:14 -0600
Subject: Bug labels documented?
In-Reply-To: <9dab9aad-96ae-7947-d4e3-0d1b11d806a1@oracle.com>
References: <CANSoFxvk958nXmheA=v4e1Amt2N5zVp_eML5sJskCeTv0hMPtw@mail.gmail.com>
 <9dab9aad-96ae-7947-d4e3-0d1b11d806a1@oracle.com>
Message-ID: <CANSoFxso45_7m-g4JvruQq367n4cjR+dsc2w49yO55=kKrJF8A@mail.gmail.com>

On Tue, Feb 21, 2023 at 3:38 PM Roger Riggs <roger.riggs at oracle.com> wrote:

> https://openjdk.org/guide/#jbs-labels
>

Ah! Thanks.

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230221/26dc70f6/attachment.htm>

From christoph.dreis at freenet.de  Mon Feb 20 18:54:19 2023
From: christoph.dreis at freenet.de (christoph.dreis at freenet.de)
Date: Mon, 20 Feb 2023 18:54:19 +0000
Subject: Reduce allocations when pretty printing JCTree during compilation
Message-ID: <PAXP193MB1231663F650EC78BDE9737E8AFA49@PAXP193MB1231.EURP193.PROD.OUTLOOK.COM>

Hi,

I?ve been profiling some build pipelines of some customer projects ? including their compilation phase.
And while Lombok is a major contributor in these projects (it?s not an option to drop it unfortunately), there are some optimization opportunities in the JDK itself.

I?ve opened a draft PR where you can find more information: https://github.com/openjdk/jdk/pull/12667
If someone finds the time to take a look, I?d highly appreciate it.

Cheers,
Christoph
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230220/66e0503e/attachment.htm>

From christoph.dreis at freenet.de  Tue Feb 21 21:03:21 2023
From: christoph.dreis at freenet.de (christoph.dreis at freenet.de)
Date: Tue, 21 Feb 2023 21:03:21 +0000
Subject: Remove stream usage from Symtab.lookupPackage()
Message-ID: <AS8P193MB12247CE232823FDE020C44B0AFA59@AS8P193MB1224.EURP193.PROD.OUTLOOK.COM>

Hi,

I'm currently profiling some compilation phases of internal projects and noticed in allocation profiles that Symtab.lookupPackage takes up ~2% overall. The majority of this is spent in .stream().anyMatch() usages to find out if the given module symbol depends on the unnamed module.



The PR under https://github.com/openjdk/jdk/pull/12700 desugars the code into a simple loop.

If you think this is worthwhile I'd appreciate if this is sponsored. I'd also need a ticket number for that because I can't create tickets. CLA should be signed though.

Let me know what you think.
Cheers,
Christoph




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230221/1821a433/attachment.htm>

From jai.forums2013 at gmail.com  Wed Feb 22 01:34:35 2023
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Wed, 22 Feb 2023 07:04:35 +0530
Subject: Bug labels documented?
In-Reply-To: <6d6edf58-7c97-953b-1f4f-c6031576c30a@oracle.com>
References: <CANSoFxvk958nXmheA=v4e1Amt2N5zVp_eML5sJskCeTv0hMPtw@mail.gmail.com>
 <6d6edf58-7c97-953b-1f4f-c6031576c30a@oracle.com>
Message-ID: <72838702-9388-79ba-ffda-271b3927ca4a@gmail.com>

The noreg-* labels are documented in the link that Roger noted in his 
mail. There's specific section for noreg-* labels in there 
https://openjdk.org/guide/index.html#noreg

-Jaikiran

On 22/02/23 3:12 am, Vicente Romero wrote:
> some of them are but not all unfortunately, when in doubt just ask. 
> For example, usually use the noreg-* labels to indicate that for some 
> reason a bug won't be including a regression test but I don't think 
> this is explicitly documented anywhere,
>
> Vicente
>
> On 2/21/23 16:34, Archie Cobbs wrote:
>> Are the issue tracker bug labels documented somewhere?
>>
>> Screenshot 2023-02-21 at 3.32.58 PM.png
>>
>> OK if not, just curious.
>>
>> Thanks,
>> -Archie
>>
>> -- 
>> Archie L. Cobbs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230222/2516fdd4/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot 2023-02-21 at 3.32.58 PM.png
Type: image/png
Size: 97839 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230222/2516fdd4/Screenshot2023-02-21at3.32.58PM-0001.png>

From vicente.romero at oracle.com  Wed Feb 22 02:52:37 2023
From: vicente.romero at oracle.com (Vicente Romero)
Date: Tue, 21 Feb 2023 21:52:37 -0500
Subject: [External] : Re: Bug labels documented?
In-Reply-To: <72838702-9388-79ba-ffda-271b3927ca4a@gmail.com>
References: <CANSoFxvk958nXmheA=v4e1Amt2N5zVp_eML5sJskCeTv0hMPtw@mail.gmail.com>
 <6d6edf58-7c97-953b-1f4f-c6031576c30a@oracle.com>
 <72838702-9388-79ba-ffda-271b3927ca4a@gmail.com>
Message-ID: <8178bbd8-eed7-03a5-7b32-bf19517315af@oracle.com>



On 2/21/23 20:34, Jaikiran Pai wrote:
>
> The noreg-* labels are documented in the link that Roger noted in his 
> mail. There's specific section for noreg-* labels in there 
> https://openjdk.org/guide/index.html#noreg
>

yep I saw that after sending my mail,

> -Jaikiran
>

Vicente

> On 22/02/23 3:12 am, Vicente Romero wrote:
>> some of them are but not all unfortunately, when in doubt just ask. 
>> For example, usually use the noreg-* labels to indicate that for some 
>> reason a bug won't be including a regression test but I don't think 
>> this is explicitly documented anywhere,
>>
>> Vicente
>>
>> On 2/21/23 16:34, Archie Cobbs wrote:
>>> Are the issue tracker bug labels documented somewhere?
>>>
>>> Screenshot 2023-02-21 at 3.32.58 PM.png
>>>
>>> OK if not, just curious.
>>>
>>> Thanks,
>>> -Archie
>>>
>>> -- 
>>> Archie L. Cobbs
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230221/847f24b1/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot 2023-02-21 at 3.32.58 PM.png
Type: image/png
Size: 97839 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230221/847f24b1/Screenshot2023-02-21at3.32.58PM-0001.png>

From vicente.romero at oracle.com  Wed Feb 22 03:16:38 2023
From: vicente.romero at oracle.com (Vicente Romero)
Date: Tue, 21 Feb 2023 22:16:38 -0500
Subject: Remove stream usage from Symtab.lookupPackage()
In-Reply-To: <AS8P193MB12247CE232823FDE020C44B0AFA59@AS8P193MB1224.EURP193.PROD.OUTLOOK.COM>
References: <AS8P193MB12247CE232823FDE020C44B0AFA59@AS8P193MB1224.EURP193.PROD.OUTLOOK.COM>
Message-ID: <783e1ca1-eed2-3b8b-a978-dd6a096f81f6@oracle.com>

Hi Christoph,

Could you please share more info like what type of sources are you 
compiling: machine generated or not, very long sources, etc. Also what's 
the performance improvement you get with your patch, etc.

Thanks,
Vicente

On 2/21/23 16:03, christoph.dreis at freenet.de wrote:
>
> Hi,
>
> I'm currently profiling some compilation phases of internal projects 
> and noticed in allocation profiles that |Symtab.lookupPackage|?takes 
> up ~2% overall. The majority of this is spent in 
> |.stream().anyMatch()|?usages to find out if the given module symbol 
> depends on the unnamed module.
>
> The PR under https://github.com/openjdk/jdk/pull/12700 desugars the 
> code into a simple loop.
>
> If you think this is worthwhile I'd appreciate if this is sponsored. 
> I'd also need a ticket number for that because I can't create tickets. 
> CLA should be signed though.
>
> Let me know what you think.
> Cheers,
> Christoph
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230221/0625322e/attachment.htm>

From archie.cobbs at gmail.com  Wed Feb 22 03:30:52 2023
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Tue, 21 Feb 2023 21:30:52 -0600
Subject: Remove stream usage from Symtab.lookupPackage()
In-Reply-To: <AS8P193MB12247CE232823FDE020C44B0AFA59@AS8P193MB1224.EURP193.PROD.OUTLOOK.COM>
References: <AS8P193MB12247CE232823FDE020C44B0AFA59@AS8P193MB1224.EURP193.PROD.OUTLOOK.COM>
Message-ID: <CANSoFxsiY_btJ7ues5GmsnyXQ4uXVC_6GZHYYXi=8Utsvs-eiQ@mail.gmail.com>

On Tue, Feb 21, 2023 at 6:24 PM christoph.dreis at freenet.de <
christoph.dreis at freenet.de> wrote:

> I'm currently profiling some compilation phases of internal projects and
> noticed in allocation profiles that Symtab.lookupPackage takes up ~2%
> overall. The majority of this is spent in .stream().anyMatch() usages to
> find out if the given module symbol depends on the unnamed module.
>

Straightforward patch, but it's disappointing that unrolling a Stream into
the equivalent for loop makes it noticeably faster (how much?).

This also brings up larger philosophical questions about code style vs.
performance. If using a Stream somewhere makes for more
clean/elegant/understandable code, but is slower, how to weigh the
trade-off? Maybe this has been discussed before on this list before I
joined. Maybe we should assign this bug to the hotspot group :)

On this same topic, this pattern which appears constantly in the compiler
always makes me kind of quizzical:

JCExpression expr = TreeInfo.skipParens(tree.expr);
if (expr.hasTag(APPLY)) {
    JCMethodInvocation apply = (JCMethodInvocation)expr;
    ...
}

Is instanceof really that much slower? Maybe it was once, long ago, and
this is a legacy thing?

-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230221/0edbb902/attachment.htm>

From vicente.romero at oracle.com  Wed Feb 22 03:52:53 2023
From: vicente.romero at oracle.com (Vicente Romero)
Date: Tue, 21 Feb 2023 22:52:53 -0500
Subject: Reduce allocations when pretty printing JCTree during compilation
In-Reply-To: <PAXP193MB1231663F650EC78BDE9737E8AFA49@PAXP193MB1231.EURP193.PROD.OUTLOOK.COM>
References: <PAXP193MB1231663F650EC78BDE9737E8AFA49@PAXP193MB1231.EURP193.PROD.OUTLOOK.COM>
Message-ID: <45d20808-7117-94ad-f385-fff8cf6e4f5c@oracle.com>

Hi Christoph,

What are the performance benefits you get from this patch? My 
understanding is that your patch reduces the memory footprint but it 
seems like there are also performance benefits, I think. The patch looks 
good and won't affect readability although some comments should be added 
to the new `print` version to explain why it is a better fit for 
printing chars,

Thanks,
Vicente

On 2/20/23 13:54, christoph.dreis at freenet.de wrote:
>
> Hi,
>
> I?ve been profiling some build pipelines of some customer projects ? 
> including their compilation phase.
>
> And while Lombok is a major contributor in these projects (it?s not an 
> option to drop it unfortunately), there are some optimization 
> opportunities in the JDK itself.
>
> I?ve opened a draft PR where you can find more information: 
> https://github.com/openjdk/jdk/pull/12667
>
> If someone finds the time to take a look, I?d highly appreciate it.
>
> Cheers,
>
> Christoph
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230221/e88d1de8/attachment-0001.htm>

From christoph.dreis at freenet.de  Wed Feb 22 11:46:54 2023
From: christoph.dreis at freenet.de (christoph.dreis at freenet.de)
Date: Wed, 22 Feb 2023 11:46:54 +0000
Subject: AW: Remove stream usage from Symtab.lookupPackage()
In-Reply-To: <783e1ca1-eed2-3b8b-a978-dd6a096f81f6@oracle.com>
References: <AS8P193MB12247CE232823FDE020C44B0AFA59@AS8P193MB1224.EURP193.PROD.OUTLOOK.COM>
 <783e1ca1-eed2-3b8b-a978-dd6a096f81f6@oracle.com>
Message-ID: <PAXP193MB12314C4F9E105818BE3ED543AFAA9@PAXP193MB1231.EURP193.PROD.OUTLOOK.COM>

Hi Vicente,

thanks for taking the time. I?ve added a comment in the PR with screenshots from async-profiler runs etc. that are somewhat easier to post there compared to the mailing list. But to share the TL;DR:


  *   ~2500 classes
  *   Average size: ~76 lines
  *   Largest class: ~2500 lines
  *   Mostly hand-written, but some auto-generated protobuf files (I'd say 90/10 split)

Overall timings didn?t improve (or regress), but the allocations of Symtab.lookupPackage() went down from 1.6% to 0.1% overall, while CPU frames went down from 1.6% to 0.9%.

Let me know if you need more information and I?ll post this to the issue on GitHub.

Cheers,
Christoph


Am 22.02.23, 04:16 schrieb "Vicente Romero" <vicente.romero at oracle.com>:

Hi Christoph,

Could you please share more info like what type of sources are you compiling: machine generated or not, very long sources, etc. Also what's the performance improvement you get with your patch, etc.

Thanks,
Vicente
On 2/21/23 16:03, christoph.dreis at freenet.de<mailto:christoph.dreis at freenet.de> wrote:

Hi,

I'm currently profiling some compilation phases of internal projects and noticed in allocation profiles that Symtab.lookupPackage takes up ~2% overall. The majority of this is spent in .stream().anyMatch() usages to find out if the given module symbol depends on the unnamed module.



The PR under https://github.com/openjdk/jdk/pull/12700 desugars the code into a simple loop.

If you think this is worthwhile I'd appreciate if this is sponsored. I'd also need a ticket number for that because I can't create tickets. CLA should be signed though.

Let me know what you think.
Cheers,
Christoph





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230222/efe14ef8/attachment-0001.htm>

From christoph.dreis at freenet.de  Wed Feb 22 12:16:55 2023
From: christoph.dreis at freenet.de (christoph.dreis at freenet.de)
Date: Wed, 22 Feb 2023 12:16:55 +0000
Subject: AW: Reduce allocations when pretty printing JCTree during compilation
In-Reply-To: <45d20808-7117-94ad-f385-fff8cf6e4f5c@oracle.com>
References: <PAXP193MB1231663F650EC78BDE9737E8AFA49@PAXP193MB1231.EURP193.PROD.OUTLOOK.COM>
 <45d20808-7117-94ad-f385-fff8cf6e4f5c@oracle.com>
Message-ID: <PAXP193MB1231474B6CB1A3CFC65DEEE3AFAA9@PAXP193MB1231.EURP193.PROD.OUTLOOK.COM>

Hi Vicente,

thanks for your time. I?ve posted a comment in the PR (https://github.com/openjdk/jdk/pull/12667#issuecomment-1439917000) with some more screenshots that are somewhat messy in the mailing list and often get lost for me.

But TL;DR. No (noticeable) time gain. CPU frames (of Pretty.visitSelect) went down from ~2.2% to ~1.4%, though. Allocations from 7.09% down to 4.13%.

Should I already go ahead and make use of the new `print(char)` method in other places as well?

Cheers,
Christoph

Am 22.02.23, 04:53 schrieb "Vicente Romero" <vicente.romero at oracle.com>:

Hi Christoph,

What are the performance benefits you get from this patch? My understanding is that your patch reduces the memory footprint but it seems like there are also performance benefits, I think. The patch looks good and won't affect readability although some comments should be added to the new `print` version to explain why it is a better fit for printing chars,

Thanks,
Vicente
On 2/20/23 13:54, christoph.dreis at freenet.de<mailto:christoph.dreis at freenet.de> wrote:
Hi,

I?ve been profiling some build pipelines of some customer projects ? including their compilation phase.
And while Lombok is a major contributor in these projects (it?s not an option to drop it unfortunately), there are some optimization opportunities in the JDK itself.

I?ve opened a draft PR where you can find more information: https://github.com/openjdk/jdk/pull/12667
If someone finds the time to take a look, I?d highly appreciate it.

Cheers,
Christoph

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230222/d078bf3f/attachment-0001.htm>

From duke at openjdk.org  Wed Feb 22 15:35:07 2023
From: duke at openjdk.org (Christoph Dreis)
Date: Wed, 22 Feb 2023 15:35:07 GMT
Subject: RFR: 8303078: Reduce allocations when pretty printing JCTree during
 compilation
Message-ID: <GmfIJukLO6280Z1lPW5hPwPRMN0_UGNTJ-Ec9_HstyY=.95fe1edc-5f28-483a-a150-e0575ace6912@github.com>

Hi,

I've been recently optimizing a few project pipelines and always noticed that their compilation step is somewhat "expensive".  Zooming into the issue always revealed Lombok to be a larger contributor. Unfortunately, I can't get rid of Lombok in this customer project (before you ask).

Apparently, Lombok is printing the respective `JCTree` here and there to check for type matches. I can't imagine this to be super efficient, but that's how it is at the moment.
<img width="948" alt="image" src="https://user-images.githubusercontent.com/6304496/220134737-bd9b508c-a908-448b-b0d1-e960db28b24a.png">

Anyhow, regardless of the Lombok inefficiencies I think there are some optimization opportunities in the JDK itself. 

1. Overall, `Pretty.visitSelect` accounts for 8-10% of the total allocations in this project. And among those there are StringBuilder allocations coming from the following:


    public void visitSelect(JCFieldAccess tree) {
        try {
            printExpr(tree.selected, TreeInfo.postfixPrec);
            // StringBuilder allocations hiding in here.
            print("." + tree.name);
        } catch (IOException e) {
            throw new UncheckedIOException(e);
        }
    }


This PR splits the `print` calls into two separate ones to avoid this String concatenation.

...
            printExpr(tree.selected, TreeInfo.postfixPrec);
            print('.');
            print(tree.name);
...


Secondly, the `print` method takes an `Object` which seems like a good fit for another (private?) variant of it that only takes a `char`. By this we would probably avoid any eventual boxing and avoid any conversion with `Convert.escapeUnicode(s.toString())` that seems superfluous for chars like `.`, ` `, or any braces like `(`, `{` etc. 

This is currently a draft PR as long as the scope is not clarified. It currently only includes the necessary changes that would optimize the particular use-case. But there are more cases where e.g. the new `char` variant could be used and/or any String concatenation could be split into separate `print` calls.

Let me know what you think and if I should include the other cases as well. If you think this is worthwhile, I'd appreciate if this is is sponsored. (Including creating an issue as I can't do this myself apparently. I will of course squash everything together with the proper issue ID once available.)

I've contributed before, so the CLA should be signed.

Cheers,
Christoph

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

Commit messages:
 - 8303078: Reduce allocations when pretty printing JCTree

Changes: https://git.openjdk.org/jdk/pull/12667/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12667&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8303078
  Stats: 155 lines in 1 file changed: 35 ins; 1 del; 119 mod
  Patch: https://git.openjdk.org/jdk/pull/12667.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12667/head:pull/12667

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

From jjg at openjdk.org  Wed Feb 22 15:35:10 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 22 Feb 2023 15:35:10 GMT
Subject: RFR: 8303078: Reduce allocations when pretty printing JCTree
 during compilation
In-Reply-To: <GmfIJukLO6280Z1lPW5hPwPRMN0_UGNTJ-Ec9_HstyY=.95fe1edc-5f28-483a-a150-e0575ace6912@github.com>
References: <GmfIJukLO6280Z1lPW5hPwPRMN0_UGNTJ-Ec9_HstyY=.95fe1edc-5f28-483a-a150-e0575ace6912@github.com>
Message-ID: <eEBaEr2__VO_s4s_KA2xDwRHQcE0gYeROFYEMQ2XtYI=.a67da85b-4fc1-4e9c-bd5c-f93f7045bf8f@github.com>

On Mon, 20 Feb 2023 14:54:18 GMT, Christoph Dreis <duke at openjdk.org> wrote:

> Hi,
> 
> I've been recently optimizing a few project pipelines and always noticed that their compilation step is somewhat "expensive".  Zooming into the issue always revealed Lombok to be a larger contributor. Unfortunately, I can't get rid of Lombok in this customer project (before you ask).
> 
> Apparently, Lombok is printing the respective `JCTree` here and there to check for type matches. I can't imagine this to be super efficient, but that's how it is at the moment.
> <img width="948" alt="image" src="https://user-images.githubusercontent.com/6304496/220134737-bd9b508c-a908-448b-b0d1-e960db28b24a.png">
> 
> Anyhow, regardless of the Lombok inefficiencies I think there are some optimization opportunities in the JDK itself. 
> 
> 1. Overall, `Pretty.visitSelect` accounts for 8-10% of the total allocations in this project. And among those there are StringBuilder allocations coming from the following:
> 
> 
>     public void visitSelect(JCFieldAccess tree) {
>         try {
>             printExpr(tree.selected, TreeInfo.postfixPrec);
>             // StringBuilder allocations hiding in here.
>             print("." + tree.name);
>         } catch (IOException e) {
>             throw new UncheckedIOException(e);
>         }
>     }
> 
> 
> This PR splits the `print` calls into two separate ones to avoid this String concatenation.
> 
> ...
>             printExpr(tree.selected, TreeInfo.postfixPrec);
>             print('.');
>             print(tree.name);
> ...
> 
> 
> Secondly, the `print` method takes an `Object` which seems like a good fit for another (private?) variant of it that only takes a `char`. By this we would probably avoid any eventual boxing and avoid any conversion with `Convert.escapeUnicode(s.toString())` that seems superfluous for chars like `.`, ` `, or any braces like `(`, `{` etc. 
> 
> This is currently a draft PR as long as the scope is not clarified. It currently only includes the necessary changes that would optimize the particular use-case. But there are more cases where e.g. the new `char` variant could be used and/or any String concatenation could be split into separate `print` calls.
> 
> Let me know what you think and if I should include the other cases as well. If you think this is worthwhile, I'd appreciate if this is is sponsored. (Including creating an issue as I can't do this myself apparently. I will of course squash everything together with the proper issue ID once available.)
> 
> I've contributed before, so the CLA should be signed.
> 
> Cheers,
> Christoph

If we proceed with this, I would recommend looking for other possible uses of the new method.

A simple `grep` shows 129 single character strings, of which 97 are arguments to `print`.

Separate but related, I note that a similar class, `DocPretty.java`, has 75 single character strings, of which  68 are arguments to print.

Overall changing the coding style to use `out.print(char)` seems worthwhile.

Filed [JDK-8303078](https://bugs.openjdk.org/browse/JDK-8303078)

You might want to un-Draft the PR, and prefix the title with `JDK-8303078: `

There are 19 instances of string concatenation in `print` arguments, for your consideration as well.

src/jdk.compiler/share/classes/com/sun/tools/javac/tree/Pretty.java line 139:

> 137:     private void print(char c) throws IOException {
> 138:         out.write(c);
> 139:     }

This bypasses the `Convert.escapeUnicode` code on line 132.   That's not bad, but should be clearly documented ... in that this is a special method for known ASCII characters, and not a general purpose method that could be used on the characters of a string

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

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

From duke at openjdk.org  Wed Feb 22 15:35:11 2023
From: duke at openjdk.org (Christoph Dreis)
Date: Wed, 22 Feb 2023 15:35:11 GMT
Subject: RFR: 8303078: Reduce allocations when pretty printing JCTree
 during compilation
In-Reply-To: <GmfIJukLO6280Z1lPW5hPwPRMN0_UGNTJ-Ec9_HstyY=.95fe1edc-5f28-483a-a150-e0575ace6912@github.com>
References: <GmfIJukLO6280Z1lPW5hPwPRMN0_UGNTJ-Ec9_HstyY=.95fe1edc-5f28-483a-a150-e0575ace6912@github.com>
Message-ID: <-Ah1XzLMNfa7D5L_F4hu5XPkS3ALlphVVOu9GXC_aSs=.5e82688f-3840-491c-b5c8-34ef8b4f1d97@github.com>

On Mon, 20 Feb 2023 14:54:18 GMT, Christoph Dreis <duke at openjdk.org> wrote:

> Hi,
> 
> I've been recently optimizing a few project pipelines and always noticed that their compilation step is somewhat "expensive".  Zooming into the issue always revealed Lombok to be a larger contributor. Unfortunately, I can't get rid of Lombok in this customer project (before you ask).
> 
> Apparently, Lombok is printing the respective `JCTree` here and there to check for type matches. I can't imagine this to be super efficient, but that's how it is at the moment.
> <img width="948" alt="image" src="https://user-images.githubusercontent.com/6304496/220134737-bd9b508c-a908-448b-b0d1-e960db28b24a.png">
> 
> Anyhow, regardless of the Lombok inefficiencies I think there are some optimization opportunities in the JDK itself. 
> 
> 1. Overall, `Pretty.visitSelect` accounts for 8-10% of the total allocations in this project. And among those there are StringBuilder allocations coming from the following:
> 
> 
>     public void visitSelect(JCFieldAccess tree) {
>         try {
>             printExpr(tree.selected, TreeInfo.postfixPrec);
>             // StringBuilder allocations hiding in here.
>             print("." + tree.name);
>         } catch (IOException e) {
>             throw new UncheckedIOException(e);
>         }
>     }
> 
> 
> This PR splits the `print` calls into two separate ones to avoid this String concatenation.
> 
> ...
>             printExpr(tree.selected, TreeInfo.postfixPrec);
>             print('.');
>             print(tree.name);
> ...
> 
> 
> Secondly, the `print` method takes an `Object` which seems like a good fit for another (private?) variant of it that only takes a `char`. By this we would probably avoid any eventual boxing and avoid any conversion with `Convert.escapeUnicode(s.toString())` that seems superfluous for chars like `.`, ` `, or any braces like `(`, `{` etc. 
> 
> This is currently a draft PR as long as the scope is not clarified. It currently only includes the necessary changes that would optimize the particular use-case. But there are more cases where e.g. the new `char` variant could be used and/or any String concatenation could be split into separate `print` calls.
> 
> Let me know what you think and if I should include the other cases as well. If you think this is worthwhile, I'd appreciate if this is is sponsored. (Including creating an issue as I can't do this myself apparently. I will of course squash everything together with the proper issue ID once available.)
> 
> I've contributed before, so the CLA should be signed.
> 
> Cheers,
> Christoph

With the patch applied I can reduce things for an internal product.

**Some specs about the project:**

~2500 classes
Average size: ~76 lines
Largest class: ~2500 lines
Mostly hand-written, but some auto-generated protobuf files (I'd say 90/10 split)

**CPU profile before**
<img width="684" alt="image" src="https://user-images.githubusercontent.com/6304496/220614136-782ba89d-3241-45d4-86a7-68588592b3b1.png">

**CPU profile after**
<img width="684" alt="image" src="https://user-images.githubusercontent.com/6304496/220613899-a151a737-bded-45c5-919a-2de5989e6f5e.png">

**Allocation profile before**
<img width="684" alt="image" src="https://user-images.githubusercontent.com/6304496/220613178-22abc2d7-e18d-44e2-a249-0d6152884281.png">

**Allocation profile after**
<img width="684" alt="image" src="https://user-images.githubusercontent.com/6304496/220613351-16332e13-22f2-4004-96a3-bbef9ef039d0.png">

| Mode | Frames matched before | Frames matched after |
|--- | --- | --- |
|`cpu` | 2.27% | 1.42% |
| `alloc` | 7.09% | 4.13% |

In terms of timings I couldn't measure anything substantially on the actual project. Neither a regression, nor a substantial improvement. But it's not so much about time anyhow but about the allocations here. The overall goal is to reduce impact on GC that is using 27% of the CPU frames (to give you some more background). Obviously, this is not coming from the JDK alone and Lombok is a major contributor here, but the JDK can easy the impact of Lombok here I'd say.
<img width="473" alt="image" src="https://user-images.githubusercontent.com/6304496/220608498-65340f0f-9342-4df4-bdd5-9a83b05b0b92.png">

Admittedly, it's more on the smaller end of things and a smaller knob in terms of GC improvements.

Let me know if you need more information.

In terms of some more absolute allocation numbers:

**Before (TOP 3 => ~5,6GB)**

       bytes  percent  samples  top
  ----------  -------  -------  ---
  3581028736   26.79%    10682  byte[]
  1291159216    9.66%     3930  java.lang.Object[]
   740065552    5.54%     2161  java.lang.String

**After (TOP 3 => ~5,4GB)**

      bytes  percent  samples  top
  ----------  -------  -------  ---
  3376915824   26.33%    11615  byte[]
  1284160152   10.01%     3847  java.lang.Object[]
   730100712    5.69%     2023  java.lang.String


`StringBuilder` savings account for an additional 62MB

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

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

From duke at openjdk.org  Wed Feb 22 15:35:13 2023
From: duke at openjdk.org (Christoph Dreis)
Date: Wed, 22 Feb 2023 15:35:13 GMT
Subject: RFR: 8303078: Reduce allocations when pretty printing JCTree
 during compilation
In-Reply-To: <eEBaEr2__VO_s4s_KA2xDwRHQcE0gYeROFYEMQ2XtYI=.a67da85b-4fc1-4e9c-bd5c-f93f7045bf8f@github.com>
References: <GmfIJukLO6280Z1lPW5hPwPRMN0_UGNTJ-Ec9_HstyY=.95fe1edc-5f28-483a-a150-e0575ace6912@github.com>
 <eEBaEr2__VO_s4s_KA2xDwRHQcE0gYeROFYEMQ2XtYI=.a67da85b-4fc1-4e9c-bd5c-f93f7045bf8f@github.com>
Message-ID: <BviOODBZnoWD7_oBJoypkzVXTZKBqkrAfR_rh1KT46A=.42b27ad9-413c-4b6d-9046-66baaf4b2351@github.com>

On Wed, 22 Feb 2023 14:52:32 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Hi,
>> 
>> I've been recently optimizing a few project pipelines and always noticed that their compilation step is somewhat "expensive".  Zooming into the issue always revealed Lombok to be a larger contributor. Unfortunately, I can't get rid of Lombok in this customer project (before you ask).
>> 
>> Apparently, Lombok is printing the respective `JCTree` here and there to check for type matches. I can't imagine this to be super efficient, but that's how it is at the moment.
>> <img width="948" alt="image" src="https://user-images.githubusercontent.com/6304496/220134737-bd9b508c-a908-448b-b0d1-e960db28b24a.png">
>> 
>> Anyhow, regardless of the Lombok inefficiencies I think there are some optimization opportunities in the JDK itself. 
>> 
>> 1. Overall, `Pretty.visitSelect` accounts for 8-10% of the total allocations in this project. And among those there are StringBuilder allocations coming from the following:
>> 
>> 
>>     public void visitSelect(JCFieldAccess tree) {
>>         try {
>>             printExpr(tree.selected, TreeInfo.postfixPrec);
>>             // StringBuilder allocations hiding in here.
>>             print("." + tree.name);
>>         } catch (IOException e) {
>>             throw new UncheckedIOException(e);
>>         }
>>     }
>> 
>> 
>> This PR splits the `print` calls into two separate ones to avoid this String concatenation.
>> 
>> ...
>>             printExpr(tree.selected, TreeInfo.postfixPrec);
>>             print('.');
>>             print(tree.name);
>> ...
>> 
>> 
>> Secondly, the `print` method takes an `Object` which seems like a good fit for another (private?) variant of it that only takes a `char`. By this we would probably avoid any eventual boxing and avoid any conversion with `Convert.escapeUnicode(s.toString())` that seems superfluous for chars like `.`, ` `, or any braces like `(`, `{` etc. 
>> 
>> This is currently a draft PR as long as the scope is not clarified. It currently only includes the necessary changes that would optimize the particular use-case. But there are more cases where e.g. the new `char` variant could be used and/or any String concatenation could be split into separate `print` calls.
>> 
>> Let me know what you think and if I should include the other cases as well. If you think this is worthwhile, I'd appreciate if this is is sponsored. (Including creating an issue as I can't do this myself apparently. I will of course squash everything together with the proper issue ID once available.)
>> 
>> I've contributed before, so the CLA should be signed.
>> 
>> Cheers,
>> Christoph
>
> If we proceed with this, I would recommend looking for other possible uses of the new method.
> 
> A simple `grep` shows 129 single character strings, of which 97 are arguments to `print`.
> 
> Separate but related, I note that a similar class, `DocPretty.java`, has 75 single character strings, of which  68 are arguments to print.
> 
> Overall changing the coding style to use `out.print(char)` seems worthwhile.

@jonathan-gibbons Thanks for your review.
> If we proceed with this, I would recommend looking for other possible uses of the new method.

That's the idea - there are multiple cases where this could be used. I'll push an updated version that already changes things to make reviewing a bit easier.

EDIT: Done.

> There are 19 instances of string concatenation in `print` arguments, for your consideration as well.

@jonathan-gibbons Made the adjustments to `Pretty`.

> src/jdk.compiler/share/classes/com/sun/tools/javac/tree/Pretty.java line 139:
> 
>> 137:     private void print(char c) throws IOException {
>> 138:         out.write(c);
>> 139:     }
> 
> This bypasses the `Convert.escapeUnicode` code on line 132.   That's not bad, but should be clearly documented ... in that this is a special method for known ASCII characters, and not a general purpose method that could be used on the characters of a string

Adjusted the comment in that regards.

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

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

From archie.cobbs at gmail.com  Wed Feb 22 16:06:20 2023
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Wed, 22 Feb 2023 10:06:20 -0600
Subject: Case-insensitive file systems and output file clashes - survey
Message-ID: <CANSoFxuM4X-E0Er8b4hSWwwg8asBRmSGmab9+sUQPXmuh2C70A@mail.gmail.com>

A few bugs I've looked at recently relate to two compiler output files
"clashing" in the sense that they end up mapping to the same actual file in
the file system.

Two of these are due to case-insensitive filesystems:

JDK-8287885 <https://bugs.openjdk.org/browse/JDK-8287885> - Local classes
cause ClassLoader error if the type names are similar but not same
JDK-8296656 <https://bugs.openjdk.org/browse/JDK-8296656> -
java.lang.NoClassDefFoundError exception on running fully legitimate code

I submitted a PR for the first bug above, but it's a gross combination of
being an ugly hack and also not really solving the real problem (I'm going
to withdraw it).

Side note: another related bug, though this one is not the filesystem's
fault (it's due to inherent clashing in the JNI specification) but would be
affected by some of the ideas mentioned below:

JDK-7016187 <https://bugs.openjdk.org/browse/JDK-7016187> - `javac -h`
could generate conflict .h for inner class and class name with '_'

Survey question: What do you think should be done about this
case-insensitive filesystem problem?

   1. Nothing. Resolve all such bugs "Not an Issue" with the comment "Go
   away! Case-insensitive filesystems are not supported!"
   2. Add a new option -Xlint:fileclash that enables checking for clashes
   (e.g., at the JavacFileSystemManager layer).
   3. Same as #2 but instead of requiring a lint flag, test the filesystem
   at startup and proactively enable the warning only if case-insensitive
   4. Add new compiler flags -dzip, -szip, -hzip (corresponding to -d, -s,
   -h) that specify ZIP files for output instead of directories
   5. Your other clever idea...

Thanks,
-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230222/4af73867/attachment.htm>

From duke at openjdk.org  Wed Feb 22 16:12:08 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Wed, 22 Feb 2023 16:12:08 GMT
Subject: RFR: 8287885: Local classes cause ClassLoader error if the type
 names are similar but not same
In-Reply-To: <UunxL2H0Gf9ef0d4p3FRR3WjNSkzkTOSQwr8oirwp9g=.824550f6-8901-476a-9a56-350d68f9b107@github.com>
References: <UunxL2H0Gf9ef0d4p3FRR3WjNSkzkTOSQwr8oirwp9g=.824550f6-8901-476a-9a56-350d68f9b107@github.com>
Message-ID: <zmYXPhQFDDj_KsUN8J8qTblexghsa84s7-dkhMgeW-A=.3e892605-d153-4488-a6cf-8c4217c87dd2@github.com>

On Mon, 20 Feb 2023 20:50:48 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

> The compiler doesn't really support case-insensitive filesystems. However, we can still avoid name clashes for local classes because their names are synthesized with indexed names like`$1`, `$2`, etc.
> 
> So previously, a class like this:
> 
> public class Test {
> 
>     void method1() {
>         enum ABC { A, B, C; };
>     }
> 
>     void method2() {
>         enum Abc { A, B, C; };
>     } 
> }
> 
> would generate these classfiles:
> 
> Test.class
> Test$1ABC.class
> Test$1Abc.class
> 
> the latter two of which clash on case-insensitive filesystems. After this patch, these non-clashing classfiles are generated instead:
> 
> Test.class
> Test$1ABC.class
> Test$2Abc.class
> 
> 
> The only thing slightly wonky about this patch is that `clearLocalClassNameIndexes()` since local classes `ABC` and `Abc` share the same index, clearing either one clears both. But this is harmless, because these indexes are cleared in a batch, during a final "cleanup" step after processing the containing class.
> 
> To avoid any locale weirdness, we only collapse ASCII letters A-Z/a-z. So this is clearly a limited, tactical fix.

Withdrawing this PR - too much of a hack and it doesn't really solve the underlying problem.

To be discussed further on compiler-dev.

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

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

From duke at openjdk.org  Wed Feb 22 16:12:10 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Wed, 22 Feb 2023 16:12:10 GMT
Subject: Withdrawn: 8287885: Local classes cause ClassLoader error if the type
 names are similar but not same
In-Reply-To: <UunxL2H0Gf9ef0d4p3FRR3WjNSkzkTOSQwr8oirwp9g=.824550f6-8901-476a-9a56-350d68f9b107@github.com>
References: <UunxL2H0Gf9ef0d4p3FRR3WjNSkzkTOSQwr8oirwp9g=.824550f6-8901-476a-9a56-350d68f9b107@github.com>
Message-ID: <xgfMyiYsYHeYYUNHqxElH0gxZ8WmjWpawzO8Sj_6c_4=.fb37bb3a-4f6e-42c4-b31c-e1bf76eb5e04@github.com>

On Mon, 20 Feb 2023 20:50:48 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

> The compiler doesn't really support case-insensitive filesystems. However, we can still avoid name clashes for local classes because their names are synthesized with indexed names like`$1`, `$2`, etc.
> 
> So previously, a class like this:
> 
> public class Test {
> 
>     void method1() {
>         enum ABC { A, B, C; };
>     }
> 
>     void method2() {
>         enum Abc { A, B, C; };
>     } 
> }
> 
> would generate these classfiles:
> 
> Test.class
> Test$1ABC.class
> Test$1Abc.class
> 
> the latter two of which clash on case-insensitive filesystems. After this patch, these non-clashing classfiles are generated instead:
> 
> Test.class
> Test$1ABC.class
> Test$2Abc.class
> 
> 
> The only thing slightly wonky about this patch is that `clearLocalClassNameIndexes()` since local classes `ABC` and `Abc` share the same index, clearing either one clears both. But this is harmless, because these indexes are cleared in a batch, during a final "cleanup" step after processing the containing class.
> 
> To avoid any locale weirdness, we only collapse ASCII letters A-Z/a-z. So this is clearly a limited, tactical fix.

This pull request has been closed without being integrated.

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

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

From vromero at openjdk.org  Wed Feb 22 16:27:24 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 22 Feb 2023 16:27:24 GMT
Subject: RFR: 8303078: Reduce allocations when pretty printing JCTree
 during compilation
In-Reply-To: <GmfIJukLO6280Z1lPW5hPwPRMN0_UGNTJ-Ec9_HstyY=.95fe1edc-5f28-483a-a150-e0575ace6912@github.com>
References: <GmfIJukLO6280Z1lPW5hPwPRMN0_UGNTJ-Ec9_HstyY=.95fe1edc-5f28-483a-a150-e0575ace6912@github.com>
Message-ID: <xJi2_wjj1WiUhz2PWJ8PhmrTVWNnPh_gTmltf9zB4no=.4c02d5ad-1ebd-4dcd-a9db-9e8b2430801f@github.com>

On Mon, 20 Feb 2023 14:54:18 GMT, Christoph Dreis <duke at openjdk.org> wrote:

> Hi,
> 
> I've been recently optimizing a few project pipelines and always noticed that their compilation step is somewhat "expensive".  Zooming into the issue always revealed Lombok to be a larger contributor. Unfortunately, I can't get rid of Lombok in this customer project (before you ask).
> 
> Apparently, Lombok is printing the respective `JCTree` here and there to check for type matches. I can't imagine this to be super efficient, but that's how it is at the moment.
> <img width="948" alt="image" src="https://user-images.githubusercontent.com/6304496/220134737-bd9b508c-a908-448b-b0d1-e960db28b24a.png">
> 
> Anyhow, regardless of the Lombok inefficiencies I think there are some optimization opportunities in the JDK itself. 
> 
> 1. Overall, `Pretty.visitSelect` accounts for 8-10% of the total allocations in this project. And among those there are StringBuilder allocations coming from the following:
> 
> 
>     public void visitSelect(JCFieldAccess tree) {
>         try {
>             printExpr(tree.selected, TreeInfo.postfixPrec);
>             // StringBuilder allocations hiding in here.
>             print("." + tree.name);
>         } catch (IOException e) {
>             throw new UncheckedIOException(e);
>         }
>     }
> 
> 
> This PR splits the `print` calls into two separate ones to avoid this String concatenation.
> 
> ...
>             printExpr(tree.selected, TreeInfo.postfixPrec);
>             print('.');
>             print(tree.name);
> ...
> 
> 
> Secondly, the `print` method takes an `Object` which seems like a good fit for another (private?) variant of it that only takes a `char`. By this we would probably avoid any eventual boxing and avoid any conversion with `Convert.escapeUnicode(s.toString())` that seems superfluous for chars like `.`, ` `, or any braces like `(`, `{` etc. 
> 
> This is currently a draft PR as long as the scope is not clarified. It currently only includes the necessary changes that would optimize the particular use-case. But there are more cases where e.g. the new `char` variant could be used and/or any String concatenation could be split into separate `print` calls.
> 
> Let me know what you think and if I should include the other cases as well. If you think this is worthwhile, I'd appreciate if this is is sponsored. (Including creating an issue as I can't do this myself apparently. I will of course squash everything together with the proper issue ID once available.)
> 
> I've contributed before, so the CLA should be signed.
> 
> Cheers,
> Christoph

this is looking good, I think that once the changes to `DocPretty.java`, as Jon suggested, are included in this patch it should be good to go

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

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

From duke at openjdk.org  Wed Feb 22 16:36:50 2023
From: duke at openjdk.org (Christoph Dreis)
Date: Wed, 22 Feb 2023 16:36:50 GMT
Subject: RFR: 8303078: Reduce allocations when pretty printing JCTree
 during compilation [v2]
In-Reply-To: <GmfIJukLO6280Z1lPW5hPwPRMN0_UGNTJ-Ec9_HstyY=.95fe1edc-5f28-483a-a150-e0575ace6912@github.com>
References: <GmfIJukLO6280Z1lPW5hPwPRMN0_UGNTJ-Ec9_HstyY=.95fe1edc-5f28-483a-a150-e0575ace6912@github.com>
Message-ID: <wQTo4HeB0JQyLQLutA_0aHDoHZSf7VGPVAECY-14P-Q=.a20572b6-b30d-48c5-840e-bddf4c11ea1c@github.com>

> Hi,
> 
> I've been recently optimizing a few project pipelines and always noticed that their compilation step is somewhat "expensive".  Zooming into the issue always revealed Lombok to be a larger contributor. Unfortunately, I can't get rid of Lombok in this customer project (before you ask).
> 
> Apparently, Lombok is printing the respective `JCTree` here and there to check for type matches. I can't imagine this to be super efficient, but that's how it is at the moment.
> <img width="948" alt="image" src="https://user-images.githubusercontent.com/6304496/220134737-bd9b508c-a908-448b-b0d1-e960db28b24a.png">
> 
> Anyhow, regardless of the Lombok inefficiencies I think there are some optimization opportunities in the JDK itself. 
> 
> 1. Overall, `Pretty.visitSelect` accounts for 8-10% of the total allocations in this project. And among those there are StringBuilder allocations coming from the following:
> 
> 
>     public void visitSelect(JCFieldAccess tree) {
>         try {
>             printExpr(tree.selected, TreeInfo.postfixPrec);
>             // StringBuilder allocations hiding in here.
>             print("." + tree.name);
>         } catch (IOException e) {
>             throw new UncheckedIOException(e);
>         }
>     }
> 
> 
> This PR splits the `print` calls into two separate ones to avoid this String concatenation.
> 
> ...
>             printExpr(tree.selected, TreeInfo.postfixPrec);
>             print('.');
>             print(tree.name);
> ...
> 
> 
> Secondly, the `print` method takes an `Object` which seems like a good fit for another (private?) variant of it that only takes a `char`. By this we would probably avoid any eventual boxing and avoid any conversion with `Convert.escapeUnicode(s.toString())` that seems superfluous for chars like `.`, ` `, or any braces like `(`, `{` etc. 
> 
> This is currently a draft PR as long as the scope is not clarified. It currently only includes the necessary changes that would optimize the particular use-case. But there are more cases where e.g. the new `char` variant could be used and/or any String concatenation could be split into separate `print` calls.
> 
> Let me know what you think and if I should include the other cases as well. If you think this is worthwhile, I'd appreciate if this is is sponsored. (Including creating an issue as I can't do this myself apparently. I will of course squash everything together with the proper issue ID once available.)
> 
> I've contributed before, so the CLA should be signed.
> 
> Cheers,
> Christoph

Christoph Dreis has updated the pull request incrementally with one additional commit since the last revision:

  8303078: Reduce allocations for single characters in DocPretty

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12667/files
  - new: https://git.openjdk.org/jdk/pull/12667/files/45d1219a..b1b8d0ca

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

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

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

From duke at openjdk.org  Wed Feb 22 16:36:52 2023
From: duke at openjdk.org (Christoph Dreis)
Date: Wed, 22 Feb 2023 16:36:52 GMT
Subject: RFR: 8303078: Reduce allocations when pretty printing JCTree
 during compilation [v2]
In-Reply-To: <xJi2_wjj1WiUhz2PWJ8PhmrTVWNnPh_gTmltf9zB4no=.4c02d5ad-1ebd-4dcd-a9db-9e8b2430801f@github.com>
References: <GmfIJukLO6280Z1lPW5hPwPRMN0_UGNTJ-Ec9_HstyY=.95fe1edc-5f28-483a-a150-e0575ace6912@github.com>
 <xJi2_wjj1WiUhz2PWJ8PhmrTVWNnPh_gTmltf9zB4no=.4c02d5ad-1ebd-4dcd-a9db-9e8b2430801f@github.com>
Message-ID: <Xecm3sZ5VCq8_ScgmwTfyz090temnaNaIw-NaEP8Q1E=.c39ef435-0546-41b0-81b2-aefce84f19e2@github.com>

On Wed, 22 Feb 2023 16:24:29 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Christoph Dreis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8303078: Reduce allocations for single characters in DocPretty
>
> this is looking good, I think that once the changes to `DocPretty.java`, as Jon suggested, are included in this patch it should be good to go

@vicente-romero-oracle & @jonathan-gibbons made the adjustments to `DocPretty` now as well.

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

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

From vicente.romero at oracle.com  Wed Feb 22 17:08:01 2023
From: vicente.romero at oracle.com (Vicente Romero)
Date: Wed, 22 Feb 2023 12:08:01 -0500
Subject: [External] : AW: Remove stream usage from Symtab.lookupPackage()
In-Reply-To: <PAXP193MB12314C4F9E105818BE3ED543AFAA9@PAXP193MB1231.EURP193.PROD.OUTLOOK.COM>
References: <AS8P193MB12247CE232823FDE020C44B0AFA59@AS8P193MB1224.EURP193.PROD.OUTLOOK.COM>
 <783e1ca1-eed2-3b8b-a978-dd6a096f81f6@oracle.com>
 <PAXP193MB12314C4F9E105818BE3ED543AFAA9@PAXP193MB1231.EURP193.PROD.OUTLOOK.COM>
Message-ID: <cfc345dd-5578-223a-63b2-9b02927ea623@oracle.com>

Hi Christoph,

I'm on the fence with this one. The improvements doesn't seems to be 
considerable, while some could see the rewriting as step back given 
that, again could be subjective, the code could be seen as more readable 
using Streams. We have seen great performance improvements overtime in 
new features like lambdas etc. I can certainly expect this to happen to 
streams too. So I don't see the same benefit here as in your other PR, 
the Pretty.java one. But others in the list could have another opinion,

Thanks,
Vicente

On 2/22/23 06:46, christoph.dreis at freenet.de wrote:
>
> Hi Vicente,
>
> thanks for taking the time. I?ve added a comment in the PR with 
> screenshots from async-profiler runs etc. that are somewhat easier to 
> post there compared to the mailing list. But to share the TL;DR:
>
>   * ~2500 classes
>   * Average size: ~76 lines
>   * Largest class: ~2500 lines
>   * Mostly hand-written, but some auto-generated protobuf files (I'd
>     say 90/10 split)
>
> Overall timings didn?t improve (or regress), but the allocations of 
> Symtab.lookupPackage() went down from 1.6% to 0.1% overall, while CPU 
> frames went down from 1.6% to 0.9%.
>
> Let me know if you need more information and I?ll post this to the 
> issue on GitHub.
>
> Cheers,
>
> Christoph
>
> Am 22.02.23, 04:16 schrieb "Vicente Romero" <vicente.romero at oracle.com>:
>
>
> Hi Christoph,
>
> Could you please share more info like what type of sources are you 
> compiling: machine generated or not, very long sources, etc. Also 
> what's the performance improvement you get with your patch, etc.
>
> Thanks,
> Vicente
>
> On 2/21/23 16:03, christoph.dreis at freenet.de wrote:
>
>     Hi,
>
>     I'm currently profiling some compilation phases of internal
>     projects and noticed in allocation profiles that
>     |Symtab.lookupPackage|?takes up ~2% overall. The majority of this
>     is spent in |.stream().anyMatch()|?usages to find out if the given
>     module symbol depends on the unnamed module.
>
>     The PR under https://github.com/openjdk/jdk/pull/12700
>     <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/12700__;!!ACWV5N9M2RV99hQ!IIXyUx5ZjLrx7hFkIokefPwtWpLqF1uyRI7MXKKY1m72UryCkRemnzgHLC2txnHo3SZFHozLPgWBvjDFql3VAAz88x1M6lU4$>
>     desugars the code into a simple loop.
>
>     If you think this is worthwhile I'd appreciate if this is
>     sponsored. I'd also need a ticket number for that because I can't
>     create tickets. CLA should be signed though.
>
>     Let me know what you think.
>     Cheers,
>     Christoph
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230222/b76b91b3/attachment-0001.htm>

From jonathan.gibbons at oracle.com  Wed Feb 22 18:11:33 2023
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 22 Feb 2023 10:11:33 -0800
Subject: Case-insensitive file systems and output file clashes - survey
In-Reply-To: <CANSoFxuM4X-E0Er8b4hSWwwg8asBRmSGmab9+sUQPXmuh2C70A@mail.gmail.com>
References: <CANSoFxuM4X-E0Er8b4hSWwwg8asBRmSGmab9+sUQPXmuh2C70A@mail.gmail.com>
Message-ID: <c7518371-31a8-78a8-3bf7-2cb0e4394ccd@oracle.com>


On 2/22/23 8:06 AM, Archie Cobbs wrote:
>
> Survey question: What do you think should be done about this 
> case-insensitive filesystem problem?
>
>  1. Nothing. Resolve all such bugs "Not an Issue" with the comment "Go
>     away! Case-insensitive filesystems are not supported!"
>  2. Add a new option -Xlint:fileclash that enables checking for
>     clashes (e.g., at the JavacFileSystemManager layer).
>
That would likely either be a partial solution, or an expensive one for 
a complete solution when taking separate compilation into account.


>  1. Same as #2 but instead of requiring a lint flag, test the
>     filesystem at startup and proactively enable the warning only if
>     case-insensitive
>
I seem to recall that on some systems, it can be a property of the 
directory, not just the file system.


>  1. Add new compiler flags -dzip, -szip, -hzip (corresponding to -d,
>     -s, -h) that specify ZIP files for output instead of directories
>
I would recommend using the existing options, and just allow those 
options to specify a zip file, and then open the file with `zipfs`.?? 
That being said, updating zip files by "overwriting" existing entries 
comes with its own set of problems.


>  1. Your other clever idea...
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230222/ea32d84c/attachment.htm>

From jonathan.gibbons at oracle.com  Wed Feb 22 18:15:29 2023
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 22 Feb 2023 10:15:29 -0800
Subject: Remove stream usage from Symtab.lookupPackage()
In-Reply-To: <CANSoFxsiY_btJ7ues5GmsnyXQ4uXVC_6GZHYYXi=8Utsvs-eiQ@mail.gmail.com>
References: <AS8P193MB12247CE232823FDE020C44B0AFA59@AS8P193MB1224.EURP193.PROD.OUTLOOK.COM>
 <CANSoFxsiY_btJ7ues5GmsnyXQ4uXVC_6GZHYYXi=8Utsvs-eiQ@mail.gmail.com>
Message-ID: <2c079f11-dc39-29fb-5335-d630deb52999@oracle.com>

In times past, there were places in javac when `instanceof` was *not* a 
substitute for checking the tag.

We've probably gotten rid of those cases by now, but as a general coding 
pattern, I note that for end users writing code like annotation 
processors, the problem still remains if using other compilers.

-- Jon

On 2/21/23 7:30 PM, Archie Cobbs wrote:
> On Tue, Feb 21, 2023 at 6:24 PM christoph.dreis at freenet.de 
> <christoph.dreis at freenet.de> wrote:
>
>     I'm currently profiling some compilation phases of internal
>     projects and noticed in allocation profiles that
>     |Symtab.lookupPackage|?takes up ~2% overall. The majority of this
>     is spent in |.stream().anyMatch()|?usages to find out if the given
>     module symbol depends on the unnamed module.
>
>
> Straightforward patch, but it's disappointing that unrolling a Stream 
> into the equivalent for loop makes it noticeably faster (how much?).
>
> This also brings up larger philosophical questions about code style 
> vs. performance. If using a Stream somewhere makes for more 
> clean/elegant/understandable code, but is slower, how to weigh the 
> trade-off? Maybe this has been discussed before on this list before I 
> joined. Maybe we should assign this bug to the hotspot group :)
>
> On this same topic, this pattern which appears constantly in the 
> compiler always makes me kind of quizzical:
>
> JCExpression expr = TreeInfo.skipParens(tree.expr);
> if (expr.hasTag(APPLY)) {
> ??? JCMethodInvocation apply = (JCMethodInvocation)expr;
> ??? ...
> }
>
> Is instanceof really that much slower? Maybe it was once, long ago, 
> and this is a legacy thing?
>
> -Archie
>
> -- 
> Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230222/7b53cd6c/attachment-0001.htm>

From duke at openjdk.org  Wed Feb 22 18:22:11 2023
From: duke at openjdk.org (Christoph Dreis)
Date: Wed, 22 Feb 2023 18:22:11 GMT
Subject: RFR: 8303078: Reduce allocations when pretty printing JCTree
 during compilation [v3]
In-Reply-To: <GmfIJukLO6280Z1lPW5hPwPRMN0_UGNTJ-Ec9_HstyY=.95fe1edc-5f28-483a-a150-e0575ace6912@github.com>
References: <GmfIJukLO6280Z1lPW5hPwPRMN0_UGNTJ-Ec9_HstyY=.95fe1edc-5f28-483a-a150-e0575ace6912@github.com>
Message-ID: <tkMC203IoUeURHz8X6pI3yjUWNBqyiSH0epw6f4Zpdk=.251439a1-6ca5-407f-b32b-73a8bd1cd206@github.com>

> Hi,
> 
> I've been recently optimizing a few project pipelines and always noticed that their compilation step is somewhat "expensive".  Zooming into the issue always revealed Lombok to be a larger contributor. Unfortunately, I can't get rid of Lombok in this customer project (before you ask).
> 
> Apparently, Lombok is printing the respective `JCTree` here and there to check for type matches. I can't imagine this to be super efficient, but that's how it is at the moment.
> <img width="948" alt="image" src="https://user-images.githubusercontent.com/6304496/220134737-bd9b508c-a908-448b-b0d1-e960db28b24a.png">
> 
> Anyhow, regardless of the Lombok inefficiencies I think there are some optimization opportunities in the JDK itself. 
> 
> 1. Overall, `Pretty.visitSelect` accounts for 8-10% of the total allocations in this project. And among those there are StringBuilder allocations coming from the following:
> 
> 
>     public void visitSelect(JCFieldAccess tree) {
>         try {
>             printExpr(tree.selected, TreeInfo.postfixPrec);
>             // StringBuilder allocations hiding in here.
>             print("." + tree.name);
>         } catch (IOException e) {
>             throw new UncheckedIOException(e);
>         }
>     }
> 
> 
> This PR splits the `print` calls into two separate ones to avoid this String concatenation.
> 
> ...
>             printExpr(tree.selected, TreeInfo.postfixPrec);
>             print('.');
>             print(tree.name);
> ...
> 
> 
> Secondly, the `print` method takes an `Object` which seems like a good fit for another (private?) variant of it that only takes a `char`. By this we would probably avoid any eventual boxing and avoid any conversion with `Convert.escapeUnicode(s.toString())` that seems superfluous for chars like `.`, ` `, or any braces like `(`, `{` etc. 
> 
> This is currently a draft PR as long as the scope is not clarified. It currently only includes the necessary changes that would optimize the particular use-case. But there are more cases where e.g. the new `char` variant could be used and/or any String concatenation could be split into separate `print` calls.
> 
> Let me know what you think and if I should include the other cases as well. If you think this is worthwhile, I'd appreciate if this is is sponsored. (Including creating an issue as I can't do this myself apparently. I will of course squash everything together with the proper issue ID once available.)
> 
> I've contributed before, so the CLA should be signed.
> 
> Cheers,
> Christoph

Christoph Dreis has updated the pull request incrementally with two additional commits since the last revision:

 - 8303078: Replace some more character print calls
 - 8303078: Replace some more character print calls

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12667/files
  - new: https://git.openjdk.org/jdk/pull/12667/files/b1b8d0ca..34f9c330

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

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

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

From vromero at openjdk.org  Wed Feb 22 18:22:14 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 22 Feb 2023 18:22:14 GMT
Subject: RFR: 8303078: Reduce allocations when pretty printing JCTree
 during compilation [v3]
In-Reply-To: <tkMC203IoUeURHz8X6pI3yjUWNBqyiSH0epw6f4Zpdk=.251439a1-6ca5-407f-b32b-73a8bd1cd206@github.com>
References: <GmfIJukLO6280Z1lPW5hPwPRMN0_UGNTJ-Ec9_HstyY=.95fe1edc-5f28-483a-a150-e0575ace6912@github.com>
 <tkMC203IoUeURHz8X6pI3yjUWNBqyiSH0epw6f4Zpdk=.251439a1-6ca5-407f-b32b-73a8bd1cd206@github.com>
Message-ID: <MPN11Sppx_zVRRfxAvTwFN0oOnpui4p55BVdQCg8CBE=.07b75c9f-fce4-4708-969c-bb868a16c5be@github.com>

On Wed, 22 Feb 2023 18:12:47 GMT, Christoph Dreis <duke at openjdk.org> wrote:

>> Hi,
>> 
>> I've been recently optimizing a few project pipelines and always noticed that their compilation step is somewhat "expensive".  Zooming into the issue always revealed Lombok to be a larger contributor. Unfortunately, I can't get rid of Lombok in this customer project (before you ask).
>> 
>> Apparently, Lombok is printing the respective `JCTree` here and there to check for type matches. I can't imagine this to be super efficient, but that's how it is at the moment.
>> <img width="948" alt="image" src="https://user-images.githubusercontent.com/6304496/220134737-bd9b508c-a908-448b-b0d1-e960db28b24a.png">
>> 
>> Anyhow, regardless of the Lombok inefficiencies I think there are some optimization opportunities in the JDK itself. 
>> 
>> 1. Overall, `Pretty.visitSelect` accounts for 8-10% of the total allocations in this project. And among those there are StringBuilder allocations coming from the following:
>> 
>> 
>>     public void visitSelect(JCFieldAccess tree) {
>>         try {
>>             printExpr(tree.selected, TreeInfo.postfixPrec);
>>             // StringBuilder allocations hiding in here.
>>             print("." + tree.name);
>>         } catch (IOException e) {
>>             throw new UncheckedIOException(e);
>>         }
>>     }
>> 
>> 
>> This PR splits the `print` calls into two separate ones to avoid this String concatenation.
>> 
>> ...
>>             printExpr(tree.selected, TreeInfo.postfixPrec);
>>             print('.');
>>             print(tree.name);
>> ...
>> 
>> 
>> Secondly, the `print` method takes an `Object` which seems like a good fit for another (private?) variant of it that only takes a `char`. By this we would probably avoid any eventual boxing and avoid any conversion with `Convert.escapeUnicode(s.toString())` that seems superfluous for chars like `.`, ` `, or any braces like `(`, `{` etc. 
>> 
>> This is currently a draft PR as long as the scope is not clarified. It currently only includes the necessary changes that would optimize the particular use-case. But there are more cases where e.g. the new `char` variant could be used and/or any String concatenation could be split into separate `print` calls.
>> 
>> Let me know what you think and if I should include the other cases as well. If you think this is worthwhile, I'd appreciate if this is is sponsored. (Including creating an issue as I can't do this myself apparently. I will of course squash everything together with the proper issue ID once available.)
>> 
>> I've contributed before, so the CLA should be signed.
>> 
>> Cheers,
>> Christoph
>
> Christoph Dreis has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8303078: Replace some more character print calls
>  - 8303078: Replace some more character print calls

src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DocPretty.java line 195:

> 193:     public Void visitDocRoot(DocRootTree node, Void p) {
> 194:         try {
> 195:             print("{");

there are some instances of `print("\n");` that could be `print('\n');` few lines above this point

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

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

From duke at openjdk.org  Wed Feb 22 18:22:16 2023
From: duke at openjdk.org (Christoph Dreis)
Date: Wed, 22 Feb 2023 18:22:16 GMT
Subject: RFR: 8303078: Reduce allocations when pretty printing JCTree
 during compilation [v3]
In-Reply-To: <MPN11Sppx_zVRRfxAvTwFN0oOnpui4p55BVdQCg8CBE=.07b75c9f-fce4-4708-969c-bb868a16c5be@github.com>
References: <GmfIJukLO6280Z1lPW5hPwPRMN0_UGNTJ-Ec9_HstyY=.95fe1edc-5f28-483a-a150-e0575ace6912@github.com>
 <tkMC203IoUeURHz8X6pI3yjUWNBqyiSH0epw6f4Zpdk=.251439a1-6ca5-407f-b32b-73a8bd1cd206@github.com>
 <MPN11Sppx_zVRRfxAvTwFN0oOnpui4p55BVdQCg8CBE=.07b75c9f-fce4-4708-969c-bb868a16c5be@github.com>
Message-ID: <TcoTi7SLEgFx6JxoHe-ryNnnM7t5YyJFJJbHNUIX87k=.90c28a3e-f8f2-4fbf-ba6b-b05609d74dd5@github.com>

On Wed, 22 Feb 2023 17:59:17 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Christoph Dreis has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - 8303078: Replace some more character print calls
>>  - 8303078: Replace some more character print calls
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DocPretty.java line 195:
> 
>> 193:     public Void visitDocRoot(DocRootTree node, Void p) {
>> 194:         try {
>> 195:             print("{");
> 
> there are some instances of `print("\n");` that could be `print('\n');` few lines above this point

Done - but had to change the one with the `sep` argument to take a char instead of String. Seems not used elsewhere, but wasn't sure because of the `protected`

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

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

From vromero at openjdk.org  Wed Feb 22 18:22:42 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 22 Feb 2023 18:22:42 GMT
Subject: RFR: 8303078: Reduce allocations when pretty printing JCTree
 during compilation [v2]
In-Reply-To: <wQTo4HeB0JQyLQLutA_0aHDoHZSf7VGPVAECY-14P-Q=.a20572b6-b30d-48c5-840e-bddf4c11ea1c@github.com>
References: <GmfIJukLO6280Z1lPW5hPwPRMN0_UGNTJ-Ec9_HstyY=.95fe1edc-5f28-483a-a150-e0575ace6912@github.com>
 <wQTo4HeB0JQyLQLutA_0aHDoHZSf7VGPVAECY-14P-Q=.a20572b6-b30d-48c5-840e-bddf4c11ea1c@github.com>
Message-ID: <flVK2vzadl2bcqCghBU3MbupyBrhQcaOrBGXIHMK_eI=.0beaea2d-e581-4192-ac6f-1dd5705b1720@github.com>

On Wed, 22 Feb 2023 16:36:50 GMT, Christoph Dreis <duke at openjdk.org> wrote:

>> Hi,
>> 
>> I've been recently optimizing a few project pipelines and always noticed that their compilation step is somewhat "expensive".  Zooming into the issue always revealed Lombok to be a larger contributor. Unfortunately, I can't get rid of Lombok in this customer project (before you ask).
>> 
>> Apparently, Lombok is printing the respective `JCTree` here and there to check for type matches. I can't imagine this to be super efficient, but that's how it is at the moment.
>> <img width="948" alt="image" src="https://user-images.githubusercontent.com/6304496/220134737-bd9b508c-a908-448b-b0d1-e960db28b24a.png">
>> 
>> Anyhow, regardless of the Lombok inefficiencies I think there are some optimization opportunities in the JDK itself. 
>> 
>> 1. Overall, `Pretty.visitSelect` accounts for 8-10% of the total allocations in this project. And among those there are StringBuilder allocations coming from the following:
>> 
>> 
>>     public void visitSelect(JCFieldAccess tree) {
>>         try {
>>             printExpr(tree.selected, TreeInfo.postfixPrec);
>>             // StringBuilder allocations hiding in here.
>>             print("." + tree.name);
>>         } catch (IOException e) {
>>             throw new UncheckedIOException(e);
>>         }
>>     }
>> 
>> 
>> This PR splits the `print` calls into two separate ones to avoid this String concatenation.
>> 
>> ...
>>             printExpr(tree.selected, TreeInfo.postfixPrec);
>>             print('.');
>>             print(tree.name);
>> ...
>> 
>> 
>> Secondly, the `print` method takes an `Object` which seems like a good fit for another (private?) variant of it that only takes a `char`. By this we would probably avoid any eventual boxing and avoid any conversion with `Convert.escapeUnicode(s.toString())` that seems superfluous for chars like `.`, ` `, or any braces like `(`, `{` etc. 
>> 
>> This is currently a draft PR as long as the scope is not clarified. It currently only includes the necessary changes that would optimize the particular use-case. But there are more cases where e.g. the new `char` variant could be used and/or any String concatenation could be split into separate `print` calls.
>> 
>> Let me know what you think and if I should include the other cases as well. If you think this is worthwhile, I'd appreciate if this is is sponsored. (Including creating an issue as I can't do this myself apparently. I will of course squash everything together with the proper issue ID once available.)
>> 
>> I've contributed before, so the CLA should be signed.
>> 
>> Cheers,
>> Christoph
>
> Christoph Dreis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8303078: Reduce allocations for single characters in DocPretty

src/jdk.compiler/share/classes/com/sun/tools/javac/tree/Pretty.java line 1246:

> 1244:             if (tree.paramKind == JCLambda.ParameterKind.EXPLICIT) {
> 1245:                 printExprs(tree.params);
> 1246:             } else {

nit, just below: `String sep = "";` -> `char sep = '\0';` also `sep = ","` -> `sep = ','`?

src/jdk.compiler/share/classes/com/sun/tools/javac/tree/Pretty.java line 1456:

> 1454:                     break;
> 1455:                 case CHAR:
> 1456:                     print("\'");

`print(''');` ?

src/jdk.compiler/share/classes/com/sun/tools/javac/tree/Pretty.java line 1458:

> 1456:                     print("\'");
> 1457:                     print(Convert.quote(String.valueOf((char)((Number)tree.value).intValue())));
> 1458:                     print("\'");

same: `print(''');` ?

src/jdk.compiler/share/classes/com/sun/tools/javac/tree/Pretty.java line 1467:

> 1465:                     break;
> 1466:                 default:
> 1467:                     print("\"");

`print('"');`?

src/jdk.compiler/share/classes/com/sun/tools/javac/tree/Pretty.java line 1469:

> 1467:                     print("\"");
> 1468:                     print(Convert.quote(tree.value.toString()));
> 1469:                     print("\"");

same as above

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

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

From duke at openjdk.org  Wed Feb 22 18:22:44 2023
From: duke at openjdk.org (Christoph Dreis)
Date: Wed, 22 Feb 2023 18:22:44 GMT
Subject: RFR: 8303078: Reduce allocations when pretty printing JCTree
 during compilation [v2]
In-Reply-To: <flVK2vzadl2bcqCghBU3MbupyBrhQcaOrBGXIHMK_eI=.0beaea2d-e581-4192-ac6f-1dd5705b1720@github.com>
References: <GmfIJukLO6280Z1lPW5hPwPRMN0_UGNTJ-Ec9_HstyY=.95fe1edc-5f28-483a-a150-e0575ace6912@github.com>
 <wQTo4HeB0JQyLQLutA_0aHDoHZSf7VGPVAECY-14P-Q=.a20572b6-b30d-48c5-840e-bddf4c11ea1c@github.com>
 <flVK2vzadl2bcqCghBU3MbupyBrhQcaOrBGXIHMK_eI=.0beaea2d-e581-4192-ac6f-1dd5705b1720@github.com>
Message-ID: <_qzvnCcRMvtm-rUD8wPK-T_IIKmFaskg7f-jahcFe5w=.5efa246e-a2a2-483a-bd6b-c6fe06415d8f@github.com>

On Wed, 22 Feb 2023 17:49:25 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Christoph Dreis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8303078: Reduce allocations for single characters in DocPretty
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/tree/Pretty.java line 1246:
> 
>> 1244:             if (tree.paramKind == JCLambda.ParameterKind.EXPLICIT) {
>> 1245:                 printExprs(tree.params);
>> 1246:             } else {
> 
> nit, just below: `String sep = "";` -> `char sep = '\0';` also `sep = ","` -> `sep = ','`?

Done

> src/jdk.compiler/share/classes/com/sun/tools/javac/tree/Pretty.java line 1456:
> 
>> 1454:                     break;
>> 1455:                 case CHAR:
>> 1456:                     print("\'");
> 
> `print(''');` ?

Done

> src/jdk.compiler/share/classes/com/sun/tools/javac/tree/Pretty.java line 1458:
> 
>> 1456:                     print("\'");
>> 1457:                     print(Convert.quote(String.valueOf((char)((Number)tree.value).intValue())));
>> 1458:                     print("\'");
> 
> same: `print(''');` ?

Already resolved

> src/jdk.compiler/share/classes/com/sun/tools/javac/tree/Pretty.java line 1467:
> 
>> 1465:                     break;
>> 1466:                 default:
>> 1467:                     print("\"");
> 
> `print('"');`?

Done

> src/jdk.compiler/share/classes/com/sun/tools/javac/tree/Pretty.java line 1469:
> 
>> 1467:                     print("\"");
>> 1468:                     print(Convert.quote(tree.value.toString()));
>> 1469:                     print("\"");
> 
> same as above

Done

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

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

From archie.cobbs at gmail.com  Wed Feb 22 18:59:39 2023
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Wed, 22 Feb 2023 12:59:39 -0600
Subject: Case-insensitive file systems and output file clashes - survey
In-Reply-To: <c7518371-31a8-78a8-3bf7-2cb0e4394ccd@oracle.com>
References: <CANSoFxuM4X-E0Er8b4hSWwwg8asBRmSGmab9+sUQPXmuh2C70A@mail.gmail.com>
 <c7518371-31a8-78a8-3bf7-2cb0e4394ccd@oracle.com>
Message-ID: <CANSoFxuoNpo9mn9E5krdzBRmKkqidyN_nSX3R=7Tb0c6efUHng@mail.gmail.com>

On Wed, Feb 22, 2023 at 12:12 PM Jonathan Gibbons <
jonathan.gibbons at oracle.com> wrote:

> On 2/22/23 8:06 AM, Archie Cobbs wrote:
>
>
> Add a new option -Xlint:fileclash that enables checking for clashes
> (e.g., at the JavacFileSystemManager layer).
>
>
> That would likely either be a partial solution, or an expensive one for a
> complete solution when taking separate compilation into account.
>
I was thinking separate compilation would definitely not be supported (too
complicated).

Given that assumption, would it necessarily be only a partial fix?

Admittedly I haven't really checked to see whether this would work but a
simple idea would be for the compiler to maintain e.g. a Map<JavaFileObject,
ClassSymbol> , then after writing out a classfile, it adds the
corresponding entry, OR finds that one already exists and emits an error
that the two ClassSymbol's have clashing output files.

You would maintain separate mappings for classfiles, header files, and
source files.


>    1. Add new compiler flags -dzip, -szip, -hzip (corresponding to -d, -s,
>    -h) that specify ZIP files for output instead of directories
>
> I would recommend using the existing options, and just allow those options
> to specify a zip file, and then open the file with `zipfs`.   That being
> said, updating zip files by "overwriting" existing entries comes with its
> own set of problems.
>
Yep.. for efficiency you'd probably need to do some gymnastics, e.g., have
a staging directory, and then at the very end of the compilation write out
a new ZIP file using merge sort with the original (if any).
-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230222/90af75cb/attachment.htm>

From jjg at openjdk.org  Wed Feb 22 19:02:55 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 22 Feb 2023 19:02:55 GMT
Subject: RFR: 8303078: Reduce allocations when pretty printing JCTree
 during compilation [v3]
In-Reply-To: <TcoTi7SLEgFx6JxoHe-ryNnnM7t5YyJFJJbHNUIX87k=.90c28a3e-f8f2-4fbf-ba6b-b05609d74dd5@github.com>
References: <GmfIJukLO6280Z1lPW5hPwPRMN0_UGNTJ-Ec9_HstyY=.95fe1edc-5f28-483a-a150-e0575ace6912@github.com>
 <tkMC203IoUeURHz8X6pI3yjUWNBqyiSH0epw6f4Zpdk=.251439a1-6ca5-407f-b32b-73a8bd1cd206@github.com>
 <MPN11Sppx_zVRRfxAvTwFN0oOnpui4p55BVdQCg8CBE=.07b75c9f-fce4-4708-969c-bb868a16c5be@github.com>
 <TcoTi7SLEgFx6JxoHe-ryNnnM7t5YyJFJJbHNUIX87k=.90c28a3e-f8f2-4fbf-ba6b-b05609d74dd5@github.com>
Message-ID: <SmTZSIyQUpLrMI6h4xzcaCWqU__hZe0B9HZ2KW0c0Uo=.f55ab52a-8de9-4784-9454-240bb41eb923@github.com>

On Wed, 22 Feb 2023 18:12:28 GMT, Christoph Dreis <duke at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DocPretty.java line 195:
>> 
>>> 193:     public Void visitDocRoot(DocRootTree node, Void p) {
>>> 194:         try {
>>> 195:             print("{");
>> 
>> there are some instances of `print("\n");` that could be `print('\n');` few lines above this point
>
> Done - but had to change the one with the `sep` argument to take a char instead of String. Seems not used elsewhere, but wasn't sure because of the `protected`

While `DocPretty` is public, the package is not publicly exported from the `jdk.compiler` module, and there are no subtypes within the JDK code base, so I think we can ignore the `protected` for now.

If we wanted to be paranoid, it would be reasonable to change `print(char)` to something along the lines of

if (Character.isASCII(ch)) out.write(ch); else print((Character) ch);

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

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

From duke at openjdk.org  Wed Feb 22 19:02:56 2023
From: duke at openjdk.org (Christoph Dreis)
Date: Wed, 22 Feb 2023 19:02:56 GMT
Subject: RFR: 8303078: Reduce allocations when pretty printing JCTree
 during compilation [v3]
In-Reply-To: <SmTZSIyQUpLrMI6h4xzcaCWqU__hZe0B9HZ2KW0c0Uo=.f55ab52a-8de9-4784-9454-240bb41eb923@github.com>
References: <GmfIJukLO6280Z1lPW5hPwPRMN0_UGNTJ-Ec9_HstyY=.95fe1edc-5f28-483a-a150-e0575ace6912@github.com>
 <tkMC203IoUeURHz8X6pI3yjUWNBqyiSH0epw6f4Zpdk=.251439a1-6ca5-407f-b32b-73a8bd1cd206@github.com>
 <MPN11Sppx_zVRRfxAvTwFN0oOnpui4p55BVdQCg8CBE=.07b75c9f-fce4-4708-969c-bb868a16c5be@github.com>
 <TcoTi7SLEgFx6JxoHe-ryNnnM7t5YyJFJJbHNUIX87k=.90c28a3e-f8f2-4fbf-ba6b-b05609d74dd5@github.com>
 <SmTZSIyQUpLrMI6h4xzcaCWqU__hZe0B9HZ2KW0c0Uo=.f55ab52a-8de9-4784-9454-240bb41eb923@github.com>
Message-ID: <BRrK6QnzQDNmb6mSmre2-dxg2FKGjxvFRZE2SQ6wWa8=.61659f8a-b7c5-4856-a738-985ba1c08f74@github.com>

On Wed, 22 Feb 2023 18:57:47 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Done - but had to change the one with the `sep` argument to take a char instead of String. Seems not used elsewhere, but wasn't sure because of the `protected`
>
> While `DocPretty` is public, the package is not publicly exported from the `jdk.compiler` module, and there are no subtypes within the JDK code base, so I think we can ignore the `protected` for now.
> 
> If we wanted to be paranoid, it would be reasonable to change `print(char)` to something along the lines of
> 
> if (Character.isASCII(ch)) out.write(ch); else print((Character) ch);

Should we (I in that case) be paranoid, though? I would leave it as-is. There is a big class comment above that anyone depending on the internal api uses this at his own risk.

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

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

From jonathan.gibbons at oracle.com  Wed Feb 22 21:25:07 2023
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 22 Feb 2023 13:25:07 -0800
Subject: RFR: 8303078: Reduce allocations when pretty printing JCTree
 during compilation [v3]
In-Reply-To: <BRrK6QnzQDNmb6mSmre2-dxg2FKGjxvFRZE2SQ6wWa8=.61659f8a-b7c5-4856-a738-985ba1c08f74@github.com>
References: <GmfIJukLO6280Z1lPW5hPwPRMN0_UGNTJ-Ec9_HstyY=.95fe1edc-5f28-483a-a150-e0575ace6912@github.com>
 <tkMC203IoUeURHz8X6pI3yjUWNBqyiSH0epw6f4Zpdk=.251439a1-6ca5-407f-b32b-73a8bd1cd206@github.com>
 <MPN11Sppx_zVRRfxAvTwFN0oOnpui4p55BVdQCg8CBE=.07b75c9f-fce4-4708-969c-bb868a16c5be@github.com>
 <TcoTi7SLEgFx6JxoHe-ryNnnM7t5YyJFJJbHNUIX87k=.90c28a3e-f8f2-4fbf-ba6b-b05609d74dd5@github.com>
 <SmTZSIyQUpLrMI6h4xzcaCWqU__hZe0B9HZ2KW0c0Uo=.f55ab52a-8de9-4784-9454-240bb41eb923@github.com>
 <BRrK6QnzQDNmb6mSmre2-dxg2FKGjxvFRZE2SQ6wWa8=.61659f8a-b7c5-4856-a738-985ba1c08f74@github.com>
Message-ID: <4365c06a-5a3c-9f4a-c415-b09720865b90@oracle.com>

Regarding paranoia: I'll address that in the PR, I'd like to record the 
suggestion there, but probably agree with your suggestion to leave it as is.

Regarding the scary comment: the comment goes back to pre-module days, 
when more people were helping themselves to using notionally internal 
JDK API.? Now that the internals are encapsulated, the scary comment 
seems less important, and might even go away, or be replaced by a single 
notice higher up. (It's helpful to have a place we can point to that 
says, "you were warned...").? We have already removed the scary warning 
from the `jdk.javadoc` module, but that code has the added advantage of 
having `.internal.` in the name of the relevant packages.

-- Jon


On 2/22/23 11:02 AM, Christoph Dreis wrote:
> On Wed, 22 Feb 2023 18:57:47 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:
>
>>> Done - but had to change the one with the `sep` argument to take a char instead of String. Seems not used elsewhere, but wasn't sure because of the `protected`
>> While `DocPretty` is public, the package is not publicly exported from the `jdk.compiler` module, and there are no subtypes within the JDK code base, so I think we can ignore the `protected` for now.
>>
>> If we wanted to be paranoid, it would be reasonable to change `print(char)` to something along the lines of
>>
>> if (Character.isASCII(ch)) out.write(ch); else print((Character) ch);
> Should we (I in that case) be paranoid, though? I would leave it as-is. There is a big class comment above that anyone depending on the internal api uses this at his own risk.
>
> -------------
>
> PR: https://git.openjdk.org/jdk/pull/12667

From jjg at openjdk.org  Wed Feb 22 21:42:16 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 22 Feb 2023 21:42:16 GMT
Subject: RFR: 8303078: Reduce allocations when pretty printing JCTree
 during compilation [v3]
In-Reply-To: <tkMC203IoUeURHz8X6pI3yjUWNBqyiSH0epw6f4Zpdk=.251439a1-6ca5-407f-b32b-73a8bd1cd206@github.com>
References: <GmfIJukLO6280Z1lPW5hPwPRMN0_UGNTJ-Ec9_HstyY=.95fe1edc-5f28-483a-a150-e0575ace6912@github.com>
 <tkMC203IoUeURHz8X6pI3yjUWNBqyiSH0epw6f4Zpdk=.251439a1-6ca5-407f-b32b-73a8bd1cd206@github.com>
Message-ID: <88IiQj4vN-3MA_S1xZ4ZELny6I1tE9Y5zkU4fFaCYZc=.e42570a9-c440-4b6e-bc00-67b4793e290b@github.com>

On Wed, 22 Feb 2023 18:22:11 GMT, Christoph Dreis <duke at openjdk.org> wrote:

>> Hi,
>> 
>> I've been recently optimizing a few project pipelines and always noticed that their compilation step is somewhat "expensive".  Zooming into the issue always revealed Lombok to be a larger contributor. Unfortunately, I can't get rid of Lombok in this customer project (before you ask).
>> 
>> Apparently, Lombok is printing the respective `JCTree` here and there to check for type matches. I can't imagine this to be super efficient, but that's how it is at the moment.
>> <img width="948" alt="image" src="https://user-images.githubusercontent.com/6304496/220134737-bd9b508c-a908-448b-b0d1-e960db28b24a.png">
>> 
>> Anyhow, regardless of the Lombok inefficiencies I think there are some optimization opportunities in the JDK itself. 
>> 
>> 1. Overall, `Pretty.visitSelect` accounts for 8-10% of the total allocations in this project. And among those there are StringBuilder allocations coming from the following:
>> 
>> 
>>     public void visitSelect(JCFieldAccess tree) {
>>         try {
>>             printExpr(tree.selected, TreeInfo.postfixPrec);
>>             // StringBuilder allocations hiding in here.
>>             print("." + tree.name);
>>         } catch (IOException e) {
>>             throw new UncheckedIOException(e);
>>         }
>>     }
>> 
>> 
>> This PR splits the `print` calls into two separate ones to avoid this String concatenation.
>> 
>> ...
>>             printExpr(tree.selected, TreeInfo.postfixPrec);
>>             print('.');
>>             print(tree.name);
>> ...
>> 
>> 
>> Secondly, the `print` method takes an `Object` which seems like a good fit for another (private?) variant of it that only takes a `char`. By this we would probably avoid any eventual boxing and avoid any conversion with `Convert.escapeUnicode(s.toString())` that seems superfluous for chars like `.`, ` `, or any braces like `(`, `{` etc. 
>> 
>> This is currently a draft PR as long as the scope is not clarified. It currently only includes the necessary changes that would optimize the particular use-case. But there are more cases where e.g. the new `char` variant could be used and/or any String concatenation could be split into separate `print` calls.
>> 
>> Let me know what you think and if I should include the other cases as well. If you think this is worthwhile, I'd appreciate if this is is sponsored. (Including creating an issue as I can't do this myself apparently. I will of course squash everything together with the proper issue ID once available.)
>> 
>> I've contributed before, so the CLA should be signed.
>> 
>> Cheers,
>> Christoph
>
> Christoph Dreis has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8303078: Replace some more character print calls
>  - 8303078: Replace some more character print calls

src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DocPretty.java line 82:

> 80:      */
> 81:     private void print(char c) throws IOException {
> 82:         out.write(c);

The restriction to skip calling `Convert.escapeUnicode(s.toString())` leaks into `print(List, char sep)`.

If we wanted to be paranoid we could do one or more of the following;

1. Change the body of this method to something like<br> `if (Character.isASCII(c)) out.write(c); else print((Character) c);`
2. include an `assert` or call to a method in `Assert.*` to verify the argument is ASCII.
3. change that `protected void print(List, char)` method to be `private` instead of `protected`

I guess I'd not bother with 1 or 2, but maybe go with 3, since it has no effect on performance, and better restricts the functionality to just this class.   I note there are no discernable external usages of this method.

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

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

From duke at openjdk.org  Wed Feb 22 21:42:16 2023
From: duke at openjdk.org (Christoph Dreis)
Date: Wed, 22 Feb 2023 21:42:16 GMT
Subject: RFR: 8303078: Reduce allocations when pretty printing JCTree
 during compilation [v3]
In-Reply-To: <88IiQj4vN-3MA_S1xZ4ZELny6I1tE9Y5zkU4fFaCYZc=.e42570a9-c440-4b6e-bc00-67b4793e290b@github.com>
References: <GmfIJukLO6280Z1lPW5hPwPRMN0_UGNTJ-Ec9_HstyY=.95fe1edc-5f28-483a-a150-e0575ace6912@github.com>
 <tkMC203IoUeURHz8X6pI3yjUWNBqyiSH0epw6f4Zpdk=.251439a1-6ca5-407f-b32b-73a8bd1cd206@github.com>
 <88IiQj4vN-3MA_S1xZ4ZELny6I1tE9Y5zkU4fFaCYZc=.e42570a9-c440-4b6e-bc00-67b4793e290b@github.com>
Message-ID: <7_O7ShFolzYmXrtH-ytMVRwO_IWHx-w3z7VlvUnoxZs=.ae8c3c38-43a2-4ace-978a-ae337a205639@github.com>

On Wed, 22 Feb 2023 21:37:02 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Christoph Dreis has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - 8303078: Replace some more character print calls
>>  - 8303078: Replace some more character print calls
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DocPretty.java line 82:
> 
>> 80:      */
>> 81:     private void print(char c) throws IOException {
>> 82:         out.write(c);
> 
> The restriction to skip calling `Convert.escapeUnicode(s.toString())` leaks into `print(List, char sep)`.
> 
> If we wanted to be paranoid we could do one or more of the following;
> 
> 1. Change the body of this method to something like<br> `if (Character.isASCII(c)) out.write(c); else print((Character) c);`
> 2. include an `assert` or call to a method in `Assert.*` to verify the argument is ASCII.
> 3. change that `protected void print(List, char)` method to be `private` instead of `protected`
> 
> I guess I'd not bother with 1 or 2, but maybe go with 3, since it has no effect on performance, and better restricts the functionality to just this class.   I note there are no discernable external usages of this method.

Already asked above: should we really be paranoid here? There is a big class comment above that anyone depending on the internal api uses this at his own risk...
But if I should change anything I'd rather make the method `private`

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

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

From jjg at openjdk.org  Wed Feb 22 22:02:14 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 22 Feb 2023 22:02:14 GMT
Subject: RFR: 8303078: Reduce allocations when pretty printing JCTree
 during compilation [v3]
In-Reply-To: <tkMC203IoUeURHz8X6pI3yjUWNBqyiSH0epw6f4Zpdk=.251439a1-6ca5-407f-b32b-73a8bd1cd206@github.com>
References: <GmfIJukLO6280Z1lPW5hPwPRMN0_UGNTJ-Ec9_HstyY=.95fe1edc-5f28-483a-a150-e0575ace6912@github.com>
 <tkMC203IoUeURHz8X6pI3yjUWNBqyiSH0epw6f4Zpdk=.251439a1-6ca5-407f-b32b-73a8bd1cd206@github.com>
Message-ID: <Vrv0g4qgsOgfNc9gnHfYlmqLCEfYZguuUjz6LuwE8PQ=.33721bab-523b-4e0d-9bce-04e4920e2831@github.com>

On Wed, 22 Feb 2023 18:22:11 GMT, Christoph Dreis <duke at openjdk.org> wrote:

>> Hi,
>> 
>> I've been recently optimizing a few project pipelines and always noticed that their compilation step is somewhat "expensive".  Zooming into the issue always revealed Lombok to be a larger contributor. Unfortunately, I can't get rid of Lombok in this customer project (before you ask).
>> 
>> Apparently, Lombok is printing the respective `JCTree` here and there to check for type matches. I can't imagine this to be super efficient, but that's how it is at the moment.
>> <img width="948" alt="image" src="https://user-images.githubusercontent.com/6304496/220134737-bd9b508c-a908-448b-b0d1-e960db28b24a.png">
>> 
>> Anyhow, regardless of the Lombok inefficiencies I think there are some optimization opportunities in the JDK itself. 
>> 
>> 1. Overall, `Pretty.visitSelect` accounts for 8-10% of the total allocations in this project. And among those there are StringBuilder allocations coming from the following:
>> 
>> 
>>     public void visitSelect(JCFieldAccess tree) {
>>         try {
>>             printExpr(tree.selected, TreeInfo.postfixPrec);
>>             // StringBuilder allocations hiding in here.
>>             print("." + tree.name);
>>         } catch (IOException e) {
>>             throw new UncheckedIOException(e);
>>         }
>>     }
>> 
>> 
>> This PR splits the `print` calls into two separate ones to avoid this String concatenation.
>> 
>> ...
>>             printExpr(tree.selected, TreeInfo.postfixPrec);
>>             print('.');
>>             print(tree.name);
>> ...
>> 
>> 
>> Secondly, the `print` method takes an `Object` which seems like a good fit for another (private?) variant of it that only takes a `char`. By this we would probably avoid any eventual boxing and avoid any conversion with `Convert.escapeUnicode(s.toString())` that seems superfluous for chars like `.`, ` `, or any braces like `(`, `{` etc. 
>> 
>> This is currently a draft PR as long as the scope is not clarified. It currently only includes the necessary changes that would optimize the particular use-case. But there are more cases where e.g. the new `char` variant could be used and/or any String concatenation could be split into separate `print` calls.
>> 
>> Let me know what you think and if I should include the other cases as well. If you think this is worthwhile, I'd appreciate if this is is sponsored. (Including creating an issue as I can't do this myself apparently. I will of course squash everything together with the proper issue ID once available.)
>> 
>> I've contributed before, so the CLA should be signed.
>> 
>> Cheers,
>> Christoph
>
> Christoph Dreis has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8303078: Replace some more character print calls
>  - 8303078: Replace some more character print calls

src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DocPretty.java line 97:

> 95:      * Print list with separators.
> 96:      */
> 97:     protected void print(List<? extends DocTree> list, char sep) throws IOException {

See comment above, suggesting that we reduce access to `private`.

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

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

From duke at openjdk.org  Wed Feb 22 22:14:45 2023
From: duke at openjdk.org (Christoph Dreis)
Date: Wed, 22 Feb 2023 22:14:45 GMT
Subject: RFR: 8303078: Reduce allocations when pretty printing JCTree
 during compilation [v4]
In-Reply-To: <GmfIJukLO6280Z1lPW5hPwPRMN0_UGNTJ-Ec9_HstyY=.95fe1edc-5f28-483a-a150-e0575ace6912@github.com>
References: <GmfIJukLO6280Z1lPW5hPwPRMN0_UGNTJ-Ec9_HstyY=.95fe1edc-5f28-483a-a150-e0575ace6912@github.com>
Message-ID: <buqpRT9A8n89CqaHyweqN8WIiGTZnRwaF2Ecke01J2U=.95b332de-60dd-44ec-8020-bc7ec0888c5e@github.com>

> Hi,
> 
> I've been recently optimizing a few project pipelines and always noticed that their compilation step is somewhat "expensive".  Zooming into the issue always revealed Lombok to be a larger contributor. Unfortunately, I can't get rid of Lombok in this customer project (before you ask).
> 
> Apparently, Lombok is printing the respective `JCTree` here and there to check for type matches. I can't imagine this to be super efficient, but that's how it is at the moment.
> <img width="948" alt="image" src="https://user-images.githubusercontent.com/6304496/220134737-bd9b508c-a908-448b-b0d1-e960db28b24a.png">
> 
> Anyhow, regardless of the Lombok inefficiencies I think there are some optimization opportunities in the JDK itself. 
> 
> 1. Overall, `Pretty.visitSelect` accounts for 8-10% of the total allocations in this project. And among those there are StringBuilder allocations coming from the following:
> 
> 
>     public void visitSelect(JCFieldAccess tree) {
>         try {
>             printExpr(tree.selected, TreeInfo.postfixPrec);
>             // StringBuilder allocations hiding in here.
>             print("." + tree.name);
>         } catch (IOException e) {
>             throw new UncheckedIOException(e);
>         }
>     }
> 
> 
> This PR splits the `print` calls into two separate ones to avoid this String concatenation.
> 
> ...
>             printExpr(tree.selected, TreeInfo.postfixPrec);
>             print('.');
>             print(tree.name);
> ...
> 
> 
> Secondly, the `print` method takes an `Object` which seems like a good fit for another (private?) variant of it that only takes a `char`. By this we would probably avoid any eventual boxing and avoid any conversion with `Convert.escapeUnicode(s.toString())` that seems superfluous for chars like `.`, ` `, or any braces like `(`, `{` etc. 
> 
> This is currently a draft PR as long as the scope is not clarified. It currently only includes the necessary changes that would optimize the particular use-case. But there are more cases where e.g. the new `char` variant could be used and/or any String concatenation could be split into separate `print` calls.
> 
> Let me know what you think and if I should include the other cases as well. If you think this is worthwhile, I'd appreciate if this is is sponsored. (Including creating an issue as I can't do this myself apparently. I will of course squash everything together with the proper issue ID once available.)
> 
> I've contributed before, so the CLA should be signed.
> 
> Cheers,
> Christoph

Christoph Dreis has updated the pull request incrementally with one additional commit since the last revision:

  8303078: Make method private

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12667/files
  - new: https://git.openjdk.org/jdk/pull/12667/files/34f9c330..489e3fe0

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

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

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

From duke at openjdk.org  Wed Feb 22 22:15:27 2023
From: duke at openjdk.org (Christoph Dreis)
Date: Wed, 22 Feb 2023 22:15:27 GMT
Subject: RFR: 8303078: Reduce allocations when pretty printing JCTree
 during compilation [v3]
In-Reply-To: <tkMC203IoUeURHz8X6pI3yjUWNBqyiSH0epw6f4Zpdk=.251439a1-6ca5-407f-b32b-73a8bd1cd206@github.com>
References: <GmfIJukLO6280Z1lPW5hPwPRMN0_UGNTJ-Ec9_HstyY=.95fe1edc-5f28-483a-a150-e0575ace6912@github.com>
 <tkMC203IoUeURHz8X6pI3yjUWNBqyiSH0epw6f4Zpdk=.251439a1-6ca5-407f-b32b-73a8bd1cd206@github.com>
Message-ID: <hL6Txjo4mYMuWQ639ss3NYWpd5kcx2YDY-4ZRkacUyQ=.c52ab7a8-7341-4ae2-967f-793966dd6bcc@github.com>

On Wed, 22 Feb 2023 18:22:11 GMT, Christoph Dreis <duke at openjdk.org> wrote:

>> Hi,
>> 
>> I've been recently optimizing a few project pipelines and always noticed that their compilation step is somewhat "expensive".  Zooming into the issue always revealed Lombok to be a larger contributor. Unfortunately, I can't get rid of Lombok in this customer project (before you ask).
>> 
>> Apparently, Lombok is printing the respective `JCTree` here and there to check for type matches. I can't imagine this to be super efficient, but that's how it is at the moment.
>> <img width="948" alt="image" src="https://user-images.githubusercontent.com/6304496/220134737-bd9b508c-a908-448b-b0d1-e960db28b24a.png">
>> 
>> Anyhow, regardless of the Lombok inefficiencies I think there are some optimization opportunities in the JDK itself. 
>> 
>> 1. Overall, `Pretty.visitSelect` accounts for 8-10% of the total allocations in this project. And among those there are StringBuilder allocations coming from the following:
>> 
>> 
>>     public void visitSelect(JCFieldAccess tree) {
>>         try {
>>             printExpr(tree.selected, TreeInfo.postfixPrec);
>>             // StringBuilder allocations hiding in here.
>>             print("." + tree.name);
>>         } catch (IOException e) {
>>             throw new UncheckedIOException(e);
>>         }
>>     }
>> 
>> 
>> This PR splits the `print` calls into two separate ones to avoid this String concatenation.
>> 
>> ...
>>             printExpr(tree.selected, TreeInfo.postfixPrec);
>>             print('.');
>>             print(tree.name);
>> ...
>> 
>> 
>> Secondly, the `print` method takes an `Object` which seems like a good fit for another (private?) variant of it that only takes a `char`. By this we would probably avoid any eventual boxing and avoid any conversion with `Convert.escapeUnicode(s.toString())` that seems superfluous for chars like `.`, ` `, or any braces like `(`, `{` etc. 
>> 
>> This is currently a draft PR as long as the scope is not clarified. It currently only includes the necessary changes that would optimize the particular use-case. But there are more cases where e.g. the new `char` variant could be used and/or any String concatenation could be split into separate `print` calls.
>> 
>> Let me know what you think and if I should include the other cases as well. If you think this is worthwhile, I'd appreciate if this is is sponsored. (Including creating an issue as I can't do this myself apparently. I will of course squash everything together with the proper issue ID once available.)
>> 
>> I've contributed before, so the CLA should be signed.
>> 
>> Cheers,
>> Christoph
>
> Christoph Dreis has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8303078: Replace some more character print calls
>  - 8303078: Replace some more character print calls

There are some test failures in langtools/tier1 that seem related. Will check

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

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

From jjg at openjdk.org  Wed Feb 22 22:16:11 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 22 Feb 2023 22:16:11 GMT
Subject: RFR: 8303078: Reduce allocations when pretty printing JCTree
 during compilation [v3]
In-Reply-To: <7_O7ShFolzYmXrtH-ytMVRwO_IWHx-w3z7VlvUnoxZs=.ae8c3c38-43a2-4ace-978a-ae337a205639@github.com>
References: <GmfIJukLO6280Z1lPW5hPwPRMN0_UGNTJ-Ec9_HstyY=.95fe1edc-5f28-483a-a150-e0575ace6912@github.com>
 <tkMC203IoUeURHz8X6pI3yjUWNBqyiSH0epw6f4Zpdk=.251439a1-6ca5-407f-b32b-73a8bd1cd206@github.com>
 <88IiQj4vN-3MA_S1xZ4ZELny6I1tE9Y5zkU4fFaCYZc=.e42570a9-c440-4b6e-bc00-67b4793e290b@github.com>
 <7_O7ShFolzYmXrtH-ytMVRwO_IWHx-w3z7VlvUnoxZs=.ae8c3c38-43a2-4ace-978a-ae337a205639@github.com>
Message-ID: <OWsgF24T3DJPjppmANai_JdGazUknZ1ZjJOLJLwZo5k=.b8e214c3-1526-4f03-adc1-b0b0790262a1@github.com>

On Wed, 22 Feb 2023 21:39:32 GMT, Christoph Dreis <duke at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DocPretty.java line 82:
>> 
>>> 80:      */
>>> 81:     private void print(char c) throws IOException {
>>> 82:         out.write(c);
>> 
>> The restriction to skip calling `Convert.escapeUnicode(s.toString())` leaks into `print(List, char sep)`.
>> 
>> If we wanted to be paranoid we could do one or more of the following;
>> 
>> 1. Change the body of this method to something like<br> `if (Character.isASCII(c)) out.write(c); else print((Character) c);`
>> 2. include an `assert` or call to a method in `Assert.*` to verify the argument is ASCII.
>> 3. change that `protected void print(List, char)` method to be `private` instead of `protected`
>> 
>> I guess I'd not bother with 1 or 2, but maybe go with 3, since it has no effect on performance, and better restricts the functionality to just this class.   I note there are no discernable external usages of this method.
>
> Already asked above: should we really be paranoid here? There is a big class comment above that anyone depending on the internal api uses this at his own risk...
> But if I should change anything I'd rather make the method `private`

_(Sorry for the duplicate entry)_

I think making the method `private` is good enough, and doing it in the same changeset that changes the signature is even better for future code historians.

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

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

From duke at openjdk.org  Wed Feb 22 22:16:48 2023
From: duke at openjdk.org (Christoph Dreis)
Date: Wed, 22 Feb 2023 22:16:48 GMT
Subject: RFR: 8303078: Reduce allocations when pretty printing JCTree
 during compilation [v3]
In-Reply-To: <Vrv0g4qgsOgfNc9gnHfYlmqLCEfYZguuUjz6LuwE8PQ=.33721bab-523b-4e0d-9bce-04e4920e2831@github.com>
References: <GmfIJukLO6280Z1lPW5hPwPRMN0_UGNTJ-Ec9_HstyY=.95fe1edc-5f28-483a-a150-e0575ace6912@github.com>
 <tkMC203IoUeURHz8X6pI3yjUWNBqyiSH0epw6f4Zpdk=.251439a1-6ca5-407f-b32b-73a8bd1cd206@github.com>
 <Vrv0g4qgsOgfNc9gnHfYlmqLCEfYZguuUjz6LuwE8PQ=.33721bab-523b-4e0d-9bce-04e4920e2831@github.com>
Message-ID: <X2zTXiLE1TDPJOOCTHyCNRzRyHTcWZf0JlzlbOw-u5M=.491a184a-888d-41db-9f9c-fe0b7bebc804@github.com>

On Wed, 22 Feb 2023 21:59:12 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Christoph Dreis has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - 8303078: Replace some more character print calls
>>  - 8303078: Replace some more character print calls
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DocPretty.java line 97:
> 
>> 95:      * Print list with separators.
>> 96:      */
>> 97:     protected void print(List<? extends DocTree> list, char sep) throws IOException {
> 
> See comment above, suggesting that we reduce access to `private`.

Done

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

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

From duke at openjdk.org  Thu Feb 23 00:05:22 2023
From: duke at openjdk.org (Christoph Dreis)
Date: Thu, 23 Feb 2023 00:05:22 GMT
Subject: RFR: 8303078: Reduce allocations when pretty printing JCTree
 during compilation [v5]
In-Reply-To: <GmfIJukLO6280Z1lPW5hPwPRMN0_UGNTJ-Ec9_HstyY=.95fe1edc-5f28-483a-a150-e0575ace6912@github.com>
References: <GmfIJukLO6280Z1lPW5hPwPRMN0_UGNTJ-Ec9_HstyY=.95fe1edc-5f28-483a-a150-e0575ace6912@github.com>
Message-ID: <TRouvUJBy1Zmz47tf4I8zr8dOxZiBAQf7YwcaAaYwSk=.a6e542bc-03a3-4c60-97ac-9d665bf1cd62@github.com>

> Hi,
> 
> I've been recently optimizing a few project pipelines and always noticed that their compilation step is somewhat "expensive".  Zooming into the issue always revealed Lombok to be a larger contributor. Unfortunately, I can't get rid of Lombok in this customer project (before you ask).
> 
> Apparently, Lombok is printing the respective `JCTree` here and there to check for type matches. I can't imagine this to be super efficient, but that's how it is at the moment.
> <img width="948" alt="image" src="https://user-images.githubusercontent.com/6304496/220134737-bd9b508c-a908-448b-b0d1-e960db28b24a.png">
> 
> Anyhow, regardless of the Lombok inefficiencies I think there are some optimization opportunities in the JDK itself. 
> 
> 1. Overall, `Pretty.visitSelect` accounts for 8-10% of the total allocations in this project. And among those there are StringBuilder allocations coming from the following:
> 
> 
>     public void visitSelect(JCFieldAccess tree) {
>         try {
>             printExpr(tree.selected, TreeInfo.postfixPrec);
>             // StringBuilder allocations hiding in here.
>             print("." + tree.name);
>         } catch (IOException e) {
>             throw new UncheckedIOException(e);
>         }
>     }
> 
> 
> This PR splits the `print` calls into two separate ones to avoid this String concatenation.
> 
> ...
>             printExpr(tree.selected, TreeInfo.postfixPrec);
>             print('.');
>             print(tree.name);
> ...
> 
> 
> Secondly, the `print` method takes an `Object` which seems like a good fit for another (private?) variant of it that only takes a `char`. By this we would probably avoid any eventual boxing and avoid any conversion with `Convert.escapeUnicode(s.toString())` that seems superfluous for chars like `.`, ` `, or any braces like `(`, `{` etc. 
> 
> This is currently a draft PR as long as the scope is not clarified. It currently only includes the necessary changes that would optimize the particular use-case. But there are more cases where e.g. the new `char` variant could be used and/or any String concatenation could be split into separate `print` calls.
> 
> Let me know what you think and if I should include the other cases as well. If you think this is worthwhile, I'd appreciate if this is is sponsored. (Including creating an issue as I can't do this myself apparently. I will of course squash everything together with the proper issue ID once available.)
> 
> I've contributed before, so the CLA should be signed.
> 
> Cheers,
> Christoph

Christoph Dreis has updated the pull request incrementally with one additional commit since the last revision:

  8303078: Fix Pretty.visitLambda

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12667/files
  - new: https://git.openjdk.org/jdk/pull/12667/files/489e3fe0..03e98938

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

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

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

From jjg at openjdk.org  Thu Feb 23 01:24:31 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 23 Feb 2023 01:24:31 GMT
Subject: RFR: 8303078: Reduce allocations when pretty printing JCTree
 during compilation [v5]
In-Reply-To: <TRouvUJBy1Zmz47tf4I8zr8dOxZiBAQf7YwcaAaYwSk=.a6e542bc-03a3-4c60-97ac-9d665bf1cd62@github.com>
References: <GmfIJukLO6280Z1lPW5hPwPRMN0_UGNTJ-Ec9_HstyY=.95fe1edc-5f28-483a-a150-e0575ace6912@github.com>
 <TRouvUJBy1Zmz47tf4I8zr8dOxZiBAQf7YwcaAaYwSk=.a6e542bc-03a3-4c60-97ac-9d665bf1cd62@github.com>
Message-ID: <dCjiUtMeQEWHrggunqsammh0SPZvrrzhEP6UfX3geTU=.19cd9b6e-37a3-4d8f-9174-0a3308dee8a8@github.com>

On Thu, 23 Feb 2023 00:05:22 GMT, Christoph Dreis <duke at openjdk.org> wrote:

>> Hi,
>> 
>> I've been recently optimizing a few project pipelines and always noticed that their compilation step is somewhat "expensive".  Zooming into the issue always revealed Lombok to be a larger contributor. Unfortunately, I can't get rid of Lombok in this customer project (before you ask).
>> 
>> Apparently, Lombok is printing the respective `JCTree` here and there to check for type matches. I can't imagine this to be super efficient, but that's how it is at the moment.
>> <img width="948" alt="image" src="https://user-images.githubusercontent.com/6304496/220134737-bd9b508c-a908-448b-b0d1-e960db28b24a.png">
>> 
>> Anyhow, regardless of the Lombok inefficiencies I think there are some optimization opportunities in the JDK itself. 
>> 
>> 1. Overall, `Pretty.visitSelect` accounts for 8-10% of the total allocations in this project. And among those there are StringBuilder allocations coming from the following:
>> 
>> 
>>     public void visitSelect(JCFieldAccess tree) {
>>         try {
>>             printExpr(tree.selected, TreeInfo.postfixPrec);
>>             // StringBuilder allocations hiding in here.
>>             print("." + tree.name);
>>         } catch (IOException e) {
>>             throw new UncheckedIOException(e);
>>         }
>>     }
>> 
>> 
>> This PR splits the `print` calls into two separate ones to avoid this String concatenation.
>> 
>> ...
>>             printExpr(tree.selected, TreeInfo.postfixPrec);
>>             print('.');
>>             print(tree.name);
>> ...
>> 
>> 
>> Secondly, the `print` method takes an `Object` which seems like a good fit for another (private?) variant of it that only takes a `char`. By this we would probably avoid any eventual boxing and avoid any conversion with `Convert.escapeUnicode(s.toString())` that seems superfluous for chars like `.`, ` `, or any braces like `(`, `{` etc. 
>> 
>> This is currently a draft PR as long as the scope is not clarified. It currently only includes the necessary changes that would optimize the particular use-case. But there are more cases where e.g. the new `char` variant could be used and/or any String concatenation could be split into separate `print` calls.
>> 
>> Let me know what you think and if I should include the other cases as well. If you think this is worthwhile, I'd appreciate if this is is sponsored. (Including creating an issue as I can't do this myself apparently. I will of course squash everything together with the proper issue ID once available.)
>> 
>> I've contributed before, so the CLA should be signed.
>> 
>> Cheers,
>> Christoph
>
> Christoph Dreis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8303078: Fix Pretty.visitLambda

I confirm that all the langtools tests now pass, at least on my local laptop.

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

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

From jjg at openjdk.org  Thu Feb 23 01:37:13 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 23 Feb 2023 01:37:13 GMT
Subject: RFR: 8303078: Reduce allocations when pretty printing JCTree
 during compilation [v5]
In-Reply-To: <TRouvUJBy1Zmz47tf4I8zr8dOxZiBAQf7YwcaAaYwSk=.a6e542bc-03a3-4c60-97ac-9d665bf1cd62@github.com>
References: <GmfIJukLO6280Z1lPW5hPwPRMN0_UGNTJ-Ec9_HstyY=.95fe1edc-5f28-483a-a150-e0575ace6912@github.com>
 <TRouvUJBy1Zmz47tf4I8zr8dOxZiBAQf7YwcaAaYwSk=.a6e542bc-03a3-4c60-97ac-9d665bf1cd62@github.com>
Message-ID: <iJgnODsGm1UPzFCl9cOW218eA0c5tFm82BaJxBPHyIw=.fef5e362-4e5b-4412-8d2f-4598a299d4b3@github.com>

On Thu, 23 Feb 2023 00:05:22 GMT, Christoph Dreis <duke at openjdk.org> wrote:

>> Hi,
>> 
>> I've been recently optimizing a few project pipelines and always noticed that their compilation step is somewhat "expensive".  Zooming into the issue always revealed Lombok to be a larger contributor. Unfortunately, I can't get rid of Lombok in this customer project (before you ask).
>> 
>> Apparently, Lombok is printing the respective `JCTree` here and there to check for type matches. I can't imagine this to be super efficient, but that's how it is at the moment.
>> <img width="948" alt="image" src="https://user-images.githubusercontent.com/6304496/220134737-bd9b508c-a908-448b-b0d1-e960db28b24a.png">
>> 
>> Anyhow, regardless of the Lombok inefficiencies I think there are some optimization opportunities in the JDK itself. 
>> 
>> 1. Overall, `Pretty.visitSelect` accounts for 8-10% of the total allocations in this project. And among those there are StringBuilder allocations coming from the following:
>> 
>> 
>>     public void visitSelect(JCFieldAccess tree) {
>>         try {
>>             printExpr(tree.selected, TreeInfo.postfixPrec);
>>             // StringBuilder allocations hiding in here.
>>             print("." + tree.name);
>>         } catch (IOException e) {
>>             throw new UncheckedIOException(e);
>>         }
>>     }
>> 
>> 
>> This PR splits the `print` calls into two separate ones to avoid this String concatenation.
>> 
>> ...
>>             printExpr(tree.selected, TreeInfo.postfixPrec);
>>             print('.');
>>             print(tree.name);
>> ...
>> 
>> 
>> Secondly, the `print` method takes an `Object` which seems like a good fit for another (private?) variant of it that only takes a `char`. By this we would probably avoid any eventual boxing and avoid any conversion with `Convert.escapeUnicode(s.toString())` that seems superfluous for chars like `.`, ` `, or any braces like `(`, `{` etc. 
>> 
>> This is currently a draft PR as long as the scope is not clarified. It currently only includes the necessary changes that would optimize the particular use-case. But there are more cases where e.g. the new `char` variant could be used and/or any String concatenation could be split into separate `print` calls.
>> 
>> Let me know what you think and if I should include the other cases as well. If you think this is worthwhile, I'd appreciate if this is is sponsored. (Including creating an issue as I can't do this myself apparently. I will of course squash everything together with the proper issue ID once available.)
>> 
>> I've contributed before, so the CLA should be signed.
>> 
>> Cheers,
>> Christoph
>
> Christoph Dreis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8303078: Fix Pretty.visitLambda

Thanks for updating `DocPretty.java` to follow the same conventions as `Pretty.java`, even though it was probably not required for your Lombok-based use-case.

I've gone through all the latest patch, and run all the langtools tests as well. All pass on my laptop, and there is no reason to expect any cross-platform issues.

I'll mark it Approved, but while not strictly necessary, I recommend that you wait for Vicente's approval as well, in case he has any final comments.

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

Marked as reviewed by jjg (Reviewer).

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

From vromero at openjdk.org  Thu Feb 23 03:16:08 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 23 Feb 2023 03:16:08 GMT
Subject: RFR: 8303078: Reduce allocations when pretty printing JCTree
 during compilation [v5]
In-Reply-To: <TRouvUJBy1Zmz47tf4I8zr8dOxZiBAQf7YwcaAaYwSk=.a6e542bc-03a3-4c60-97ac-9d665bf1cd62@github.com>
References: <GmfIJukLO6280Z1lPW5hPwPRMN0_UGNTJ-Ec9_HstyY=.95fe1edc-5f28-483a-a150-e0575ace6912@github.com>
 <TRouvUJBy1Zmz47tf4I8zr8dOxZiBAQf7YwcaAaYwSk=.a6e542bc-03a3-4c60-97ac-9d665bf1cd62@github.com>
Message-ID: <WraP5doLI7-xtRkBD7kPfaeuUW5FPheRDRPyzhrWYwQ=.e77fe6ef-a5e9-402b-9563-942314237e7c@github.com>

On Thu, 23 Feb 2023 00:05:22 GMT, Christoph Dreis <duke at openjdk.org> wrote:

>> Hi,
>> 
>> I've been recently optimizing a few project pipelines and always noticed that their compilation step is somewhat "expensive".  Zooming into the issue always revealed Lombok to be a larger contributor. Unfortunately, I can't get rid of Lombok in this customer project (before you ask).
>> 
>> Apparently, Lombok is printing the respective `JCTree` here and there to check for type matches. I can't imagine this to be super efficient, but that's how it is at the moment.
>> <img width="948" alt="image" src="https://user-images.githubusercontent.com/6304496/220134737-bd9b508c-a908-448b-b0d1-e960db28b24a.png">
>> 
>> Anyhow, regardless of the Lombok inefficiencies I think there are some optimization opportunities in the JDK itself. 
>> 
>> 1. Overall, `Pretty.visitSelect` accounts for 8-10% of the total allocations in this project. And among those there are StringBuilder allocations coming from the following:
>> 
>> 
>>     public void visitSelect(JCFieldAccess tree) {
>>         try {
>>             printExpr(tree.selected, TreeInfo.postfixPrec);
>>             // StringBuilder allocations hiding in here.
>>             print("." + tree.name);
>>         } catch (IOException e) {
>>             throw new UncheckedIOException(e);
>>         }
>>     }
>> 
>> 
>> This PR splits the `print` calls into two separate ones to avoid this String concatenation.
>> 
>> ...
>>             printExpr(tree.selected, TreeInfo.postfixPrec);
>>             print('.');
>>             print(tree.name);
>> ...
>> 
>> 
>> Secondly, the `print` method takes an `Object` which seems like a good fit for another (private?) variant of it that only takes a `char`. By this we would probably avoid any eventual boxing and avoid any conversion with `Convert.escapeUnicode(s.toString())` that seems superfluous for chars like `.`, ` `, or any braces like `(`, `{` etc. 
>> 
>> This is currently a draft PR as long as the scope is not clarified. It currently only includes the necessary changes that would optimize the particular use-case. But there are more cases where e.g. the new `char` variant could be used and/or any String concatenation could be split into separate `print` calls.
>> 
>> Let me know what you think and if I should include the other cases as well. If you think this is worthwhile, I'd appreciate if this is is sponsored. (Including creating an issue as I can't do this myself apparently. I will of course squash everything together with the proper issue ID once available.)
>> 
>> I've contributed before, so the CLA should be signed.
>> 
>> Cheers,
>> Christoph
>
> Christoph Dreis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8303078: Fix Pretty.visitLambda

nit please consider including this minor change:


diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/tree/Pretty.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/tree/Pretty.java
index f87d5c05a74..dd05d4ac9d1 100644
--- a/src/jdk.compiler/share/classes/com/sun/tools/javac/tree/Pretty.java
+++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/tree/Pretty.java
@@ -1244,11 +1244,11 @@ public class Pretty extends JCTree.Visitor {
             if (tree.paramKind == JCLambda.ParameterKind.EXPLICIT) {
                 printExprs(tree.params);
             } else {
-                String sep = "";
+                char sep = '\0';
                 for (JCVariableDecl param : tree.params) {
                     print(sep);
                     print(param.name);
-                    sep = ",";
+                    sep = ',';
                 }
             }
             print(")->");


thanks!

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

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

From vromero at openjdk.org  Thu Feb 23 03:31:08 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 23 Feb 2023 03:31:08 GMT
Subject: RFR: 8303078: Reduce allocations when pretty printing JCTree
 during compilation [v5]
In-Reply-To: <TRouvUJBy1Zmz47tf4I8zr8dOxZiBAQf7YwcaAaYwSk=.a6e542bc-03a3-4c60-97ac-9d665bf1cd62@github.com>
References: <GmfIJukLO6280Z1lPW5hPwPRMN0_UGNTJ-Ec9_HstyY=.95fe1edc-5f28-483a-a150-e0575ace6912@github.com>
 <TRouvUJBy1Zmz47tf4I8zr8dOxZiBAQf7YwcaAaYwSk=.a6e542bc-03a3-4c60-97ac-9d665bf1cd62@github.com>
Message-ID: <Pp_gd6CTeaKCfNAkPDchIvzPGPt60jMjq5xGyxLS3oc=.cb15c54b-b151-4cec-98f5-c268b8e6eced@github.com>

On Thu, 23 Feb 2023 00:05:22 GMT, Christoph Dreis <duke at openjdk.org> wrote:

>> Hi,
>> 
>> I've been recently optimizing a few project pipelines and always noticed that their compilation step is somewhat "expensive".  Zooming into the issue always revealed Lombok to be a larger contributor. Unfortunately, I can't get rid of Lombok in this customer project (before you ask).
>> 
>> Apparently, Lombok is printing the respective `JCTree` here and there to check for type matches. I can't imagine this to be super efficient, but that's how it is at the moment.
>> <img width="948" alt="image" src="https://user-images.githubusercontent.com/6304496/220134737-bd9b508c-a908-448b-b0d1-e960db28b24a.png">
>> 
>> Anyhow, regardless of the Lombok inefficiencies I think there are some optimization opportunities in the JDK itself. 
>> 
>> 1. Overall, `Pretty.visitSelect` accounts for 8-10% of the total allocations in this project. And among those there are StringBuilder allocations coming from the following:
>> 
>> 
>>     public void visitSelect(JCFieldAccess tree) {
>>         try {
>>             printExpr(tree.selected, TreeInfo.postfixPrec);
>>             // StringBuilder allocations hiding in here.
>>             print("." + tree.name);
>>         } catch (IOException e) {
>>             throw new UncheckedIOException(e);
>>         }
>>     }
>> 
>> 
>> This PR splits the `print` calls into two separate ones to avoid this String concatenation.
>> 
>> ...
>>             printExpr(tree.selected, TreeInfo.postfixPrec);
>>             print('.');
>>             print(tree.name);
>> ...
>> 
>> 
>> Secondly, the `print` method takes an `Object` which seems like a good fit for another (private?) variant of it that only takes a `char`. By this we would probably avoid any eventual boxing and avoid any conversion with `Convert.escapeUnicode(s.toString())` that seems superfluous for chars like `.`, ` `, or any braces like `(`, `{` etc. 
>> 
>> This is currently a draft PR as long as the scope is not clarified. It currently only includes the necessary changes that would optimize the particular use-case. But there are more cases where e.g. the new `char` variant could be used and/or any String concatenation could be split into separate `print` calls.
>> 
>> Let me know what you think and if I should include the other cases as well. If you think this is worthwhile, I'd appreciate if this is is sponsored. (Including creating an issue as I can't do this myself apparently. I will of course squash everything together with the proper issue ID once available.)
>> 
>> I've contributed before, so the CLA should be signed.
>> 
>> Cheers,
>> Christoph
>
> Christoph Dreis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8303078: Fix Pretty.visitLambda

looks good. I will run an internal test that executes all regression tests in all supported platforms just to be xtra sure

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

Marked as reviewed by vromero (Reviewer).

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

From vromero at openjdk.org  Thu Feb 23 04:57:08 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 23 Feb 2023 04:57:08 GMT
Subject: RFR: 8303078: Reduce allocations when pretty printing JCTree
 during compilation [v5]
In-Reply-To: <Pp_gd6CTeaKCfNAkPDchIvzPGPt60jMjq5xGyxLS3oc=.cb15c54b-b151-4cec-98f5-c268b8e6eced@github.com>
References: <GmfIJukLO6280Z1lPW5hPwPRMN0_UGNTJ-Ec9_HstyY=.95fe1edc-5f28-483a-a150-e0575ace6912@github.com>
 <TRouvUJBy1Zmz47tf4I8zr8dOxZiBAQf7YwcaAaYwSk=.a6e542bc-03a3-4c60-97ac-9d665bf1cd62@github.com>
 <Pp_gd6CTeaKCfNAkPDchIvzPGPt60jMjq5xGyxLS3oc=.cb15c54b-b151-4cec-98f5-c268b8e6eced@github.com>
Message-ID: <ubItY3VFl34KooM9Ds_o-Kdv28TRweCVeLlw-8t0Umg=.09f21343-70fe-44d1-a161-7f414328749c@github.com>

On Thu, 23 Feb 2023 03:28:13 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> looks good. I will run an internal test that executes all regression tests in all supported platforms just to be xtra sure

all green :)

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

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

From duke at openjdk.org  Thu Feb 23 07:06:11 2023
From: duke at openjdk.org (Christoph Dreis)
Date: Thu, 23 Feb 2023 07:06:11 GMT
Subject: RFR: 8303078: Reduce allocations when pretty printing JCTree
 during compilation [v2]
In-Reply-To: <_qzvnCcRMvtm-rUD8wPK-T_IIKmFaskg7f-jahcFe5w=.5efa246e-a2a2-483a-bd6b-c6fe06415d8f@github.com>
References: <GmfIJukLO6280Z1lPW5hPwPRMN0_UGNTJ-Ec9_HstyY=.95fe1edc-5f28-483a-a150-e0575ace6912@github.com>
 <wQTo4HeB0JQyLQLutA_0aHDoHZSf7VGPVAECY-14P-Q=.a20572b6-b30d-48c5-840e-bddf4c11ea1c@github.com>
 <flVK2vzadl2bcqCghBU3MbupyBrhQcaOrBGXIHMK_eI=.0beaea2d-e581-4192-ac6f-1dd5705b1720@github.com>
 <_qzvnCcRMvtm-rUD8wPK-T_IIKmFaskg7f-jahcFe5w=.5efa246e-a2a2-483a-bd6b-c6fe06415d8f@github.com>
Message-ID: <UZBPwPsSk_hkcV6zJeUEATweZXBt4kfSIlAtnu__Rko=.a316f413-0c91-4e93-b631-9f80eba96bbd@github.com>

On Wed, 22 Feb 2023 17:55:34 GMT, Christoph Dreis <duke at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/tree/Pretty.java line 1246:
>> 
>>> 1244:             if (tree.paramKind == JCLambda.ParameterKind.EXPLICIT) {
>>> 1245:                 printExprs(tree.params);
>>> 1246:             } else {
>> 
>> nit, just below: `String sep = "";` -> `char sep = '\0';` also `sep = ","` -> `sep = ','`?
>
> Done

This failed the build - I reverted it.

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

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

From duke at openjdk.org  Thu Feb 23 15:29:26 2023
From: duke at openjdk.org (Christoph Dreis)
Date: Thu, 23 Feb 2023 15:29:26 GMT
Subject: RFR: 8303078: Reduce allocations when pretty printing JCTree
 during compilation [v5]
In-Reply-To: <dCjiUtMeQEWHrggunqsammh0SPZvrrzhEP6UfX3geTU=.19cd9b6e-37a3-4d8f-9174-0a3308dee8a8@github.com>
References: <GmfIJukLO6280Z1lPW5hPwPRMN0_UGNTJ-Ec9_HstyY=.95fe1edc-5f28-483a-a150-e0575ace6912@github.com>
 <TRouvUJBy1Zmz47tf4I8zr8dOxZiBAQf7YwcaAaYwSk=.a6e542bc-03a3-4c60-97ac-9d665bf1cd62@github.com>
 <dCjiUtMeQEWHrggunqsammh0SPZvrrzhEP6UfX3geTU=.19cd9b6e-37a3-4d8f-9174-0a3308dee8a8@github.com>
Message-ID: <Qmk94TvgGDdx7Ou_enfiEAkmOIoE5-5rQf6Rn3Xqo9M=.d63f83d1-70ca-404c-928d-66130dd0356f@github.com>

On Thu, 23 Feb 2023 01:21:42 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Christoph Dreis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8303078: Fix Pretty.visitLambda
>
> I confirm that all the langtools tests now pass, at least on my local laptop.

Thanks @jonathan-gibbons & @vicente-romero-oracle for your active advice, reviewing and sponsoring :)

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

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

From duke at openjdk.org  Thu Feb 23 15:29:28 2023
From: duke at openjdk.org (Christoph Dreis)
Date: Thu, 23 Feb 2023 15:29:28 GMT
Subject: Integrated: 8303078: Reduce allocations when pretty printing JCTree
 during compilation
In-Reply-To: <GmfIJukLO6280Z1lPW5hPwPRMN0_UGNTJ-Ec9_HstyY=.95fe1edc-5f28-483a-a150-e0575ace6912@github.com>
References: <GmfIJukLO6280Z1lPW5hPwPRMN0_UGNTJ-Ec9_HstyY=.95fe1edc-5f28-483a-a150-e0575ace6912@github.com>
Message-ID: <1JV-dVPGfsWA7v2446TGmikcHg0i71fsQ4e-d4KC3cg=.eb7503ea-1b1f-49e6-9926-3811d4cfe893@github.com>

On Mon, 20 Feb 2023 14:54:18 GMT, Christoph Dreis <duke at openjdk.org> wrote:

> Hi,
> 
> I've been recently optimizing a few project pipelines and always noticed that their compilation step is somewhat "expensive".  Zooming into the issue always revealed Lombok to be a larger contributor. Unfortunately, I can't get rid of Lombok in this customer project (before you ask).
> 
> Apparently, Lombok is printing the respective `JCTree` here and there to check for type matches. I can't imagine this to be super efficient, but that's how it is at the moment.
> <img width="948" alt="image" src="https://user-images.githubusercontent.com/6304496/220134737-bd9b508c-a908-448b-b0d1-e960db28b24a.png">
> 
> Anyhow, regardless of the Lombok inefficiencies I think there are some optimization opportunities in the JDK itself. 
> 
> 1. Overall, `Pretty.visitSelect` accounts for 8-10% of the total allocations in this project. And among those there are StringBuilder allocations coming from the following:
> 
> 
>     public void visitSelect(JCFieldAccess tree) {
>         try {
>             printExpr(tree.selected, TreeInfo.postfixPrec);
>             // StringBuilder allocations hiding in here.
>             print("." + tree.name);
>         } catch (IOException e) {
>             throw new UncheckedIOException(e);
>         }
>     }
> 
> 
> This PR splits the `print` calls into two separate ones to avoid this String concatenation.
> 
> ...
>             printExpr(tree.selected, TreeInfo.postfixPrec);
>             print('.');
>             print(tree.name);
> ...
> 
> 
> Secondly, the `print` method takes an `Object` which seems like a good fit for another (private?) variant of it that only takes a `char`. By this we would probably avoid any eventual boxing and avoid any conversion with `Convert.escapeUnicode(s.toString())` that seems superfluous for chars like `.`, ` `, or any braces like `(`, `{` etc. 
> 
> This is currently a draft PR as long as the scope is not clarified. It currently only includes the necessary changes that would optimize the particular use-case. But there are more cases where e.g. the new `char` variant could be used and/or any String concatenation could be split into separate `print` calls.
> 
> Let me know what you think and if I should include the other cases as well. If you think this is worthwhile, I'd appreciate if this is is sponsored. (Including creating an issue as I can't do this myself apparently. I will of course squash everything together with the proper issue ID once available.)
> 
> I've contributed before, so the CLA should be signed.
> 
> Cheers,
> Christoph

This pull request has now been integrated.

Changeset: 58ca711a
Author:    Christoph Dreis <christoph.dreis at freenet.de>
Committer: Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/58ca711a9751ce38ef13e8e3ba78221f87de700f
Stats:     241 lines in 2 files changed: 44 ins; 1 del; 196 mod

8303078: Reduce allocations when pretty printing JCTree during compilation

Reviewed-by: jjg, vromero

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

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

From jjg at openjdk.org  Thu Feb 23 15:38:32 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 23 Feb 2023 15:38:32 GMT
Subject: RFR: 8303078: Reduce allocations when pretty printing JCTree
 during compilation [v5]
In-Reply-To: <dCjiUtMeQEWHrggunqsammh0SPZvrrzhEP6UfX3geTU=.19cd9b6e-37a3-4d8f-9174-0a3308dee8a8@github.com>
References: <GmfIJukLO6280Z1lPW5hPwPRMN0_UGNTJ-Ec9_HstyY=.95fe1edc-5f28-483a-a150-e0575ace6912@github.com>
 <TRouvUJBy1Zmz47tf4I8zr8dOxZiBAQf7YwcaAaYwSk=.a6e542bc-03a3-4c60-97ac-9d665bf1cd62@github.com>
 <dCjiUtMeQEWHrggunqsammh0SPZvrrzhEP6UfX3geTU=.19cd9b6e-37a3-4d8f-9174-0a3308dee8a8@github.com>
Message-ID: <WQXiyaVJZ67y0gZsIAOxvjRcnrPGTix_GXRIYmKKVMk=.6c9deef2-3d1f-441b-af9b-158a73e9f379@github.com>

On Thu, 23 Feb 2023 01:21:42 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Christoph Dreis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8303078: Fix Pretty.visitLambda
>
> I confirm that all the langtools tests now pass, at least on my local laptop.

> Thanks @jonathan-gibbons & @vicente-romero-oracle for your active advice, reviewing and sponsoring :)

You're welcome; thanks for the contribution.

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

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

From vromero at openjdk.org  Thu Feb 23 16:36:23 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 23 Feb 2023 16:36:23 GMT
Subject: RFR: 8303078: Reduce allocations when pretty printing JCTree
 during compilation [v5]
In-Reply-To: <WQXiyaVJZ67y0gZsIAOxvjRcnrPGTix_GXRIYmKKVMk=.6c9deef2-3d1f-441b-af9b-158a73e9f379@github.com>
References: <GmfIJukLO6280Z1lPW5hPwPRMN0_UGNTJ-Ec9_HstyY=.95fe1edc-5f28-483a-a150-e0575ace6912@github.com>
 <TRouvUJBy1Zmz47tf4I8zr8dOxZiBAQf7YwcaAaYwSk=.a6e542bc-03a3-4c60-97ac-9d665bf1cd62@github.com>
 <dCjiUtMeQEWHrggunqsammh0SPZvrrzhEP6UfX3geTU=.19cd9b6e-37a3-4d8f-9174-0a3308dee8a8@github.com>
 <WQXiyaVJZ67y0gZsIAOxvjRcnrPGTix_GXRIYmKKVMk=.6c9deef2-3d1f-441b-af9b-158a73e9f379@github.com>
Message-ID: <NuzhLaiacz4OA1w4rwqYFEvJDXBUJxgHqOW7_MrLkrU=.2345ab58-bd64-4c55-a035-c4b6f9d1edfc@github.com>

On Thu, 23 Feb 2023 15:35:27 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> > Thanks @jonathan-gibbons & @vicente-romero-oracle for your active advice, reviewing and sponsoring :)
> 
> You're welcome; thanks for the contribution.

+1

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

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

From jonathan.gibbons at oracle.com  Thu Feb 23 19:33:04 2023
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Thu, 23 Feb 2023 11:33:04 -0800
Subject: [External] : Re: Case-insensitive file systems and output file
 clashes - survey
In-Reply-To: <CANSoFxuoNpo9mn9E5krdzBRmKkqidyN_nSX3R=7Tb0c6efUHng@mail.gmail.com>
References: <CANSoFxuM4X-E0Er8b4hSWwwg8asBRmSGmab9+sUQPXmuh2C70A@mail.gmail.com>
 <c7518371-31a8-78a8-3bf7-2cb0e4394ccd@oracle.com>
 <CANSoFxuoNpo9mn9E5krdzBRmKkqidyN_nSX3R=7Tb0c6efUHng@mail.gmail.com>
Message-ID: <f2868e3b-1c13-b86b-547b-129c0d3a0cab@oracle.com>


On 2/22/23 10:59 AM, Archie Cobbs wrote:
> On Wed, Feb 22, 2023 at 12:12 PM Jonathan Gibbons 
> <jonathan.gibbons at oracle.com> wrote:
>
>     On 2/22/23 8:06 AM, Archie Cobbs wrote:
>>
>>     Add a new option -Xlint:fileclash that enables checking for
>>     clashes (e.g., at the JavacFileSystemManager layer).
>>
>     That would likely either be a partial solution, or an expensive
>     one for a complete solution when taking separate compilation into
>     account.
>
> I was thinking separate compilation would definitely not be supported 
> (too complicated).
>
> Given that assumption, would it necessarily be only a partial fix?


Yes, it would be a partial fix, because by your own assumption, it would 
not cover some important cases.

Also, the problem of file system issues is more than just case-clash 
class names; on Windows, you cannot (or used not to be able) to write 
files like CON, NUL, etc. (I haven't checked Windows to see if there are 
still issues there.)


>
> Admittedly I haven't really checked to see whether this would work but 
> a simple idea would be for the compiler to maintain e.g. a 
> Map<JavaFileObject, ClassSymbol> , then after writing out a classfile, 
> it adds the corresponding entry, OR finds that one already exists and 
> emits an error that the two ClassSymbol's have clashing output files.
>
> You would maintain separate mappings for classfiles, header files, and 
> source files.
>>
>>      1. Add new compiler flags -dzip, -szip, -hzip (corresponding to
>>         -d, -s, -h) that specify ZIP files for output instead of
>>         directories
>>
>     I would recommend using the existing options, and just allow those
>     options to specify a zip file, and then open the file with
>     `zipfs`.?? That being said, updating zip files by "overwriting"
>     existing entries comes with its own set of problems.
>
> Yep.. for efficiency you'd probably need to do some gymnastics, e.g., 
> have a staging directory, and then at the very end of the compilation 
> write out a new ZIP file using merge sort with the original (if any).
>
If anyone were to pursue this, I would recommend that it be done at 
least 99.99% in a separate implementation of `java.nio.file.FileSystem`, 
and not directly in javac itself. Such a FileSystem could be used 
without changing javac at all when invoking javac through its API (i.e. 
`javax.tools.JavaCompiler.getTask`), or with minimal change to 
command-line javac to specify the use of that file system.

-- Jon


> -Archie
>
> -- 
> Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230223/9109e53c/attachment-0001.htm>

From jlaskey at openjdk.org  Thu Feb 23 20:08:21 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 23 Feb 2023 20:08:21 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v41]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <8acQaVjcsJLZjZv02chxRMODQ1wJnJ6zvb5IkaIGH2w=.94b6a788-b129-4623-bd4e-ecaaeb4bce37@github.com>

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

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

 - Merge branch 'master' into 8285932
 - Merge branch 'master' into 8285932
 - Minor correction to javadoc
 - Merge branch 'master' into 8285932
 - CSR review
 - Bring up to date
 - Merge branch 'master' into 8285932
 - Update to JDK 21
 - Merge branch 'master' into 8285932
 - Merge branch 'master' into 8285932
 - ... and 46 more: https://git.openjdk.org/jdk/compare/6b24b4a7...89806d49

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

Changes: https://git.openjdk.org/jdk/pull/10889/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=40
  Stats: 9494 lines in 81 files changed: 9395 ins; 29 del; 70 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10889/head:pull/10889

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

From archie.cobbs at gmail.com  Thu Feb 23 21:06:02 2023
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Thu, 23 Feb 2023 15:06:02 -0600
Subject: [External] : Re: Case-insensitive file systems and output file
 clashes - survey
In-Reply-To: <f2868e3b-1c13-b86b-547b-129c0d3a0cab@oracle.com>
References: <CANSoFxuM4X-E0Er8b4hSWwwg8asBRmSGmab9+sUQPXmuh2C70A@mail.gmail.com>
 <c7518371-31a8-78a8-3bf7-2cb0e4394ccd@oracle.com>
 <CANSoFxuoNpo9mn9E5krdzBRmKkqidyN_nSX3R=7Tb0c6efUHng@mail.gmail.com>
 <f2868e3b-1c13-b86b-547b-129c0d3a0cab@oracle.com>
Message-ID: <CANSoFxum7aFO=DKOmYbE49i_HWs=+xHgGYo0L79agF3fBXrhrQ@mail.gmail.com>

On Thu, Feb 23, 2023 at 1:33 PM Jonathan Gibbons <
jonathan.gibbons at oracle.com> wrote:

> On 2/22/23 10:59 AM, Archie Cobbs wrote:
>
> On Wed, Feb 22, 2023 at 12:12 PM Jonathan Gibbons <
> jonathan.gibbons at oracle.com> wrote:
>
>> On 2/22/23 8:06 AM, Archie Cobbs wrote:
>>
>>
>> Add a new option -Xlint:fileclash that enables checking for clashes
>> (e.g., at the JavacFileSystemManager layer).
>>
>>
>> That would likely either be a partial solution, or an expensive one for a
>> complete solution when taking separate compilation into account.
>>
> I was thinking separate compilation would definitely not be supported (too
> complicated).
>
> Given that assumption, would it necessarily be only a partial fix?
>
> Yes, it would be a partial fix, because by your own assumption, it would
> not cover some important cases.
>
Well I guess I meant, would it be "partial" in some way besides the fact
that separate compilations are not taken into account.

Digressing a bit, I'm not sure I agree that not supporting separate
compilations makes it partial. Isn't a "compilation" the extent of the unit
of work that a compiler is being asked to do? Asking it to solve problems
that span multiple compilations seems out of scope. Or maybe I'm
misunderstanding what you mean by "compilation".


> Also, the problem of file system issues is more than just case-clash class
> names; on Windows, you cannot (or used not to be able) to write files like
> CON, NUL, etc. (I haven't checked Windows to see if there are still issues
> there.)
>
Yes, but in those cases an error is generated, right? In contrast of course
the problems that stem from case-insensitive filesystems are "silent"
errors.


>
>
>>    1. Add new compiler flags -dzip, -szip, -hzip (corresponding to -d, -s,
>>    -h) that specify ZIP files for output instead of directories
>>
>> I would recommend using the existing options, and just allow those
>> options to specify a zip file, and then open the file with `zipfs`.   That
>> being said, updating zip files by "overwriting" existing entries comes with
>> its own set of problems.
>>
> Yep.. for efficiency you'd probably need to do some gymnastics, e.g., have
> a staging directory, and then at the very end of the compilation write out
> a new ZIP file using merge sort with the original (if any).
>
> If anyone were to pursue this, I would recommend that it be done at least
> 99.99% in a separate implementation of  `java.nio.file.FileSystem`, and not
> directly in javac itself.  Such a FileSystem could be used without changing
> javac at all when invoking javac through its API (i.e.
> `javax.tools.JavaCompiler.getTask`), or with minimal change to command-line
> javac to specify the use of that file system.
>
That's a neat approach.

The idea of a javac flag like --use-filesystem-impl com.foobar.MyFileSystem
is something that could be useful in its own right.

-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230223/7911368a/attachment.htm>

From duke at openjdk.org  Thu Feb 23 22:22:04 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Thu, 23 Feb 2023 22:22:04 GMT
Subject: RFR: 7016187: `javac -h` could generate conflict .h for inner
 class and class name with '_'
In-Reply-To: <Qp5hpb5ArmwaV1pngPe5dIYLOeOay6DO5GRPGLcM8Ok=.13ab7eb7-93ee-404d-9cb8-6e50ca35a41e@github.com>
References: <TjKjaZLrq5AnmfxbBfv7Yr29TRkl7p_egrz8AzCTGf8=.c5953e6d-6ff2-4a4f-8327-a3cc956a3e0b@github.com>
 <Qp5hpb5ArmwaV1pngPe5dIYLOeOay6DO5GRPGLcM8Ok=.13ab7eb7-93ee-404d-9cb8-6e50ca35a41e@github.com>
Message-ID: <qaDf3VXuRyrpKXC61n75lOKTK_gRguRh-qE_2epP1JI=.cc3604d9-edf4-408d-a332-a73dd52aa13a@github.com>

On Fri, 17 Feb 2023 23:31:55 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Consider these two classes:
>> 
>> public class Foo_Bar {
>>     public static native void method();
>> }
>> 
>> 
>> public class Foo {
>>     public static class Bar {
>>         public static native void method();
>>     }
>> }
>> 
>> If you run `javac -h` to generate native header files, classes `Foo_Bar` and `Foo$Bar` will want to generate the same native header file `Foo_Bar.h`.
>> 
>> Currently, javac does not detect this situation, so in effect you get a "last writer wins" situation.
>> 
>> This patch causes compilation to fail instead in this case with an error like this:
>> 
>> Foo.java:2: error: error while writing Bar: native header file collision between Foo_Bar and Foo$Bar (both generate Foo_Bar.h)
>>     public static class Bar {
>>                   ^
>> 1 error
>
> The JBS issue lists _two_ problem cases, of which this PR addresses one.
> 
> You should either fix both, or file a subsidiary issue for the part that is not covered here (if that is still an issue):
> 
>> It also does not handle the fields properly for O_I.class and O$I.class if both have same named fields. The generated field constant names are the same in the jni header file.

@jonathan-gibbons - Are you OK with this patch as it currently stands?

Thanks.

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

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

From jonathan.gibbons at oracle.com  Fri Feb 24 01:09:37 2023
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Thu, 23 Feb 2023 17:09:37 -0800
Subject: [External] : Re: Case-insensitive file systems and output file
 clashes - survey
In-Reply-To: <CANSoFxum7aFO=DKOmYbE49i_HWs=+xHgGYo0L79agF3fBXrhrQ@mail.gmail.com>
References: <CANSoFxuM4X-E0Er8b4hSWwwg8asBRmSGmab9+sUQPXmuh2C70A@mail.gmail.com>
 <c7518371-31a8-78a8-3bf7-2cb0e4394ccd@oracle.com>
 <CANSoFxuoNpo9mn9E5krdzBRmKkqidyN_nSX3R=7Tb0c6efUHng@mail.gmail.com>
 <f2868e3b-1c13-b86b-547b-129c0d3a0cab@oracle.com>
 <CANSoFxum7aFO=DKOmYbE49i_HWs=+xHgGYo0L79agF3fBXrhrQ@mail.gmail.com>
Message-ID: <4611aa34-3779-d35d-659b-a9f6c7781a33@oracle.com>


On 2/23/23 1:06 PM, Archie Cobbs wrote:
>
>>
>     If anyone were to pursue this, I would recommend that it be done
>     at least 99.99% in a separate implementation of?
>     `java.nio.file.FileSystem`, and not directly in javac itself.?
>     Such a FileSystem could be used without changing javac at all when
>     invoking javac through its API (i.e.
>     `javax.tools.JavaCompiler.getTask`), or with minimal change to
>     command-line javac to specify the use of that file system.
>
> That's a neat approach.
>
> The idea of a javac flag like --use-filesystem-impl 
> com.foobar.MyFileSystem is something that could be useful in its own 
> right.
>
> -Archie

FWIW, I probably meant `javax.tools.JavaFileManager` instead of 
`java.nio.file.FileSystem`. That good, because it's easier to write an 
interposing file manager than a new file system. :-)

-- Jon

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230223/d084001a/attachment.htm>

From jonathan.gibbons at oracle.com  Fri Feb 24 01:25:42 2023
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Thu, 23 Feb 2023 17:25:42 -0800
Subject: [External] : Re: Case-insensitive file systems and output file
 clashes - survey
In-Reply-To: <CANSoFxum7aFO=DKOmYbE49i_HWs=+xHgGYo0L79agF3fBXrhrQ@mail.gmail.com>
References: <CANSoFxuM4X-E0Er8b4hSWwwg8asBRmSGmab9+sUQPXmuh2C70A@mail.gmail.com>
 <c7518371-31a8-78a8-3bf7-2cb0e4394ccd@oracle.com>
 <CANSoFxuoNpo9mn9E5krdzBRmKkqidyN_nSX3R=7Tb0c6efUHng@mail.gmail.com>
 <f2868e3b-1c13-b86b-547b-129c0d3a0cab@oracle.com>
 <CANSoFxum7aFO=DKOmYbE49i_HWs=+xHgGYo0L79agF3fBXrhrQ@mail.gmail.com>
Message-ID: <49107c5f-7f51-9827-7830-6ea2a9ff42f2@oracle.com>


On 2/23/23 1:06 PM, Archie Cobbs wrote:
> On Thu, Feb 23, 2023 at 1:33 PM Jonathan Gibbons 
> <jonathan.gibbons at oracle.com> wrote:
>
>     On 2/22/23 10:59 AM, Archie Cobbs wrote:
>
>>     On Wed, Feb 22, 2023 at 12:12 PM Jonathan Gibbons
>>     <jonathan.gibbons at oracle.com> wrote:
>>
>>         On 2/22/23 8:06 AM, Archie Cobbs wrote:
>>>
>>>         Add a new option -Xlint:fileclash that enables checking for
>>>         clashes (e.g., at the JavacFileSystemManager layer).
>>>
>>         That would likely either be a partial solution, or an
>>         expensive one for a complete solution when taking separate
>>         compilation into account.
>>
>>     I was thinking separate compilation would definitely not be
>>     supported (too complicated).
>>
>>     Given that assumption, would it necessarily be only a partial fix?
>
>     Yes, it would be a partial fix, because by your own assumption, it
>     would not cover some important cases.
>
> Well I guess I meant, would it be "partial" in some way besides the 
> fact that separate compilations are not taken into account.
>
> Digressing a bit, I'm not sure I agree that not supporting separate 
> compilations makes it partial. Isn't a "compilation" the extent of the 
> unit of work that a compiler is being asked to do? Asking it to solve 
> problems that span multiple compilations seems out of scope. Or maybe 
> I'm misunderstanding what you mean by "compilation".

Compiling against precompiled class files is expecting javac to solve a 
problem spanning multiple compilations. :-)

That being said, I agree it is a reasonable expectation that any one 
compilation should not write the same physical file more than once, and 
so it might be reasonable to have a possibly always-on diagnostic if 
that situation is detected, perhaps even an error. Like the (separate) 
zip file discussion, this could be handled inside a custom file 
manager.? The challenge may be in specifying the behavior correctly, and 
not over-promising in the command-line help or man page. But if you 
stick to something like the following in the man page, you may be OK:

 ?? An error will be reported if any file is written more than once 
during a compilation. This may occur in the following situations: 
list-of-known-situations


>     Also, the problem of file system issues is more than just
>     case-clash class names; on Windows, you cannot (or used not to be
>     able) to write files like CON, NUL, etc. (I haven't checked
>     Windows to see if there are still issues there.)
>
> Yes, but in those cases an error is generated, right? In contrast of 
> course the problems that stem from case-insensitive filesystems are 
> "silent" errors.
>
>
>>>          1. Add new compiler flags -dzip, -szip, -hzip
>>>             (corresponding to -d, -s, -h) that specify ZIP files for
>>>             output instead of directories
>>>
>>         I would recommend using the existing options, and just allow
>>         those options to specify a zip file, and then open the file
>>         with `zipfs`.?? That being said, updating zip files by
>>         "overwriting" existing entries comes with its own set of
>>         problems.
>>
>>     Yep.. for efficiency you'd probably need to do some gymnastics,
>>     e.g., have a staging directory, and then at the very end of the
>>     compilation write out a new ZIP file using merge sort with the
>>     original (if any).
>>
>     If anyone were to pursue this, I would recommend that it be done
>     at least 99.99% in a separate implementation of?
>     `java.nio.file.FileSystem`, and not directly in javac itself.?
>     Such a FileSystem could be used without changing javac at all when
>     invoking javac through its API (i.e.
>     `javax.tools.JavaCompiler.getTask`), or with minimal change to
>     command-line javac to specify the use of that file system.
>
> That's a neat approach.
>
> The idea of a javac flag like --use-filesystem-impl 
> com.foobar.MyFileSystem is something that could be useful in its own 
> right.
>
> -Archie
>
> -- 
> Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230223/78bdcd91/attachment-0001.htm>

From jonathan.gibbons at oracle.com  Fri Feb 24 02:24:09 2023
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Thu, 23 Feb 2023 18:24:09 -0800
Subject: RFR: 7016187: `javac -h` could generate conflict .h for inner
 class and class name with '_'
In-Reply-To: <88jLCv2N9jprPQiS8hfVdccJEvZmfDti-OZVXWB3eeE=.e34acd67-880a-479f-aa31-49807747fd7f@github.com>
References: <TjKjaZLrq5AnmfxbBfv7Yr29TRkl7p_egrz8AzCTGf8=.c5953e6d-6ff2-4a4f-8327-a3cc956a3e0b@github.com>
 <88jLCv2N9jprPQiS8hfVdccJEvZmfDti-OZVXWB3eeE=.e34acd67-880a-479f-aa31-49807747fd7f@github.com>
Message-ID: <8488c3ec-e640-dd8c-c561-bea9dc959910@oracle.com>


On 2/17/23 5:22 PM, Archie L. Cobbs wrote:
> On Thu, 16 Feb 2023 17:49:00 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:
>
>> Consider these two classes:
>>
>> public class Foo_Bar {
>>      public static native void method();
>> }
>>
>>
>> public class Foo {
>>      public static class Bar {
>>          public static native void method();
>>      }
>> }
>>
>> If you run `javac -h` to generate native header files, classes `Foo_Bar` and `Foo$Bar` will want to generate the same native header file `Foo_Bar.h`.
>>
>> Currently, javac does not detect this situation, so in effect you get a "last writer wins" situation.
>>
>> This patch causes compilation to fail instead in this case with an error like this:
>>
>> Foo.java:2: error: error while writing Bar: native header file collision between Foo_Bar and Foo$Bar (both generate Foo_Bar.h)
>>      public static class Bar {
>>                    ^
>> 1 error
>> The JBS issue lists two problem cases, of which this PR addresses one.
> Thanks for the heads-up on that, admittedly I had totally forgotten about it. However I'm not sure whether there is anything to do beyond what's already being done to flag the filename conflict.
>
> The second problem (as I understand it) is that the two header files will include C macro definitions for `static final` constants that end up having the same name. For example, if `Foo$Bar` has a `public static final int field = 123` and `Foo_Bar` has a `public static final int field = 456`, then one header file will have:
>
> #undef Foo_Bar_field
> #define Foo_Bar_field 123L
>
> and the other will have:
>
> #undef Foo_Bar_field
> #define Foo_Bar_field 456L
>
> But notice the JNI version of the class names (`Foo_Bar`) is a prefix of the macro name (`Foo_Bar_field`) and also the name of the header file (`Foo_Bar.h`) minus the `.h`. So it's not possible to have two field macro symbols conflict this way without there already being a header file conflict, and therefore the current changes will detect these field conflicts as well as a side-effect. Put another way, the field name conflicts are just a side-effect of the JNI class name conflicts.
>
> Of course (and this is going beyond the reported bug) you could also have a field name conflict where the header file names don't conflict. For example:
>
> public class Foo {
>      public static final int Bar_field = 123;
> }
> public class Foo_Bar {
>      public static final int field = 456;
> }
>
> and so you'd generate two different header files (with different names) that both define `Foo_Bar_field`:
>
> #undef Foo_Bar_field
> #define Foo_Bar_field 123L
>
>
> #undef Foo_Bar_field
> #define Foo_Bar_field 456L
>
> But then you can still deal with it at the C/C++ level by including the headers in the right order, or including only one in each of two separate C/C++ files, etc. Yes, you would have to "know what you're doing" but I don't think there's enough justification for turning this case into an error at the javac compiler level. And in any case if you're writing JNI, you probably "know what you're doing" :)


Yeah, maybe the file-name conflict is enough. And as for JNI, Panama and 
jextract may be the way of the future.

-- Jon


>
> -------------
>
> PR: https://git.openjdk.org/jdk/pull/12602

From vromero at openjdk.org  Fri Feb 24 11:23:09 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 24 Feb 2023 11:23:09 GMT
Subject: RFR: 8026369: javac potentially ambiguous overload warning needs
 an improved scheme [v2]
In-Reply-To: <NlqhxTe-Li08DSIjyYVn5HI9uIAvIHZE4IG0x8tQTQw=.0ae9928e-7814-4356-bf75-11bc4eefc6be@github.com>
References: <IMxp3iCK--jYJ5Ia04i6QPYfnCHQobVcsmlI5aJXdqc=.892abcb8-7f2a-4fe9-aea2-1b1d41098a6d@github.com>
 <NlqhxTe-Li08DSIjyYVn5HI9uIAvIHZE4IG0x8tQTQw=.0ae9928e-7814-4356-bf75-11bc4eefc6be@github.com>
Message-ID: <Q5L__4hI_EKmVkQZ6GMyp77cxinOIap14vzgwBs1kF4=.374c3f34-bc0a-4bee-a548-6f454a78314e@github.com>

On Tue, 21 Feb 2023 01:42:41 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> This bug relates to the "potentially ambiguous overload" warning which is enabled by `-Xlint:overloads`.
>> 
>> The warning detects certain ambiguities that can cause problems for lambdas. For example, consider the interface `Spliterator.OfInt`, which declares these two methods:
>> 
>> void forEachRemaining(Consumer<? super Integer> action);
>> void forEachRemaining(IntConsumer action);
>> 
>> Both methods have the same name, same number of parameters, and take a lambda with the same "shape" in the same argument position. This causes an ambiguity in any code that wants to do this:
>> 
>>     spliterator.forEachRemaining(x -> { ... });
>> 
>> That code won't compile; instead, you'll get this error:
>> 
>> Ambiguity.java:4: error: reference to forEachRemaining is ambiguous
>>         spliterator.forEachRemaining(x -> { });
>>                    ^
>>   both method forEachRemaining(IntConsumer) in OfInt and method forEachRemaining(Consumer<? super Integer>) in OfInt match
>> 
>> 
>> The problem reported by the bug is that the warning fails to detect ambiguities which are created purely by inheritance, for example:
>> 
>> interface ConsumerOfInteger {
>>     void foo(Consumer<Integer> c);
>> }
>> 
>> interface IntegerConsumer {
>>     void foo(IntConsumer c);
>> }
>> 
>> // We should get a warning here...
>> interface Test extends ConsumerOfInteger, IntegerConsumer {
>> }
>> 
>> 
>> The cause of the bug is that ambiguities are detected on a per-method basis, by checking whether a method is part of an ambiguity pair when we visit that method. So if the methods in an ambiguity pair are inherited from two distinct supertypes, we'll miss the ambiguity.
>> 
>> To fix the problem, we need to look for ambiguities on a per-class level, checking all pairs of methods. However, it's not that simple - we only want to "blame" a class when that class itself, and not some supertype, is responsible for creating the ambiguity. For example, any interface extending `Spliterator.OfInt` will automatically inherit the two ambiguities mentioned above, but these are not the interface's fault so to speak so no warning should be generated. Making things more complicated is the fact that methods can be overridden and declared in generic classes so they only conflict in some subtypes, etc.
>> 
>> So we generate the warning when there are two methods m1 and m2 in a class C such that:
>> 
>> * m1 and m2 consitiute a "potentially ambiguous overload" (using the same definition as before)
>> * There is no direct supertype T of C such that m1 and m2, or some methods they override, both exist in T and constitute a "potentially ambiguous overload" as members of T
>> * We haven't already generated a warning for either m1 or m2 in class C
>> 
>> If either method is declared in C, we locate the warning there, but when both methods are inherited, there's no method declaration to point at so the warning is instead located at the class declaration.
>> 
>> I noticed a couple of other minor bugs; these are also being fixed here:
>> 
>> (1) For inherited methods, the method signatures were being reported as they are declared, rather than in the context of the class being visited. As a result, when a methods is inherited from a generic supertype, the ambiguity is less clear. Here's an example:
>> 
>> interface Upper<T> {
>>     void foo(T c);
>> }
>> 
>> interface Lower extends Upper<IntConsumer> {
>>     void foo(Consumer<Integer> c);
>> }
>> 
>> Currently, the error is reported as:
>> 
>> warning: [overloads] foo(Consumer<Integer>) in Lower is potentially ambiguous with foo(T) in Upper
>> 
>> Reporting the method signatures in the context of the class being visited makes the ambiguity clearer:
>> 
>> warning: [overloads] foo(Consumer<Integer>) in Lower is potentially ambiguous with foo(IntConsumer) in Upper
>> 
>> 
>> (2) When a method is identified as part of an ambiguous pair, we were setting a `POTENTIALLY_AMBIGUOUS` flag on it. This caused it to be forever excluded from future warnings. For methods that are declared in the class we're visiting, this makes sense, but it doesn't make sense for inherited methods, because it disqualifies them from participating in the analysis of any other class that also inherits them.
>> 
>> As a result, for a class like the one below, the compiler was only generating one warning instead of three:
>> 
>> public interface SuperIface {
>>     void foo(Consumer<Integer> c);
>> }
>> 
>> public interface I1 extends SuperIface { 
>>     void foo(IntConsumer c);        // warning was generated here
>> }   
>> 
>> public interface I2 extends SuperIface { 
>>     void foo(IntConsumer c);        // no warning was generated here
>> }   
>> 
>> public interface I3 extends SuperIface { 
>>     void foo(IntConsumer c);        // no warning was generated here
>> }   
>> 
>> 
>> With this patch the `POTENTIALLY_AMBIGUOUS` flag is no longer needed. I wasn't sure whether to renumber all the subsequent flags, or just leave an empty placeholder, so I chose the latter.
>> 
>> Finally, this fix uncovers new warnings in `java.base` and `java.desktop`, so these are now suppressed in the patch.
>
> Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove @SuppressWarnings("overloads") annotations that were added but not needed.

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java line 280:

> 278:      * Currently available.
> 279:      */
> 280:     public static final long UNUSED_1 = 1L<<48;

what about just adding the comment saying that this spot is free without declaring an unused flag?

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

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

From vromero at openjdk.org  Fri Feb 24 11:53:06 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 24 Feb 2023 11:53:06 GMT
Subject: RFR: 8026369: javac potentially ambiguous overload warning needs
 an improved scheme [v2]
In-Reply-To: <NlqhxTe-Li08DSIjyYVn5HI9uIAvIHZE4IG0x8tQTQw=.0ae9928e-7814-4356-bf75-11bc4eefc6be@github.com>
References: <IMxp3iCK--jYJ5Ia04i6QPYfnCHQobVcsmlI5aJXdqc=.892abcb8-7f2a-4fe9-aea2-1b1d41098a6d@github.com>
 <NlqhxTe-Li08DSIjyYVn5HI9uIAvIHZE4IG0x8tQTQw=.0ae9928e-7814-4356-bf75-11bc4eefc6be@github.com>
Message-ID: <tk3D21HgO9mRKLEvFHiLSqUPBqCBn483UBY8vu_Mb8E=.e9a261cb-752b-420e-967e-fbf09d8ab65b@github.com>

On Tue, 21 Feb 2023 01:42:41 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> This bug relates to the "potentially ambiguous overload" warning which is enabled by `-Xlint:overloads`.
>> 
>> The warning detects certain ambiguities that can cause problems for lambdas. For example, consider the interface `Spliterator.OfInt`, which declares these two methods:
>> 
>> void forEachRemaining(Consumer<? super Integer> action);
>> void forEachRemaining(IntConsumer action);
>> 
>> Both methods have the same name, same number of parameters, and take a lambda with the same "shape" in the same argument position. This causes an ambiguity in any code that wants to do this:
>> 
>>     spliterator.forEachRemaining(x -> { ... });
>> 
>> That code won't compile; instead, you'll get this error:
>> 
>> Ambiguity.java:4: error: reference to forEachRemaining is ambiguous
>>         spliterator.forEachRemaining(x -> { });
>>                    ^
>>   both method forEachRemaining(IntConsumer) in OfInt and method forEachRemaining(Consumer<? super Integer>) in OfInt match
>> 
>> 
>> The problem reported by the bug is that the warning fails to detect ambiguities which are created purely by inheritance, for example:
>> 
>> interface ConsumerOfInteger {
>>     void foo(Consumer<Integer> c);
>> }
>> 
>> interface IntegerConsumer {
>>     void foo(IntConsumer c);
>> }
>> 
>> // We should get a warning here...
>> interface Test extends ConsumerOfInteger, IntegerConsumer {
>> }
>> 
>> 
>> The cause of the bug is that ambiguities are detected on a per-method basis, by checking whether a method is part of an ambiguity pair when we visit that method. So if the methods in an ambiguity pair are inherited from two distinct supertypes, we'll miss the ambiguity.
>> 
>> To fix the problem, we need to look for ambiguities on a per-class level, checking all pairs of methods. However, it's not that simple - we only want to "blame" a class when that class itself, and not some supertype, is responsible for creating the ambiguity. For example, any interface extending `Spliterator.OfInt` will automatically inherit the two ambiguities mentioned above, but these are not the interface's fault so to speak so no warning should be generated. Making things more complicated is the fact that methods can be overridden and declared in generic classes so they only conflict in some subtypes, etc.
>> 
>> So we generate the warning when there are two methods m1 and m2 in a class C such that:
>> 
>> * m1 and m2 consitiute a "potentially ambiguous overload" (using the same definition as before)
>> * There is no direct supertype T of C such that m1 and m2, or some methods they override, both exist in T and constitute a "potentially ambiguous overload" as members of T
>> * We haven't already generated a warning for either m1 or m2 in class C
>> 
>> If either method is declared in C, we locate the warning there, but when both methods are inherited, there's no method declaration to point at so the warning is instead located at the class declaration.
>> 
>> I noticed a couple of other minor bugs; these are also being fixed here:
>> 
>> (1) For inherited methods, the method signatures were being reported as they are declared, rather than in the context of the class being visited. As a result, when a methods is inherited from a generic supertype, the ambiguity is less clear. Here's an example:
>> 
>> interface Upper<T> {
>>     void foo(T c);
>> }
>> 
>> interface Lower extends Upper<IntConsumer> {
>>     void foo(Consumer<Integer> c);
>> }
>> 
>> Currently, the error is reported as:
>> 
>> warning: [overloads] foo(Consumer<Integer>) in Lower is potentially ambiguous with foo(T) in Upper
>> 
>> Reporting the method signatures in the context of the class being visited makes the ambiguity clearer:
>> 
>> warning: [overloads] foo(Consumer<Integer>) in Lower is potentially ambiguous with foo(IntConsumer) in Upper
>> 
>> 
>> (2) When a method is identified as part of an ambiguous pair, we were setting a `POTENTIALLY_AMBIGUOUS` flag on it. This caused it to be forever excluded from future warnings. For methods that are declared in the class we're visiting, this makes sense, but it doesn't make sense for inherited methods, because it disqualifies them from participating in the analysis of any other class that also inherits them.
>> 
>> As a result, for a class like the one below, the compiler was only generating one warning instead of three:
>> 
>> public interface SuperIface {
>>     void foo(Consumer<Integer> c);
>> }
>> 
>> public interface I1 extends SuperIface { 
>>     void foo(IntConsumer c);        // warning was generated here
>> }   
>> 
>> public interface I2 extends SuperIface { 
>>     void foo(IntConsumer c);        // no warning was generated here
>> }   
>> 
>> public interface I3 extends SuperIface { 
>>     void foo(IntConsumer c);        // no warning was generated here
>> }   
>> 
>> 
>> With this patch the `POTENTIALLY_AMBIGUOUS` flag is no longer needed. I wasn't sure whether to renumber all the subsequent flags, or just leave an empty placeholder, so I chose the latter.
>> 
>> Finally, this fix uncovers new warnings in `java.base` and `java.desktop`, so these are now suppressed in the patch.
>
> Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove @SuppressWarnings("overloads") annotations that were added but not needed.

I think a CSR is needed as we will be generating more warnings and projects compiling with -Werror could see compilation errors

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

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

From duke at openjdk.org  Fri Feb 24 16:04:38 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Fri, 24 Feb 2023 16:04:38 GMT
Subject: RFR: 8026369: javac potentially ambiguous overload warning needs
 an improved scheme [v3]
In-Reply-To: <IMxp3iCK--jYJ5Ia04i6QPYfnCHQobVcsmlI5aJXdqc=.892abcb8-7f2a-4fe9-aea2-1b1d41098a6d@github.com>
References: <IMxp3iCK--jYJ5Ia04i6QPYfnCHQobVcsmlI5aJXdqc=.892abcb8-7f2a-4fe9-aea2-1b1d41098a6d@github.com>
Message-ID: <NHHLq4y0LkeQGPPSoHjNOquUU0_iafjmkeFZosjoFPs=.22a5e84f-eaba-4e44-b531-dcd9ea9a92c7@github.com>

> This bug relates to the "potentially ambiguous overload" warning which is enabled by `-Xlint:overloads`.
> 
> The warning detects certain ambiguities that can cause problems for lambdas. For example, consider the interface `Spliterator.OfInt`, which declares these two methods:
> 
> void forEachRemaining(Consumer<? super Integer> action);
> void forEachRemaining(IntConsumer action);
> 
> Both methods have the same name, same number of parameters, and take a lambda with the same "shape" in the same argument position. This causes an ambiguity in any code that wants to do this:
> 
>     spliterator.forEachRemaining(x -> { ... });
> 
> That code won't compile; instead, you'll get this error:
> 
> Ambiguity.java:4: error: reference to forEachRemaining is ambiguous
>         spliterator.forEachRemaining(x -> { });
>                    ^
>   both method forEachRemaining(IntConsumer) in OfInt and method forEachRemaining(Consumer<? super Integer>) in OfInt match
> 
> 
> The problem reported by the bug is that the warning fails to detect ambiguities which are created purely by inheritance, for example:
> 
> interface ConsumerOfInteger {
>     void foo(Consumer<Integer> c);
> }
> 
> interface IntegerConsumer {
>     void foo(IntConsumer c);
> }
> 
> // We should get a warning here...
> interface Test extends ConsumerOfInteger, IntegerConsumer {
> }
> 
> 
> The cause of the bug is that ambiguities are detected on a per-method basis, by checking whether a method is part of an ambiguity pair when we visit that method. So if the methods in an ambiguity pair are inherited from two distinct supertypes, we'll miss the ambiguity.
> 
> To fix the problem, we need to look for ambiguities on a per-class level, checking all pairs of methods. However, it's not that simple - we only want to "blame" a class when that class itself, and not some supertype, is responsible for creating the ambiguity. For example, any interface extending `Spliterator.OfInt` will automatically inherit the two ambiguities mentioned above, but these are not the interface's fault so to speak so no warning should be generated. Making things more complicated is the fact that methods can be overridden and declared in generic classes so they only conflict in some subtypes, etc.
> 
> So we generate the warning when there are two methods m1 and m2 in a class C such that:
> 
> * m1 and m2 consitiute a "potentially ambiguous overload" (using the same definition as before)
> * There is no direct supertype T of C such that m1 and m2, or some methods they override, both exist in T and constitute a "potentially ambiguous overload" as members of T
> * We haven't already generated a warning for either m1 or m2 in class C
> 
> If either method is declared in C, we locate the warning there, but when both methods are inherited, there's no method declaration to point at so the warning is instead located at the class declaration.
> 
> I noticed a couple of other minor bugs; these are also being fixed here:
> 
> (1) For inherited methods, the method signatures were being reported as they are declared, rather than in the context of the class being visited. As a result, when a methods is inherited from a generic supertype, the ambiguity is less clear. Here's an example:
> 
> interface Upper<T> {
>     void foo(T c);
> }
> 
> interface Lower extends Upper<IntConsumer> {
>     void foo(Consumer<Integer> c);
> }
> 
> Currently, the error is reported as:
> 
> warning: [overloads] foo(Consumer<Integer>) in Lower is potentially ambiguous with foo(T) in Upper
> 
> Reporting the method signatures in the context of the class being visited makes the ambiguity clearer:
> 
> warning: [overloads] foo(Consumer<Integer>) in Lower is potentially ambiguous with foo(IntConsumer) in Upper
> 
> 
> (2) When a method is identified as part of an ambiguous pair, we were setting a `POTENTIALLY_AMBIGUOUS` flag on it. This caused it to be forever excluded from future warnings. For methods that are declared in the class we're visiting, this makes sense, but it doesn't make sense for inherited methods, because it disqualifies them from participating in the analysis of any other class that also inherits them.
> 
> As a result, for a class like the one below, the compiler was only generating one warning instead of three:
> 
> public interface SuperIface {
>     void foo(Consumer<Integer> c);
> }
> 
> public interface I1 extends SuperIface { 
>     void foo(IntConsumer c);        // warning was generated here
> }   
> 
> public interface I2 extends SuperIface { 
>     void foo(IntConsumer c);        // no warning was generated here
> }   
> 
> public interface I3 extends SuperIface { 
>     void foo(IntConsumer c);        // no warning was generated here
> }   
> 
> 
> With this patch the `POTENTIALLY_AMBIGUOUS` flag is no longer needed. I wasn't sure whether to renumber all the subsequent flags, or just leave an empty placeholder, so I chose the latter.
> 
> Finally, this fix uncovers new warnings in `java.base` and `java.desktop`, so these are now suppressed in the patch.

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

  Remove placeholder flag UNUSED_1; just leave a comment instead.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12645/files
  - new: https://git.openjdk.org/jdk/pull/12645/files/88a5f993..0131b9b2

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

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

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

From duke at openjdk.org  Fri Feb 24 16:04:38 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Fri, 24 Feb 2023 16:04:38 GMT
Subject: RFR: 8026369: javac potentially ambiguous overload warning needs
 an improved scheme [v2]
In-Reply-To: <tk3D21HgO9mRKLEvFHiLSqUPBqCBn483UBY8vu_Mb8E=.e9a261cb-752b-420e-967e-fbf09d8ab65b@github.com>
References: <IMxp3iCK--jYJ5Ia04i6QPYfnCHQobVcsmlI5aJXdqc=.892abcb8-7f2a-4fe9-aea2-1b1d41098a6d@github.com>
 <NlqhxTe-Li08DSIjyYVn5HI9uIAvIHZE4IG0x8tQTQw=.0ae9928e-7814-4356-bf75-11bc4eefc6be@github.com>
 <tk3D21HgO9mRKLEvFHiLSqUPBqCBn483UBY8vu_Mb8E=.e9a261cb-752b-420e-967e-fbf09d8ab65b@github.com>
Message-ID: <i1Dp-1K3ywedPnomS8q3-OWhpV_UJ5-th915f_TfKpg=.4c83976e-cedf-4a92-ba70-a64473a249b3@github.com>

On Fri, 24 Feb 2023 11:49:55 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> I think a CSR is needed as we will be generating more warnings and projects compiling with -Werror could see compilation errors

Will do - thanks.

> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java line 280:
> 
>> 278:      * Currently available.
>> 279:      */
>> 280:     public static final long UNUSED_1 = 1L<<48;
> 
> what about just adding the comment saying that this spot is free without declaring an unused flag?

Works for me - as long as it's OK that this will cause the `Flags` enum constant ordinals to renumber after that point.

Fixed in 0131b9b23a2.

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

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

From vromero at openjdk.org  Fri Feb 24 18:05:08 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 24 Feb 2023 18:05:08 GMT
Subject: RFR: 8026369: javac potentially ambiguous overload warning needs
 an improved scheme [v3]
In-Reply-To: <NHHLq4y0LkeQGPPSoHjNOquUU0_iafjmkeFZosjoFPs=.22a5e84f-eaba-4e44-b531-dcd9ea9a92c7@github.com>
References: <IMxp3iCK--jYJ5Ia04i6QPYfnCHQobVcsmlI5aJXdqc=.892abcb8-7f2a-4fe9-aea2-1b1d41098a6d@github.com>
 <NHHLq4y0LkeQGPPSoHjNOquUU0_iafjmkeFZosjoFPs=.22a5e84f-eaba-4e44-b531-dcd9ea9a92c7@github.com>
Message-ID: <ZIdOhXQBODF8-99L-8pXK452tKVwhr6fZ7lHpBafq5w=.91267b20-5a36-4ede-acdb-99898bd958be@github.com>

On Fri, 24 Feb 2023 16:04:38 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> This bug relates to the "potentially ambiguous overload" warning which is enabled by `-Xlint:overloads`.
>> 
>> The warning detects certain ambiguities that can cause problems for lambdas. For example, consider the interface `Spliterator.OfInt`, which declares these two methods:
>> 
>> void forEachRemaining(Consumer<? super Integer> action);
>> void forEachRemaining(IntConsumer action);
>> 
>> Both methods have the same name, same number of parameters, and take a lambda with the same "shape" in the same argument position. This causes an ambiguity in any code that wants to do this:
>> 
>>     spliterator.forEachRemaining(x -> { ... });
>> 
>> That code won't compile; instead, you'll get this error:
>> 
>> Ambiguity.java:4: error: reference to forEachRemaining is ambiguous
>>         spliterator.forEachRemaining(x -> { });
>>                    ^
>>   both method forEachRemaining(IntConsumer) in OfInt and method forEachRemaining(Consumer<? super Integer>) in OfInt match
>> 
>> 
>> The problem reported by the bug is that the warning fails to detect ambiguities which are created purely by inheritance, for example:
>> 
>> interface ConsumerOfInteger {
>>     void foo(Consumer<Integer> c);
>> }
>> 
>> interface IntegerConsumer {
>>     void foo(IntConsumer c);
>> }
>> 
>> // We should get a warning here...
>> interface Test extends ConsumerOfInteger, IntegerConsumer {
>> }
>> 
>> 
>> The cause of the bug is that ambiguities are detected on a per-method basis, by checking whether a method is part of an ambiguity pair when we visit that method. So if the methods in an ambiguity pair are inherited from two distinct supertypes, we'll miss the ambiguity.
>> 
>> To fix the problem, we need to look for ambiguities on a per-class level, checking all pairs of methods. However, it's not that simple - we only want to "blame" a class when that class itself, and not some supertype, is responsible for creating the ambiguity. For example, any interface extending `Spliterator.OfInt` will automatically inherit the two ambiguities mentioned above, but these are not the interface's fault so to speak so no warning should be generated. Making things more complicated is the fact that methods can be overridden and declared in generic classes so they only conflict in some subtypes, etc.
>> 
>> So we generate the warning when there are two methods m1 and m2 in a class C such that:
>> 
>> * m1 and m2 consitiute a "potentially ambiguous overload" (using the same definition as before)
>> * There is no direct supertype T of C such that m1 and m2, or some methods they override, both exist in T and constitute a "potentially ambiguous overload" as members of T
>> * We haven't already generated a warning for either m1 or m2 in class C
>> 
>> If either method is declared in C, we locate the warning there, but when both methods are inherited, there's no method declaration to point at so the warning is instead located at the class declaration.
>> 
>> I noticed a couple of other minor bugs; these are also being fixed here:
>> 
>> (1) For inherited methods, the method signatures were being reported as they are declared, rather than in the context of the class being visited. As a result, when a methods is inherited from a generic supertype, the ambiguity is less clear. Here's an example:
>> 
>> interface Upper<T> {
>>     void foo(T c);
>> }
>> 
>> interface Lower extends Upper<IntConsumer> {
>>     void foo(Consumer<Integer> c);
>> }
>> 
>> Currently, the error is reported as:
>> 
>> warning: [overloads] foo(Consumer<Integer>) in Lower is potentially ambiguous with foo(T) in Upper
>> 
>> Reporting the method signatures in the context of the class being visited makes the ambiguity clearer:
>> 
>> warning: [overloads] foo(Consumer<Integer>) in Lower is potentially ambiguous with foo(IntConsumer) in Upper
>> 
>> 
>> (2) When a method is identified as part of an ambiguous pair, we were setting a `POTENTIALLY_AMBIGUOUS` flag on it. This caused it to be forever excluded from future warnings. For methods that are declared in the class we're visiting, this makes sense, but it doesn't make sense for inherited methods, because it disqualifies them from participating in the analysis of any other class that also inherits them.
>> 
>> As a result, for a class like the one below, the compiler was only generating one warning instead of three:
>> 
>> public interface SuperIface {
>>     void foo(Consumer<Integer> c);
>> }
>> 
>> public interface I1 extends SuperIface { 
>>     void foo(IntConsumer c);        // warning was generated here
>> }   
>> 
>> public interface I2 extends SuperIface { 
>>     void foo(IntConsumer c);        // no warning was generated here
>> }   
>> 
>> public interface I3 extends SuperIface { 
>>     void foo(IntConsumer c);        // no warning was generated here
>> }   
>> 
>> 
>> With this patch the `POTENTIALLY_AMBIGUOUS` flag is no longer needed. I wasn't sure whether to renumber all the subsequent flags, or just leave an empty placeholder, so I chose the latter.
>> 
>> Finally, this fix uncovers new warnings in `java.base` and `java.desktop`, so these are now suppressed in the patch.
>
> Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove placeholder flag UNUSED_1; just leave a comment instead.

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

> 2711:      *  overloads are IntConsumer and Consumer&lt;? super Integer&gt;). So we only want
> 2712:      *  to "blame" a class when that class is itself responsible for creating the
> 2713:      *  ambiguity. So we declare that site is "responsible" for the ambigutity between

typo: ambigutity -> ambiguity

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

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

From duke at openjdk.org  Fri Feb 24 18:09:16 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Fri, 24 Feb 2023 18:09:16 GMT
Subject: RFR: 8026369: javac potentially ambiguous overload warning needs
 an improved scheme [v4]
In-Reply-To: <IMxp3iCK--jYJ5Ia04i6QPYfnCHQobVcsmlI5aJXdqc=.892abcb8-7f2a-4fe9-aea2-1b1d41098a6d@github.com>
References: <IMxp3iCK--jYJ5Ia04i6QPYfnCHQobVcsmlI5aJXdqc=.892abcb8-7f2a-4fe9-aea2-1b1d41098a6d@github.com>
Message-ID: <La7IUyuwT43IIKFp8OKW0Wd3iGPnVyvTHyJr00XXq8s=.4b0c537d-1fcd-416a-bd4f-7a1e88466be1@github.com>

> This bug relates to the "potentially ambiguous overload" warning which is enabled by `-Xlint:overloads`.
> 
> The warning detects certain ambiguities that can cause problems for lambdas. For example, consider the interface `Spliterator.OfInt`, which declares these two methods:
> 
> void forEachRemaining(Consumer<? super Integer> action);
> void forEachRemaining(IntConsumer action);
> 
> Both methods have the same name, same number of parameters, and take a lambda with the same "shape" in the same argument position. This causes an ambiguity in any code that wants to do this:
> 
>     spliterator.forEachRemaining(x -> { ... });
> 
> That code won't compile; instead, you'll get this error:
> 
> Ambiguity.java:4: error: reference to forEachRemaining is ambiguous
>         spliterator.forEachRemaining(x -> { });
>                    ^
>   both method forEachRemaining(IntConsumer) in OfInt and method forEachRemaining(Consumer<? super Integer>) in OfInt match
> 
> 
> The problem reported by the bug is that the warning fails to detect ambiguities which are created purely by inheritance, for example:
> 
> interface ConsumerOfInteger {
>     void foo(Consumer<Integer> c);
> }
> 
> interface IntegerConsumer {
>     void foo(IntConsumer c);
> }
> 
> // We should get a warning here...
> interface Test extends ConsumerOfInteger, IntegerConsumer {
> }
> 
> 
> The cause of the bug is that ambiguities are detected on a per-method basis, by checking whether a method is part of an ambiguity pair when we visit that method. So if the methods in an ambiguity pair are inherited from two distinct supertypes, we'll miss the ambiguity.
> 
> To fix the problem, we need to look for ambiguities on a per-class level, checking all pairs of methods. However, it's not that simple - we only want to "blame" a class when that class itself, and not some supertype, is responsible for creating the ambiguity. For example, any interface extending `Spliterator.OfInt` will automatically inherit the two ambiguities mentioned above, but these are not the interface's fault so to speak so no warning should be generated. Making things more complicated is the fact that methods can be overridden and declared in generic classes so they only conflict in some subtypes, etc.
> 
> So we generate the warning when there are two methods m1 and m2 in a class C such that:
> 
> * m1 and m2 consitiute a "potentially ambiguous overload" (using the same definition as before)
> * There is no direct supertype T of C such that m1 and m2, or some methods they override, both exist in T and constitute a "potentially ambiguous overload" as members of T
> * We haven't already generated a warning for either m1 or m2 in class C
> 
> If either method is declared in C, we locate the warning there, but when both methods are inherited, there's no method declaration to point at so the warning is instead located at the class declaration.
> 
> I noticed a couple of other minor bugs; these are also being fixed here:
> 
> (1) For inherited methods, the method signatures were being reported as they are declared, rather than in the context of the class being visited. As a result, when a methods is inherited from a generic supertype, the ambiguity is less clear. Here's an example:
> 
> interface Upper<T> {
>     void foo(T c);
> }
> 
> interface Lower extends Upper<IntConsumer> {
>     void foo(Consumer<Integer> c);
> }
> 
> Currently, the error is reported as:
> 
> warning: [overloads] foo(Consumer<Integer>) in Lower is potentially ambiguous with foo(T) in Upper
> 
> Reporting the method signatures in the context of the class being visited makes the ambiguity clearer:
> 
> warning: [overloads] foo(Consumer<Integer>) in Lower is potentially ambiguous with foo(IntConsumer) in Upper
> 
> 
> (2) When a method is identified as part of an ambiguous pair, we were setting a `POTENTIALLY_AMBIGUOUS` flag on it. This caused it to be forever excluded from future warnings. For methods that are declared in the class we're visiting, this makes sense, but it doesn't make sense for inherited methods, because it disqualifies them from participating in the analysis of any other class that also inherits them.
> 
> As a result, for a class like the one below, the compiler was only generating one warning instead of three:
> 
> public interface SuperIface {
>     void foo(Consumer<Integer> c);
> }
> 
> public interface I1 extends SuperIface { 
>     void foo(IntConsumer c);        // warning was generated here
> }   
> 
> public interface I2 extends SuperIface { 
>     void foo(IntConsumer c);        // no warning was generated here
> }   
> 
> public interface I3 extends SuperIface { 
>     void foo(IntConsumer c);        // no warning was generated here
> }   
> 
> 
> With this patch the `POTENTIALLY_AMBIGUOUS` flag is no longer needed. I wasn't sure whether to renumber all the subsequent flags, or just leave an empty placeholder, so I chose the latter.
> 
> Finally, this fix uncovers new warnings in `java.base` and `java.desktop`, so these are now suppressed in the patch.

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

  Fix typo in one comment and clarify another.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12645/files
  - new: https://git.openjdk.org/jdk/pull/12645/files/0131b9b2..49cbaece

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

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

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

From duke at openjdk.org  Fri Feb 24 18:09:18 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Fri, 24 Feb 2023 18:09:18 GMT
Subject: RFR: 8026369: javac potentially ambiguous overload warning needs
 an improved scheme [v3]
In-Reply-To: <ZIdOhXQBODF8-99L-8pXK452tKVwhr6fZ7lHpBafq5w=.91267b20-5a36-4ede-acdb-99898bd958be@github.com>
References: <IMxp3iCK--jYJ5Ia04i6QPYfnCHQobVcsmlI5aJXdqc=.892abcb8-7f2a-4fe9-aea2-1b1d41098a6d@github.com>
 <NHHLq4y0LkeQGPPSoHjNOquUU0_iafjmkeFZosjoFPs=.22a5e84f-eaba-4e44-b531-dcd9ea9a92c7@github.com>
 <ZIdOhXQBODF8-99L-8pXK452tKVwhr6fZ7lHpBafq5w=.91267b20-5a36-4ede-acdb-99898bd958be@github.com>
Message-ID: <ZTfQHfbgPpb-Gf14HVgZ1Agepn3pLPFpX9VepraESdQ=.d57d9b83-b5e2-4d3a-abea-0646fed69345@github.com>

On Fri, 24 Feb 2023 18:01:56 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove placeholder flag UNUSED_1; just leave a comment instead.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 2713:
> 
>> 2711:      *  overloads are IntConsumer and Consumer&lt;? super Integer&gt;). So we only want
>> 2712:      *  to "blame" a class when that class is itself responsible for creating the
>> 2713:      *  ambiguity. So we declare that site is "responsible" for the ambigutity between
> 
> typo: ambigutity -> ambiguity

Thanks - fixed.

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

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

From vromero at openjdk.org  Fri Feb 24 19:04:07 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 24 Feb 2023 19:04:07 GMT
Subject: RFR: 8026369: javac potentially ambiguous overload warning needs
 an improved scheme [v3]
In-Reply-To: <NHHLq4y0LkeQGPPSoHjNOquUU0_iafjmkeFZosjoFPs=.22a5e84f-eaba-4e44-b531-dcd9ea9a92c7@github.com>
References: <IMxp3iCK--jYJ5Ia04i6QPYfnCHQobVcsmlI5aJXdqc=.892abcb8-7f2a-4fe9-aea2-1b1d41098a6d@github.com>
 <NHHLq4y0LkeQGPPSoHjNOquUU0_iafjmkeFZosjoFPs=.22a5e84f-eaba-4e44-b531-dcd9ea9a92c7@github.com>
Message-ID: <98kTDWOcTYL9jRLZQhDXFjPmHQJQPZg8tGuUhi0Iwlk=.b91510cc-5e55-4090-919f-a5a5cc5b2347@github.com>

On Fri, 24 Feb 2023 16:04:38 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> This bug relates to the "potentially ambiguous overload" warning which is enabled by `-Xlint:overloads`.
>> 
>> The warning detects certain ambiguities that can cause problems for lambdas. For example, consider the interface `Spliterator.OfInt`, which declares these two methods:
>> 
>> void forEachRemaining(Consumer<? super Integer> action);
>> void forEachRemaining(IntConsumer action);
>> 
>> Both methods have the same name, same number of parameters, and take a lambda with the same "shape" in the same argument position. This causes an ambiguity in any code that wants to do this:
>> 
>>     spliterator.forEachRemaining(x -> { ... });
>> 
>> That code won't compile; instead, you'll get this error:
>> 
>> Ambiguity.java:4: error: reference to forEachRemaining is ambiguous
>>         spliterator.forEachRemaining(x -> { });
>>                    ^
>>   both method forEachRemaining(IntConsumer) in OfInt and method forEachRemaining(Consumer<? super Integer>) in OfInt match
>> 
>> 
>> The problem reported by the bug is that the warning fails to detect ambiguities which are created purely by inheritance, for example:
>> 
>> interface ConsumerOfInteger {
>>     void foo(Consumer<Integer> c);
>> }
>> 
>> interface IntegerConsumer {
>>     void foo(IntConsumer c);
>> }
>> 
>> // We should get a warning here...
>> interface Test extends ConsumerOfInteger, IntegerConsumer {
>> }
>> 
>> 
>> The cause of the bug is that ambiguities are detected on a per-method basis, by checking whether a method is part of an ambiguity pair when we visit that method. So if the methods in an ambiguity pair are inherited from two distinct supertypes, we'll miss the ambiguity.
>> 
>> To fix the problem, we need to look for ambiguities on a per-class level, checking all pairs of methods. However, it's not that simple - we only want to "blame" a class when that class itself, and not some supertype, is responsible for creating the ambiguity. For example, any interface extending `Spliterator.OfInt` will automatically inherit the two ambiguities mentioned above, but these are not the interface's fault so to speak so no warning should be generated. Making things more complicated is the fact that methods can be overridden and declared in generic classes so they only conflict in some subtypes, etc.
>> 
>> So we generate the warning when there are two methods m1 and m2 in a class C such that:
>> 
>> * m1 and m2 consitiute a "potentially ambiguous overload" (using the same definition as before)
>> * There is no direct supertype T of C such that m1 and m2, or some methods they override, both exist in T and constitute a "potentially ambiguous overload" as members of T
>> * We haven't already generated a warning for either m1 or m2 in class C
>> 
>> If either method is declared in C, we locate the warning there, but when both methods are inherited, there's no method declaration to point at so the warning is instead located at the class declaration.
>> 
>> I noticed a couple of other minor bugs; these are also being fixed here:
>> 
>> (1) For inherited methods, the method signatures were being reported as they are declared, rather than in the context of the class being visited. As a result, when a methods is inherited from a generic supertype, the ambiguity is less clear. Here's an example:
>> 
>> interface Upper<T> {
>>     void foo(T c);
>> }
>> 
>> interface Lower extends Upper<IntConsumer> {
>>     void foo(Consumer<Integer> c);
>> }
>> 
>> Currently, the error is reported as:
>> 
>> warning: [overloads] foo(Consumer<Integer>) in Lower is potentially ambiguous with foo(T) in Upper
>> 
>> Reporting the method signatures in the context of the class being visited makes the ambiguity clearer:
>> 
>> warning: [overloads] foo(Consumer<Integer>) in Lower is potentially ambiguous with foo(IntConsumer) in Upper
>> 
>> 
>> (2) When a method is identified as part of an ambiguous pair, we were setting a `POTENTIALLY_AMBIGUOUS` flag on it. This caused it to be forever excluded from future warnings. For methods that are declared in the class we're visiting, this makes sense, but it doesn't make sense for inherited methods, because it disqualifies them from participating in the analysis of any other class that also inherits them.
>> 
>> As a result, for a class like the one below, the compiler was only generating one warning instead of three:
>> 
>> public interface SuperIface {
>>     void foo(Consumer<Integer> c);
>> }
>> 
>> public interface I1 extends SuperIface { 
>>     void foo(IntConsumer c);        // warning was generated here
>> }   
>> 
>> public interface I2 extends SuperIface { 
>>     void foo(IntConsumer c);        // no warning was generated here
>> }   
>> 
>> public interface I3 extends SuperIface { 
>>     void foo(IntConsumer c);        // no warning was generated here
>> }   
>> 
>> 
>> With this patch the `POTENTIALLY_AMBIGUOUS` flag is no longer needed. I wasn't sure whether to renumber all the subsequent flags, or just leave an empty placeholder, so I chose the latter.
>> 
>> Finally, this fix uncovers new warnings in `java.base` and `java.desktop`, so these are now suppressed in the patch.
>
> Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove placeholder flag UNUSED_1; just leave a comment instead.

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

> 2717:      *  does not override any other methods (in which case site is responsible).
> 2718:      */
> 2719:     void checkPotentiallyAmbiguousOverloads(JCClassDecl tree, Type site) {

general comments: overall looks correct but I think the code should be split a bit using helper methods, that will help with readability, I think. Side: I'm a bit worried that overuse of streams in this code could imply some performance hit. Of course if the corresponding lint warning is not enabled we will skip it but a lot of projects compile with `-Xlint:all` nowadays.

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

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

From duke at openjdk.org  Fri Feb 24 19:30:08 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Fri, 24 Feb 2023 19:30:08 GMT
Subject: RFR: 8026369: javac potentially ambiguous overload warning needs
 an improved scheme [v3]
In-Reply-To: <98kTDWOcTYL9jRLZQhDXFjPmHQJQPZg8tGuUhi0Iwlk=.b91510cc-5e55-4090-919f-a5a5cc5b2347@github.com>
References: <IMxp3iCK--jYJ5Ia04i6QPYfnCHQobVcsmlI5aJXdqc=.892abcb8-7f2a-4fe9-aea2-1b1d41098a6d@github.com>
 <NHHLq4y0LkeQGPPSoHjNOquUU0_iafjmkeFZosjoFPs=.22a5e84f-eaba-4e44-b531-dcd9ea9a92c7@github.com>
 <98kTDWOcTYL9jRLZQhDXFjPmHQJQPZg8tGuUhi0Iwlk=.b91510cc-5e55-4090-919f-a5a5cc5b2347@github.com>
Message-ID: <LZ7r3Q3pbjdcWCb0h3osWvkTBGXtjnIJY2ZJFu7AcZc=.83196683-0e0f-4308-ac99-431c018af15e@github.com>

On Fri, 24 Feb 2023 19:00:51 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> I think the code should be split a bit using helper methods

OK - will do.

> I'm a bit worried that overuse of streams in this code could imply some performance hit

I asked basically the same question ([in a separate thread](https://mail.openjdk.org/pipermail/compiler-dev/2023-February/022259.html)) two days ago and nobody replied with a definitive answer (not surprising).

However, note also that in that same thread Christoph reported no timing difference between `Stream` vs. `for()` loop ([here](https://mail.openjdk.org/pipermail/compiler-dev/2023-February/022261.html)), although there were more allocations. FWIW.

Sorry to go off on a tangent here, but I'm sure this issue will come up again and it would be nice to have some kind of (informal) policy to go on...

I generally try to follow the "measure first, optimize second" rule to avoid preemptive "optimizations" that come at the expense of code clarity for unproven meaningful benefit.

So I can de-`Stream` the code but are we sure it's worth it? Are we going to have a no `Stream` policy in the compiler code? Why did we develop `Stream`'s if they can't be used in a mainstream tool like `javac`? Where does the madness end? :)

There is also the larger philosophical question as well, which is that if a `Stream` is appreciably slower than the semantically-equivalent `for()` loop, then isn't that a Hotspot problem, not a developer problem?

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

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

From vromero at openjdk.org  Fri Feb 24 19:52:07 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 24 Feb 2023 19:52:07 GMT
Subject: RFR: 8026369: javac potentially ambiguous overload warning needs
 an improved scheme [v3]
In-Reply-To: <LZ7r3Q3pbjdcWCb0h3osWvkTBGXtjnIJY2ZJFu7AcZc=.83196683-0e0f-4308-ac99-431c018af15e@github.com>
References: <IMxp3iCK--jYJ5Ia04i6QPYfnCHQobVcsmlI5aJXdqc=.892abcb8-7f2a-4fe9-aea2-1b1d41098a6d@github.com>
 <NHHLq4y0LkeQGPPSoHjNOquUU0_iafjmkeFZosjoFPs=.22a5e84f-eaba-4e44-b531-dcd9ea9a92c7@github.com>
 <98kTDWOcTYL9jRLZQhDXFjPmHQJQPZg8tGuUhi0Iwlk=.b91510cc-5e55-4090-919f-a5a5cc5b2347@github.com>
 <LZ7r3Q3pbjdcWCb0h3osWvkTBGXtjnIJY2ZJFu7AcZc=.83196683-0e0f-4308-ac99-431c018af15e@github.com>
Message-ID: <LRcPwyPlnlmp2j66TpinIm9K89EfZZbM7Ll67kM7DLA=.becf5103-4d8e-48d5-b699-9f699935e105@github.com>

On Fri, 24 Feb 2023 19:27:02 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 2719:
>> 
>>> 2717:      *  does not override any other methods (in which case site is responsible).
>>> 2718:      */
>>> 2719:     void checkPotentiallyAmbiguousOverloads(JCClassDecl tree, Type site) {
>> 
>> general comments: overall looks correct but I think the code should be split a bit using helper methods, that will help with readability, I think. Side: I'm a bit worried that overuse of streams in this code could imply some performance hit. Of course if the corresponding lint warning is not enabled we will skip it but a lot of projects compile with `-Xlint:all` nowadays.
>
>> I think the code should be split a bit using helper methods
> 
> OK - will do.
> 
>> I'm a bit worried that overuse of streams in this code could imply some performance hit
> 
> I asked basically the same question ([in a separate thread](https://mail.openjdk.org/pipermail/compiler-dev/2023-February/022259.html)) two days ago and nobody replied with a definitive answer (not surprising).
> 
> However, note also that in that same thread Christoph reported no timing difference between `Stream` vs. `for()` loop ([here](https://mail.openjdk.org/pipermail/compiler-dev/2023-February/022261.html)), although there were more allocations. FWIW.
> 
> Sorry to go off on a tangent here, but I'm sure this issue will come up again and it would be nice to have some kind of (informal) policy to go on...
> 
> I generally try to follow the "measure first, optimize second" rule to avoid preemptive "optimizations" that come at the expense of code clarity for unproven meaningful benefit.
> 
> So I can de-`Stream` the code but are we sure it's worth it? Are we going to have a no `Stream` policy in the compiler code? Why did we develop `Stream`'s if they can't be used in a mainstream tool like `javac`? Where does the madness end? :)
> 
> There is also the larger philosophical question as well, which is that if a `Stream` is appreciably slower than the semantically-equivalent `for()` loop, then isn't that a Hotspot problem, not a developer problem?

I'm not saying that we should de-stream the code, actually we can do that later on iff there is a performance related complain, but it is true that in the past, I have seen some performance issues and the final culprit have been streams. But you are right it could be that it is not worthy to affect the readability of the code.

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

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

From duke at openjdk.org  Fri Feb 24 20:09:07 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Fri, 24 Feb 2023 20:09:07 GMT
Subject: RFR: 8026369: javac potentially ambiguous overload warning needs
 an improved scheme [v3]
In-Reply-To: <LRcPwyPlnlmp2j66TpinIm9K89EfZZbM7Ll67kM7DLA=.becf5103-4d8e-48d5-b699-9f699935e105@github.com>
References: <IMxp3iCK--jYJ5Ia04i6QPYfnCHQobVcsmlI5aJXdqc=.892abcb8-7f2a-4fe9-aea2-1b1d41098a6d@github.com>
 <NHHLq4y0LkeQGPPSoHjNOquUU0_iafjmkeFZosjoFPs=.22a5e84f-eaba-4e44-b531-dcd9ea9a92c7@github.com>
 <98kTDWOcTYL9jRLZQhDXFjPmHQJQPZg8tGuUhi0Iwlk=.b91510cc-5e55-4090-919f-a5a5cc5b2347@github.com>
 <LZ7r3Q3pbjdcWCb0h3osWvkTBGXtjnIJY2ZJFu7AcZc=.83196683-0e0f-4308-ac99-431c018af15e@github.com>
 <LRcPwyPlnlmp2j66TpinIm9K89EfZZbM7Ll67kM7DLA=.becf5103-4d8e-48d5-b699-9f699935e105@github.com>
Message-ID: <wFxhY4VU9XEIbb2apCJdg4s5E15-yXlSSl-b6BMyS1k=.327469a7-2050-4dfc-a82f-745e0667381d@github.com>

On Fri, 24 Feb 2023 19:49:18 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>>> I think the code should be split a bit using helper methods
>> 
>> OK - will do.
>> 
>>> I'm a bit worried that overuse of streams in this code could imply some performance hit
>> 
>> I asked basically the same question ([in a separate thread](https://mail.openjdk.org/pipermail/compiler-dev/2023-February/022259.html)) two days ago and nobody replied with a definitive answer (not surprising).
>> 
>> However, note also that in that same thread Christoph reported no timing difference between `Stream` vs. `for()` loop ([here](https://mail.openjdk.org/pipermail/compiler-dev/2023-February/022261.html)), although there were more allocations. FWIW.
>> 
>> Sorry to go off on a tangent here, but I'm sure this issue will come up again and it would be nice to have some kind of (informal) policy to go on...
>> 
>> I generally try to follow the "measure first, optimize second" rule to avoid preemptive "optimizations" that come at the expense of code clarity for unproven meaningful benefit.
>> 
>> So I can de-`Stream` the code but are we sure it's worth it? Are we going to have a no `Stream` policy in the compiler code? Why did we develop `Stream`'s if they can't be used in a mainstream tool like `javac`? Where does the madness end? :)
>> 
>> There is also the larger philosophical question as well, which is that if a `Stream` is appreciably slower than the semantically-equivalent `for()` loop, then isn't that a Hotspot problem, not a developer problem?
>
> I'm not saying that we should de-stream the code, actually we can do that later on, in a separate issue, iff there is a performance related complain, but it is true that in the past, I have seen some performance issues and the final culprit have been streams. But you are right it could be that it is not worthy to affect the readability of the code.

OK thanks, I'll leave it for now - but it would be nice to (someday) do some comprehensive testing so we have a better intuitive understanding of the performance impact of using a `Stream` in any particular situation.

I wonder if there is some IDE tool that could automatically `Stream`ify and/or de-`Stream`ify loops. If so, we could apply it to the entire compiler and compare...

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

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

From vromero at openjdk.org  Fri Feb 24 20:24:05 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 24 Feb 2023 20:24:05 GMT
Subject: RFR: 8026369: javac potentially ambiguous overload warning needs
 an improved scheme [v3]
In-Reply-To: <wFxhY4VU9XEIbb2apCJdg4s5E15-yXlSSl-b6BMyS1k=.327469a7-2050-4dfc-a82f-745e0667381d@github.com>
References: <IMxp3iCK--jYJ5Ia04i6QPYfnCHQobVcsmlI5aJXdqc=.892abcb8-7f2a-4fe9-aea2-1b1d41098a6d@github.com>
 <NHHLq4y0LkeQGPPSoHjNOquUU0_iafjmkeFZosjoFPs=.22a5e84f-eaba-4e44-b531-dcd9ea9a92c7@github.com>
 <98kTDWOcTYL9jRLZQhDXFjPmHQJQPZg8tGuUhi0Iwlk=.b91510cc-5e55-4090-919f-a5a5cc5b2347@github.com>
 <LZ7r3Q3pbjdcWCb0h3osWvkTBGXtjnIJY2ZJFu7AcZc=.83196683-0e0f-4308-ac99-431c018af15e@github.com>
 <LRcPwyPlnlmp2j66TpinIm9K89EfZZbM7Ll67kM7DLA=.becf5103-4d8e-48d5-b699-9f699935e105@github.com>
 <wFxhY4VU9XEIbb2apCJdg4s5E15-yXlSSl-b6BMyS1k=.327469a7-2050-4dfc-a82f-745e0667381d@github.com>
Message-ID: <UD953877MkjcZlJwygP4tGohiJDGDGXhHAqeE0X2FbY=.9194f6e1-a31b-44c9-8a37-3b399a27130d@github.com>

On Fri, 24 Feb 2023 20:05:52 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> I'm not saying that we should de-stream the code, actually we can do that later on, in a separate issue, iff there is a performance related complain, but it is true that in the past, I have seen some performance issues and the final culprit have been streams. But you are right it could be that it is not worthy to affect the readability of the code.
>
> OK thanks, I'll leave it for now - but it would be nice to (someday) do some comprehensive testing so we have a better intuitive understanding of the performance impact of using a `Stream` in any particular situation.
> 
> I wonder if there is some IDE tool that could automatically `Stream`ify and/or de-`Stream`ify loops. If so, we could apply it to the entire compiler and compare...

yes that would be nice to have, although streams have different effects depending on how hot the code path is, so in general they are OK. Inference code is one of the places where I have seen that using streams is not a good idea for example

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

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

From vromero at openjdk.org  Fri Feb 24 22:41:09 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 24 Feb 2023 22:41:09 GMT
Subject: RFR: 8026369: javac potentially ambiguous overload warning needs
 an improved scheme [v4]
In-Reply-To: <La7IUyuwT43IIKFp8OKW0Wd3iGPnVyvTHyJr00XXq8s=.4b0c537d-1fcd-416a-bd4f-7a1e88466be1@github.com>
References: <IMxp3iCK--jYJ5Ia04i6QPYfnCHQobVcsmlI5aJXdqc=.892abcb8-7f2a-4fe9-aea2-1b1d41098a6d@github.com>
 <La7IUyuwT43IIKFp8OKW0Wd3iGPnVyvTHyJr00XXq8s=.4b0c537d-1fcd-416a-bd4f-7a1e88466be1@github.com>
Message-ID: <a76nqGkGeJn4TPnRRhiwHZTTCOhboaL0TDrbvHA2FLM=.110e0330-aa7a-49ed-8518-1ca076b1a4b3@github.com>

On Fri, 24 Feb 2023 18:09:16 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> This bug relates to the "potentially ambiguous overload" warning which is enabled by `-Xlint:overloads`.
>> 
>> The warning detects certain ambiguities that can cause problems for lambdas. For example, consider the interface `Spliterator.OfInt`, which declares these two methods:
>> 
>> void forEachRemaining(Consumer<? super Integer> action);
>> void forEachRemaining(IntConsumer action);
>> 
>> Both methods have the same name, same number of parameters, and take a lambda with the same "shape" in the same argument position. This causes an ambiguity in any code that wants to do this:
>> 
>>     spliterator.forEachRemaining(x -> { ... });
>> 
>> That code won't compile; instead, you'll get this error:
>> 
>> Ambiguity.java:4: error: reference to forEachRemaining is ambiguous
>>         spliterator.forEachRemaining(x -> { });
>>                    ^
>>   both method forEachRemaining(IntConsumer) in OfInt and method forEachRemaining(Consumer<? super Integer>) in OfInt match
>> 
>> 
>> The problem reported by the bug is that the warning fails to detect ambiguities which are created purely by inheritance, for example:
>> 
>> interface ConsumerOfInteger {
>>     void foo(Consumer<Integer> c);
>> }
>> 
>> interface IntegerConsumer {
>>     void foo(IntConsumer c);
>> }
>> 
>> // We should get a warning here...
>> interface Test extends ConsumerOfInteger, IntegerConsumer {
>> }
>> 
>> 
>> The cause of the bug is that ambiguities are detected on a per-method basis, by checking whether a method is part of an ambiguity pair when we visit that method. So if the methods in an ambiguity pair are inherited from two distinct supertypes, we'll miss the ambiguity.
>> 
>> To fix the problem, we need to look for ambiguities on a per-class level, checking all pairs of methods. However, it's not that simple - we only want to "blame" a class when that class itself, and not some supertype, is responsible for creating the ambiguity. For example, any interface extending `Spliterator.OfInt` will automatically inherit the two ambiguities mentioned above, but these are not the interface's fault so to speak so no warning should be generated. Making things more complicated is the fact that methods can be overridden and declared in generic classes so they only conflict in some subtypes, etc.
>> 
>> So we generate the warning when there are two methods m1 and m2 in a class C such that:
>> 
>> * m1 and m2 consitiute a "potentially ambiguous overload" (using the same definition as before)
>> * There is no direct supertype T of C such that m1 and m2, or some methods they override, both exist in T and constitute a "potentially ambiguous overload" as members of T
>> * We haven't already generated a warning for either m1 or m2 in class C
>> 
>> If either method is declared in C, we locate the warning there, but when both methods are inherited, there's no method declaration to point at so the warning is instead located at the class declaration.
>> 
>> I noticed a couple of other minor bugs; these are also being fixed here:
>> 
>> (1) For inherited methods, the method signatures were being reported as they are declared, rather than in the context of the class being visited. As a result, when a methods is inherited from a generic supertype, the ambiguity is less clear. Here's an example:
>> 
>> interface Upper<T> {
>>     void foo(T c);
>> }
>> 
>> interface Lower extends Upper<IntConsumer> {
>>     void foo(Consumer<Integer> c);
>> }
>> 
>> Currently, the error is reported as:
>> 
>> warning: [overloads] foo(Consumer<Integer>) in Lower is potentially ambiguous with foo(T) in Upper
>> 
>> Reporting the method signatures in the context of the class being visited makes the ambiguity clearer:
>> 
>> warning: [overloads] foo(Consumer<Integer>) in Lower is potentially ambiguous with foo(IntConsumer) in Upper
>> 
>> 
>> (2) When a method is identified as part of an ambiguous pair, we were setting a `POTENTIALLY_AMBIGUOUS` flag on it. This caused it to be forever excluded from future warnings. For methods that are declared in the class we're visiting, this makes sense, but it doesn't make sense for inherited methods, because it disqualifies them from participating in the analysis of any other class that also inherits them.
>> 
>> As a result, for a class like the one below, the compiler was only generating one warning instead of three:
>> 
>> public interface SuperIface {
>>     void foo(Consumer<Integer> c);
>> }
>> 
>> public interface I1 extends SuperIface { 
>>     void foo(IntConsumer c);        // warning was generated here
>> }   
>> 
>> public interface I2 extends SuperIface { 
>>     void foo(IntConsumer c);        // no warning was generated here
>> }   
>> 
>> public interface I3 extends SuperIface { 
>>     void foo(IntConsumer c);        // no warning was generated here
>> }   
>> 
>> 
>> With this patch the `POTENTIALLY_AMBIGUOUS` flag is no longer needed. I wasn't sure whether to renumber all the subsequent flags, or just leave an empty placeholder, so I chose the latter.
>> 
>> Finally, this fix uncovers new warnings in `java.base` and `java.desktop`, so these are now suppressed in the patch.
>
> Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo in one comment and clarify another.

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

> 2728:             types.membersClosure(site, false).getSymbols(new ClashFilter(site), RECURSIVE).spliterator(), false)
> 2729:           .map(MethodSymbol.class::cast)
> 2730:           .filter(m -> m.owner.type.tsym != syms.objectType.tsym)

nit: this filter could be folded with the one above, `new ClashFilter(site)`

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

> 2770:                 java.util.List<MethodSymbol> overriddenMethods = list.stream()
> 2771:                   .filter(m2 -> m2 != m)
> 2772:                   .filter(m2 -> overrides.test(m, m2))

can these two filters be folded?

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

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

From duke at openjdk.org  Sat Feb 25 03:57:30 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Sat, 25 Feb 2023 03:57:30 GMT
Subject: RFR: 8026369: javac potentially ambiguous overload warning needs
 an improved scheme [v5]
In-Reply-To: <IMxp3iCK--jYJ5Ia04i6QPYfnCHQobVcsmlI5aJXdqc=.892abcb8-7f2a-4fe9-aea2-1b1d41098a6d@github.com>
References: <IMxp3iCK--jYJ5Ia04i6QPYfnCHQobVcsmlI5aJXdqc=.892abcb8-7f2a-4fe9-aea2-1b1d41098a6d@github.com>
Message-ID: <kfjz51X87aU9nppjkM08j-GuyuWOQ9m_vzTugkjYxVE=.75e83ec8-5810-43cb-8bd1-2a3b5db76b0d@github.com>

> This bug relates to the "potentially ambiguous overload" warning which is enabled by `-Xlint:overloads`.
> 
> The warning detects certain ambiguities that can cause problems for lambdas. For example, consider the interface `Spliterator.OfInt`, which declares these two methods:
> 
> void forEachRemaining(Consumer<? super Integer> action);
> void forEachRemaining(IntConsumer action);
> 
> Both methods have the same name, same number of parameters, and take a lambda with the same "shape" in the same argument position. This causes an ambiguity in any code that wants to do this:
> 
>     spliterator.forEachRemaining(x -> { ... });
> 
> That code won't compile; instead, you'll get this error:
> 
> Ambiguity.java:4: error: reference to forEachRemaining is ambiguous
>         spliterator.forEachRemaining(x -> { });
>                    ^
>   both method forEachRemaining(IntConsumer) in OfInt and method forEachRemaining(Consumer<? super Integer>) in OfInt match
> 
> 
> The problem reported by the bug is that the warning fails to detect ambiguities which are created purely by inheritance, for example:
> 
> interface ConsumerOfInteger {
>     void foo(Consumer<Integer> c);
> }
> 
> interface IntegerConsumer {
>     void foo(IntConsumer c);
> }
> 
> // We should get a warning here...
> interface Test extends ConsumerOfInteger, IntegerConsumer {
> }
> 
> 
> The cause of the bug is that ambiguities are detected on a per-method basis, by checking whether a method is part of an ambiguity pair when we visit that method. So if the methods in an ambiguity pair are inherited from two distinct supertypes, we'll miss the ambiguity.
> 
> To fix the problem, we need to look for ambiguities on a per-class level, checking all pairs of methods. However, it's not that simple - we only want to "blame" a class when that class itself, and not some supertype, is responsible for creating the ambiguity. For example, any interface extending `Spliterator.OfInt` will automatically inherit the two ambiguities mentioned above, but these are not the interface's fault so to speak so no warning should be generated. Making things more complicated is the fact that methods can be overridden and declared in generic classes so they only conflict in some subtypes, etc.
> 
> So we generate the warning when there are two methods m1 and m2 in a class C such that:
> 
> * m1 and m2 consitiute a "potentially ambiguous overload" (using the same definition as before)
> * There is no direct supertype T of C such that m1 and m2, or some methods they override, both exist in T and constitute a "potentially ambiguous overload" as members of T
> * We haven't already generated a warning for either m1 or m2 in class C
> 
> If either method is declared in C, we locate the warning there, but when both methods are inherited, there's no method declaration to point at so the warning is instead located at the class declaration.
> 
> I noticed a couple of other minor bugs; these are also being fixed here:
> 
> (1) For inherited methods, the method signatures were being reported as they are declared, rather than in the context of the class being visited. As a result, when a methods is inherited from a generic supertype, the ambiguity is less clear. Here's an example:
> 
> interface Upper<T> {
>     void foo(T c);
> }
> 
> interface Lower extends Upper<IntConsumer> {
>     void foo(Consumer<Integer> c);
> }
> 
> Currently, the error is reported as:
> 
> warning: [overloads] foo(Consumer<Integer>) in Lower is potentially ambiguous with foo(T) in Upper
> 
> Reporting the method signatures in the context of the class being visited makes the ambiguity clearer:
> 
> warning: [overloads] foo(Consumer<Integer>) in Lower is potentially ambiguous with foo(IntConsumer) in Upper
> 
> 
> (2) When a method is identified as part of an ambiguous pair, we were setting a `POTENTIALLY_AMBIGUOUS` flag on it. This caused it to be forever excluded from future warnings. For methods that are declared in the class we're visiting, this makes sense, but it doesn't make sense for inherited methods, because it disqualifies them from participating in the analysis of any other class that also inherits them.
> 
> As a result, for a class like the one below, the compiler was only generating one warning instead of three:
> 
> public interface SuperIface {
>     void foo(Consumer<Integer> c);
> }
> 
> public interface I1 extends SuperIface { 
>     void foo(IntConsumer c);        // warning was generated here
> }   
> 
> public interface I2 extends SuperIface { 
>     void foo(IntConsumer c);        // no warning was generated here
> }   
> 
> public interface I3 extends SuperIface { 
>     void foo(IntConsumer c);        // no warning was generated here
> }   
> 
> 
> With this patch the `POTENTIALLY_AMBIGUOUS` flag is no longer needed. I wasn't sure whether to renumber all the subsequent flags, or just leave an empty placeholder, so I chose the latter.
> 
> Finally, this fix uncovers new warnings in `java.base` and `java.desktop`, so these are now suppressed in the patch.

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

  Do some refactoring & cleanup suggested in reviews.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12645/files
  - new: https://git.openjdk.org/jdk/pull/12645/files/49cbaece..7d8a54c6

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

  Stats: 158 lines in 1 file changed: 76 ins; 31 del; 51 mod
  Patch: https://git.openjdk.org/jdk/pull/12645.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12645/head:pull/12645

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

From duke at openjdk.org  Sat Feb 25 03:57:31 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Sat, 25 Feb 2023 03:57:31 GMT
Subject: RFR: 8026369: javac potentially ambiguous overload warning needs
 an improved scheme [v4]
In-Reply-To: <a76nqGkGeJn4TPnRRhiwHZTTCOhboaL0TDrbvHA2FLM=.110e0330-aa7a-49ed-8518-1ca076b1a4b3@github.com>
References: <IMxp3iCK--jYJ5Ia04i6QPYfnCHQobVcsmlI5aJXdqc=.892abcb8-7f2a-4fe9-aea2-1b1d41098a6d@github.com>
 <La7IUyuwT43IIKFp8OKW0Wd3iGPnVyvTHyJr00XXq8s=.4b0c537d-1fcd-416a-bd4f-7a1e88466be1@github.com>
 <a76nqGkGeJn4TPnRRhiwHZTTCOhboaL0TDrbvHA2FLM=.110e0330-aa7a-49ed-8518-1ca076b1a4b3@github.com>
Message-ID: <1Ffr-tqo8AxPD6H19yrf_OPfLUdTwcAFHLakCLlE0_w=.9877ea14-8715-4ae8-b6e8-210bd7e2159a@github.com>

On Fri, 24 Feb 2023 22:24:10 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix typo in one comment and clarify another.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 2730:
> 
>> 2728:             types.membersClosure(site, false).getSymbols(new ClashFilter(site), RECURSIVE).spliterator(), false)
>> 2729:           .map(MethodSymbol.class::cast)
>> 2730:           .filter(m -> m.owner.type.tsym != syms.objectType.tsym)
> 
> nit: this filter could be folded with the one above, `new ClashFilter(site)`

Should be fixed in 7d8a54c6679.

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 2772:
> 
>> 2770:                 java.util.List<MethodSymbol> overriddenMethods = list.stream()
>> 2771:                   .filter(m2 -> m2 != m)
>> 2772:                   .filter(m2 -> overrides.test(m, m2))
> 
> can these two filters be folded?

Should be fixed in 7d8a54c6679.

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

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

From vromero at openjdk.org  Sat Feb 25 04:08:12 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Sat, 25 Feb 2023 04:08:12 GMT
Subject: RFR: 8026369: javac potentially ambiguous overload warning needs
 an improved scheme [v4]
In-Reply-To: <La7IUyuwT43IIKFp8OKW0Wd3iGPnVyvTHyJr00XXq8s=.4b0c537d-1fcd-416a-bd4f-7a1e88466be1@github.com>
References: <IMxp3iCK--jYJ5Ia04i6QPYfnCHQobVcsmlI5aJXdqc=.892abcb8-7f2a-4fe9-aea2-1b1d41098a6d@github.com>
 <La7IUyuwT43IIKFp8OKW0Wd3iGPnVyvTHyJr00XXq8s=.4b0c537d-1fcd-416a-bd4f-7a1e88466be1@github.com>
Message-ID: <PkTEmILJ73U76aqatkz4FJ4yZa5biyx4iMgbES9cMRk=.e8d752a1-af8c-4339-8362-d2187dd19287@github.com>

On Fri, 24 Feb 2023 18:09:16 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> This bug relates to the "potentially ambiguous overload" warning which is enabled by `-Xlint:overloads`.
>> 
>> The warning detects certain ambiguities that can cause problems for lambdas. For example, consider the interface `Spliterator.OfInt`, which declares these two methods:
>> 
>> void forEachRemaining(Consumer<? super Integer> action);
>> void forEachRemaining(IntConsumer action);
>> 
>> Both methods have the same name, same number of parameters, and take a lambda with the same "shape" in the same argument position. This causes an ambiguity in any code that wants to do this:
>> 
>>     spliterator.forEachRemaining(x -> { ... });
>> 
>> That code won't compile; instead, you'll get this error:
>> 
>> Ambiguity.java:4: error: reference to forEachRemaining is ambiguous
>>         spliterator.forEachRemaining(x -> { });
>>                    ^
>>   both method forEachRemaining(IntConsumer) in OfInt and method forEachRemaining(Consumer<? super Integer>) in OfInt match
>> 
>> 
>> The problem reported by the bug is that the warning fails to detect ambiguities which are created purely by inheritance, for example:
>> 
>> interface ConsumerOfInteger {
>>     void foo(Consumer<Integer> c);
>> }
>> 
>> interface IntegerConsumer {
>>     void foo(IntConsumer c);
>> }
>> 
>> // We should get a warning here...
>> interface Test extends ConsumerOfInteger, IntegerConsumer {
>> }
>> 
>> 
>> The cause of the bug is that ambiguities are detected on a per-method basis, by checking whether a method is part of an ambiguity pair when we visit that method. So if the methods in an ambiguity pair are inherited from two distinct supertypes, we'll miss the ambiguity.
>> 
>> To fix the problem, we need to look for ambiguities on a per-class level, checking all pairs of methods. However, it's not that simple - we only want to "blame" a class when that class itself, and not some supertype, is responsible for creating the ambiguity. For example, any interface extending `Spliterator.OfInt` will automatically inherit the two ambiguities mentioned above, but these are not the interface's fault so to speak so no warning should be generated. Making things more complicated is the fact that methods can be overridden and declared in generic classes so they only conflict in some subtypes, etc.
>> 
>> So we generate the warning when there are two methods m1 and m2 in a class C such that:
>> 
>> * m1 and m2 consitiute a "potentially ambiguous overload" (using the same definition as before)
>> * There is no direct supertype T of C such that m1 and m2, or some methods they override, both exist in T and constitute a "potentially ambiguous overload" as members of T
>> * We haven't already generated a warning for either m1 or m2 in class C
>> 
>> If either method is declared in C, we locate the warning there, but when both methods are inherited, there's no method declaration to point at so the warning is instead located at the class declaration.
>> 
>> I noticed a couple of other minor bugs; these are also being fixed here:
>> 
>> (1) For inherited methods, the method signatures were being reported as they are declared, rather than in the context of the class being visited. As a result, when a methods is inherited from a generic supertype, the ambiguity is less clear. Here's an example:
>> 
>> interface Upper<T> {
>>     void foo(T c);
>> }
>> 
>> interface Lower extends Upper<IntConsumer> {
>>     void foo(Consumer<Integer> c);
>> }
>> 
>> Currently, the error is reported as:
>> 
>> warning: [overloads] foo(Consumer<Integer>) in Lower is potentially ambiguous with foo(T) in Upper
>> 
>> Reporting the method signatures in the context of the class being visited makes the ambiguity clearer:
>> 
>> warning: [overloads] foo(Consumer<Integer>) in Lower is potentially ambiguous with foo(IntConsumer) in Upper
>> 
>> 
>> (2) When a method is identified as part of an ambiguous pair, we were setting a `POTENTIALLY_AMBIGUOUS` flag on it. This caused it to be forever excluded from future warnings. For methods that are declared in the class we're visiting, this makes sense, but it doesn't make sense for inherited methods, because it disqualifies them from participating in the analysis of any other class that also inherits them.
>> 
>> As a result, for a class like the one below, the compiler was only generating one warning instead of three:
>> 
>> public interface SuperIface {
>>     void foo(Consumer<Integer> c);
>> }
>> 
>> public interface I1 extends SuperIface { 
>>     void foo(IntConsumer c);        // warning was generated here
>> }   
>> 
>> public interface I2 extends SuperIface { 
>>     void foo(IntConsumer c);        // no warning was generated here
>> }   
>> 
>> public interface I3 extends SuperIface { 
>>     void foo(IntConsumer c);        // no warning was generated here
>> }   
>> 
>> 
>> With this patch the `POTENTIALLY_AMBIGUOUS` flag is no longer needed. I wasn't sure whether to renumber all the subsequent flags, or just leave an empty placeholder, so I chose the latter.
>> 
>> Finally, this fix uncovers new warnings in `java.base` and `java.desktop`, so these are now suppressed in the patch.
>
> Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo in one comment and clarify another.

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

> 2734:           .sorted(Comparator.comparing(e -> e.getKey().toString()))
> 2735:           .map(Map.Entry::getValue)
> 2736:           .peek(Collections::reverse)               // seems to help warning ordering

not sure about reversing the order here, it seems to me that if the order is reversed then the warning is shown in the first occurrence of a method instead of in the second which is the offending one. So for example for this code:


    interface I1 {
        void foo(Consumer<Integer> c);
        void foo(IntConsumer c);
    }

the warning is shown for the first method when I think it should be shown for the second which is the one introducing the ambiguity

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

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

From vromero at openjdk.org  Sat Feb 25 12:24:06 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Sat, 25 Feb 2023 12:24:06 GMT
Subject: RFR: 8026369: javac potentially ambiguous overload warning needs
 an improved scheme [v5]
In-Reply-To: <kfjz51X87aU9nppjkM08j-GuyuWOQ9m_vzTugkjYxVE=.75e83ec8-5810-43cb-8bd1-2a3b5db76b0d@github.com>
References: <IMxp3iCK--jYJ5Ia04i6QPYfnCHQobVcsmlI5aJXdqc=.892abcb8-7f2a-4fe9-aea2-1b1d41098a6d@github.com>
 <kfjz51X87aU9nppjkM08j-GuyuWOQ9m_vzTugkjYxVE=.75e83ec8-5810-43cb-8bd1-2a3b5db76b0d@github.com>
Message-ID: <6T8-fJe2Ova0tUXbJPkEQEXB42bLiZnStlHmucaAUTQ=.162c3a53-1409-4710-bc7e-0fe22b8da263@github.com>

On Sat, 25 Feb 2023 03:57:30 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> This bug relates to the "potentially ambiguous overload" warning which is enabled by `-Xlint:overloads`.
>> 
>> The warning detects certain ambiguities that can cause problems for lambdas. For example, consider the interface `Spliterator.OfInt`, which declares these two methods:
>> 
>> void forEachRemaining(Consumer<? super Integer> action);
>> void forEachRemaining(IntConsumer action);
>> 
>> Both methods have the same name, same number of parameters, and take a lambda with the same "shape" in the same argument position. This causes an ambiguity in any code that wants to do this:
>> 
>>     spliterator.forEachRemaining(x -> { ... });
>> 
>> That code won't compile; instead, you'll get this error:
>> 
>> Ambiguity.java:4: error: reference to forEachRemaining is ambiguous
>>         spliterator.forEachRemaining(x -> { });
>>                    ^
>>   both method forEachRemaining(IntConsumer) in OfInt and method forEachRemaining(Consumer<? super Integer>) in OfInt match
>> 
>> 
>> The problem reported by the bug is that the warning fails to detect ambiguities which are created purely by inheritance, for example:
>> 
>> interface ConsumerOfInteger {
>>     void foo(Consumer<Integer> c);
>> }
>> 
>> interface IntegerConsumer {
>>     void foo(IntConsumer c);
>> }
>> 
>> // We should get a warning here...
>> interface Test extends ConsumerOfInteger, IntegerConsumer {
>> }
>> 
>> 
>> The cause of the bug is that ambiguities are detected on a per-method basis, by checking whether a method is part of an ambiguity pair when we visit that method. So if the methods in an ambiguity pair are inherited from two distinct supertypes, we'll miss the ambiguity.
>> 
>> To fix the problem, we need to look for ambiguities on a per-class level, checking all pairs of methods. However, it's not that simple - we only want to "blame" a class when that class itself, and not some supertype, is responsible for creating the ambiguity. For example, any interface extending `Spliterator.OfInt` will automatically inherit the two ambiguities mentioned above, but these are not the interface's fault so to speak so no warning should be generated. Making things more complicated is the fact that methods can be overridden and declared in generic classes so they only conflict in some subtypes, etc.
>> 
>> So we generate the warning when there are two methods m1 and m2 in a class C such that:
>> 
>> * m1 and m2 consitiute a "potentially ambiguous overload" (using the same definition as before)
>> * There is no direct supertype T of C such that m1 and m2, or some methods they override, both exist in T and constitute a "potentially ambiguous overload" as members of T
>> * We haven't already generated a warning for either m1 or m2 in class C
>> 
>> If either method is declared in C, we locate the warning there, but when both methods are inherited, there's no method declaration to point at so the warning is instead located at the class declaration.
>> 
>> I noticed a couple of other minor bugs; these are also being fixed here:
>> 
>> (1) For inherited methods, the method signatures were being reported as they are declared, rather than in the context of the class being visited. As a result, when a methods is inherited from a generic supertype, the ambiguity is less clear. Here's an example:
>> 
>> interface Upper<T> {
>>     void foo(T c);
>> }
>> 
>> interface Lower extends Upper<IntConsumer> {
>>     void foo(Consumer<Integer> c);
>> }
>> 
>> Currently, the error is reported as:
>> 
>> warning: [overloads] foo(Consumer<Integer>) in Lower is potentially ambiguous with foo(T) in Upper
>> 
>> Reporting the method signatures in the context of the class being visited makes the ambiguity clearer:
>> 
>> warning: [overloads] foo(Consumer<Integer>) in Lower is potentially ambiguous with foo(IntConsumer) in Upper
>> 
>> 
>> (2) When a method is identified as part of an ambiguous pair, we were setting a `POTENTIALLY_AMBIGUOUS` flag on it. This caused it to be forever excluded from future warnings. For methods that are declared in the class we're visiting, this makes sense, but it doesn't make sense for inherited methods, because it disqualifies them from participating in the analysis of any other class that also inherits them.
>> 
>> As a result, for a class like the one below, the compiler was only generating one warning instead of three:
>> 
>> public interface SuperIface {
>>     void foo(Consumer<Integer> c);
>> }
>> 
>> public interface I1 extends SuperIface { 
>>     void foo(IntConsumer c);        // warning was generated here
>> }   
>> 
>> public interface I2 extends SuperIface { 
>>     void foo(IntConsumer c);        // no warning was generated here
>> }   
>> 
>> public interface I3 extends SuperIface { 
>>     void foo(IntConsumer c);        // no warning was generated here
>> }   
>> 
>> 
>> With this patch the `POTENTIALLY_AMBIGUOUS` flag is no longer needed. I wasn't sure whether to renumber all the subsequent flags, or just leave an empty placeholder, so I chose the latter.
>> 
>> Finally, this fix uncovers new warnings in `java.base` and `java.desktop`, so these are now suppressed in the patch.
>
> Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Do some refactoring & cleanup suggested in reviews.

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

> 99:     // Flag bits indicating which item(s) chosen from a pair of items
> 100:     private static final int FIRST = 0x01;
> 101:     private static final int SECOND = 0x02;

not sure about this flags, won't they clash with the existing flags?

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

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

From vromero at openjdk.org  Sat Feb 25 13:41:16 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Sat, 25 Feb 2023 13:41:16 GMT
Subject: RFR: 8026369: javac potentially ambiguous overload warning needs
 an improved scheme [v5]
In-Reply-To: <kfjz51X87aU9nppjkM08j-GuyuWOQ9m_vzTugkjYxVE=.75e83ec8-5810-43cb-8bd1-2a3b5db76b0d@github.com>
References: <IMxp3iCK--jYJ5Ia04i6QPYfnCHQobVcsmlI5aJXdqc=.892abcb8-7f2a-4fe9-aea2-1b1d41098a6d@github.com>
 <kfjz51X87aU9nppjkM08j-GuyuWOQ9m_vzTugkjYxVE=.75e83ec8-5810-43cb-8bd1-2a3b5db76b0d@github.com>
Message-ID: <zmXwajsexkHVYrThszlpiKVhvbGQk86OAgpl7XUqesk=.54943ead-e540-46e7-b4b4-31595f823206@github.com>

On Sat, 25 Feb 2023 03:57:30 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> This bug relates to the "potentially ambiguous overload" warning which is enabled by `-Xlint:overloads`.
>> 
>> The warning detects certain ambiguities that can cause problems for lambdas. For example, consider the interface `Spliterator.OfInt`, which declares these two methods:
>> 
>> void forEachRemaining(Consumer<? super Integer> action);
>> void forEachRemaining(IntConsumer action);
>> 
>> Both methods have the same name, same number of parameters, and take a lambda with the same "shape" in the same argument position. This causes an ambiguity in any code that wants to do this:
>> 
>>     spliterator.forEachRemaining(x -> { ... });
>> 
>> That code won't compile; instead, you'll get this error:
>> 
>> Ambiguity.java:4: error: reference to forEachRemaining is ambiguous
>>         spliterator.forEachRemaining(x -> { });
>>                    ^
>>   both method forEachRemaining(IntConsumer) in OfInt and method forEachRemaining(Consumer<? super Integer>) in OfInt match
>> 
>> 
>> The problem reported by the bug is that the warning fails to detect ambiguities which are created purely by inheritance, for example:
>> 
>> interface ConsumerOfInteger {
>>     void foo(Consumer<Integer> c);
>> }
>> 
>> interface IntegerConsumer {
>>     void foo(IntConsumer c);
>> }
>> 
>> // We should get a warning here...
>> interface Test extends ConsumerOfInteger, IntegerConsumer {
>> }
>> 
>> 
>> The cause of the bug is that ambiguities are detected on a per-method basis, by checking whether a method is part of an ambiguity pair when we visit that method. So if the methods in an ambiguity pair are inherited from two distinct supertypes, we'll miss the ambiguity.
>> 
>> To fix the problem, we need to look for ambiguities on a per-class level, checking all pairs of methods. However, it's not that simple - we only want to "blame" a class when that class itself, and not some supertype, is responsible for creating the ambiguity. For example, any interface extending `Spliterator.OfInt` will automatically inherit the two ambiguities mentioned above, but these are not the interface's fault so to speak so no warning should be generated. Making things more complicated is the fact that methods can be overridden and declared in generic classes so they only conflict in some subtypes, etc.
>> 
>> So we generate the warning when there are two methods m1 and m2 in a class C such that:
>> 
>> * m1 and m2 consitiute a "potentially ambiguous overload" (using the same definition as before)
>> * There is no direct supertype T of C such that m1 and m2, or some methods they override, both exist in T and constitute a "potentially ambiguous overload" as members of T
>> * We haven't already generated a warning for either m1 or m2 in class C
>> 
>> If either method is declared in C, we locate the warning there, but when both methods are inherited, there's no method declaration to point at so the warning is instead located at the class declaration.
>> 
>> I noticed a couple of other minor bugs; these are also being fixed here:
>> 
>> (1) For inherited methods, the method signatures were being reported as they are declared, rather than in the context of the class being visited. As a result, when a methods is inherited from a generic supertype, the ambiguity is less clear. Here's an example:
>> 
>> interface Upper<T> {
>>     void foo(T c);
>> }
>> 
>> interface Lower extends Upper<IntConsumer> {
>>     void foo(Consumer<Integer> c);
>> }
>> 
>> Currently, the error is reported as:
>> 
>> warning: [overloads] foo(Consumer<Integer>) in Lower is potentially ambiguous with foo(T) in Upper
>> 
>> Reporting the method signatures in the context of the class being visited makes the ambiguity clearer:
>> 
>> warning: [overloads] foo(Consumer<Integer>) in Lower is potentially ambiguous with foo(IntConsumer) in Upper
>> 
>> 
>> (2) When a method is identified as part of an ambiguous pair, we were setting a `POTENTIALLY_AMBIGUOUS` flag on it. This caused it to be forever excluded from future warnings. For methods that are declared in the class we're visiting, this makes sense, but it doesn't make sense for inherited methods, because it disqualifies them from participating in the analysis of any other class that also inherits them.
>> 
>> As a result, for a class like the one below, the compiler was only generating one warning instead of three:
>> 
>> public interface SuperIface {
>>     void foo(Consumer<Integer> c);
>> }
>> 
>> public interface I1 extends SuperIface { 
>>     void foo(IntConsumer c);        // warning was generated here
>> }   
>> 
>> public interface I2 extends SuperIface { 
>>     void foo(IntConsumer c);        // no warning was generated here
>> }   
>> 
>> public interface I3 extends SuperIface { 
>>     void foo(IntConsumer c);        // no warning was generated here
>> }   
>> 
>> 
>> With this patch the `POTENTIALLY_AMBIGUOUS` flag is no longer needed. I wasn't sure whether to renumber all the subsequent flags, or just leave an empty placeholder, so I chose the latter.
>> 
>> Finally, this fix uncovers new warnings in `java.base` and `java.desktop`, so these are now suppressed in the patch.
>
> Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Do some refactoring & cleanup suggested in reviews.

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

> 2763:      *  any other methods; in this case the class is definitely responsible.
> 2764:      */
> 2765:     BiPredicate<MethodSymbol, MethodSymbol> buildResponsiblePredicate(Type site,

this method not only builds the predicate as its name indicates, it also removes methods from the `methodGroups`, not saying that we should split this method but I think that this removing activity should be mentioned in the comment above

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

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

From duke at openjdk.org  Sat Feb 25 16:07:24 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Sat, 25 Feb 2023 16:07:24 GMT
Subject: RFR: 8026369: javac potentially ambiguous overload warning needs
 an improved scheme [v6]
In-Reply-To: <IMxp3iCK--jYJ5Ia04i6QPYfnCHQobVcsmlI5aJXdqc=.892abcb8-7f2a-4fe9-aea2-1b1d41098a6d@github.com>
References: <IMxp3iCK--jYJ5Ia04i6QPYfnCHQobVcsmlI5aJXdqc=.892abcb8-7f2a-4fe9-aea2-1b1d41098a6d@github.com>
Message-ID: <7CIC6bBj00Mh18mr-g3j6HszbQzf88ND1OHaCW8_ydk=.b6ad3d5b-8bec-47ff-a091-bc483feaee12@github.com>

> This bug relates to the "potentially ambiguous overload" warning which is enabled by `-Xlint:overloads`.
> 
> The warning detects certain ambiguities that can cause problems for lambdas. For example, consider the interface `Spliterator.OfInt`, which declares these two methods:
> 
> void forEachRemaining(Consumer<? super Integer> action);
> void forEachRemaining(IntConsumer action);
> 
> Both methods have the same name, same number of parameters, and take a lambda with the same "shape" in the same argument position. This causes an ambiguity in any code that wants to do this:
> 
>     spliterator.forEachRemaining(x -> { ... });
> 
> That code won't compile; instead, you'll get this error:
> 
> Ambiguity.java:4: error: reference to forEachRemaining is ambiguous
>         spliterator.forEachRemaining(x -> { });
>                    ^
>   both method forEachRemaining(IntConsumer) in OfInt and method forEachRemaining(Consumer<? super Integer>) in OfInt match
> 
> 
> The problem reported by the bug is that the warning fails to detect ambiguities which are created purely by inheritance, for example:
> 
> interface ConsumerOfInteger {
>     void foo(Consumer<Integer> c);
> }
> 
> interface IntegerConsumer {
>     void foo(IntConsumer c);
> }
> 
> // We should get a warning here...
> interface Test extends ConsumerOfInteger, IntegerConsumer {
> }
> 
> 
> The cause of the bug is that ambiguities are detected on a per-method basis, by checking whether a method is part of an ambiguity pair when we visit that method. So if the methods in an ambiguity pair are inherited from two distinct supertypes, we'll miss the ambiguity.
> 
> To fix the problem, we need to look for ambiguities on a per-class level, checking all pairs of methods. However, it's not that simple - we only want to "blame" a class when that class itself, and not some supertype, is responsible for creating the ambiguity. For example, any interface extending `Spliterator.OfInt` will automatically inherit the two ambiguities mentioned above, but these are not the interface's fault so to speak so no warning should be generated. Making things more complicated is the fact that methods can be overridden and declared in generic classes so they only conflict in some subtypes, etc.
> 
> So we generate the warning when there are two methods m1 and m2 in a class C such that:
> 
> * m1 and m2 consitiute a "potentially ambiguous overload" (using the same definition as before)
> * There is no direct supertype T of C such that m1 and m2, or some methods they override, both exist in T and constitute a "potentially ambiguous overload" as members of T
> * We haven't already generated a warning for either m1 or m2 in class C
> 
> If either method is declared in C, we locate the warning there, but when both methods are inherited, there's no method declaration to point at so the warning is instead located at the class declaration.
> 
> I noticed a couple of other minor bugs; these are also being fixed here:
> 
> (1) For inherited methods, the method signatures were being reported as they are declared, rather than in the context of the class being visited. As a result, when a methods is inherited from a generic supertype, the ambiguity is less clear. Here's an example:
> 
> interface Upper<T> {
>     void foo(T c);
> }
> 
> interface Lower extends Upper<IntConsumer> {
>     void foo(Consumer<Integer> c);
> }
> 
> Currently, the error is reported as:
> 
> warning: [overloads] foo(Consumer<Integer>) in Lower is potentially ambiguous with foo(T) in Upper
> 
> Reporting the method signatures in the context of the class being visited makes the ambiguity clearer:
> 
> warning: [overloads] foo(Consumer<Integer>) in Lower is potentially ambiguous with foo(IntConsumer) in Upper
> 
> 
> (2) When a method is identified as part of an ambiguous pair, we were setting a `POTENTIALLY_AMBIGUOUS` flag on it. This caused it to be forever excluded from future warnings. For methods that are declared in the class we're visiting, this makes sense, but it doesn't make sense for inherited methods, because it disqualifies them from participating in the analysis of any other class that also inherits them.
> 
> As a result, for a class like the one below, the compiler was only generating one warning instead of three:
> 
> public interface SuperIface {
>     void foo(Consumer<Integer> c);
> }
> 
> public interface I1 extends SuperIface { 
>     void foo(IntConsumer c);        // warning was generated here
> }   
> 
> public interface I2 extends SuperIface { 
>     void foo(IntConsumer c);        // no warning was generated here
> }   
> 
> public interface I3 extends SuperIface { 
>     void foo(IntConsumer c);        // no warning was generated here
> }   
> 
> 
> With this patch the `POTENTIALLY_AMBIGUOUS` flag is no longer needed. I wasn't sure whether to renumber all the subsequent flags, or just leave an empty placeholder, so I chose the latter.
> 
> Finally, this fix uncovers new warnings in `java.base` and `java.desktop`, so these are now suppressed in the patch.

Archie L. Cobbs has updated the pull request incrementally with two additional commits since the last revision:

 - Process methods in order so the second method triggers the warning.
 - Clean up previous buildResponsiblePredicate() refactoring, which was incomplete.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12645/files
  - new: https://git.openjdk.org/jdk/pull/12645/files/7d8a54c6..e25ceced

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

  Stats: 32 lines in 3 files changed: 7 ins; 10 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/12645.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12645/head:pull/12645

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

From duke at openjdk.org  Sat Feb 25 16:07:25 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Sat, 25 Feb 2023 16:07:25 GMT
Subject: RFR: 8026369: javac potentially ambiguous overload warning needs
 an improved scheme [v4]
In-Reply-To: <PkTEmILJ73U76aqatkz4FJ4yZa5biyx4iMgbES9cMRk=.e8d752a1-af8c-4339-8362-d2187dd19287@github.com>
References: <IMxp3iCK--jYJ5Ia04i6QPYfnCHQobVcsmlI5aJXdqc=.892abcb8-7f2a-4fe9-aea2-1b1d41098a6d@github.com>
 <La7IUyuwT43IIKFp8OKW0Wd3iGPnVyvTHyJr00XXq8s=.4b0c537d-1fcd-416a-bd4f-7a1e88466be1@github.com>
 <PkTEmILJ73U76aqatkz4FJ4yZa5biyx4iMgbES9cMRk=.e8d752a1-af8c-4339-8362-d2187dd19287@github.com>
Message-ID: <ieDiuJJzNO2TiSNlfeceVAB0ZKDhOWOINlg3HSgUR_4=.2110f7f4-ba44-4c05-a3ab-8311a7da453d@github.com>

On Sat, 25 Feb 2023 04:05:29 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix typo in one comment and clarify another.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 2736:
> 
>> 2734:           .sorted(Comparator.comparing(e -> e.getKey().toString()))
>> 2735:           .map(Map.Entry::getValue)
>> 2736:           .peek(Collections::reverse)               // seems to help warning ordering
> 
> not sure about reversing the order here, it seems to me that if the order is reversed then the warning is shown in the first occurrence of a method instead of in the second which is the offending one. So for example for this code:
> 
> 
>     interface I1 {
>         void foo(Consumer<Integer> c);
>         void foo(IntConsumer c);
>     }
> 
> the warning is shown for the first method when I think it should be shown for the second which is the one introducing the ambiguity
> 
> EDIT, after your last commit, this comment now applies to: `methodGroups.forEach(Collections::reverse);`

The reversing was originally done in order to maintain consistency with the existing regression test outputs. But you are right - it results in visiting the methods backwards.

Fixed in e25ceced163.

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

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

From duke at openjdk.org  Sat Feb 25 16:07:27 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Sat, 25 Feb 2023 16:07:27 GMT
Subject: RFR: 8026369: javac potentially ambiguous overload warning needs
 an improved scheme [v5]
In-Reply-To: <zmXwajsexkHVYrThszlpiKVhvbGQk86OAgpl7XUqesk=.54943ead-e540-46e7-b4b4-31595f823206@github.com>
References: <IMxp3iCK--jYJ5Ia04i6QPYfnCHQobVcsmlI5aJXdqc=.892abcb8-7f2a-4fe9-aea2-1b1d41098a6d@github.com>
 <kfjz51X87aU9nppjkM08j-GuyuWOQ9m_vzTugkjYxVE=.75e83ec8-5810-43cb-8bd1-2a3b5db76b0d@github.com>
 <zmXwajsexkHVYrThszlpiKVhvbGQk86OAgpl7XUqesk=.54943ead-e540-46e7-b4b4-31595f823206@github.com>
Message-ID: <kHDAf6VSsTMiO34L5HgR-AlpGcKTgRUyL689crUUaJs=.08571e02-e807-4f17-abef-9d058c2be4ae@github.com>

On Sat, 25 Feb 2023 13:38:05 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Do some refactoring & cleanup suggested in reviews.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 2765:
> 
>> 2763:      *  any other methods; in this case the class is definitely responsible.
>> 2764:      */
>> 2765:     BiPredicate<MethodSymbol, MethodSymbol> buildResponsiblePredicate(Type site,
> 
> this method not only builds the predicate as its name indicates, it also removes methods from the `methodGroups`, not saying that we should split this method but I think that this removing activity should be mentioned in the comment above

Oops, my bad - previous refactoring was incomplete.

Should be fixed in e25ceced163.

Thanks again for the careful review!

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

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

From aturbanov at openjdk.org  Sat Feb 25 19:10:06 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Sat, 25 Feb 2023 19:10:06 GMT
Subject: RFR: 8302685: Some javac unit tests aren't reliably closing open
 files
In-Reply-To: <Gz1mh8dLxhqpmPWa3S9V_v-nR5aTC-l4JrEFINKl9Xg=.eab3b0c4-a3e9-44d6-b710-5ce7b354350d@github.com>
References: <Gz1mh8dLxhqpmPWa3S9V_v-nR5aTC-l4JrEFINKl9Xg=.eab3b0c4-a3e9-44d6-b710-5ce7b354350d@github.com>
Message-ID: <dviV49xWTkcGdV1654VmwUhqyg4Wbd-LZ0bcNYu-REU=.e1ff1e79-d8ea-4e9f-add0-42da9b9ad138@github.com>

On Thu, 16 Feb 2023 21:32:44 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

> Some javac unit tests aren't reliably closing open files. Many were written prior to (or without utilizing) try-with-resources.
> 
> Leaving files and other resources open can cause problems during automated builds, etc.
> 
> This patch updates these tests to use try-with-resource.
> 
> Side note: there is at least one unit test that intentionally leaves a file open - `diags/examples/ProcUnclosedTypeFiles/processors/AnnoProc.java`.

test/langtools/tools/javac/T8071847/T8071847.java line 86:

> 84:     File writeHexFile(String classFileName, String hexString) throws IOException {
> 85:         File f = new File(classFileName);
> 86:         try (FileOutputStream output  = new FileOutputStream(f)) {

Suggestion:

        try (FileOutputStream output = new FileOutputStream(f)) {

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

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

From archie.cobbs at gmail.com  Sat Feb 25 21:28:44 2023
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Sat, 25 Feb 2023 15:28:44 -0600
Subject: [External] : Re: Case-insensitive file systems and output file
 clashes - survey
In-Reply-To: <49107c5f-7f51-9827-7830-6ea2a9ff42f2@oracle.com>
References: <CANSoFxuM4X-E0Er8b4hSWwwg8asBRmSGmab9+sUQPXmuh2C70A@mail.gmail.com>
 <c7518371-31a8-78a8-3bf7-2cb0e4394ccd@oracle.com>
 <CANSoFxuoNpo9mn9E5krdzBRmKkqidyN_nSX3R=7Tb0c6efUHng@mail.gmail.com>
 <f2868e3b-1c13-b86b-547b-129c0d3a0cab@oracle.com>
 <CANSoFxum7aFO=DKOmYbE49i_HWs=+xHgGYo0L79agF3fBXrhrQ@mail.gmail.com>
 <49107c5f-7f51-9827-7830-6ea2a9ff42f2@oracle.com>
Message-ID: <CANSoFxvgNKMPUAc6W-Hkr1uBk7XYjknAR98dF9CKr-6a3C5yPw@mail.gmail.com>

On Thu, Feb 23, 2023 at 7:25 PM Jonathan Gibbons <
jonathan.gibbons at oracle.com> wrote:

> On 2/23/23 1:06 PM, Archie Cobbs wrote:
>
> On Thu, Feb 23, 2023 at 1:33 PM Jonathan Gibbons <
> jonathan.gibbons at oracle.com> wrote:
>
>> On 2/22/23 10:59 AM, Archie Cobbs wrote:
>>
>> On Wed, Feb 22, 2023 at 12:12 PM Jonathan Gibbons <
>> jonathan.gibbons at oracle.com> wrote:
>>
>>> On 2/22/23 8:06 AM, Archie Cobbs wrote:
>>>
>>>
>>> Add a new option -Xlint:fileclash that enables checking for clashes
>>> (e.g., at the JavacFileSystemManager layer).
>>>
>>>
>>> That would likely either be a partial solution, or an expensive one for
>>> a complete solution when taking separate compilation into account.
>>>
>> I was thinking separate compilation would definitely not be supported
>> (too complicated).
>>
>> Given that assumption, would it necessarily be only a partial fix?
>>
>> Yes, it would be a partial fix, because by your own assumption, it would
>> not cover some important cases.
>>
> Well I guess I meant, would it be "partial" in some way besides the fact
> that separate compilations are not taken into account.
>
> Digressing a bit, I'm not sure I agree that not supporting separate
> compilations makes it partial. Isn't a "compilation" the extent of the unit
> of work that a compiler is being asked to do? Asking it to solve problems
> that span multiple compilations seems out of scope. Or maybe I'm
> misunderstanding what you mean by "compilation".
>
> Compiling against precompiled class files is expecting javac to solve a
> problem spanning multiple compilations. :-)
>
> That being said, I agree it is a reasonable expectation that any one
> compilation should not write the same physical file more than once, and so
> it might be reasonable to have a possibly always-on diagnostic if that
> situation is detected, perhaps even an error.  Like the (separate) zip file
> discussion, this could be handled inside a custom file manager.  The
> challenge may be in specifying the behavior correctly, and not
> over-promising in the command-line help or man page. But if you stick to
> something like the following in the man page, you may be OK:
>
>    An error will be reported if any file is written more than once during
> a compilation. This may occur in the following situations:
> list-of-known-situations
>
I've put together a draft PR demonstrating this idea:
https://github.com/openjdk/jdk/pull/12754

It wasn't really feasible to NOT do this within the existing
JavacFileManager/BaseFileManager framework. But the changes are fairly well
contained and it works for all three output file types: class files, source
files, and native header files.

I hid this behind a new "extended" javac flag --detect-output-file-clashes
instead of adding it as a new lint option... somehow it didn't really seem
like a "lint" thing.

Please let me know what you think.

-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230225/ce06f71a/attachment.htm>

From duke at openjdk.org  Sat Feb 25 21:38:17 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Sat, 25 Feb 2023 21:38:17 GMT
Subject: RFR: 8302685: Some javac unit tests aren't reliably closing open
 files [v2]
In-Reply-To: <Gz1mh8dLxhqpmPWa3S9V_v-nR5aTC-l4JrEFINKl9Xg=.eab3b0c4-a3e9-44d6-b710-5ce7b354350d@github.com>
References: <Gz1mh8dLxhqpmPWa3S9V_v-nR5aTC-l4JrEFINKl9Xg=.eab3b0c4-a3e9-44d6-b710-5ce7b354350d@github.com>
Message-ID: <obivREUvPRLaiuiQqSFV4KzYg9LODM-M7NBqLpcMPu4=.f6553917-b911-4536-beb1-8aec62509c35@github.com>

> Some javac unit tests aren't reliably closing open files. Many were written prior to (or without utilizing) try-with-resources.
> 
> Leaving files and other resources open can cause problems during automated builds, etc.
> 
> This patch updates these tests to use try-with-resource.
> 
> Side note: there is at least one unit test that intentionally leaves a file open - `diags/examples/ProcUnclosedTypeFiles/processors/AnnoProc.java`.

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

  Remove extra whitespace.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12609/files
  - new: https://git.openjdk.org/jdk/pull/12609/files/e61e5714..40a31c3b

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

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

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

From duke at openjdk.org  Sat Feb 25 21:38:20 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Sat, 25 Feb 2023 21:38:20 GMT
Subject: RFR: 8302685: Some javac unit tests aren't reliably closing open
 files [v2]
In-Reply-To: <dviV49xWTkcGdV1654VmwUhqyg4Wbd-LZ0bcNYu-REU=.e1ff1e79-d8ea-4e9f-add0-42da9b9ad138@github.com>
References: <Gz1mh8dLxhqpmPWa3S9V_v-nR5aTC-l4JrEFINKl9Xg=.eab3b0c4-a3e9-44d6-b710-5ce7b354350d@github.com>
 <dviV49xWTkcGdV1654VmwUhqyg4Wbd-LZ0bcNYu-REU=.e1ff1e79-d8ea-4e9f-add0-42da9b9ad138@github.com>
Message-ID: <d3WOPsPVHFcOKz_mzmWa_xck9h0gN2k-iAS3BoecDEU=.26cc1f0a-e3e4-4022-915b-20848c00a527@github.com>

On Sat, 25 Feb 2023 19:06:49 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove extra whitespace.
>
> test/langtools/tools/javac/T8071847/T8071847.java line 86:
> 
>> 84:     File writeHexFile(String classFileName, String hexString) throws IOException {
>> 85:         File f = new File(classFileName);
>> 86:         try (FileOutputStream output  = new FileOutputStream(f)) {
> 
> Suggestion:
> 
>         try (FileOutputStream output = new FileOutputStream(f)) {

Thanks - should be fixed in 40a31c3bc13.

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

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

From duke at openjdk.org  Sun Feb 26 00:23:51 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Sun, 26 Feb 2023 00:23:51 GMT
Subject: RFR: 8277501: Revisit PathFileObject.getCharContent and friends
Message-ID: <yQF4pP2-WRqbrhvTX8OWJsEiemcxfpxqma9R4U4eGbc=.7b0c42e1-95af-419d-8b1b-43e65b828446@github.com>

The method `BaseFileManager.makeByteBuffer()` assumes that the result from`InputStream.available()` is always accurate, but this is not guaranteed.

This patch cleans up this logic by piggybacking on a similar cleanup that was recently done for [JDK-8302514](https://bugs.openjdk.org/browse/JDK-8302514).

This change also makes a couple of other changes:

(1) Adjust the sematics of `ByteBuffer.appendStream()` so that it doesn't also close the input, which is abnormal for a method like this.

(2) Add synchronization to the buffer caching in `BaseFileManager.makeByteBuffer()` because, according to the API documentation for `JavaFileManager`:
> An object of this interface is not required to support multi-threaded access, that is, be synchronized. However, it must support concurrent access to different file objects created by this object. 

`BaseFileManager.makeByteBuffer()` is invoked from `PathFileObject` and so the per-file object thread-safety requirement would apply here.

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

Commit messages:
 - Avoid over-reliance on InputStream.available() in BaseFileManager.makeByteBuffer().
 - Adjust the semantics of ByteBuffer.appendStream() to not close the stream.

Changes: https://git.openjdk.org/jdk/pull/12755/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12755&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8277501
  Stats: 93 lines in 3 files changed: 27 ins; 34 del; 32 mod
  Patch: https://git.openjdk.org/jdk/pull/12755.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12755/head:pull/12755

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

From vromero at openjdk.org  Mon Feb 27 11:11:07 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 27 Feb 2023 11:11:07 GMT
Subject: RFR: 8026369: javac potentially ambiguous overload warning needs
 an improved scheme [v5]
In-Reply-To: <kHDAf6VSsTMiO34L5HgR-AlpGcKTgRUyL689crUUaJs=.08571e02-e807-4f17-abef-9d058c2be4ae@github.com>
References: <IMxp3iCK--jYJ5Ia04i6QPYfnCHQobVcsmlI5aJXdqc=.892abcb8-7f2a-4fe9-aea2-1b1d41098a6d@github.com>
 <kfjz51X87aU9nppjkM08j-GuyuWOQ9m_vzTugkjYxVE=.75e83ec8-5810-43cb-8bd1-2a3b5db76b0d@github.com>
 <zmXwajsexkHVYrThszlpiKVhvbGQk86OAgpl7XUqesk=.54943ead-e540-46e7-b4b4-31595f823206@github.com>
 <kHDAf6VSsTMiO34L5HgR-AlpGcKTgRUyL689crUUaJs=.08571e02-e807-4f17-abef-9d058c2be4ae@github.com>
Message-ID: <STm7SDR83SqoSSUplUUGAi_RKhHQa4oL8eq6O8ei25Q=.019cd38e-a19e-4b6c-8ff0-a09749b23bd0@github.com>

On Sat, 25 Feb 2023 16:03:39 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 2765:
>> 
>>> 2763:      *  any other methods; in this case the class is definitely responsible.
>>> 2764:      */
>>> 2765:     BiPredicate<MethodSymbol, MethodSymbol> buildResponsiblePredicate(Type site,
>> 
>> this method not only builds the predicate as its name indicates, it also removes methods from the `methodGroups`, not saying that we should split this method but I think that this removing activity should be mentioned in the comment above
>
> Oops, my bad - previous refactoring was incomplete.
> 
> Should be fixed in e25ceced163.
> 
> Thanks again for the careful review!

sure, thanks, nice refactoring

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

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

From vromero at openjdk.org  Mon Feb 27 11:15:10 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 27 Feb 2023 11:15:10 GMT
Subject: RFR: 8026369: javac potentially ambiguous overload warning needs
 an improved scheme [v6]
In-Reply-To: <7CIC6bBj00Mh18mr-g3j6HszbQzf88ND1OHaCW8_ydk=.b6ad3d5b-8bec-47ff-a091-bc483feaee12@github.com>
References: <IMxp3iCK--jYJ5Ia04i6QPYfnCHQobVcsmlI5aJXdqc=.892abcb8-7f2a-4fe9-aea2-1b1d41098a6d@github.com>
 <7CIC6bBj00Mh18mr-g3j6HszbQzf88ND1OHaCW8_ydk=.b6ad3d5b-8bec-47ff-a091-bc483feaee12@github.com>
Message-ID: <Xj4Hm6WdTwtE6punx-MjHNw3LfPMFLPwS0YmSVinpeE=.06192892-d713-417a-b8a2-ab28a9706800@github.com>

On Sat, 25 Feb 2023 16:07:24 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> This bug relates to the "potentially ambiguous overload" warning which is enabled by `-Xlint:overloads`.
>> 
>> The warning detects certain ambiguities that can cause problems for lambdas. For example, consider the interface `Spliterator.OfInt`, which declares these two methods:
>> 
>> void forEachRemaining(Consumer<? super Integer> action);
>> void forEachRemaining(IntConsumer action);
>> 
>> Both methods have the same name, same number of parameters, and take a lambda with the same "shape" in the same argument position. This causes an ambiguity in any code that wants to do this:
>> 
>>     spliterator.forEachRemaining(x -> { ... });
>> 
>> That code won't compile; instead, you'll get this error:
>> 
>> Ambiguity.java:4: error: reference to forEachRemaining is ambiguous
>>         spliterator.forEachRemaining(x -> { });
>>                    ^
>>   both method forEachRemaining(IntConsumer) in OfInt and method forEachRemaining(Consumer<? super Integer>) in OfInt match
>> 
>> 
>> The problem reported by the bug is that the warning fails to detect ambiguities which are created purely by inheritance, for example:
>> 
>> interface ConsumerOfInteger {
>>     void foo(Consumer<Integer> c);
>> }
>> 
>> interface IntegerConsumer {
>>     void foo(IntConsumer c);
>> }
>> 
>> // We should get a warning here...
>> interface Test extends ConsumerOfInteger, IntegerConsumer {
>> }
>> 
>> 
>> The cause of the bug is that ambiguities are detected on a per-method basis, by checking whether a method is part of an ambiguity pair when we visit that method. So if the methods in an ambiguity pair are inherited from two distinct supertypes, we'll miss the ambiguity.
>> 
>> To fix the problem, we need to look for ambiguities on a per-class level, checking all pairs of methods. However, it's not that simple - we only want to "blame" a class when that class itself, and not some supertype, is responsible for creating the ambiguity. For example, any interface extending `Spliterator.OfInt` will automatically inherit the two ambiguities mentioned above, but these are not the interface's fault so to speak so no warning should be generated. Making things more complicated is the fact that methods can be overridden and declared in generic classes so they only conflict in some subtypes, etc.
>> 
>> So we generate the warning when there are two methods m1 and m2 in a class C such that:
>> 
>> * m1 and m2 consitiute a "potentially ambiguous overload" (using the same definition as before)
>> * There is no direct supertype T of C such that m1 and m2, or some methods they override, both exist in T and constitute a "potentially ambiguous overload" as members of T
>> * We haven't already generated a warning for either m1 or m2 in class C
>> 
>> If either method is declared in C, we locate the warning there, but when both methods are inherited, there's no method declaration to point at so the warning is instead located at the class declaration.
>> 
>> I noticed a couple of other minor bugs; these are also being fixed here:
>> 
>> (1) For inherited methods, the method signatures were being reported as they are declared, rather than in the context of the class being visited. As a result, when a methods is inherited from a generic supertype, the ambiguity is less clear. Here's an example:
>> 
>> interface Upper<T> {
>>     void foo(T c);
>> }
>> 
>> interface Lower extends Upper<IntConsumer> {
>>     void foo(Consumer<Integer> c);
>> }
>> 
>> Currently, the error is reported as:
>> 
>> warning: [overloads] foo(Consumer<Integer>) in Lower is potentially ambiguous with foo(T) in Upper
>> 
>> Reporting the method signatures in the context of the class being visited makes the ambiguity clearer:
>> 
>> warning: [overloads] foo(Consumer<Integer>) in Lower is potentially ambiguous with foo(IntConsumer) in Upper
>> 
>> 
>> (2) When a method is identified as part of an ambiguous pair, we were setting a `POTENTIALLY_AMBIGUOUS` flag on it. This caused it to be forever excluded from future warnings. For methods that are declared in the class we're visiting, this makes sense, but it doesn't make sense for inherited methods, because it disqualifies them from participating in the analysis of any other class that also inherits them.
>> 
>> As a result, for a class like the one below, the compiler was only generating one warning instead of three:
>> 
>> public interface SuperIface {
>>     void foo(Consumer<Integer> c);
>> }
>> 
>> public interface I1 extends SuperIface { 
>>     void foo(IntConsumer c);        // warning was generated here
>> }   
>> 
>> public interface I2 extends SuperIface { 
>>     void foo(IntConsumer c);        // no warning was generated here
>> }   
>> 
>> public interface I3 extends SuperIface { 
>>     void foo(IntConsumer c);        // no warning was generated here
>> }   
>> 
>> 
>> With this patch the `POTENTIALLY_AMBIGUOUS` flag is no longer needed. I wasn't sure whether to renumber all the subsequent flags, or just leave an empty placeholder, so I chose the latter.
>> 
>> Finally, this fix uncovers new warnings in `java.base` and `java.desktop`, so these are now suppressed in the patch.
>
> Archie L. Cobbs has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Process methods in order so the second method triggers the warning.
>  - Clean up previous buildResponsiblePredicate() refactoring, which was incomplete.

looks good, thanks for fixing this!

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

Marked as reviewed by vromero (Reviewer).

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

From jlaskey at openjdk.org  Mon Feb 27 12:47:03 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 27 Feb 2023 12:47:03 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v42]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <9XP497xudeRhZKkIpxIgpbqT24eG8SCbfG6TelYtM3M=.f1ad5a76-798c-4e3d-b43b-a25a20210154@github.com>

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

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

  Tighten up reporting of string template errors (fewer messages)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/89806d49..85cc7efc

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

  Stats: 52 lines in 5 files changed: 27 ins; 7 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10889/head:pull/10889

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

From duke at openjdk.org  Mon Feb 27 16:25:22 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Mon, 27 Feb 2023 16:25:22 GMT
Subject: Integrated: 8302685: Some javac unit tests aren't reliably closing
 open files
In-Reply-To: <Gz1mh8dLxhqpmPWa3S9V_v-nR5aTC-l4JrEFINKl9Xg=.eab3b0c4-a3e9-44d6-b710-5ce7b354350d@github.com>
References: <Gz1mh8dLxhqpmPWa3S9V_v-nR5aTC-l4JrEFINKl9Xg=.eab3b0c4-a3e9-44d6-b710-5ce7b354350d@github.com>
Message-ID: <KDpIaTa0uazLWu634CvdRJ3NaEWY4MAZ0GbZOcPvCfc=.af0228b6-52ee-4a5e-9609-54e40a14608b@github.com>

On Thu, 16 Feb 2023 21:32:44 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

> Some javac unit tests aren't reliably closing open files. Many were written prior to (or without utilizing) try-with-resources.
> 
> Leaving files and other resources open can cause problems during automated builds, etc.
> 
> This patch updates these tests to use try-with-resource.
> 
> Side note: there is at least one unit test that intentionally leaves a file open - `diags/examples/ProcUnclosedTypeFiles/processors/AnnoProc.java`.

This pull request has now been integrated.

Changeset: 55e6bb6b
Author:    Archie L. Cobbs <archie.cobbs at gmail.com>
Committer: Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/55e6bb6b85828f9a0ac37467ac2d28fd3349c64f
Stats:     445 lines in 58 files changed: 54 ins; 205 del; 186 mod

8302685: Some javac unit tests aren't reliably closing open files

Reviewed-by: darcy, vromero

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

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

From duke at openjdk.org  Tue Feb 28 03:36:14 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Tue, 28 Feb 2023 03:36:14 GMT
Subject: Integrated: 8026369: javac potentially ambiguous overload warning
 needs an improved scheme
In-Reply-To: <IMxp3iCK--jYJ5Ia04i6QPYfnCHQobVcsmlI5aJXdqc=.892abcb8-7f2a-4fe9-aea2-1b1d41098a6d@github.com>
References: <IMxp3iCK--jYJ5Ia04i6QPYfnCHQobVcsmlI5aJXdqc=.892abcb8-7f2a-4fe9-aea2-1b1d41098a6d@github.com>
Message-ID: <B-0L2Tb7KAyVr1ZnWvPRvSDxzntwoxFY-bY5ta_ecFs=.638328a4-0633-4f84-9126-1bd038250511@github.com>

On Sun, 19 Feb 2023 23:52:52 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

> This bug relates to the "potentially ambiguous overload" warning which is enabled by `-Xlint:overloads`.
> 
> The warning detects certain ambiguities that can cause problems for lambdas. For example, consider the interface `Spliterator.OfInt`, which declares these two methods:
> 
> void forEachRemaining(Consumer<? super Integer> action);
> void forEachRemaining(IntConsumer action);
> 
> Both methods have the same name, same number of parameters, and take a lambda with the same "shape" in the same argument position. This causes an ambiguity in any code that wants to do this:
> 
>     spliterator.forEachRemaining(x -> { ... });
> 
> That code won't compile; instead, you'll get this error:
> 
> Ambiguity.java:4: error: reference to forEachRemaining is ambiguous
>         spliterator.forEachRemaining(x -> { });
>                    ^
>   both method forEachRemaining(IntConsumer) in OfInt and method forEachRemaining(Consumer<? super Integer>) in OfInt match
> 
> 
> The problem reported by the bug is that the warning fails to detect ambiguities which are created purely by inheritance, for example:
> 
> interface ConsumerOfInteger {
>     void foo(Consumer<Integer> c);
> }
> 
> interface IntegerConsumer {
>     void foo(IntConsumer c);
> }
> 
> // We should get a warning here...
> interface Test extends ConsumerOfInteger, IntegerConsumer {
> }
> 
> 
> The cause of the bug is that ambiguities are detected on a per-method basis, by checking whether a method is part of an ambiguity pair when we visit that method. So if the methods in an ambiguity pair are inherited from two distinct supertypes, we'll miss the ambiguity.
> 
> To fix the problem, we need to look for ambiguities on a per-class level, checking all pairs of methods. However, it's not that simple - we only want to "blame" a class when that class itself, and not some supertype, is responsible for creating the ambiguity. For example, any interface extending `Spliterator.OfInt` will automatically inherit the two ambiguities mentioned above, but these are not the interface's fault so to speak so no warning should be generated. Making things more complicated is the fact that methods can be overridden and declared in generic classes so they only conflict in some subtypes, etc.
> 
> So we generate the warning when there are two methods m1 and m2 in a class C such that:
> 
> * m1 and m2 consitiute a "potentially ambiguous overload" (using the same definition as before)
> * There is no direct supertype T of C such that m1 and m2, or some methods they override, both exist in T and constitute a "potentially ambiguous overload" as members of T
> * We haven't already generated a warning for either m1 or m2 in class C
> 
> If either method is declared in C, we locate the warning there, but when both methods are inherited, there's no method declaration to point at so the warning is instead located at the class declaration.
> 
> I noticed a couple of other minor bugs; these are also being fixed here:
> 
> (1) For inherited methods, the method signatures were being reported as they are declared, rather than in the context of the class being visited. As a result, when a methods is inherited from a generic supertype, the ambiguity is less clear. Here's an example:
> 
> interface Upper<T> {
>     void foo(T c);
> }
> 
> interface Lower extends Upper<IntConsumer> {
>     void foo(Consumer<Integer> c);
> }
> 
> Currently, the error is reported as:
> 
> warning: [overloads] foo(Consumer<Integer>) in Lower is potentially ambiguous with foo(T) in Upper
> 
> Reporting the method signatures in the context of the class being visited makes the ambiguity clearer:
> 
> warning: [overloads] foo(Consumer<Integer>) in Lower is potentially ambiguous with foo(IntConsumer) in Upper
> 
> 
> (2) When a method is identified as part of an ambiguous pair, we were setting a `POTENTIALLY_AMBIGUOUS` flag on it. This caused it to be forever excluded from future warnings. For methods that are declared in the class we're visiting, this makes sense, but it doesn't make sense for inherited methods, because it disqualifies them from participating in the analysis of any other class that also inherits them.
> 
> As a result, for a class like the one below, the compiler was only generating one warning instead of three:
> 
> public interface SuperIface {
>     void foo(Consumer<Integer> c);
> }
> 
> public interface I1 extends SuperIface { 
>     void foo(IntConsumer c);        // warning was generated here
> }   
> 
> public interface I2 extends SuperIface { 
>     void foo(IntConsumer c);        // no warning was generated here
> }   
> 
> public interface I3 extends SuperIface { 
>     void foo(IntConsumer c);        // no warning was generated here
> }   
> 
> 
> With this patch the `POTENTIALLY_AMBIGUOUS` flag is no longer needed. I wasn't sure whether to renumber all the subsequent flags, or just leave an empty placeholder, so I chose the latter.
> 
> Finally, this fix uncovers new warnings in `java.base` and `java.desktop`, so these are now suppressed in the patch.

This pull request has now been integrated.

Changeset: 1e3c9fd6
Author:    Archie L. Cobbs <archie.cobbs at gmail.com>
Committer: Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1e3c9fd67efd8428f702c7a3e26ac2b60e0fe618
Stats:     399 lines in 16 files changed: 319 ins; 37 del; 43 mod

8026369: javac potentially ambiguous overload warning needs an improved scheme

Reviewed-by: vromero

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

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

From prappo at openjdk.org  Tue Feb 28 13:39:49 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 28 Feb 2023 13:39:49 GMT
Subject: RFR: 8303350: Fix mistyped {@code}
Message-ID: <Si2xSZHXw8_KzOOGK8zTHu1yVJ_20lIc15mg_LovvCk=.5a7c6041-71c3-4208-8110-6a9a13f66857@github.com>

Please review this trivial fix.

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

Commit messages:
 - Initial commit

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

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

From jpai at openjdk.org  Tue Feb 28 15:03:13 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 28 Feb 2023 15:03:13 GMT
Subject: RFR: 8303350: Fix mistyped {@code}
In-Reply-To: <Si2xSZHXw8_KzOOGK8zTHu1yVJ_20lIc15mg_LovvCk=.5a7c6041-71c3-4208-8110-6a9a13f66857@github.com>
References: <Si2xSZHXw8_KzOOGK8zTHu1yVJ_20lIc15mg_LovvCk=.5a7c6041-71c3-4208-8110-6a9a13f66857@github.com>
Message-ID: <GNA47jn1WpRf3iJ_KAVC2AeRmky18NEK5o-XehSBtNs=.87ac4554-501f-496f-9749-fac9be873801@github.com>

On Tue, 28 Feb 2023 13:31:06 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this trivial fix.

The changes look fine to me.

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

Marked as reviewed by jpai (Reviewer).

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

From archie.cobbs at gmail.com  Tue Feb 28 15:30:02 2023
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Tue, 28 Feb 2023 09:30:02 -0600
Subject: JDK-8268622 - Performance issues in javac `Name` class
Message-ID: <CANSoFxsO3FTZ5MXSRXcTAPMUgwJThoJ7XVTkXbkv12i=BE6ZFg@mail.gmail.com>

Jon and I have been discussing JDK-8268622
<https://bugs.openjdk.org/browse/JDK-8268622> via JBS comments, but it's
better off being discussed on compiler-dev, so we're moving the discussion
here...

First question: what is a good performance test with which to measure any
purported improvements? In my tests the JDK build doesn't seem to be very
revealing.

-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230228/7ef0e1ac/attachment.htm>

From prappo at openjdk.org  Tue Feb 28 15:43:36 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 28 Feb 2023 15:43:36 GMT
Subject: Integrated: 8303350: Fix mistyped {@code}
In-Reply-To: <Si2xSZHXw8_KzOOGK8zTHu1yVJ_20lIc15mg_LovvCk=.5a7c6041-71c3-4208-8110-6a9a13f66857@github.com>
References: <Si2xSZHXw8_KzOOGK8zTHu1yVJ_20lIc15mg_LovvCk=.5a7c6041-71c3-4208-8110-6a9a13f66857@github.com>
Message-ID: <aLhW_1hUQUS1wd5eIU5qyYiTsyB83RBtGdN8Yv5ZiVk=.7c36ef4d-fad7-48e0-87a4-770d797cb42a@github.com>

On Tue, 28 Feb 2023 13:31:06 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this trivial fix.

This pull request has now been integrated.

Changeset: dc5ea6ae
Author:    Pavel Rappo <prappo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/dc5ea6aeb500d531b4ba49c8e95bf97744cc6c33
Stats:     6 lines in 3 files changed: 0 ins; 0 del; 6 mod

8303350: Fix mistyped {@code}

Reviewed-by: jpai

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

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