From acobbs at openjdk.org  Tue Jul  1 16:03:33 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 1 Jul 2025 16:03:33 GMT
Subject: RFR: 8359493: Refactor how aggregated mandatory warnings are
 handled in the compiler [v4]
In-Reply-To: <cNgGXJbQfH7OtGQtQCAOmt9o432jDuqCPUfL701Q7bU=.72e81015-307d-4b37-a241-d5b337a6dd38@github.com>
References: <cNgGXJbQfH7OtGQtQCAOmt9o432jDuqCPUfL701Q7bU=.72e81015-307d-4b37-a241-d5b337a6dd38@github.com>
Message-ID: <69PsKSuzJdOVRwn5j60MDT7-TmmzqGM47cQl4RPJBQ8=.d7551f64-f470-40c9-8756-801f528417b6@github.com>

> The compiler's handling of the aggregation of mandatory warnings into "notes" at the end of compilation can be refactored to simplify the code.
> 
> The `JCDiagnostic` class supports flags that alter how warnings are handled, e.g., `MANDATORY`, `NON_DEFERRABLE`, etc. So instead of having to log aggregated mandatory warnings through a separate channel (the `MandatoryWarningHandler`), these warnings could instead be logged just like any other warning, but with an `AGGREGATED` flag added. The actual aggregation can then be handled "behind the scenes" by the logging subsystem.
> 
> This will also make it easier to implement `@SuppressAnnotations` support for parser/tokenizer warnings which require aggregated mandatory warning notes such as warnings for preview features.

Archie 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 five additional commits since the last revision:

 - Merge branch 'master' into MandatoryWarningCleanup
 - Move (most) SOURCE_LEVEL flags into compiler.properties.
 - Add DiagnosticFlag support to compiler.properties and put AGGREGATE there.
 - Apply some review suggestions.
 - Refactor MandatoryWarningHandler to just be an aggregator.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25810/files
  - new: https://git.openjdk.org/jdk/pull/25810/files/95b368fb..94cda824

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

  Stats: 37873 lines in 1141 files changed: 20469 ins; 11683 del; 5721 mod
  Patch: https://git.openjdk.org/jdk/pull/25810.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25810/head:pull/25810

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

From vromero at openjdk.org  Wed Jul  2 18:06:24 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 2 Jul 2025 18:06:24 GMT
Subject: RFR: 8361214: An anonymous class is erroneously being classify as an
 abstract class
Message-ID: <Ngr9MegwUJMSYUSNjhkZUAd6hHosdV6Fjb7Lcg-jB7o=.0aaab968-abb9-4fce-861c-2c5e9b10b682@github.com>

Javac is failing to compile this code:

abstract class Base<T> {}
abstract class Derived1<T> extends Base<T> {}
abstract class Derived2<T> extends Base<T> {
    Derived2(Derived1<T> obj) {}
}

class Test {
    Base<String> obj = new Derived2<>(new Derived1<>() { /* not abstract */ }) { /* not abstract */ };
}

issuing error message:

Test.java:8: error: Derived1 is abstract; cannot be instantiated
    Base<String> obj = new Derived2<>(new Derived1<>() { /* not abstract */ }) { /* not abstract */ };

basically during speculative attribution we make a copy of the new class expression but the class body is nuked to avoid side-effects during the process. Javac is checking the error condition on a speculative version of the AST and thus it seems to it that the user is trying to create an abstract class. The proposed fix is to use an already existing predicate that indicates if the class body has been removed or not,

TIA

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

Commit messages:
 - adding test case
 - minor change to test
 - Merge branch 'master' into JDK-8361214
 - 8361214: An anonymous class is erroneously being classify as an abstract class

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

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

From jlu at openjdk.org  Wed Jul  2 21:11:49 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 2 Jul 2025 21:11:49 GMT
Subject: RFR: 8361303: L10n comment for javac.opt.Xlint.desc.synchronization in
 javac.properties
Message-ID: <1cRO6PyBt082oEy7twA7ms6nSE06DX9wC0Ko_pAn0WY=.bb745c3a-355a-4699-81fb-6326c63a6afe@github.com>

Please review this PR which provides a comment to make apparent what should not be localized in the value for the key: `javac.opt.Xlint.desc.synchronization`. This was suggested by the translation team and is also consistent with other key values in the properties file that make similar comments.

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

Commit messages:
 - init

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

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

From liach at openjdk.org  Wed Jul  2 21:41:14 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 2 Jul 2025 21:41:14 GMT
Subject: RFR: 8360022: ClassRefDupInConstantPoolTest.java fails when running in
 repeat
Message-ID: <m5pM9zbPZkRbASSLj-a_HrRXEVqhcG_7B5_n_z9YFBE=.2b71dda6-db28-4f5b-8dc6-c0872478b7e5@github.com>

The javac test `ClassRefDupInConstantPoolTest.java` has an incorrect clean directive: when its subsidary Duplicates class is cleaned, the main class is not, and jtreg eagerly reexecutes the main class and then the test fails by not able to find the nested class.

This problem is evident when running from intellij idea. It can also be reproduced consistently by:

make test TEST=langtools/tools/javac/jvm/ClassRefDupInConstantPoolTest.java JTREG=REPEAT_COUNT=2


Testing: that make test line above now passes.

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

Commit messages:
 - 8360022: ClassRefDupInConstantPoolTest.java fails when running in repeat

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

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

From vromero at openjdk.org  Wed Jul  2 21:51:42 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 2 Jul 2025 21:51:42 GMT
Subject: RFR: 8360022: ClassRefDupInConstantPoolTest.java fails when
 running in repeat
In-Reply-To: <m5pM9zbPZkRbASSLj-a_HrRXEVqhcG_7B5_n_z9YFBE=.2b71dda6-db28-4f5b-8dc6-c0872478b7e5@github.com>
References: <m5pM9zbPZkRbASSLj-a_HrRXEVqhcG_7B5_n_z9YFBE=.2b71dda6-db28-4f5b-8dc6-c0872478b7e5@github.com>
Message-ID: <TY8nUaNU979lDpzMV_uV65hfDiAHJ54CcmPOa2rjL50=.07f473f8-fa7e-499e-8612-29ef17473051@github.com>

On Wed, 2 Jul 2025 21:36:07 GMT, Chen Liang <liach at openjdk.org> wrote:

> The javac test `ClassRefDupInConstantPoolTest.java` has an incorrect clean directive: when its subsidary Duplicates class is cleaned, the main class is not, and jtreg eagerly reexecutes the main class and then the test fails by not able to find the nested class.
> 
> This problem is evident when running from intellij idea. It can also be reproduced consistently by:
> 
> make test TEST=langtools/tools/javac/jvm/ClassRefDupInConstantPoolTest.java JTREG=REPEAT_COUNT=2
> 
> 
> Testing: that make test line above now passes.

looks good, please consider placing the `@clean` directive after the `@run` one

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26106#pullrequestreview-2980733808

From naoto at openjdk.org  Wed Jul  2 22:12:40 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 2 Jul 2025 22:12:40 GMT
Subject: RFR: 8361303: L10n comment for
 javac.opt.Xlint.desc.synchronization in javac.properties
In-Reply-To: <1cRO6PyBt082oEy7twA7ms6nSE06DX9wC0Ko_pAn0WY=.bb745c3a-355a-4699-81fb-6326c63a6afe@github.com>
References: <1cRO6PyBt082oEy7twA7ms6nSE06DX9wC0Ko_pAn0WY=.bb745c3a-355a-4699-81fb-6326c63a6afe@github.com>
Message-ID: <4tCuq_CiVXYNLgj3X_KDQwhSqn7PgnS9lFZ9GJRYftw=.e04528d0-6622-4147-a2ab-3acbd4ea6968@github.com>

On Wed, 2 Jul 2025 21:07:21 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which provides a comment to make apparent what should not be localized in the value for the key: `javac.opt.Xlint.desc.synchronization`. This was suggested by the translation team and is also consistent with other key values in the properties file that make similar comments.

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26105#pullrequestreview-2980777591

From liach at openjdk.org  Wed Jul  2 22:29:41 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 2 Jul 2025 22:29:41 GMT
Subject: RFR: 8360022: ClassRefDupInConstantPoolTest.java fails when
 running in repeat
In-Reply-To: <m5pM9zbPZkRbASSLj-a_HrRXEVqhcG_7B5_n_z9YFBE=.2b71dda6-db28-4f5b-8dc6-c0872478b7e5@github.com>
References: <m5pM9zbPZkRbASSLj-a_HrRXEVqhcG_7B5_n_z9YFBE=.2b71dda6-db28-4f5b-8dc6-c0872478b7e5@github.com>
Message-ID: <Yy_x-V-kmI42vluYHLMWzXzPO0pVV3s55mbIXwh5zvI=.4603b1f7-1f55-4f20-ae91-f75851f1ea16@github.com>

On Wed, 2 Jul 2025 21:36:07 GMT, Chen Liang <liach at openjdk.org> wrote:

> The javac test `ClassRefDupInConstantPoolTest.java` has an incorrect clean directive: when its subsidary Duplicates class is cleaned, the main class is not, and jtreg eagerly reexecutes the main class and then the test fails by not able to find the nested class.
> 
> This problem is evident when running from intellij idea. It can also be reproduced consistently by:
> 
> make test TEST=langtools/tools/javac/jvm/ClassRefDupInConstantPoolTest.java JTREG=REPEAT_COUNT=2
> 
> 
> Testing: that make test line above now passes.

The placement of clean and run doesn't matter here - for both fails and successes. Per my understanding, they usually are only important when there are multiple run directives in one jtreg header.

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

PR Comment: https://git.openjdk.org/jdk/pull/26106#issuecomment-3029489025

From liach at openjdk.org  Wed Jul  2 23:08:38 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 2 Jul 2025 23:08:38 GMT
Subject: RFR: 8361303: L10n comment for
 javac.opt.Xlint.desc.synchronization in javac.properties
In-Reply-To: <1cRO6PyBt082oEy7twA7ms6nSE06DX9wC0Ko_pAn0WY=.bb745c3a-355a-4699-81fb-6326c63a6afe@github.com>
References: <1cRO6PyBt082oEy7twA7ms6nSE06DX9wC0Ko_pAn0WY=.bb745c3a-355a-4699-81fb-6326c63a6afe@github.com>
Message-ID: <SiC2qzNLTSnV1bcAXKVmQUA83ma1Sih3XD-GmAnaxss=.2c003346-c32f-4b70-82f2-1dda8f55ffe7@github.com>

On Wed, 2 Jul 2025 21:07:21 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which provides a comment to make apparent what should not be localized in the value for the key: `javac.opt.Xlint.desc.synchronization`. This was suggested by the translation team and is also consistent with other key values in the properties file that make similar comments.

Indeed, this is a javac command line flag instead of a word to be translated.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26105#pullrequestreview-2980875250

From liach at openjdk.org  Wed Jul  2 23:12:20 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 2 Jul 2025 23:12:20 GMT
Subject: RFR: 8357185: Redundant local variables with unconditionally matching
 primitive patterns
Message-ID: <Rc2zwv2WHpOwXUjeBUEeUDC3f_3PXNwnNHPC7OWsIvs=.d61b1b72-5917-4026-bad1-3052c0402ebe@github.com>

A commit in the implementation of JEP 455, https://github.com/openjdk/jdk/pull/15638/commits/ceee1e4c08457a0793fdfb556db99e057a947af1, added redundant synthetic local variable for trivial `instanceof int`-ish type conversion operations in the javac AST. Such conversions have been present since the introduction of record patterns, and previously they consistently lower to the part before `instanceof`. With this change, the introduced redundant variable is visible in the class file, as seen in the JBS issue.

Testing: langtools/tools/javac

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

Commit messages:
 - Fix
 - Fixup
 - 8357185: Redundant local variables with unconditionally matching primitive patterns

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

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

From liach at openjdk.org  Wed Jul  2 23:18:37 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 2 Jul 2025 23:18:37 GMT
Subject: RFR: 8361214: An anonymous class is erroneously being classify as
 an abstract class
In-Reply-To: <Ngr9MegwUJMSYUSNjhkZUAd6hHosdV6Fjb7Lcg-jB7o=.0aaab968-abb9-4fce-861c-2c5e9b10b682@github.com>
References: <Ngr9MegwUJMSYUSNjhkZUAd6hHosdV6Fjb7Lcg-jB7o=.0aaab968-abb9-4fce-861c-2c5e9b10b682@github.com>
Message-ID: <JXh9UfQQXPTRMpiHCuXYchLbD6o03FuGhHXmvgJh_rs=.3880075e-ca4f-46f5-9318-8edff94b8e45@github.com>

On Wed, 2 Jul 2025 18:01:15 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Javac is failing to compile this code:
> 
> abstract class Base<T> {}
> abstract class Derived1<T> extends Base<T> {}
> abstract class Derived2<T> extends Base<T> {
>     Derived2(Derived1<T> obj) {}
> }
> 
> class Test {
>     Base<String> obj = new Derived2<>(new Derived1<>() { /* not abstract */ }) { /* not abstract */ };
> }
> 
> issuing error message:
> 
> Test.java:8: error: Derived1 is abstract; cannot be instantiated
>     Base<String> obj = new Derived2<>(new Derived1<>() { /* not abstract */ }) { /* not abstract */ };
> 
> basically during speculative attribution we make a copy of the new class expression but the class body is nuked to avoid side-effects during the process. Javac is checking the error condition on a speculative version of the AST and thus it seems to it that the user is trying to create an abstract class. The proposed fix is to use an already existing predicate that indicates if the class body has been removed or not,
> 
> TIA

Looks reasonable.

I see there are two sites of `cdef != null && clazztype.tsym.isInterface()`; do they need to check this too?

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26103#pullrequestreview-2980889360

From jlahoda at openjdk.org  Thu Jul  3 07:20:49 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 3 Jul 2025 07:20:49 GMT
Subject: Integrated: 8358801: javac produces class that does not pass verifier.
In-Reply-To: <mvyOqsq9sqxR0L2Q0hbPrGR3ffVmEAI_xnDto4-EVxc=.97784c09-4faf-4621-b570-104de120004b@github.com>
References: <mvyOqsq9sqxR0L2Q0hbPrGR3ffVmEAI_xnDto4-EVxc=.97784c09-4faf-4621-b570-104de120004b@github.com>
Message-ID: <uK_NIODWlF0Hk5YY2rsAdVVMqqrC37wT2xNJWWraMnQ=.c68b74af-2e2f-494a-9ac5-ff9436e3e423@github.com>

On Tue, 17 Jun 2025 10:01:02 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider code like:
> 
> 
> public class Main {
> 
>     private boolean test(String s, int i) {
>         if (s.subSequence(0, 1) instanceof Runnable r) {
>             return true;
>         }
> 
>         Integer dummy;
>         switch (i) {
>             case 0:
>                 String clashing = null;
>                 return true;
>             default:
>                 return true;
>         }
>     }
> 
>     public static void main(String[] args) {
>     }
> }
> 
> 
> javac will produce code that won't (rightfully) pass the verifier:
> 
> 
> $ java Main.java
> Exception in thread "main" java.lang.VerifyError: Inconsistent stackmap frames at branch target 49
> Exception Details:
>   Location:
>     Main.test(Ljava/lang/String;I)Z @49: iconst_1
>   Reason:
>     Type top (current frame, locals[4]) is not assignable to 'java/lang/String' (stack map, locals[4])
>   Current Frame:
>     bci: @25
>     flags: { }
>     locals: { 'Main', 'java/lang/String', integer }
>     stack: { integer }
>   Stackmap Frame:
>     bci: @49
>     flags: { }
>     locals: { 'Main', 'java/lang/String', integer, top, 'java/lang/String' }
>     stack: { }
>   Bytecode:
>     0000000: 2b03 04b6 0007 3a04 1904 c100 0d99 000b
>     0000010: 1904 c000 0d4e 04ac 1cab 0000 0000 0018
>     0000020: 0000 0001 0000 0000 0000 0013 013a 0404
>     0000030: ac04 ac
>   Stackmap Table:
>     same_frame(@24)
>     same_frame(@44)
>     append_frame(@49,Top,Object[#8])
> 
>         at java.base/java.lang.Class.getDeclaredMethods0(Native Method)
>         at java.base/java.lang.Class.privateGetDeclaredMethods(Class.java:3035)
>         at java.base/java.lang.Class.getMethodsRecursive(Class.java:3177)
>         at java.base/java.lang.Class.findMethod(Class.java:2465)
>         at java.base/java.lang.System$1.findMethod(System.java:1980)
>         at java.base/jdk.internal.misc.MethodFinder.findMainMethod(MethodFinder.java:86)
>         at jdk.compiler/com.sun.tools.javac.launcher.SourceLauncher.execute(SourceLauncher.java:194)
>         at jdk.compiler/com.sun.tools.javac.launcher.SourceLauncher.run(SourceLauncher.java:138)
>         at jdk.compiler/com.sun.tools.javac.launcher.SourceLauncher.main(SourceLauncher.java:76)
> 
> 
> 
> Now, the problem, as far as I can tell, is this: javac will desugar the pattern matching instanceof along the lines of:
> 
> 
> if (... (var $temp = s.subSequence(0, 1) in ... && ...) ...) {
>     return true;
> }
> 
> 
> (`$temp` is register/local variable number 4)
> specifically, note the `&&` in the middle of the let expression, and that the expression is in the conditional position. What happens here is...

This pull request has now been integrated.

Changeset: fd13e1ce
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fd13e1ce9805a903ab60ad9b476eb5a6687d22ee
Stats:     144 lines in 2 files changed: 144 ins; 0 del; 0 mod

8358801: javac produces class that does not pass verifier.

Reviewed-by: mcimadamore, liach

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

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

From jlahoda at openjdk.org  Thu Jul  3 09:17:38 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 3 Jul 2025 09:17:38 GMT
Subject: RFR: 8357185: Redundant local variables with unconditionally
 matching primitive patterns
In-Reply-To: <Rc2zwv2WHpOwXUjeBUEeUDC3f_3PXNwnNHPC7OWsIvs=.d61b1b72-5917-4026-bad1-3052c0402ebe@github.com>
References: <Rc2zwv2WHpOwXUjeBUEeUDC3f_3PXNwnNHPC7OWsIvs=.d61b1b72-5917-4026-bad1-3052c0402ebe@github.com>
Message-ID: <Hv5p9AM02q1-dRAYMrbpzg9uRrMuGCN_6wBypoCJ1MI=.1343c539-5a7b-4faf-acab-46b8375a68a9@github.com>

On Wed, 2 Jul 2025 23:06:42 GMT, Chen Liang <liach at openjdk.org> wrote:

> A commit in the implementation of JEP 455, https://github.com/openjdk/jdk/pull/15638/commits/ceee1e4c08457a0793fdfb556db99e057a947af1, added redundant synthetic local variable for trivial `instanceof int`-ish type conversion operations in the javac AST. Such conversions have been present since the introduction of record patterns, and previously they consistently lower to the part before `instanceof`. With this change, the introduced redundant variable is visible in the class file, as seen in the JBS issue.
> 
> Testing: langtools/tools/javac

This seems like a reasonable direction, but please see inline for suggestions for improvements.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 2846:

> 2844: 
> 2845:             if (types.isUnconditionallyExact(tree.expr.type, tree.pattern.type)) {
> 2846:                 var = make.Exec(instanceOfExpr);  // drop redundant variable

While this is sufficient to solve the issue, it might be good to go through the if cascade more thoroughly, and only introduce the variable if needed. I.e. in case the value is used more than once. If the value is used only once (like in the `else if (tree.expr.type.isPrimitive()) {`, it ought to be possible to use it directly. Unless there are ordering or other concerns, of course.

test/langtools/tools/javac/patterns/PrimitiveUnconditionallyExactTest.java line 88:

> 86:     public void testExpressionExecution() {
> 87:         int a = 0;
> 88:         boolean b = (a = 5) instanceof int;

I would suggest to also include the same test cases with binding patterns instead of types. In the current state/code shape, there should be no difference, but it would be better to not be caught later if the code shape changes.

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

PR Review: https://git.openjdk.org/jdk/pull/26107#pullrequestreview-2982391708
PR Review Comment: https://git.openjdk.org/jdk/pull/26107#discussion_r2182280878
PR Review Comment: https://git.openjdk.org/jdk/pull/26107#discussion_r2182284238

From abimpoudis at openjdk.org  Thu Jul  3 09:27:41 2025
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 3 Jul 2025 09:27:41 GMT
Subject: RFR: 8357185: Redundant local variables with unconditionally
 matching primitive patterns
In-Reply-To: <Hv5p9AM02q1-dRAYMrbpzg9uRrMuGCN_6wBypoCJ1MI=.1343c539-5a7b-4faf-acab-46b8375a68a9@github.com>
References: <Rc2zwv2WHpOwXUjeBUEeUDC3f_3PXNwnNHPC7OWsIvs=.d61b1b72-5917-4026-bad1-3052c0402ebe@github.com>
 <Hv5p9AM02q1-dRAYMrbpzg9uRrMuGCN_6wBypoCJ1MI=.1343c539-5a7b-4faf-acab-46b8375a68a9@github.com>
Message-ID: <yg0paZrJMOXS5qoKcSJDCkw-S1lj183vY5jJfvShHKo=.75a64ac4-80ca-4b43-b1e9-154ce04d53dc@github.com>

On Thu, 3 Jul 2025 09:13:30 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> A commit in the implementation of JEP 455, https://github.com/openjdk/jdk/pull/15638/commits/ceee1e4c08457a0793fdfb556db99e057a947af1, added redundant synthetic local variable for trivial `instanceof int`-ish type conversion operations in the javac AST. Such conversions have been present since the introduction of record patterns, and previously they consistently lower to the part before `instanceof`. With this change, the introduced redundant variable is visible in the class file, as seen in the JBS issue.
>> 
>> Testing: langtools/tools/javac
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 2846:
> 
>> 2844: 
>> 2845:             if (types.isUnconditionallyExact(tree.expr.type, tree.pattern.type)) {
>> 2846:                 var = make.Exec(instanceOfExpr);  // drop redundant variable
> 
> While this is sufficient to solve the issue, it might be good to go through the if cascade more thoroughly, and only introduce the variable if needed. I.e. in case the value is used more than once. If the value is used only once (like in the `else if (tree.expr.type.isPrimitive()) {`, it ought to be possible to use it directly. Unless there are ordering or other concerns, of course.

On the flipside, in the tests we already have this:


    public static int meth() {return 42;}
    public static boolean exprMethod() {
        return meth() instanceof int ii;
    }


However this is not sufficient. Can we also add one that actually has side effects and a null check as well and confirm that i is incremented once?


    static int i = 0;
    public static Integer meth_sideEffect() {  i++; return 42;}
    public static boolean exprMethod2() {
        return meth_sideEffect() instanceof int ii;
    }

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26107#discussion_r2182305255

From mcimadamore at openjdk.org  Thu Jul  3 10:08:45 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 3 Jul 2025 10:08:45 GMT
Subject: RFR: 8359493: Refactor how aggregated mandatory warnings are
 handled in the compiler [v4]
In-Reply-To: <69PsKSuzJdOVRwn5j60MDT7-TmmzqGM47cQl4RPJBQ8=.d7551f64-f470-40c9-8756-801f528417b6@github.com>
References: <cNgGXJbQfH7OtGQtQCAOmt9o432jDuqCPUfL701Q7bU=.72e81015-307d-4b37-a241-d5b337a6dd38@github.com>
 <69PsKSuzJdOVRwn5j60MDT7-TmmzqGM47cQl4RPJBQ8=.d7551f64-f470-40c9-8756-801f528417b6@github.com>
Message-ID: <xROS1RfJqtwFunYl_GmFPjTGQcz587GGW2x2ezrcWH8=.aa897e51-758f-4284-b1f3-7c58bce3cc71@github.com>

On Tue, 1 Jul 2025 16:03:33 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> The compiler's handling of the aggregation of mandatory warnings into "notes" at the end of compilation can be refactored to simplify the code.
>> 
>> The `JCDiagnostic` class supports flags that alter how warnings are handled, e.g., `MANDATORY`, `NON_DEFERRABLE`, etc. So instead of having to log aggregated mandatory warnings through a separate channel (the `MandatoryWarningHandler`), these warnings could instead be logged just like any other warning, but with an `AGGREGATED` flag added. The actual aggregation can then be handled "behind the scenes" by the logging subsystem.
>> 
>> This will also make it easier to implement `@SuppressAnnotations` support for parser/tokenizer warnings which require aggregated mandatory warning notes such as warnings for preview features.
>
> Archie 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 five additional commits since the last revision:
> 
>  - Merge branch 'master' into MandatoryWarningCleanup
>  - Move (most) SOURCE_LEVEL flags into compiler.properties.
>  - Add DiagnosticFlag support to compiler.properties and put AGGREGATE there.
>  - Apply some review suggestions.
>  - Refactor MandatoryWarningHandler to just be an aggregator.

make/langtools/tools/propertiesparser/resources/templates.properties line 93:

> 91: diagnostic.flags=\n\
> 92:   '  'Stream.of({0})\n\
> 93:   '    '.map(s -> s.replace(''-'', ''_''))\n\

These transformations could be also done in Java code inside `ClassGenerator` right?

make/langtools/tools/propertiesparser/resources/templates.properties line 96:

> 94:   '    '.map(s -> s.toUpperCase(Locale.ROOT))\n\
> 95:   '    '.map(DiagnosticFlag::valueOf)\n\
> 96:   '    '.toArray(DiagnosticFlag[]::new)

If instead of an array we returned a list, or a set, maybe we could use empty list/set if there's no flag (instead of `null` as we do now?)

src/jdk.compiler/share/classes/com/sun/tools/javac/util/JCDiagnostic.java line 512:

> 510:         DiagnosticType type;
> 511: 
> 512:         /** A set of diagnostic flags to be automatically added to newly created JCDiagnostics (if not null). */

As commented elsewhere -- should we use `null` or something like an empty list/set?

src/jdk.compiler/share/classes/com/sun/tools/javac/util/JCDiagnostic.java line 585:

> 583: 
> 584:         public boolean hasFlag(DiagnosticFlag flag) {
> 585:             return flags != null && Arrays.asList(flags).contains(flag);

This is where it seems that encoding as a possibly null array has a cost

src/jdk.compiler/share/classes/com/sun/tools/javac/util/JCDiagnostic.java line 685:

> 683:         if (diagnosticInfo.flags != null) {
> 684:             for (DiagnosticFlag flag : diagnosticInfo.flags) {
> 685:                 this.flags.add(flag);

This could be `addAll` (if flags were not arrays)

src/jdk.compiler/share/classes/com/sun/tools/javac/util/MandatoryWarningAggregator.java line 131:

> 129:      *                that may be generated, or null to infer from the lint category.
> 130:      */
> 131:     public MandatoryWarningAggregator(Log log, Source source, LintCategory lc, String prefix) {

I think we should call it just `WarningAggregator`. While for now the cases where we aggregate are mandatory warnings, it is not clear to me that we want to give this coupling much importance.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25810#discussion_r2182380617
PR Review Comment: https://git.openjdk.org/jdk/pull/25810#discussion_r2182382167
PR Review Comment: https://git.openjdk.org/jdk/pull/25810#discussion_r2182385914
PR Review Comment: https://git.openjdk.org/jdk/pull/25810#discussion_r2182387337
PR Review Comment: https://git.openjdk.org/jdk/pull/25810#discussion_r2182388765
PR Review Comment: https://git.openjdk.org/jdk/pull/25810#discussion_r2182392534

From mcimadamore at openjdk.org  Thu Jul  3 10:17:42 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 3 Jul 2025 10:17:42 GMT
Subject: RFR: 8359493: Refactor how aggregated mandatory warnings are
 handled in the compiler [v4]
In-Reply-To: <69PsKSuzJdOVRwn5j60MDT7-TmmzqGM47cQl4RPJBQ8=.d7551f64-f470-40c9-8756-801f528417b6@github.com>
References: <cNgGXJbQfH7OtGQtQCAOmt9o432jDuqCPUfL701Q7bU=.72e81015-307d-4b37-a241-d5b337a6dd38@github.com>
 <69PsKSuzJdOVRwn5j60MDT7-TmmzqGM47cQl4RPJBQ8=.d7551f64-f470-40c9-8756-801f528417b6@github.com>
Message-ID: <dEBVBLrTs-GRo3b_Td0Qyv74qNgB-HNB9jBAMA63Fic=.2337869d-7a69-4a33-a1cd-d003016a7ff0@github.com>

On Tue, 1 Jul 2025 16:03:33 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> The compiler's handling of the aggregation of mandatory warnings into "notes" at the end of compilation can be refactored to simplify the code.
>> 
>> The `JCDiagnostic` class supports flags that alter how warnings are handled, e.g., `MANDATORY`, `NON_DEFERRABLE`, etc. So instead of having to log aggregated mandatory warnings through a separate channel (the `MandatoryWarningHandler`), these warnings could instead be logged just like any other warning, but with an `AGGREGATED` flag added. The actual aggregation can then be handled "behind the scenes" by the logging subsystem.
>> 
>> This will also make it easier to implement `@SuppressAnnotations` support for parser/tokenizer warnings which require aggregated mandatory warning notes such as warnings for preview features.
>
> Archie 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 five additional commits since the last revision:
> 
>  - Merge branch 'master' into MandatoryWarningCleanup
>  - Move (most) SOURCE_LEVEL flags into compiler.properties.
>  - Add DiagnosticFlag support to compiler.properties and put AGGREGATE there.
>  - Apply some review suggestions.
>  - Refactor MandatoryWarningHandler to just be an aggregator.

I like capturing flags in the diagnostic key -- it seems to go in the direction of trying to make the diagnostic subsystem more robust and "statically self-described" -- a direction we've kept pushing for quite some time now. I have some (minor) quibbles re. use of nulls.

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

PR Review: https://git.openjdk.org/jdk/pull/25810#pullrequestreview-2982595048

From liach at openjdk.org  Thu Jul  3 13:45:02 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 3 Jul 2025 13:45:02 GMT
Subject: RFR: 8355536: Create version constants to model preview language
 and vm features [v6]
In-Reply-To: <YAzO8X5dqBy4BL3lTS3luonLm9A2RO25tHqcSfPunxo=.df2704c5-148d-49c8-9782-215362b3b034@github.com>
References: <YAzO8X5dqBy4BL3lTS3luonLm9A2RO25tHqcSfPunxo=.df2704c5-148d-49c8-9782-215362b3b034@github.com>
Message-ID: <CR9SL_8QfaRIkg4yyD2zsBzyLyJCHevsJJQkLmyGyOM=.e060bbf3-9ddf-4934-bcb4-61fa7572291f@github.com>

> Sometimes, for version-specific feature access APIs, we wish to access the preview features of the current Java SE release. To reduce the impact of adding one preview-specific version on every site, we can add a constant modeling the preview features as a fake version.

Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits:

 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/preview-cffv
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/preview-cffv
 - Update src/java.base/share/classes/java/lang/reflect/ClassFileFormatVersion.java
 - Update src/java.compiler/share/classes/javax/lang/model/SourceVersion.java
   
   Co-authored-by: Luca Kellermann <lukellmann at gmail.com>
 - Don't need to update latestSupported later
   
 - Merge branch 'pr/25015' of https://github.com/openjdk/jdk into feature/preview-cffv
 - JDK-8356108: Update SourceVersion.RELEASE_25 description for JEPs 511 and 512
 - Add advanced testing for different latestSupported
   
 - 8355536: Create version constants to model preview language and vm features

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

Changes: https://git.openjdk.org/jdk/pull/25017/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25017&range=05
  Stats: 1265 lines in 6 files changed: 1123 ins; 83 del; 59 mod
  Patch: https://git.openjdk.org/jdk/pull/25017.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25017/head:pull/25017

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

From liach at openjdk.org  Thu Jul  3 14:45:50 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 3 Jul 2025 14:45:50 GMT
Subject: RFR: 8357185: Redundant local variables with unconditionally
 matching primitive patterns
In-Reply-To: <yg0paZrJMOXS5qoKcSJDCkw-S1lj183vY5jJfvShHKo=.75a64ac4-80ca-4b43-b1e9-154ce04d53dc@github.com>
References: <Rc2zwv2WHpOwXUjeBUEeUDC3f_3PXNwnNHPC7OWsIvs=.d61b1b72-5917-4026-bad1-3052c0402ebe@github.com>
 <Hv5p9AM02q1-dRAYMrbpzg9uRrMuGCN_6wBypoCJ1MI=.1343c539-5a7b-4faf-acab-46b8375a68a9@github.com>
 <yg0paZrJMOXS5qoKcSJDCkw-S1lj183vY5jJfvShHKo=.75a64ac4-80ca-4b43-b1e9-154ce04d53dc@github.com>
Message-ID: <eev4Qv1FSFJBe63Sq_FjMLNoBSdHfMwYzl3NPYNRJS4=.211fdc65-9dea-4527-bac3-0d468cdb9b90@github.com>

On Thu, 3 Jul 2025 09:24:33 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 2846:
>> 
>>> 2844: 
>>> 2845:             if (types.isUnconditionallyExact(tree.expr.type, tree.pattern.type)) {
>>> 2846:                 var = make.Exec(instanceOfExpr);  // drop redundant variable
>> 
>> While this is sufficient to solve the issue, it might be good to go through the if cascade more thoroughly, and only introduce the variable if needed. I.e. in case the value is used more than once. If the value is used only once (like in the `else if (tree.expr.type.isPrimitive()) {`, it ought to be possible to use it directly. Unless there are ordering or other concerns, of course.
>
> On the flipside, in the tests we already have this (in `PrimitiveInstanceOfPatternOpWithTopLevelPatterns` but also as a type comparison op in `PrimitiveInstanceOfTypeComparisonOp`):
> 
> 
>     public static int meth() {return 42;}
>     public static boolean exprMethod() {
>         return meth() instanceof int ii;
>     }
> 
> 
> However this is not sufficient. Can we also add one (one in each file) that actually has side effects and a null check as well and confirm that i is incremented once?
> 
> 
>     static int i = 0;
>     public static Integer meth_sideEffect() {  i++; return 42;}
>     public static boolean exprMethod2() {
>         return meth_sideEffect() instanceof int ii;
>     }

Do I just paste this block into both tests and call them in main?

    static int sideEffect;
    public static Integer methSideEffect() { sideEffect++; return 42;}
    public static boolean exprMethodSideEffect() {
        sideEffect = 5;
        return methSideEffect() instanceof int ii && sideEffect == 6;
    }

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26107#discussion_r2182970222

From abimpoudis at openjdk.org  Thu Jul  3 14:45:50 2025
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 3 Jul 2025 14:45:50 GMT
Subject: RFR: 8357185: Redundant local variables with unconditionally
 matching primitive patterns
In-Reply-To: <eev4Qv1FSFJBe63Sq_FjMLNoBSdHfMwYzl3NPYNRJS4=.211fdc65-9dea-4527-bac3-0d468cdb9b90@github.com>
References: <Rc2zwv2WHpOwXUjeBUEeUDC3f_3PXNwnNHPC7OWsIvs=.d61b1b72-5917-4026-bad1-3052c0402ebe@github.com>
 <Hv5p9AM02q1-dRAYMrbpzg9uRrMuGCN_6wBypoCJ1MI=.1343c539-5a7b-4faf-acab-46b8375a68a9@github.com>
 <yg0paZrJMOXS5qoKcSJDCkw-S1lj183vY5jJfvShHKo=.75a64ac4-80ca-4b43-b1e9-154ce04d53dc@github.com>
 <eev4Qv1FSFJBe63Sq_FjMLNoBSdHfMwYzl3NPYNRJS4=.211fdc65-9dea-4527-bac3-0d468cdb9b90@github.com>
Message-ID: <6iLjpA5m0_wMfBLilFB131aX53XipiLXO9BkUA1j-GQ=.cf0b3879-3f55-4641-8cd6-2ba23fed4649@github.com>

On Thu, 3 Jul 2025 14:41:08 GMT, Chen Liang <liach at openjdk.org> wrote:

>> On the flipside, in the tests we already have this (in `PrimitiveInstanceOfPatternOpWithTopLevelPatterns` but also as a type comparison op in `PrimitiveInstanceOfTypeComparisonOp`):
>> 
>> 
>>     public static int meth() {return 42;}
>>     public static boolean exprMethod() {
>>         return meth() instanceof int ii;
>>     }
>> 
>> 
>> However this is not sufficient. Can we also add one (one in each file) that actually has side effects and a null check as well and confirm that i is incremented once?
>> 
>> 
>>     static int i = 0;
>>     public static Integer meth_sideEffect() {  i++; return 42;}
>>     public static boolean exprMethod2() {
>>         return meth_sideEffect() instanceof int ii;
>>     }
>
> Do I just paste this block into both tests and call them in main?
> 
>     static int sideEffect;
>     public static Integer methSideEffect() { sideEffect++; return 42;}
>     public static boolean exprMethodSideEffect() {
>         sideEffect = 5;
>         return methSideEffect() instanceof int ii && sideEffect == 6;
>     }

Sure. One with `int ii` and the other with just `int`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26107#discussion_r2182974720

From liach at openjdk.org  Thu Jul  3 14:50:40 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 3 Jul 2025 14:50:40 GMT
Subject: RFR: 8357185: Redundant local variables with unconditionally
 matching primitive patterns
In-Reply-To: <Hv5p9AM02q1-dRAYMrbpzg9uRrMuGCN_6wBypoCJ1MI=.1343c539-5a7b-4faf-acab-46b8375a68a9@github.com>
References: <Rc2zwv2WHpOwXUjeBUEeUDC3f_3PXNwnNHPC7OWsIvs=.d61b1b72-5917-4026-bad1-3052c0402ebe@github.com>
 <Hv5p9AM02q1-dRAYMrbpzg9uRrMuGCN_6wBypoCJ1MI=.1343c539-5a7b-4faf-acab-46b8375a68a9@github.com>
Message-ID: <HwxqtLs9cPWN56US8saskfMeHXWsXc6LGSGuFy29Xco=.31cee469-ee9f-4f93-9396-928db521bd19@github.com>

On Thu, 3 Jul 2025 09:13:30 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> A commit in the implementation of JEP 455, https://github.com/openjdk/jdk/pull/15638/commits/ceee1e4c08457a0793fdfb556db99e057a947af1, added redundant synthetic local variable for trivial `instanceof int`-ish type conversion operations in the javac AST. Such conversions have been present since the introduction of record patterns, and previously they consistently lower to the part before `instanceof`. With this change, the introduced redundant variable is visible in the class file, as seen in the JBS issue.
>> 
>> Testing: langtools/tools/javac
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 2846:
> 
>> 2844: 
>> 2845:             if (types.isUnconditionallyExact(tree.expr.type, tree.pattern.type)) {
>> 2846:                 var = make.Exec(instanceOfExpr);  // drop redundant variable
> 
> While this is sufficient to solve the issue, it might be good to go through the if cascade more thoroughly, and only introduce the variable if needed. I.e. in case the value is used more than once. If the value is used only once (like in the `else if (tree.expr.type.isPrimitive()) {`, it ought to be possible to use it directly. Unless there are ordering or other concerns, of course.

Re @lahodaj: I don't see how the primitive branch uses the value only once - it computes the value, and use it twice: 1st for ExactConversionSupport, 2nd for the expression result. I don't think we can elide the variable.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26107#discussion_r2182985619

From liach at openjdk.org  Thu Jul  3 15:31:01 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 3 Jul 2025 15:31:01 GMT
Subject: RFR: 8357185: Redundant local variables with unconditionally
 matching primitive patterns [v2]
In-Reply-To: <Rc2zwv2WHpOwXUjeBUEeUDC3f_3PXNwnNHPC7OWsIvs=.d61b1b72-5917-4026-bad1-3052c0402ebe@github.com>
References: <Rc2zwv2WHpOwXUjeBUEeUDC3f_3PXNwnNHPC7OWsIvs=.d61b1b72-5917-4026-bad1-3052c0402ebe@github.com>
Message-ID: <cnGmet6Fo6vhE7hjnRJZ4cxhqHQMHASwUvAyNkYNQQM=.11dd4a62-3647-44e4-8c85-bf400d96c298@github.com>

> A commit in the implementation of JEP 455, https://github.com/openjdk/jdk/pull/15638/commits/ceee1e4c08457a0793fdfb556db99e057a947af1, added redundant synthetic local variable for trivial `instanceof int`-ish type conversion operations in the javac AST. Such conversions have been present since the introduction of record patterns, and previously they consistently lower to the part before `instanceof`. With this change, the introduced redundant variable is visible in the class file, as seen in the JBS issue.
> 
> Testing: langtools/tools/javac

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Further improvements and testing per suggestions

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26107/files
  - new: https://git.openjdk.org/jdk/pull/26107/files/c577875b..544822b0

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

  Stats: 88 lines in 4 files changed: 46 ins; 18 del; 24 mod
  Patch: https://git.openjdk.org/jdk/pull/26107.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26107/head:pull/26107

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

From acobbs at openjdk.org  Thu Jul  3 16:28:27 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 3 Jul 2025 16:28:27 GMT
Subject: RFR: 8359493: Refactor how aggregated mandatory warnings are
 handled in the compiler [v5]
In-Reply-To: <cNgGXJbQfH7OtGQtQCAOmt9o432jDuqCPUfL701Q7bU=.72e81015-307d-4b37-a241-d5b337a6dd38@github.com>
References: <cNgGXJbQfH7OtGQtQCAOmt9o432jDuqCPUfL701Q7bU=.72e81015-307d-4b37-a241-d5b337a6dd38@github.com>
Message-ID: <zHnCpmF-8G0QuOYlTN9GLtrCXYaR8oP1ni5njeLwqSc=.bdf2c98b-701a-4729-9a1d-74386b64318a@github.com>

> The compiler's handling of the aggregation of mandatory warnings into "notes" at the end of compilation can be refactored to simplify the code.
> 
> The `JCDiagnostic` class supports flags that alter how warnings are handled, e.g., `MANDATORY`, `NON_DEFERRABLE`, etc. So instead of having to log aggregated mandatory warnings through a separate channel (the `MandatoryWarningHandler`), these warnings could instead be logged just like any other warning, but with an `AGGREGATED` flag added. The actual aggregation can then be handled "behind the scenes" by the logging subsystem.
> 
> This will also make it easier to implement `@SuppressAnnotations` support for parser/tokenizer warnings which require aggregated mandatory warning notes such as warnings for preview features.

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

 - Address review suggestions.
 - Remove assumptions about mandatoryness from the MandatoryWarningAggregator.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25810/files
  - new: https://git.openjdk.org/jdk/pull/25810/files/94cda824..2b16d657

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

  Stats: 68 lines in 5 files changed: 13 ins; 14 del; 41 mod
  Patch: https://git.openjdk.org/jdk/pull/25810.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25810/head:pull/25810

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

From acobbs at openjdk.org  Thu Jul  3 16:28:27 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 3 Jul 2025 16:28:27 GMT
Subject: RFR: 8359493: Refactor how aggregated mandatory warnings are
 handled in the compiler [v4]
In-Reply-To: <xROS1RfJqtwFunYl_GmFPjTGQcz587GGW2x2ezrcWH8=.aa897e51-758f-4284-b1f3-7c58bce3cc71@github.com>
References: <cNgGXJbQfH7OtGQtQCAOmt9o432jDuqCPUfL701Q7bU=.72e81015-307d-4b37-a241-d5b337a6dd38@github.com>
 <69PsKSuzJdOVRwn5j60MDT7-TmmzqGM47cQl4RPJBQ8=.d7551f64-f470-40c9-8756-801f528417b6@github.com>
 <xROS1RfJqtwFunYl_GmFPjTGQcz587GGW2x2ezrcWH8=.aa897e51-758f-4284-b1f3-7c58bce3cc71@github.com>
Message-ID: <JQhqkwng2Cwfl-i_DwxCOGFqxcq2wIrij98PlO_PygM=.b6fc1877-7635-4bef-b70e-660a79d65ba0@github.com>

On Thu, 3 Jul 2025 10:00:14 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> These transformations could be also done in Java code inside `ClassGenerator` right?

Yes, that's simpler. Thanks for this and your other suggestions - all good ones. They should all be addressed in 2b16d65758b.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25810#discussion_r2183204177

From mcimadamore at openjdk.org  Thu Jul  3 17:58:41 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 3 Jul 2025 17:58:41 GMT
Subject: RFR: 8359493: Refactor how aggregated mandatory warnings are
 handled in the compiler [v5]
In-Reply-To: <zHnCpmF-8G0QuOYlTN9GLtrCXYaR8oP1ni5njeLwqSc=.bdf2c98b-701a-4729-9a1d-74386b64318a@github.com>
References: <cNgGXJbQfH7OtGQtQCAOmt9o432jDuqCPUfL701Q7bU=.72e81015-307d-4b37-a241-d5b337a6dd38@github.com>
 <zHnCpmF-8G0QuOYlTN9GLtrCXYaR8oP1ni5njeLwqSc=.bdf2c98b-701a-4729-9a1d-74386b64318a@github.com>
Message-ID: <a0oLOUljihFNwKnCEkvEY9wGsJ9m9xDZ5woQYm87SVQ=.fab9ef92-8d53-4ba2-9989-6e70f699416f@github.com>

On Thu, 3 Jul 2025 16:28:27 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> The compiler's handling of the aggregation of mandatory warnings into "notes" at the end of compilation can be refactored to simplify the code.
>> 
>> The `JCDiagnostic` class supports flags that alter how warnings are handled, e.g., `MANDATORY`, `NON_DEFERRABLE`, etc. So instead of having to log aggregated mandatory warnings through a separate channel (the `MandatoryWarningHandler`), these warnings could instead be logged just like any other warning, but with an `AGGREGATED` flag added. The actual aggregation can then be handled "behind the scenes" by the logging subsystem.
>> 
>> This will also make it easier to implement `@SuppressAnnotations` support for parser/tokenizer warnings which require aggregated mandatory warning notes such as warnings for preview features.
>
> Archie Cobbs has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Address review suggestions.
>  - Remove assumptions about mandatoryness from the MandatoryWarningAggregator.

Looks good!

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

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25810#pullrequestreview-2984134010

From acobbs at openjdk.org  Thu Jul  3 18:15:50 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 3 Jul 2025 18:15:50 GMT
Subject: RFR: 8359493: Refactor how aggregated mandatory warnings are
 handled in the compiler [v5]
In-Reply-To: <zHnCpmF-8G0QuOYlTN9GLtrCXYaR8oP1ni5njeLwqSc=.bdf2c98b-701a-4729-9a1d-74386b64318a@github.com>
References: <cNgGXJbQfH7OtGQtQCAOmt9o432jDuqCPUfL701Q7bU=.72e81015-307d-4b37-a241-d5b337a6dd38@github.com>
 <zHnCpmF-8G0QuOYlTN9GLtrCXYaR8oP1ni5njeLwqSc=.bdf2c98b-701a-4729-9a1d-74386b64318a@github.com>
Message-ID: <9g4fYx4fjc-Ugrc1sANarOyZYAXEOVI5u9QpkpcbrOQ=.18ef2010-a865-48f7-bb1f-eaa5f7e072bc@github.com>

On Thu, 3 Jul 2025 16:28:27 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> The compiler's handling of the aggregation of mandatory warnings into "notes" at the end of compilation can be refactored to simplify the code.
>> 
>> The `JCDiagnostic` class supports flags that alter how warnings are handled, e.g., `MANDATORY`, `NON_DEFERRABLE`, etc. So instead of having to log aggregated mandatory warnings through a separate channel (the `MandatoryWarningHandler`), these warnings could instead be logged just like any other warning, but with an `AGGREGATED` flag added. The actual aggregation can then be handled "behind the scenes" by the logging subsystem.
>> 
>> This will also make it easier to implement `@SuppressAnnotations` support for parser/tokenizer warnings which require aggregated mandatory warning notes such as warnings for preview features.
>
> Archie Cobbs has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Address review suggestions.
>  - Remove assumptions about mandatoryness from the MandatoryWarningAggregator.

Thanks for the review!

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

PR Comment: https://git.openjdk.org/jdk/pull/25810#issuecomment-3033139885

From acobbs at openjdk.org  Thu Jul  3 18:15:51 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 3 Jul 2025 18:15:51 GMT
Subject: Integrated: 8359493: Refactor how aggregated mandatory warnings are
 handled in the compiler
In-Reply-To: <cNgGXJbQfH7OtGQtQCAOmt9o432jDuqCPUfL701Q7bU=.72e81015-307d-4b37-a241-d5b337a6dd38@github.com>
References: <cNgGXJbQfH7OtGQtQCAOmt9o432jDuqCPUfL701Q7bU=.72e81015-307d-4b37-a241-d5b337a6dd38@github.com>
Message-ID: <imDmHS_yHF3Qxfg712iDAFK64gLqEpfcsxwMxWm7FpI=.9e504053-aae7-4569-8bcd-24c0c0069360@github.com>

On Fri, 13 Jun 2025 21:25:54 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> The compiler's handling of the aggregation of mandatory warnings into "notes" at the end of compilation can be refactored to simplify the code.
> 
> The `JCDiagnostic` class supports flags that alter how warnings are handled, e.g., `MANDATORY`, `NON_DEFERRABLE`, etc. So instead of having to log aggregated mandatory warnings through a separate channel (the `MandatoryWarningHandler`), these warnings could instead be logged just like any other warning, but with an `AGGREGATED` flag added. The actual aggregation can then be handled "behind the scenes" by the logging subsystem.
> 
> This will also make it easier to implement `@SuppressAnnotations` support for parser/tokenizer warnings which require aggregated mandatory warning notes such as warnings for preview features.

This pull request has now been integrated.

Changeset: 25ed36f3
Author:    Archie Cobbs <acobbs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/25ed36f3ef1fe1d6914689c762910f104775f48c
Stats:     919 lines in 17 files changed: 440 ins; 417 del; 62 mod

8359493: Refactor how aggregated mandatory warnings are handled in the compiler
8350514: Refactor MandatoryWarningHandler to support dynamic verbosity

Reviewed-by: mcimadamore

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

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

From acobbs at openjdk.org  Thu Jul  3 19:02:27 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 3 Jul 2025 19:02:27 GMT
Subject: RFR: 8348611: Eliminate DeferredLintHandler and emit warnings after
 attribution
Message-ID: <08zj2WBmFFeEQbGegExwyGLIDLQV71_TmkqDA4lYad8=.50f5befe-7d49-4865-92e8-fcbbf1f5ea32@github.com>

This is a cleanup/refactoring of how lint warnings are logged and `@SuppressWarnings` annotations applied.

A central challenge with lint warnings is that warnings can be generated during any compiler phase, but whether a particular lint warning is suppressed via `@SuppressWarnings` can't be known until after attribution. For example, the parser doesn't have enough information to interpret and apply `@SuppressWarnings("text-blocks")` to text blocks, or `@SuppressWarnings("preview")` to preview lexical features; instead, the `DeferredLintHandler` is used to workaround this limitation.

In addition, several other factors complicate things:
* Knowing the current applicable `Lint` instance requires manually tracking it with each declaration visited and applying/removing the `@SuppressWarnings` annotation there, if any
* Some warnings are "suppressibly mandatory" (i.e., they are _emitted if not suppressed_ instead of _emitted if enabled_)
* Some warnings are "unsuppressibly mandatory" (e.g., the "internal proprietary API" warning)
* Some mandatory warnings are _aggregated_ into notes that are emitted at the end of compilation when not enabled
* Some warnings are _lint_ warnings, with a corresponding lint category, while others are just "plain" warnings
* Some lint warnings are suppressible via `@SuppressWarnings`, while others are only suppressible via `-Xlint:-foo` flags
* Speculative compilation requires holding log messages in purgatory until the speculation resolves, after which they are then either discarded or emitted. But this creates a tricky interaction with `DeferredLintHandler` because even after speculation is complete, we may still not yet know whether a warning should be suppressed.

Previously the logic to get all of this right was non-obviously woven around the code base. In particular, you needed to know somehow whether or not to use `DeferredLintHandler`, and in what "mode".

The overall goal of this PR is to simplify usage so that **no matter where you are in the compiler, you can just invoke `log.warning()` to log a warning** and (mostly) forget about all of the details listed above.

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

Commit messages:
 - Merge branch 'master' into JDK-8348611 to fix conflicts.
 - Merge branch 'MandatoryWarningCleanup' into JDK-8348611
 - Address review suggestions.
 - Remove assumptions about mandatoryness from the MandatoryWarningAggregator.
 - Merge branch 'MandatoryWarningCleanup' into JDK-8348611
 - Merge branch 'master' into MandatoryWarningCleanup
 - Merge branch 'MandatoryWarningCleanup' into JDK-8348611
 - Move (most) SOURCE_LEVEL flags into compiler.properties.
 - Add DiagnosticFlag support to compiler.properties and put AGGREGATE there.
 - Apply some review suggestions.
 - ... and 76 more: https://git.openjdk.org/jdk/compare/25ed36f3...ec02990a

Changes: https://git.openjdk.org/jdk/pull/24584/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24584&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8348611
  Stats: 1999 lines in 57 files changed: 1065 ins; 587 del; 347 mod
  Patch: https://git.openjdk.org/jdk/pull/24584.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24584/head:pull/24584

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

From acobbs at openjdk.org  Thu Jul  3 19:02:27 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 3 Jul 2025 19:02:27 GMT
Subject: RFR: 8348611: Eliminate DeferredLintHandler and emit warnings
 after attribution
In-Reply-To: <08zj2WBmFFeEQbGegExwyGLIDLQV71_TmkqDA4lYad8=.50f5befe-7d49-4865-92e8-fcbbf1f5ea32@github.com>
References: <08zj2WBmFFeEQbGegExwyGLIDLQV71_TmkqDA4lYad8=.50f5befe-7d49-4865-92e8-fcbbf1f5ea32@github.com>
Message-ID: <DjwL7B3A49wsthxqPnQUB-JrtEy15CpEzRDYZOE6AgQ=.62dbff04-cb76-4049-97d9-03fb8e7bbb51@github.com>

On Thu, 10 Apr 2025 20:23:15 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> This is a cleanup/refactoring of how lint warnings are logged and `@SuppressWarnings` annotations applied.
> 
> A central challenge with lint warnings is that warnings can be generated during any compiler phase, but whether a particular lint warning is suppressed via `@SuppressWarnings` can't be known until after attribution. For example, the parser doesn't have enough information to interpret and apply `@SuppressWarnings("text-blocks")` to text blocks, or `@SuppressWarnings("preview")` to preview lexical features; instead, the `DeferredLintHandler` is used to workaround this limitation.
> 
> In addition, several other factors complicate things:
> * Knowing the current applicable `Lint` instance requires manually tracking it with each declaration visited and applying/removing the `@SuppressWarnings` annotation there, if any
> * Some warnings are "suppressibly mandatory" (i.e., they are _emitted if not suppressed_ instead of _emitted if enabled_)
> * Some warnings are "unsuppressibly mandatory" (e.g., the "internal proprietary API" warning)
> * Some mandatory warnings are _aggregated_ into notes that are emitted at the end of compilation when not enabled
> * Some warnings are _lint_ warnings, with a corresponding lint category, while others are just "plain" warnings
> * Some lint warnings are suppressible via `@SuppressWarnings`, while others are only suppressible via `-Xlint:-foo` flags
> * Speculative compilation requires holding log messages in purgatory until the speculation resolves, after which they are then either discarded or emitted. But this creates a tricky interaction with `DeferredLintHandler` because even after speculation is complete, we may still not yet know whether a warning should be suppressed.
> 
> Previously the logic to get all of this right was non-obviously woven around the code base. In particular, you needed to know somehow whether or not to use `DeferredLintHandler`, and in what "mode".
> 
> The overall goal of this PR is to simplify usage so that **no matter where you are in the compiler, you can just invoke `log.warning()` to log a warning** and (mostly) forget about all of the details listed above.

Goals:

* Eliminate `DeferredLintHandler` and the requirement for code to configure and use it in order to log warnings
* Allow all warnings to be logged via `log.warning()` without having to know if/how `@SuppressWarnings` might apply
* Eliminate (mostly) the need for manual `Lint` instance manipulation

Design overview:

* Maintain mappings from source code position to `Lint` configuration in the `LintMapper` class
* Notify `LintMapper` when attribution completes so `Lint` configurations can be updated
* Hold/defer lint warnings in `Log.DiagnosticHandler` if the `Lint` configuration is not yet known
* Notify `Log` when held/deferred warnings should be reconsidered and flushed

Patch overview:
* `LintMapper.java`, `Log.java` - Replacing the functionality of `DeferredLintHandler` as described above
* `JavacTrees.java` - Add a couple of missing calls to `Log.useSource()`
* Other `src` classes - Derivative changes and cleanups/code removal
* `test` classes - Warning/error reorderings, plus a few new tests

Recommend ignoring whitespace when viewing the patch.

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

PR Comment: https://git.openjdk.org/jdk/pull/24584#issuecomment-2835563690

From abimpoudis at openjdk.org  Thu Jul  3 19:15:40 2025
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 3 Jul 2025 19:15:40 GMT
Subject: RFR: 8357185: Redundant local variables with unconditionally
 matching primitive patterns [v2]
In-Reply-To: <cnGmet6Fo6vhE7hjnRJZ4cxhqHQMHASwUvAyNkYNQQM=.11dd4a62-3647-44e4-8c85-bf400d96c298@github.com>
References: <Rc2zwv2WHpOwXUjeBUEeUDC3f_3PXNwnNHPC7OWsIvs=.d61b1b72-5917-4026-bad1-3052c0402ebe@github.com>
 <cnGmet6Fo6vhE7hjnRJZ4cxhqHQMHASwUvAyNkYNQQM=.11dd4a62-3647-44e4-8c85-bf400d96c298@github.com>
Message-ID: <czDVyX5XkuJ5nWuY8dPv59BfMCe3_w_6gDYdUHao80s=.b70f7b4d-2bd0-4f24-9b7c-7b496bea2c34@github.com>

On Thu, 3 Jul 2025 15:31:01 GMT, Chen Liang <liach at openjdk.org> wrote:

>> A commit in the implementation of JEP 455, https://github.com/openjdk/jdk/pull/15638/commits/ceee1e4c08457a0793fdfb556db99e057a947af1, added redundant synthetic local variable for trivial `instanceof int`-ish type conversion operations in the javac AST. Such conversions have been present since the introduction of record patterns, and previously they consistently lower to the part before `instanceof`. With this change, the introduced redundant variable is visible in the class file, as seen in the JBS issue.
>> 
>> Testing: langtools/tools/javac
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Further improvements and testing per suggestions

test/langtools/tools/javac/patterns/PrimitiveUnconditionallyExactTest.java line 86:

> 84:     @Test
> 85:     public void testExpressionExecution() {
> 86:         int a = 0;

I wonder, should we also include a test that uses assignment to a reference type? 

e.g., `Long` so that we generate both the `null` check and the ECS call. I am 95% sure that everything will be fine. Up to you @liach

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26107#discussion_r2183595443

From abimpoudis at openjdk.org  Thu Jul  3 19:48:38 2025
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 3 Jul 2025 19:48:38 GMT
Subject: RFR: 8357185: Redundant local variables with unconditionally
 matching primitive patterns [v2]
In-Reply-To: <cnGmet6Fo6vhE7hjnRJZ4cxhqHQMHASwUvAyNkYNQQM=.11dd4a62-3647-44e4-8c85-bf400d96c298@github.com>
References: <Rc2zwv2WHpOwXUjeBUEeUDC3f_3PXNwnNHPC7OWsIvs=.d61b1b72-5917-4026-bad1-3052c0402ebe@github.com>
 <cnGmet6Fo6vhE7hjnRJZ4cxhqHQMHASwUvAyNkYNQQM=.11dd4a62-3647-44e4-8c85-bf400d96c298@github.com>
Message-ID: <oB_gHTl_z4bIYoSbUj3VZG_HygmTo5mVAaiTI7ZOkW0=.971c435c-c15b-46fa-a0d2-447fc9cd7188@github.com>

On Thu, 3 Jul 2025 15:31:01 GMT, Chen Liang <liach at openjdk.org> wrote:

>> A commit in the implementation of JEP 455, https://github.com/openjdk/jdk/pull/15638/commits/ceee1e4c08457a0793fdfb556db99e057a947af1, added redundant synthetic local variable for trivial `instanceof int`-ish type conversion operations in the javac AST. Such conversions have been present since the introduction of record patterns, and previously they consistently lower to the part before `instanceof`. With this change, the introduced redundant variable is visible in the class file, as seen in the JBS issue.
>> 
>> Testing: langtools/tools/javac
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Further improvements and testing per suggestions

Looks good from my side.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 2840:

> 2838:             if (types.isUnconditionallyExact(tree.expr.type, tree.pattern.type)) {
> 2839:                 // instanceOfExpr; true
> 2840:                 sideEffect = make.Exec(instanceOfExpr);

maybe `evaluatedLHS` or `memoizedLHS`.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 2880:

> 2878:                 }
> 2879:             } else {
> 2880:                 throw Assert.error("Non primitive or reference type");

Nice!

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

PR Comment: https://git.openjdk.org/jdk/pull/26107#issuecomment-3033424938
PR Review Comment: https://git.openjdk.org/jdk/pull/26107#discussion_r2183635855
PR Review Comment: https://git.openjdk.org/jdk/pull/26107#discussion_r2183636159

From liach at openjdk.org  Thu Jul  3 20:50:40 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 3 Jul 2025 20:50:40 GMT
Subject: RFR: 8357185: Redundant local variables with unconditionally
 matching primitive patterns [v2]
In-Reply-To: <oB_gHTl_z4bIYoSbUj3VZG_HygmTo5mVAaiTI7ZOkW0=.971c435c-c15b-46fa-a0d2-447fc9cd7188@github.com>
References: <Rc2zwv2WHpOwXUjeBUEeUDC3f_3PXNwnNHPC7OWsIvs=.d61b1b72-5917-4026-bad1-3052c0402ebe@github.com>
 <cnGmet6Fo6vhE7hjnRJZ4cxhqHQMHASwUvAyNkYNQQM=.11dd4a62-3647-44e4-8c85-bf400d96c298@github.com>
 <oB_gHTl_z4bIYoSbUj3VZG_HygmTo5mVAaiTI7ZOkW0=.971c435c-c15b-46fa-a0d2-447fc9cd7188@github.com>
Message-ID: <05ARNMM1w4TIVu92xo4mYjTnBwczZbk0N1x2_lM7UwE=.792845bc-5c78-4c2e-a130-32e799797b4d@github.com>

On Thu, 3 Jul 2025 19:45:04 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Further improvements and testing per suggestions
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 2840:
> 
>> 2838:             if (types.isUnconditionallyExact(tree.expr.type, tree.pattern.type)) {
>> 2839:                 // instanceOfExpr; true
>> 2840:                 sideEffect = make.Exec(instanceOfExpr);
> 
> maybe `evaluatedLHS` or `memoizedLHS`.

This is not really a lhs - we are trying to generate "statement; expression", maybe rename this to `prefixStatement`?

> test/langtools/tools/javac/patterns/PrimitiveUnconditionallyExactTest.java line 86:
> 
>> 84:     @Test
>> 85:     public void testExpressionExecution() {
>> 86:         int a = 0;
> 
> I wonder, should we also include a test that uses assignment to a reference type? 
> 
> e.g., `Long` so that we generate both the `null` check and the ECS call. I am 95% sure that everything will be fine. Up to you @liach

This test aims to ensure side effects are generated. Do we have no such tests yet? I think they better belong to the other 2 existing tests modified.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26107#discussion_r2183724653
PR Review Comment: https://git.openjdk.org/jdk/pull/26107#discussion_r2183727330

From liach at openjdk.org  Thu Jul  3 20:51:43 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 3 Jul 2025 20:51:43 GMT
Subject: RFR: 8360022: ClassRefDupInConstantPoolTest.java fails when
 running in repeat
In-Reply-To: <m5pM9zbPZkRbASSLj-a_HrRXEVqhcG_7B5_n_z9YFBE=.2b71dda6-db28-4f5b-8dc6-c0872478b7e5@github.com>
References: <m5pM9zbPZkRbASSLj-a_HrRXEVqhcG_7B5_n_z9YFBE=.2b71dda6-db28-4f5b-8dc6-c0872478b7e5@github.com>
Message-ID: <gVwKFjlUGe4MKl2JCYrT-aRd26Uy9BHx2xBt7XWx1KY=.95b0bf69-e08f-4ebd-adaf-52e67dc3e17e@github.com>

On Wed, 2 Jul 2025 21:36:07 GMT, Chen Liang <liach at openjdk.org> wrote:

> The javac test `ClassRefDupInConstantPoolTest.java` has an incorrect clean directive: when its subsidary Duplicates class is cleaned, the main class is not, and jtreg eagerly reexecutes the main class and then the test fails by not able to find the nested class.
> 
> This problem is evident when running from intellij idea. It can also be reproduced consistently by:
> 
> make test TEST=langtools/tools/javac/jvm/ClassRefDupInConstantPoolTest.java JTREG=REPEAT_COUNT=2
> 
> 
> Testing: that make test line above now passes.

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/26106#issuecomment-3033598244

From liach at openjdk.org  Thu Jul  3 20:51:43 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 3 Jul 2025 20:51:43 GMT
Subject: Integrated: 8360022: ClassRefDupInConstantPoolTest.java fails when
 running in repeat
In-Reply-To: <m5pM9zbPZkRbASSLj-a_HrRXEVqhcG_7B5_n_z9YFBE=.2b71dda6-db28-4f5b-8dc6-c0872478b7e5@github.com>
References: <m5pM9zbPZkRbASSLj-a_HrRXEVqhcG_7B5_n_z9YFBE=.2b71dda6-db28-4f5b-8dc6-c0872478b7e5@github.com>
Message-ID: <gSeH0ViymoV9cSpUWBMjgscoN83frpec7AccTWIeCtI=.0647b68c-acd9-4eba-843e-5f595e0330aa@github.com>

On Wed, 2 Jul 2025 21:36:07 GMT, Chen Liang <liach at openjdk.org> wrote:

> The javac test `ClassRefDupInConstantPoolTest.java` has an incorrect clean directive: when its subsidary Duplicates class is cleaned, the main class is not, and jtreg eagerly reexecutes the main class and then the test fails by not able to find the nested class.
> 
> This problem is evident when running from intellij idea. It can also be reproduced consistently by:
> 
> make test TEST=langtools/tools/javac/jvm/ClassRefDupInConstantPoolTest.java JTREG=REPEAT_COUNT=2
> 
> 
> Testing: that make test line above now passes.

This pull request has now been integrated.

Changeset: 566279af
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/566279af49a7cf47e6030222e989417855caf1a9
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8360022: ClassRefDupInConstantPoolTest.java fails when running in repeat

Reviewed-by: vromero

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

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

From abimpoudis at openjdk.org  Thu Jul  3 20:56:38 2025
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 3 Jul 2025 20:56:38 GMT
Subject: RFR: 8357185: Redundant local variables with unconditionally
 matching primitive patterns [v2]
In-Reply-To: <05ARNMM1w4TIVu92xo4mYjTnBwczZbk0N1x2_lM7UwE=.792845bc-5c78-4c2e-a130-32e799797b4d@github.com>
References: <Rc2zwv2WHpOwXUjeBUEeUDC3f_3PXNwnNHPC7OWsIvs=.d61b1b72-5917-4026-bad1-3052c0402ebe@github.com>
 <cnGmet6Fo6vhE7hjnRJZ4cxhqHQMHASwUvAyNkYNQQM=.11dd4a62-3647-44e4-8c85-bf400d96c298@github.com>
 <oB_gHTl_z4bIYoSbUj3VZG_HygmTo5mVAaiTI7ZOkW0=.971c435c-c15b-46fa-a0d2-447fc9cd7188@github.com>
 <05ARNMM1w4TIVu92xo4mYjTnBwczZbk0N1x2_lM7UwE=.792845bc-5c78-4c2e-a130-32e799797b4d@github.com>
Message-ID: <v2-cQsy12wfZxcRc3r7-HxriDkPdtclYNVshbU1NcX4=.eb79253d-e2f4-4702-a040-d3af1569f6ef@github.com>

On Thu, 3 Jul 2025 20:45:54 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 2840:
>> 
>>> 2838:             if (types.isUnconditionallyExact(tree.expr.type, tree.pattern.type)) {
>>> 2839:                 // instanceOfExpr; true
>>> 2840:                 sideEffect = make.Exec(instanceOfExpr);
>> 
>> maybe `evaluatedLHS` or `memoizedLHS`.
>
> This is not really a lhs - we are trying to generate "statement; expression", maybe rename this to `prefixStatement`?

True. Yes, good name. Go for it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26107#discussion_r2183737197

From abimpoudis at openjdk.org  Thu Jul  3 21:36:38 2025
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 3 Jul 2025 21:36:38 GMT
Subject: RFR: 8357185: Redundant local variables with unconditionally
 matching primitive patterns [v2]
In-Reply-To: <cnGmet6Fo6vhE7hjnRJZ4cxhqHQMHASwUvAyNkYNQQM=.11dd4a62-3647-44e4-8c85-bf400d96c298@github.com>
References: <Rc2zwv2WHpOwXUjeBUEeUDC3f_3PXNwnNHPC7OWsIvs=.d61b1b72-5917-4026-bad1-3052c0402ebe@github.com>
 <cnGmet6Fo6vhE7hjnRJZ4cxhqHQMHASwUvAyNkYNQQM=.11dd4a62-3647-44e4-8c85-bf400d96c298@github.com>
Message-ID: <-YXFUgp7uUeKkL6W8sXPSZM6OPRgLAjWCyB42-0dhb0=.122a6eca-72d7-4abb-b758-e7ae72f9b0a9@github.com>

On Thu, 3 Jul 2025 15:31:01 GMT, Chen Liang <liach at openjdk.org> wrote:

>> A commit in the implementation of JEP 455, https://github.com/openjdk/jdk/pull/15638/commits/ceee1e4c08457a0793fdfb556db99e057a947af1, added redundant synthetic local variable for trivial `instanceof int`-ish type conversion operations in the javac AST. Such conversions have been present since the introduction of record patterns, and previously they consistently lower to the part before `instanceof`. With this change, the introduced redundant variable is visible in the class file, as seen in the JBS issue.
>> 
>> Testing: langtools/tools/javac
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Further improvements and testing per suggestions

test/langtools/tools/javac/patterns/PrimitiveUnconditionallyExactTest.java line 37:

> 35: 
> 36: /*
> 37:  * @test

The name of this test should be `T8357185` I think.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26107#discussion_r2183783683

From liach at openjdk.org  Fri Jul  4 01:00:58 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 4 Jul 2025 01:00:58 GMT
Subject: RFR: 8357185: Redundant local variables with unconditionally
 matching primitive patterns [v2]
In-Reply-To: <-YXFUgp7uUeKkL6W8sXPSZM6OPRgLAjWCyB42-0dhb0=.122a6eca-72d7-4abb-b758-e7ae72f9b0a9@github.com>
References: <Rc2zwv2WHpOwXUjeBUEeUDC3f_3PXNwnNHPC7OWsIvs=.d61b1b72-5917-4026-bad1-3052c0402ebe@github.com>
 <cnGmet6Fo6vhE7hjnRJZ4cxhqHQMHASwUvAyNkYNQQM=.11dd4a62-3647-44e4-8c85-bf400d96c298@github.com>
 <-YXFUgp7uUeKkL6W8sXPSZM6OPRgLAjWCyB42-0dhb0=.122a6eca-72d7-4abb-b758-e7ae72f9b0a9@github.com>
Message-ID: <T4YeOBNzmkoC5y-HiZBsgg3vcExZaAU1W0_M9SeZGHI=.4c43b383-feb8-4225-ac48-f41dbf21be00@github.com>

On Thu, 3 Jul 2025 21:34:03 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Further improvements and testing per suggestions
>
> test/langtools/tools/javac/patterns/PrimitiveUnconditionallyExactTest.java line 37:
> 
>> 35: 
>> 36: /*
>> 37:  * @test
> 
> The name of this test should be `T8357185` I think.

I think we aim to name tests by the content instead of uninformative bug ids - ids are tracked with the bug jtreg directive.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26107#discussion_r2184013173

From abimpoudis at openjdk.org  Fri Jul  4 07:39:40 2025
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Fri, 4 Jul 2025 07:39:40 GMT
Subject: RFR: 8357185: Redundant local variables with unconditionally
 matching primitive patterns [v2]
In-Reply-To: <T4YeOBNzmkoC5y-HiZBsgg3vcExZaAU1W0_M9SeZGHI=.4c43b383-feb8-4225-ac48-f41dbf21be00@github.com>
References: <Rc2zwv2WHpOwXUjeBUEeUDC3f_3PXNwnNHPC7OWsIvs=.d61b1b72-5917-4026-bad1-3052c0402ebe@github.com>
 <cnGmet6Fo6vhE7hjnRJZ4cxhqHQMHASwUvAyNkYNQQM=.11dd4a62-3647-44e4-8c85-bf400d96c298@github.com>
 <-YXFUgp7uUeKkL6W8sXPSZM6OPRgLAjWCyB42-0dhb0=.122a6eca-72d7-4abb-b758-e7ae72f9b0a9@github.com>
 <T4YeOBNzmkoC5y-HiZBsgg3vcExZaAU1W0_M9SeZGHI=.4c43b383-feb8-4225-ac48-f41dbf21be00@github.com>
Message-ID: <4pskHhl0w3f-_fEZiRuJpEtIhst8W49B0frxFIEYZ1I=.4d699614-cffe-415e-8fed-7cce83a32262@github.com>

On Fri, 4 Jul 2025 00:58:19 GMT, Chen Liang <liach at openjdk.org> wrote:

>> test/langtools/tools/javac/patterns/PrimitiveUnconditionallyExactTest.java line 37:
>> 
>>> 35: 
>>> 36: /*
>>> 37:  * @test
>> 
>> The name of this test should be `T8357185` I think.
>
> I think we aim to name tests by the content instead of uninformative bug ids - ids are tracked with the bug jtreg directive.

Both styles are adopted as we can observe in `jdk/test/langtools/tools/javac`. 

In any case the current name is definitely not descriptive as it has nothing to do with unconditionally exact testing inherently. This is done in `test/jdk/java/lang/runtime/ExactnessConversionsSupportTest.java` or other tests. Unconditionally exact conversion is the context but not the observed effect. 

The test name can be either `T8357185` or something descriptive like `RedundantVariablesInPrimitivePatterns`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26107#discussion_r2184634119

From nbenalla at openjdk.org  Fri Jul  4 11:39:12 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Fri, 4 Jul 2025 11:39:12 GMT
Subject: RFR: 8360302: Update --release 25 symbol information for JDK 25 build
 29
Message-ID: <qcH5s9SdgvEYsSGRYFceDt-U57zMLzC17CTdKD8Nddw=.d7d0efcb-5ccb-4d93-9523-2bef41266f5a@github.com>

Usual symbol file update for a new JDK build. Looks like [JDK-8358099](https://bugs.openjdk.org/browse/JDK-8358099).

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

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

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

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

From mcimadamore at openjdk.org  Fri Jul  4 15:23:53 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 4 Jul 2025 15:23:53 GMT
Subject: RFR: 8361401: Warnings for use of Sun APIs should not be mandatory
Message-ID: <pI2Ks9lTuXr4wIomviZ-blBOlAzVs0uVpddvm_LxlHs=.fa918200-726a-44f5-8595-48dc5ef6fbfb@github.com>

During Java 8, we changed the code that reported use of Sun API warnings (e.g. `com.sun.misc.Unsafe`) to use `Log::mandatoryWarning` instead of `Log::strictWarning`. This change had two effects:

* warnings for use of Sun API would *not* be emitted if more than 100 warnings were displayed
* warnings for use of Sun API would become [mandatory warnings](https://download.java.net/java/early_access/jdk25/docs/api/java.compiler/javax/tools/Diagnostic.Kind.html#MANDATORY_WARNING)

The latter is particularly bad, because the definition of a mandatory warning is that of a warning mandated by the specification. Currently we only use the mandatory status for unchecked, deprecation and preview warnings.

This PR reverts the behavior to what it was before Java 8. That is, the warning for Sun API use is now marked with the `STRICT` flag -- and `Log` will not attempt to filter out warnings with such flag. As a result, the (unused) method `Log::strictWarning` can be removed.

I've tweaked an existing test to check the kind of the Sun API warnings.

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

Commit messages:
 - Remove Log::strictWarning
 - Merge with latest compiler changes
 - Initial push

Changes: https://git.openjdk.org/jdk/pull/26129/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26129&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8361401
  Stats: 69 lines in 6 files changed: 38 ins; 16 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/26129.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26129/head:pull/26129

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

From jlahoda at openjdk.org  Fri Jul  4 15:28:41 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 4 Jul 2025 15:28:41 GMT
Subject: RFR: 8361401: Warnings for use of Sun APIs should not be mandatory
In-Reply-To: <pI2Ks9lTuXr4wIomviZ-blBOlAzVs0uVpddvm_LxlHs=.fa918200-726a-44f5-8595-48dc5ef6fbfb@github.com>
References: <pI2Ks9lTuXr4wIomviZ-blBOlAzVs0uVpddvm_LxlHs=.fa918200-726a-44f5-8595-48dc5ef6fbfb@github.com>
Message-ID: <vFtp7nD2aamWawY4BowzzUPNbS3YjiqZCD9Fy6EndLc=.8ede6fec-8e3b-4fa7-81e4-3ff2a6643ac6@github.com>

On Fri, 4 Jul 2025 10:57:39 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> During Java 8, we changed the code that reported use of Sun API warnings (e.g. `com.sun.misc.Unsafe`) to use `Log::mandatoryWarning` instead of `Log::strictWarning`. This change had two effects:
> 
> * warnings for use of Sun API would *not* be emitted if more than 100 warnings were displayed
> * warnings for use of Sun API would become [mandatory warnings](https://download.java.net/java/early_access/jdk25/docs/api/java.compiler/javax/tools/Diagnostic.Kind.html#MANDATORY_WARNING)
> 
> The latter is particularly bad, because the definition of a mandatory warning is that of a warning mandated by the specification. Currently we only use the mandatory status for unchecked, deprecation and preview warnings.
> 
> This PR reverts the behavior to what it was before Java 8. That is, the warning for Sun API use is now marked with the `STRICT` flag -- and `Log` will not attempt to filter out warnings with such flag. As a result, the (unused) method `Log::strictWarning` can be removed.
> 
> I've tweaked an existing test to check the kind of the Sun API warnings.

Looks good to me.

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26129#pullrequestreview-2987683863