From joe.darcy at oracle.com Sun Feb 2 10:52:27 2025 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Sun, 2 Feb 2025 02:52:27 -0800 Subject: Question about "sourcefile" In-Reply-To: References: Message-ID: <8fd04d9f-9375-4abb-a14c-85031a2b533a@oracle.com> Hi Archie, Without actually checking if this is the case, if "sourcefile" could also mean the class file a type was constructed from, then nested types would have a different sourcefile field than the top-level type. HTH, -Joe On 1/30/2025 8:18 AM, Archie Cobbs wrote: > In JavaCompiler.java, there is code that looks like this: > > JavaFileObject prev = log.useSource(*env.enclClass.sym.sourcefile != > null ? > env.enclClass.sym.sourcefile : > env.toplevel.sourcefile*); > ??????? try { > ??????????? ... do something ... > ??????? } finally { > log.useSource(prev); > ??????? } > > I don't understand why the boldface part is needed. How would it ever > be possible for a class A to have an enclosing class B that exists in > a different source file? > > Put another way, isn't env.toplevel.sourcefile always the source file > that corresponds to any class being compiled? > > Thanks for any clarifications. > > -Archie > > -- > Archie L. Cobbs -------------- next part -------------- An HTML attachment was scrubbed... URL: From archie.cobbs at gmail.com Sun Feb 2 21:08:28 2025 From: archie.cobbs at gmail.com (Archie Cobbs) Date: Sun, 2 Feb 2025 15:08:28 -0600 Subject: Question about "sourcefile" In-Reply-To: <8fd04d9f-9375-4abb-a14c-85031a2b533a@oracle.com> References: <8fd04d9f-9375-4abb-a14c-85031a2b533a@oracle.com> Message-ID: Hi Joe, Thanks for the hint! Looking further it looks like "sourcefile" can derive from a class file, so what you're saying can actually happen. But it also looks like for classes defined in actual source files being compiled, the two things are always the same. That happens here . Thanks, -Archie On Sun, Feb 2, 2025 at 4:52?AM Joseph D. Darcy wrote: > Hi Archie, > > Without actually checking if this is the case, if "sourcefile" could also > mean the class file a type was constructed from, then nested types would > have a different sourcefile field than the top-level type. > > HTH, > > -Joe > On 1/30/2025 8:18 AM, Archie Cobbs wrote: > > In JavaCompiler.java, there is code that looks like this: > > JavaFileObject prev = log.useSource( > > *env.enclClass.sym.sourcefile != null ? > env.enclClass.sym.sourcefile : > env.toplevel.sourcefile*); > try { > ... do something ... > } finally { > log.useSource(prev); > } > > I don't understand why the boldface part is needed. How would it ever be > possible for a class A to have an enclosing class B that exists in a > different source file? > > Put another way, isn't env.toplevel.sourcefile always the source file > that corresponds to any class being compiled? > > Thanks for any clarifications. > > -Archie > > -- > Archie L. Cobbs > > -- Archie L. Cobbs -------------- next part -------------- An HTML attachment was scrubbed... URL: From abimpoudis at openjdk.org Mon Feb 3 09:10:55 2025 From: abimpoudis at openjdk.org (Aggelos Biboudis) Date: Mon, 3 Feb 2025 09:10:55 GMT Subject: Integrated: 8326485: Assertion due to Type.addMetadata adding annotations to already-annotated type In-Reply-To: <8gvMozOrqmReKzLdGSWhQOiVUIZNi7_W6PxXdwfOYD8=.bf2f67ca-4b17-4506-bec2-c1738865b123@github.com> References: <8gvMozOrqmReKzLdGSWhQOiVUIZNi7_W6PxXdwfOYD8=.bf2f67ca-4b17-4506-bec2-c1738865b123@github.com> Message-ID: On Thu, 23 Jan 2025 16:17:45 GMT, Aggelos Biboudis wrote: > We end up with an errorType having annotation metadata (which subsequently results in this assertion getting invalidated after `Type ret = typeWithAnnotations(type, enclTy, annotations);` is executed). > > What if we continue to try to define the `enclTy` (iteratively)? The error can still be reported appropriately. If this PR is merged it reproduces the original test case by running as expected: many errors without a crash: > > > javac src/main/java/net/ccbluex/liquidbounce/injection/mixins/minecraft/gui/MixinChatInputSuggestor.java -cp /tmp/jars/annotations-20.1.0.jar:/tmp/jars/kotlin-compiler-embeddable-1.9.0.jar > > > WDYT? This pull request has now been integrated. Changeset: 9aa6d09b Author: Aggelos Biboudis URL: https://git.openjdk.org/jdk/commit/9aa6d09bf74110bf4f5756d7c3b106558042102f Stats: 44 lines in 3 files changed: 42 ins; 1 del; 1 mod 8326485: Assertion due to Type.addMetadata adding annotations to already-annotated type Reviewed-by: jlahoda ------------- PR: https://git.openjdk.org/jdk/pull/23272 From abimpoudis at openjdk.org Mon Feb 3 10:40:46 2025 From: abimpoudis at openjdk.org (Aggelos Biboudis) Date: Mon, 3 Feb 2025 10:40:46 GMT Subject: RFR: 8349132: javac Analyzers should handle non-deferrable errors In-Reply-To: References: Message-ID: On Fri, 31 Jan 2025 12:44:32 GMT, Jan Lahoda wrote: > Consider this test script: > > $ cat JDK8349132.sh > mkdir -p JDK-8349132 > cd JDK-8349132 > cat >Utils.java < package test; > public class Utils { > public static void run(Task uat) {} > } > interface Task { > public void run(T t) throws Exception; > } > class Param {} > EOF > cat >Test.java < package test; > public class Test { > private static void test() { > Utils.run(new Task() { > @Override > public void run(Param parameter) throws Exception { > } > }); > } > } > EOF > > javac -d out Utils.java > rm out/test/Param.class > javac -XDfind=diamond -XDshould-stop.at=FLOW -classpath out Test.java > > > It fails with: > > $ bash JDK8349132.sh > Test.java:4: error: cannot find symbol > Utils.run(new Task() { > ^ > symbol: class Param > location: class Test > Test.java:6: error: cannot find symbol > public void run(Param parameter) throws Exception { > ^ > symbol: class Param > Test.java:4: error: cannot access Param > Utils.run(new Task() { > ^ > class file for test.Param not found > 3 errors > An exception has occurred in the compiler (21.0.5). 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.AssertionError: Analyzer error when processing: Utils.run(new Task(){ > > () { > super(); > } > > @Override > public void run(Param parameter) throws Exception { > } > });:java.lang.NullPointerException: Cannot invoke "com.sun.tools.javac.code.Type.getTypeArguments()" because "com.sun.tools.javac.util.List.get(int).type" is null > jdk.compiler/com.sun.tools.javac.comp.Analyzer$DiamondInitializer.process(Analyzer.java:258) > jdk.compiler/com.sun.tools.javac.comp.Analyzer$DiamondInitializer.process(Analyzer.java:228) > jdk.compiler/com.sun.tools.javac.comp.Analyzer.doAnalysis(Analyzer.java:577) > jdk.compiler/com.sun.tools.javac.comp.Analyzer$2.flush(Analyzer.java:547) > jdk.compiler/com.sun.tools.javac.comp.Analyzer.flush(Analyzer.java:591) > jdk.compiler/com.sun.tools.javac.main.JavaCompiler.flow(JavaCompiler.java:1425) > jdk.compiler/com.sun.tools.javac.main.JavaCompiler.flow(JavaCompiler.java:1393) > jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:976... Looks good to me. And thanks for the great analysis. I was wondering, the third error is not coming from the `DiamondInitializer` is seems. It must have been one of the subsequent, right?: `LambdaAnalyzer`, `RedundantTypeArgAnalyzer`, `RedundantLocalVarTypeAnalyzer`, `RedundantLocalVarTypeAnalyzerForEach`. ------------- Marked as reviewed by abimpoudis (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23387#pullrequestreview-2589523382 From maurizio.cimadamore at oracle.com Tue Feb 4 17:13:37 2025 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 4 Feb 2025 17:13:37 +0000 Subject: Would it make sense to make missing/incorrect method errors be above generics errors? In-Reply-To: References: Message-ID: <6e42c58e-b199-4622-b7cd-58eca057bfda@oracle.com> Hi David, in general there's nothing preventing us from reordering or presenting messages in a different way. In fact, as part of Java 8, we introduced some heuristics so that if a method callsite had many potentially applicable methods, but only one had the correct arity, we show a much more specific error assuming that's the method the user wanted to call. As for your case, I think it would help if you could boil it down to a specific example, so that we can discuss it further, and maybe file an issue. Cheers Maurizio On 28/01/2025 19:07, David Alayachew wrote: > Hello Compiler Dev Team, > > I am coming in entirely ignorant of how the compiler works under the > hood. I am trying to correct this ignorance, but I hope you'll forgive > an ignorant question in the meantime. > > Would it make sense to have missing method errors (can't find symbol) > be above errors like invalid method references (trying to use > non-static method in static context)? > > Basically, I am just asking to alter the output order of compile time > errors. We all have run into situations where we get this nightmarish > generics error, and the actual error is that we mispelled a method > name or something. However, the misspelled error is usually beneath > the ugly generics error. > > If the top of the list was a "can't find symbol", that would make it > much more obvious what the problem is. Then, when the problem actually > is our generics, then it will be unambiguous as opposed to trying to > parse the many errors in compile time. > > Of course, if altering error output order is a pandora's box that we > don't want to open, then I understand. From my ignorant opinion, > altering the output order of an already compiled list seems easy, but > maybe there are rules in place that prevent that, or we don't want to > mess with people's mental model. Or maybe we are expected to have read > the entire list of errors and parse the best next steps only after > having read the whole thing lol. I don't know. > > Thank you for your time and help. > David Alayachew From cushon at openjdk.org Tue Feb 4 23:54:40 2025 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Tue, 4 Feb 2025 23:54:40 GMT Subject: RFR: 8349058: 'internal proprietary API' warnings make javac warnings unusable Message-ID: This change is a partial backout of [JDK-8332744](https://bugs.openjdk.org/browse/JDK-8332744). The logic was reverted, but the test was preserved and updated to reflect the updated behaviour, and some cleanups to benchmark code were kept. This restores the ability to use `-XDignore.symbol.file` as an ad-hoc suppression mechanism for `sunapi` diagnostics, see discussion in [JDK-8349058](https://bugs.openjdk.org/browse/JDK-8349058). ------------- Commit messages: - 8349058: 'internal proprietary API' warnings make javac warnings unusable Changes: https://git.openjdk.org/jdk/pull/23448/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23448&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8349058 Stats: 87 lines in 2 files changed: 30 ins; 38 del; 19 mod Patch: https://git.openjdk.org/jdk/pull/23448.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23448/head:pull/23448 PR: https://git.openjdk.org/jdk/pull/23448 From mcimadamore at openjdk.org Wed Feb 5 11:05:16 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 5 Feb 2025 11:05:16 GMT Subject: RFR: 8347958: Minor compiler cleanups relating to MandatoryWarningHandler [v2] In-Reply-To: References: <-8kPXPXKm9itoPQw509dc7-qVsaGQoItWUdfjsdm2Bo=.fdb56031-0392-44d7-b190-e30fc25b17ca@github.com> Message-ID: On Sat, 25 Jan 2025 23:01:38 GMT, Archie Cobbs wrote: >> After recent improvements to Lint-related classes, there are now a few minor cleanup opportunities relating to `MandatoryWarningHandler`. >> >> 1. The new `LintWarning` class provides access to the associated `LintCategory`. This means that the `LintCategory` parameter being passed to the `MandatoryWarningHandler` constructor is no longer needed. >> 1. The `prefix` string being passed to the `MandatoryWarningHandler` constructor can (in most cases) be inferred as well. >> 1. The field `Check.sunApiHandler` (which has type `MandatoryWarningHandler`) is no longer used and can be removed. > > Archie Cobbs 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 branch 'master' into JDK-8347958 to fix conflict. > - Some cleanups relating to MandatoryWarningHandler. src/jdk.compiler/share/classes/com/sun/tools/javac/util/MandatoryWarningHandler.java line 155: > 153: > 154: // Infer the log prefix from the lint category if not given explicitly > 155: if (prefix == null) Honestly, I'm not sure if I would call this an improvement. The code used to be strict -- only one kind of warning allowed per handler. Now the handler starts off empty, and the first `report` determines the kind. But the same kind is then used for _all_ deferred logging... my feeling is that this would be better left alone (in the sense that I'm not sure the outcome of this PR is _objectively_ better than the code it replaces?) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23167#discussion_r1942665132 From mcimadamore at openjdk.org Wed Feb 5 11:05:16 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 5 Feb 2025 11:05:16 GMT Subject: RFR: 8347958: Minor compiler cleanups relating to MandatoryWarningHandler [v2] In-Reply-To: References: <-8kPXPXKm9itoPQw509dc7-qVsaGQoItWUdfjsdm2Bo=.fdb56031-0392-44d7-b190-e30fc25b17ca@github.com> Message-ID: On Wed, 5 Feb 2025 11:01:12 GMT, Maurizio Cimadamore wrote: >> Archie Cobbs 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 branch 'master' into JDK-8347958 to fix conflict. >> - Some cleanups relating to MandatoryWarningHandler. > > src/jdk.compiler/share/classes/com/sun/tools/javac/util/MandatoryWarningHandler.java line 155: > >> 153: >> 154: // Infer the log prefix from the lint category if not given explicitly >> 155: if (prefix == null) > > Honestly, I'm not sure if I would call this an improvement. The code used to be strict -- only one kind of warning allowed per handler. Now the handler starts off empty, and the first `report` determines the kind. But the same kind is then used for _all_ deferred logging... my feeling is that this would be better left alone (in the sense that I'm not sure the outcome of this PR is _objectively_ better than the code it replaces?) (of course the part that removes the sunapi handler is ok and orthogonal) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23167#discussion_r1942666297 From mcimadamore at openjdk.org Wed Feb 5 11:07:13 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 5 Feb 2025 11:07:13 GMT Subject: RFR: 8349155: The "log" parameter to Lint.logIfEnabled() is not needed In-Reply-To: References: Message-ID: On Fri, 31 Jan 2025 18:11:41 GMT, Archie Cobbs wrote: > In [JDK-8345263](https://bugs.openjdk.org/browse/JDK-8345263), a new method `Lint.logIfEnabled(Log log, DiagnosticPosition pos, LintWarning warning)` was added. It was decided at the time to pass a `log` parameter explicitly instead of having `Lint` keep its own reference to the `Log` singleton. This was done to keep a conservative approach with the refactoring and to avoid possible initialization ordering issues. > > After other recent changes ([JDK-8344079](https://bugs.openjdk.org/browse/JDK-8344079), [JDK-8347474](https://bugs.openjdk.org/browse/JDK-8347474)) the initialization ordering issues have been alleviated. It's also the case that there is only ever one `Log` instance per compiler `Context`. So the `log` parameter can be removed and `Lint` can just keep its own reference, as is the normal custom in the compiler code. This results in a minor code cleanup. This change looks good - thanks for picking this up again! ------------- Marked as reviewed by mcimadamore (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23400#pullrequestreview-2595339263 From mcimadamore at openjdk.org Wed Feb 5 11:13:16 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 5 Feb 2025 11:13:16 GMT Subject: RFR: 8348427: DeferredLintHandler API should use JCTree instead of DiagnosticPosition [v2] In-Reply-To: <_n7hsThMGaGZhlj2DiHBN63oeiajVON_Qmn_gSdPpjM=.d075b726-061d-4054-850b-8d52bcf7ab37@github.com> References: <_n7hsThMGaGZhlj2DiHBN63oeiajVON_Qmn_gSdPpjM=.d075b726-061d-4054-850b-8d52bcf7ab37@github.com> Message-ID: On Fri, 24 Jan 2025 23:34:28 GMT, Archie Cobbs wrote: >> The purpose of `DeferredLintHandler` is to allow `@SuppressWarnings` to be applied to warnings that are generated before `@SuppressWarnings` annotations themselves have been processed. The way this currently works is that warning callbacks are kept in a `HashMap` keyed by the innermost containing module, package, class, method, or variable declarations (in the form of a `JCModuleDecl`, `JCPackageDecl`, `JCClassDecl`, `JCMethodDecl`, or `JCVariableDecl`). Later, when the compiler executes the attribution phase and the lint categories suppressed at each declaration are known, the corresponding warning callbacks are provided with an appropriately configured `Lint` instance and "flushed". >> >> However, the `DeferredLintHandler` API uses `DiagnosticPosition` instead of `JCTree` for registering and flushing deferred warnings. This opens the door for bugs where warnings are registered to an object which is not a declaration, and therefore ignored. >> >> In fact, this occurs once in the code ([here](https://github.com/openjdk/jdk/blob/48ece0721489c1b357aaa81e89fe59f486079d15/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Annotate.java#L679)) where a `JCExpression` is being passed, although in this case the bug appears to be harmless (because annotation values can't contain any type of declaration). >> >> The API should be tighted up, and furthermore an assertion should be added to verify that the JCTree being passed is actually a declaration supporting `@SuppressWarnings`. >> >> In addition, there is a design flaw in the API: it's not possible to obtain the current immediate mode `Lint` object, so if an immediate mode `Lint` object is pushed/popped more than once, the second `Lint` object will overwrite the first. >> >> To fix this, the API should be adjusted so the stack of current declarations and/or immediate mode `Lint` objects is managed by the `DeferredLintHandler` itself, by providing a `push()` and `pop()` methods in the API. > > Archie Cobbs 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 branch 'master' into JDK-8348427 to fix conflict. > - Refactor the DeferredLintHandler API to maintain the "stack" itself. > - Add Javadoc to document a subtley in the API. > - Update DeferredLintHandler API to use JCTree instead of DiagnosticPosition. src/jdk.compiler/share/classes/com/sun/tools/javac/code/DeferredLintHandler.java line 30: > 28: import java.util.ArrayDeque; > 29: import java.util.ArrayList; > 30: import java.util.Comparator; Are these imports all used? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23281#discussion_r1942677347 From mcimadamore at openjdk.org Wed Feb 5 11:33:11 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 5 Feb 2025 11:33:11 GMT Subject: RFR: 8348427: DeferredLintHandler API should use JCTree instead of DiagnosticPosition [v2] In-Reply-To: <_n7hsThMGaGZhlj2DiHBN63oeiajVON_Qmn_gSdPpjM=.d075b726-061d-4054-850b-8d52bcf7ab37@github.com> References: <_n7hsThMGaGZhlj2DiHBN63oeiajVON_Qmn_gSdPpjM=.d075b726-061d-4054-850b-8d52bcf7ab37@github.com> Message-ID: On Fri, 24 Jan 2025 23:34:28 GMT, Archie Cobbs wrote: >> The purpose of `DeferredLintHandler` is to allow `@SuppressWarnings` to be applied to warnings that are generated before `@SuppressWarnings` annotations themselves have been processed. The way this currently works is that warning callbacks are kept in a `HashMap` keyed by the innermost containing module, package, class, method, or variable declarations (in the form of a `JCModuleDecl`, `JCPackageDecl`, `JCClassDecl`, `JCMethodDecl`, or `JCVariableDecl`). Later, when the compiler executes the attribution phase and the lint categories suppressed at each declaration are known, the corresponding warning callbacks are provided with an appropriately configured `Lint` instance and "flushed". >> >> However, the `DeferredLintHandler` API uses `DiagnosticPosition` instead of `JCTree` for registering and flushing deferred warnings. This opens the door for bugs where warnings are registered to an object which is not a declaration, and therefore ignored. >> >> In fact, this occurs once in the code ([here](https://github.com/openjdk/jdk/blob/48ece0721489c1b357aaa81e89fe59f486079d15/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Annotate.java#L679)) where a `JCExpression` is being passed, although in this case the bug appears to be harmless (because annotation values can't contain any type of declaration). >> >> The API should be tighted up, and furthermore an assertion should be added to verify that the JCTree being passed is actually a declaration supporting `@SuppressWarnings`. >> >> In addition, there is a design flaw in the API: it's not possible to obtain the current immediate mode `Lint` object, so if an immediate mode `Lint` object is pushed/popped more than once, the second `Lint` object will overwrite the first. >> >> To fix this, the API should be adjusted so the stack of current declarations and/or immediate mode `Lint` objects is managed by the `DeferredLintHandler` itself, by providing a `push()` and `pop()` methods in the API. > > Archie Cobbs 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 branch 'master' into JDK-8348427 to fix conflict. > - Refactor the DeferredLintHandler API to maintain the "stack" itself. > - Add Javadoc to document a subtley in the API. > - Update DeferredLintHandler API to use JCTree instead of DiagnosticPosition. Question: what happens if we get rid of the "immediate" and we always defer? Does this only affect the order in which diagnostics are reported, or is there something deeper? ------------- PR Review: https://git.openjdk.org/jdk/pull/23281#pullrequestreview-2595400317 From maurizio.cimadamore at oracle.com Wed Feb 5 11:41:47 2025 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 5 Feb 2025 11:41:47 +0000 Subject: Capture conversion and switch selectors In-Reply-To: References: Message-ID: I'm not sure the capture is the issue here. Note that if the case is rewritten to case B b Then everything works as expected and javac doesn't get confused by capture conversion. Note that capture conversion is always problematic when it comes to cast expressions -- because the cast has to "relax" some of the captured variable that might be introduced by capture conversion. This is an area of the specification that is underspecified, so javac (and other implementations) have to workaround such issues the best they can. The particular example you pose seems like it should work to me -- there's only one possible parameterization for A coming up from B.C - and that's A, so the conversion should be safe here. It seems to me like a case of bad interplay between enums constants and patterns. Maurizio On 28/01/2025 18:51, Liam Miller-Cushon wrote: > Hi, > > Chris Povirk and I were trying to understand why examples like the > following are rejected: > > sealed interface A { > ? enum B implements A { > ? ? C; > ? } > > ? static void d(A a) { > ? ? switch (a) { > ? ? ? case B.C: > ? ? } > ? } > } > > A.java:8: error: incompatible types: B cannot be converted to A > ? ? ? case B.C: > ? ? ? ? ? ? ^ > ? where CAP#1 is a fresh type-variable: > ? ? CAP#1 extends Object from capture of ? > > I think this is a consequence of JLS 6.5.6.1, which says that the type > of the switch selector expression is subject to capture conversion, > and then the captured type is not convertible. > > In the implementation, this is happening here [1], where attribExpr > uses KindSelector.VAL, which causes the capture to happen. > > Has consideration been given to treating selector expressions > differently, to avoid the capture conversion, and allow examples like > this to compile? I couldn't find test coverage for this specific > combination of features, which made me wonder if this was a corner > case that hadn't been explored, rather than something that had > definitely been ruled out. > > Liam > > [1] > https://github.com/openjdk/jdk/blob/a224f12cb701b45df4706a403a05c66de2d623af/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java#L1702 From acobbs at openjdk.org Wed Feb 5 16:21:37 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Wed, 5 Feb 2025 16:21:37 GMT Subject: RFR: 8347958: Minor compiler cleanups relating to MandatoryWarningHandler [v3] In-Reply-To: <-8kPXPXKm9itoPQw509dc7-qVsaGQoItWUdfjsdm2Bo=.fdb56031-0392-44d7-b190-e30fc25b17ca@github.com> References: <-8kPXPXKm9itoPQw509dc7-qVsaGQoItWUdfjsdm2Bo=.fdb56031-0392-44d7-b190-e30fc25b17ca@github.com> Message-ID: > After recent improvements to Lint-related classes, there are now a few minor cleanup opportunities relating to `MandatoryWarningHandler`. > > 1. The new `LintWarning` class provides access to the associated `LintCategory`. This means that the `LintCategory` parameter being passed to the `MandatoryWarningHandler` constructor is no longer needed. > 1. The `prefix` string being passed to the `MandatoryWarningHandler` constructor can (in most cases) be inferred as well. > 1. The field `Check.sunApiHandler` (which has type `MandatoryWarningHandler`) is no longer used and can be removed. Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision: Restore the explicit LintCategory constructor parameter. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23167/files - new: https://git.openjdk.org/jdk/pull/23167/files/0ce44d63..87e44347 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23167&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23167&range=01-02 Stats: 26 lines in 3 files changed: 12 ins; 3 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/23167.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23167/head:pull/23167 PR: https://git.openjdk.org/jdk/pull/23167 From acobbs at openjdk.org Wed Feb 5 16:21:38 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Wed, 5 Feb 2025 16:21:38 GMT Subject: RFR: 8347958: Minor compiler cleanups relating to MandatoryWarningHandler [v2] In-Reply-To: References: <-8kPXPXKm9itoPQw509dc7-qVsaGQoItWUdfjsdm2Bo=.fdb56031-0392-44d7-b190-e30fc25b17ca@github.com> Message-ID: On Wed, 5 Feb 2025 11:02:06 GMT, Maurizio Cimadamore wrote: >> src/jdk.compiler/share/classes/com/sun/tools/javac/util/MandatoryWarningHandler.java line 155: >> >>> 153: >>> 154: // Infer the log prefix from the lint category if not given explicitly >>> 155: if (prefix == null) >> >> Honestly, I'm not sure if I would call this an improvement. The code used to be strict -- only one kind of warning allowed per handler. Now the handler starts off empty, and the first `report` determines the kind. But the same kind is then used for _all_ deferred logging... my feeling is that this would be better left alone (in the sense that I'm not sure the outcome of this PR is _objectively_ better than the code it replaces?) > > (of course the part that removes the sunapi handler is ok and orthogonal) > Now the handler starts off empty, and the first report determines the kind. But the same kind is then used for all deferred logging... You are correct - which is why the Javadoc comment "Instances assume all warnings will be in the same LintCategory" was added. So in summary, I replaced what was previously an assertion of an invariant with a new API requirement of that invariant (which, currently, is satisfied). Admittedly it was a close call - the benefit being the elimination of an instance field and constructor parameter. But keeping the assertion is a more conservative approach so I'll do that instead. Updated in 87e44347f65. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23167#discussion_r1943267113 From jlahoda at openjdk.org Wed Feb 5 16:23:49 2025 From: jlahoda at openjdk.org (Jan Lahoda) Date: Wed, 5 Feb 2025 16:23:49 GMT Subject: RFR: 8349132: javac Analyzers should handle non-deferrable errors In-Reply-To: References: Message-ID: On Mon, 3 Feb 2025 10:38:21 GMT, Aggelos Biboudis wrote: > Looks good to me. And thanks for the great analysis. > > I was wondering, the third error is not coming from the `DiamondInitializer` is seems. It must have been one of the subsequent, right?: `LambdaAnalyzer`, `RedundantTypeArgAnalyzer`, `RedundantLocalVarTypeAnalyzer`, `RedundantLocalVarTypeAnalyzerForEach`. The third error comes from the DiamondInitializer (I checked, the rewrites are queued, and run later, but I printed the analyzer that scheduled the rewrite). ------------- PR Comment: https://git.openjdk.org/jdk/pull/23387#issuecomment-2637403603 From cushon at openjdk.org Wed Feb 5 18:34:26 2025 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Wed, 5 Feb 2025 18:34:26 GMT Subject: RFR: 8349058: 'internal proprietary API' warnings make javac warnings unusable [v2] In-Reply-To: References: Message-ID: > This change is a partial backout of [JDK-8332744](https://bugs.openjdk.org/browse/JDK-8332744). The logic was reverted, but the test was preserved and updated to reflect the updated behaviour, and some cleanups to benchmark code were kept. > > This restores the ability to use `-XDignore.symbol.file` as an ad-hoc suppression mechanism for `sunapi` diagnostics, see discussion in [JDK-8349058](https://bugs.openjdk.org/browse/JDK-8349058). Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: Improvements to test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23448/files - new: https://git.openjdk.org/jdk/pull/23448/files/48388688..9bf37fc6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23448&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23448&range=00-01 Stats: 24 lines in 1 file changed: 17 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/23448.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23448/head:pull/23448 PR: https://git.openjdk.org/jdk/pull/23448 From mcimadamore at openjdk.org Wed Feb 5 22:09:11 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 5 Feb 2025 22:09:11 GMT Subject: RFR: 8347958: Minor compiler cleanups relating to MandatoryWarningHandler [v3] In-Reply-To: References: <-8kPXPXKm9itoPQw509dc7-qVsaGQoItWUdfjsdm2Bo=.fdb56031-0392-44d7-b190-e30fc25b17ca@github.com> Message-ID: On Wed, 5 Feb 2025 16:21:37 GMT, Archie Cobbs wrote: >> After recent improvements to Lint-related classes, there are now a few minor cleanup opportunities relating to `MandatoryWarningHandler`. >> >> 1. The new `LintWarning` class provides access to the associated `LintCategory`. This means that the `LintCategory` parameter being passed to the `MandatoryWarningHandler` constructor is no longer needed. >> 1. The `prefix` string being passed to the `MandatoryWarningHandler` constructor can (in most cases) be inferred as well. >> 1. The field `Check.sunApiHandler` (which has type `MandatoryWarningHandler`) is no longer used and can be removed. > > Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision: > > Restore the explicit LintCategory constructor parameter. Thanks for fixing! ------------- Marked as reviewed by mcimadamore (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23167#pullrequestreview-2597086741 From mcimadamore at openjdk.org Wed Feb 5 22:09:12 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 5 Feb 2025 22:09:12 GMT Subject: RFR: 8347958: Minor compiler cleanups relating to MandatoryWarningHandler [v2] In-Reply-To: References: <-8kPXPXKm9itoPQw509dc7-qVsaGQoItWUdfjsdm2Bo=.fdb56031-0392-44d7-b190-e30fc25b17ca@github.com> Message-ID: <-0WfDRp85SwgKyL42WdPCw8WTilVKyXAiXtuh0nApSE=.fc154bb5-bed4-4e29-8487-3f4d830c190c@github.com> On Wed, 5 Feb 2025 16:18:50 GMT, Archie Cobbs wrote: > Admittedly it was a close call - the benefit being the elimination of an instance field and constructor parameter. To clarify my thought process a bit: while the change made the impl simpler (one less field, one less constructor parameter) it also made it more "magic", in the sense that we lost the hard constraint that a MWH can only refer to _one_ lint category. So, overall, at least in my eyes, the overall balance was negative. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23167#discussion_r1943737457 From acobbs at openjdk.org Wed Feb 5 22:19:12 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Wed, 5 Feb 2025 22:19:12 GMT Subject: RFR: 8347958: Minor compiler cleanups relating to MandatoryWarningHandler [v2] In-Reply-To: <-0WfDRp85SwgKyL42WdPCw8WTilVKyXAiXtuh0nApSE=.fc154bb5-bed4-4e29-8487-3f4d830c190c@github.com> References: <-8kPXPXKm9itoPQw509dc7-qVsaGQoItWUdfjsdm2Bo=.fdb56031-0392-44d7-b190-e30fc25b17ca@github.com> <-0WfDRp85SwgKyL42WdPCw8WTilVKyXAiXtuh0nApSE=.fc154bb5-bed4-4e29-8487-3f4d830c190c@github.com> Message-ID: On Wed, 5 Feb 2025 22:06:32 GMT, Maurizio Cimadamore wrote: >>> Now the handler starts off empty, and the first report determines the kind. But the same kind is then used for all deferred logging... >> >> You are correct - which is why the Javadoc comment "Instances assume all warnings will be in the same LintCategory" was added. >> >> So in summary, I replaced what was previously an assertion of an invariant with a new API requirement of that invariant (which, currently, is satisfied). Admittedly it was a close call - the benefit being the elimination of an instance field and constructor parameter. >> >> But keeping the assertion is a more conservative approach so I'll do that instead. Updated in 87e44347f65. > >> Admittedly it was a close call - the benefit being the elimination of an instance field and constructor parameter. > > To clarify my thought process a bit: while the change made the impl simpler (one less field, one less constructor parameter) it also made it more "magic", in the sense that we lost the hard constraint that a MWH can only refer to _one_ lint category. So, overall, at least in my eyes, the overall balance was negative. I agree, less magic is better :) Thanks for your review - very helpful as always. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23167#discussion_r1943748681 From dholmes at openjdk.org Thu Feb 6 01:52:57 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 6 Feb 2025 01:52:57 GMT Subject: RFR: 8349511: [BACKOUT] Framework for tracing makefile inclusion and parsing Message-ID: <2bf6g3iLVTSpqlp0ka4LeAovJRyPvdibwFZsONUGPI4=.3d01a784-5e93-4c78-87c6-a31c948a81c0@github.com> This reverts commit 61465883b465a184e31e7a03e2603d29ab4815a4. JDK-8348190: Framework for tracing makefile inclusion and parsing The above issue caused problems in the Oracle closed builds and so needs to be backed out until that is addressed. Thanks. ------------- Commit messages: - Revert "8348190: Framework for tracing makefile inclusion and parsing" Changes: https://git.openjdk.org/jdk/pull/23481/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23481&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8349511 Stats: 2717 lines in 273 files changed: 501 ins; 1663 del; 553 mod Patch: https://git.openjdk.org/jdk/pull/23481.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23481/head:pull/23481 PR: https://git.openjdk.org/jdk/pull/23481 From acobbs at openjdk.org Thu Feb 6 01:55:33 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Thu, 6 Feb 2025 01:55:33 GMT Subject: RFR: 8349155: The "log" parameter to Lint.logIfEnabled() is not needed In-Reply-To: References: Message-ID: On Fri, 31 Jan 2025 18:11:41 GMT, Archie Cobbs wrote: > In [JDK-8345263](https://bugs.openjdk.org/browse/JDK-8345263), a new method `Lint.logIfEnabled(Log log, DiagnosticPosition pos, LintWarning warning)` was added. It was decided at the time to pass a `log` parameter explicitly instead of having `Lint` keep its own reference to the `Log` singleton. This was done to keep a conservative approach with the refactoring and to avoid possible initialization ordering issues. > > After other recent changes ([JDK-8344079](https://bugs.openjdk.org/browse/JDK-8344079), [JDK-8347474](https://bugs.openjdk.org/browse/JDK-8347474)) the initialization ordering issues have been alleviated. It's also the case that there is only ever one `Log` instance per compiler `Context`. So the `log` parameter can be removed and `Lint` can just keep its own reference, as is the normal custom in the compiler code. This results in a minor code cleanup. Thanks for the review! ------------- PR Comment: https://git.openjdk.org/jdk/pull/23400#issuecomment-2638518977 From acobbs at openjdk.org Thu Feb 6 01:55:33 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Thu, 6 Feb 2025 01:55:33 GMT Subject: Integrated: 8349155: The "log" parameter to Lint.logIfEnabled() is not needed In-Reply-To: References: Message-ID: <-WY-4PV7Zuw_y_j019mYAhstw8nUSsdH-uTHCeiJHHg=.ad984855-fb02-4bc6-bdbd-b2c6343132dc@github.com> On Fri, 31 Jan 2025 18:11:41 GMT, Archie Cobbs wrote: > In [JDK-8345263](https://bugs.openjdk.org/browse/JDK-8345263), a new method `Lint.logIfEnabled(Log log, DiagnosticPosition pos, LintWarning warning)` was added. It was decided at the time to pass a `log` parameter explicitly instead of having `Lint` keep its own reference to the `Log` singleton. This was done to keep a conservative approach with the refactoring and to avoid possible initialization ordering issues. > > After other recent changes ([JDK-8344079](https://bugs.openjdk.org/browse/JDK-8344079), [JDK-8347474](https://bugs.openjdk.org/browse/JDK-8347474)) the initialization ordering issues have been alleviated. It's also the case that there is only ever one `Log` instance per compiler `Context`. So the `log` parameter can be removed and `Lint` can just keep its own reference, as is the normal custom in the compiler code. This results in a minor code cleanup. This pull request has now been integrated. Changeset: 89e5e7ab Author: Archie Cobbs URL: https://git.openjdk.org/jdk/commit/89e5e7ab73472b7d02aac5b8b0c7e9f26db6ec32 Stats: 49 lines in 8 files changed: 3 ins; 2 del; 44 mod 8349155: The "log" parameter to Lint.logIfEnabled() is not needed Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.org/jdk/pull/23400 From darcy at openjdk.org Thu Feb 6 02:04:15 2025 From: darcy at openjdk.org (Joe Darcy) Date: Thu, 6 Feb 2025 02:04:15 GMT Subject: RFR: 8349511: [BACKOUT] Framework for tracing makefile inclusion and parsing In-Reply-To: <2bf6g3iLVTSpqlp0ka4LeAovJRyPvdibwFZsONUGPI4=.3d01a784-5e93-4c78-87c6-a31c948a81c0@github.com> References: <2bf6g3iLVTSpqlp0ka4LeAovJRyPvdibwFZsONUGPI4=.3d01a784-5e93-4c78-87c6-a31c948a81c0@github.com> Message-ID: On Thu, 6 Feb 2025 01:32:51 GMT, David Holmes wrote: > This reverts commit 61465883b465a184e31e7a03e2603d29ab4815a4. > > JDK-8348190: Framework for tracing makefile inclusion and parsing > > The above issue caused problems in the Oracle closed builds and so needs to be backed out until that is addressed. > > Thanks. Approving clean backout. ------------- Marked as reviewed by darcy (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23481#pullrequestreview-2597463613 From acobbs at openjdk.org Thu Feb 6 02:41:54 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Thu, 6 Feb 2025 02:41:54 GMT Subject: RFR: 8348427: DeferredLintHandler API should use JCTree instead of DiagnosticPosition [v3] In-Reply-To: References: Message-ID: > The purpose of `DeferredLintHandler` is to allow `@SuppressWarnings` to be applied to warnings that are generated before `@SuppressWarnings` annotations themselves have been processed. The way this currently works is that warning callbacks are kept in a `HashMap` keyed by the innermost containing module, package, class, method, or variable declarations (in the form of a `JCModuleDecl`, `JCPackageDecl`, `JCClassDecl`, `JCMethodDecl`, or `JCVariableDecl`). Later, when the compiler executes the attribution phase and the lint categories suppressed at each declaration are known, the corresponding warning callbacks are provided with an appropriately configured `Lint` instance and "flushed". > > However, the `DeferredLintHandler` API uses `DiagnosticPosition` instead of `JCTree` for registering and flushing deferred warnings. This opens the door for bugs where warnings are registered to an object which is not a declaration, and therefore ignored. > > In fact, this occurs once in the code ([here](https://github.com/openjdk/jdk/blob/48ece0721489c1b357aaa81e89fe59f486079d15/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Annotate.java#L679)) where a `JCExpression` is being passed, although in this case the bug appears to be harmless (because annotation values can't contain any type of declaration). > > The API should be tighted up, and furthermore an assertion should be added to verify that the JCTree being passed is actually a declaration supporting `@SuppressWarnings`. > > In addition, there is a design flaw in the API: it's not possible to obtain the current immediate mode `Lint` object, so if an immediate mode `Lint` object is pushed/popped more than once, the second `Lint` object will overwrite the first. > > To fix this, the API should be adjusted so the stack of current declarations and/or immediate mode `Lint` objects is managed by the `DeferredLintHandler` itself, by providing a `push()` and `pop()` methods in the API. Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: - Eliminate code branch that never occurs. - Clean up imports. - Merge branch 'master' into JDK-8348427 to resolve conflict. - Merge branch 'master' into JDK-8348427 to fix conflict. - Refactor the DeferredLintHandler API to maintain the "stack" itself. - Add Javadoc to document a subtley in the API. - Update DeferredLintHandler API to use JCTree instead of DiagnosticPosition. ------------- Changes: https://git.openjdk.org/jdk/pull/23281/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23281&range=02 Stats: 210 lines in 9 files changed: 50 ins; 34 del; 126 mod Patch: https://git.openjdk.org/jdk/pull/23281.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23281/head:pull/23281 PR: https://git.openjdk.org/jdk/pull/23281 From dholmes at openjdk.org Thu Feb 6 02:44:08 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 6 Feb 2025 02:44:08 GMT Subject: RFR: 8349511: [BACKOUT] Framework for tracing makefile inclusion and parsing In-Reply-To: References: <2bf6g3iLVTSpqlp0ka4LeAovJRyPvdibwFZsONUGPI4=.3d01a784-5e93-4c78-87c6-a31c948a81c0@github.com> Message-ID: On Thu, 6 Feb 2025 02:01:47 GMT, Joe Darcy wrote: >> This reverts commit 61465883b465a184e31e7a03e2603d29ab4815a4. >> >> JDK-8348190: Framework for tracing makefile inclusion and parsing >> >> The above issue caused problems in the Oracle closed builds and so needs to be backed out until that is addressed. >> >> Thanks. > > Approving clean backout. Thanks @jddarcy ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/23481#issuecomment-2638687813 From mikael at openjdk.org Thu Feb 6 02:54:17 2025 From: mikael at openjdk.org (Mikael Vidstedt) Date: Thu, 6 Feb 2025 02:54:17 GMT Subject: RFR: 8349511: [BACKOUT] Framework for tracing makefile inclusion and parsing In-Reply-To: <2bf6g3iLVTSpqlp0ka4LeAovJRyPvdibwFZsONUGPI4=.3d01a784-5e93-4c78-87c6-a31c948a81c0@github.com> References: <2bf6g3iLVTSpqlp0ka4LeAovJRyPvdibwFZsONUGPI4=.3d01a784-5e93-4c78-87c6-a31c948a81c0@github.com> Message-ID: On Thu, 6 Feb 2025 01:32:51 GMT, David Holmes wrote: > This reverts commit 61465883b465a184e31e7a03e2603d29ab4815a4. > > JDK-8348190: Framework for tracing makefile inclusion and parsing > > The above issue caused problems in the Oracle closed builds and so needs to be backed out until that is addressed. > > Thanks. Marked as reviewed by mikael (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23481#pullrequestreview-2597531112 From dholmes at openjdk.org Thu Feb 6 02:54:18 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 6 Feb 2025 02:54:18 GMT Subject: RFR: 8349511: [BACKOUT] Framework for tracing makefile inclusion and parsing In-Reply-To: References: <2bf6g3iLVTSpqlp0ka4LeAovJRyPvdibwFZsONUGPI4=.3d01a784-5e93-4c78-87c6-a31c948a81c0@github.com> Message-ID: On Thu, 6 Feb 2025 02:48:21 GMT, Mikael Vidstedt wrote: >> This reverts commit 61465883b465a184e31e7a03e2603d29ab4815a4. >> >> JDK-8348190: Framework for tracing makefile inclusion and parsing >> >> The above issue caused problems in the Oracle closed builds and so needs to be backed out until that is addressed. >> >> Thanks. > > Marked as reviewed by mikael (Reviewer). Thanks @vidmik ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/23481#issuecomment-2638701374 From dholmes at openjdk.org Thu Feb 6 02:54:18 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 6 Feb 2025 02:54:18 GMT Subject: Integrated: 8349511: [BACKOUT] Framework for tracing makefile inclusion and parsing In-Reply-To: <2bf6g3iLVTSpqlp0ka4LeAovJRyPvdibwFZsONUGPI4=.3d01a784-5e93-4c78-87c6-a31c948a81c0@github.com> References: <2bf6g3iLVTSpqlp0ka4LeAovJRyPvdibwFZsONUGPI4=.3d01a784-5e93-4c78-87c6-a31c948a81c0@github.com> Message-ID: On Thu, 6 Feb 2025 01:32:51 GMT, David Holmes wrote: > This reverts commit 61465883b465a184e31e7a03e2603d29ab4815a4. > > JDK-8348190: Framework for tracing makefile inclusion and parsing > > The above issue caused problems in the Oracle closed builds and so needs to be backed out until that is addressed. > > Thanks. This pull request has now been integrated. Changeset: 64bd8d25 Author: David Holmes URL: https://git.openjdk.org/jdk/commit/64bd8d2592d26e02a7f2f96caa47cba5e158aaa2 Stats: 2717 lines in 273 files changed: 501 ins; 1663 del; 553 mod 8349511: [BACKOUT] Framework for tracing makefile inclusion and parsing Reviewed-by: darcy, mikael ------------- PR: https://git.openjdk.org/jdk/pull/23481 From jlahoda at openjdk.org Thu Feb 6 07:37:18 2025 From: jlahoda at openjdk.org (Jan Lahoda) Date: Thu, 6 Feb 2025 07:37:18 GMT Subject: Integrated: 8349132: javac Analyzers should handle non-deferrable errors In-Reply-To: References: Message-ID: On Fri, 31 Jan 2025 12:44:32 GMT, Jan Lahoda wrote: > Consider this test script: > > $ cat JDK8349132.sh > mkdir -p JDK-8349132 > cd JDK-8349132 > cat >Utils.java < package test; > public class Utils { > public static void run(Task uat) {} > } > interface Task { > public void run(T t) throws Exception; > } > class Param {} > EOF > cat >Test.java < package test; > public class Test { > private static void test() { > Utils.run(new Task() { > @Override > public void run(Param parameter) throws Exception { > } > }); > } > } > EOF > > javac -d out Utils.java > rm out/test/Param.class > javac -XDfind=diamond -XDshould-stop.at=FLOW -classpath out Test.java > > > It fails with: > > $ bash JDK8349132.sh > Test.java:4: error: cannot find symbol > Utils.run(new Task() { > ^ > symbol: class Param > location: class Test > Test.java:6: error: cannot find symbol > public void run(Param parameter) throws Exception { > ^ > symbol: class Param > Test.java:4: error: cannot access Param > Utils.run(new Task() { > ^ > class file for test.Param not found > 3 errors > An exception has occurred in the compiler (21.0.5). 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.AssertionError: Analyzer error when processing: Utils.run(new Task(){ > > () { > super(); > } > > @Override > public void run(Param parameter) throws Exception { > } > });:java.lang.NullPointerException: Cannot invoke "com.sun.tools.javac.code.Type.getTypeArguments()" because "com.sun.tools.javac.util.List.get(int).type" is null > jdk.compiler/com.sun.tools.javac.comp.Analyzer$DiamondInitializer.process(Analyzer.java:258) > jdk.compiler/com.sun.tools.javac.comp.Analyzer$DiamondInitializer.process(Analyzer.java:228) > jdk.compiler/com.sun.tools.javac.comp.Analyzer.doAnalysis(Analyzer.java:577) > jdk.compiler/com.sun.tools.javac.comp.Analyzer$2.flush(Analyzer.java:547) > jdk.compiler/com.sun.tools.javac.comp.Analyzer.flush(Analyzer.java:591) > jdk.compiler/com.sun.tools.javac.main.JavaCompiler.flow(JavaCompiler.java:1425) > jdk.compiler/com.sun.tools.javac.main.JavaCompiler.flow(JavaCompiler.java:1393) > jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:976... This pull request has now been integrated. Changeset: 3cf04dec Author: Jan Lahoda URL: https://git.openjdk.org/jdk/commit/3cf04dec493d28730d4462257f64ea636f58d7e5 Stats: 155 lines in 3 files changed: 151 ins; 1 del; 3 mod 8349132: javac Analyzers should handle non-deferrable errors Reviewed-by: abimpoudis ------------- PR: https://git.openjdk.org/jdk/pull/23387 From acobbs at openjdk.org Thu Feb 6 14:35:15 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Thu, 6 Feb 2025 14:35:15 GMT Subject: Integrated: 8347958: Minor compiler cleanups relating to MandatoryWarningHandler In-Reply-To: <-8kPXPXKm9itoPQw509dc7-qVsaGQoItWUdfjsdm2Bo=.fdb56031-0392-44d7-b190-e30fc25b17ca@github.com> References: <-8kPXPXKm9itoPQw509dc7-qVsaGQoItWUdfjsdm2Bo=.fdb56031-0392-44d7-b190-e30fc25b17ca@github.com> Message-ID: On Thu, 16 Jan 2025 23:47:13 GMT, Archie Cobbs wrote: > After recent improvements to Lint-related classes, there are now a few minor cleanup opportunities relating to `MandatoryWarningHandler`. > > 1. The new `LintWarning` class provides access to the associated `LintCategory`. This means that the `LintCategory` parameter being passed to the `MandatoryWarningHandler` constructor is no longer needed. > 1. The `prefix` string being passed to the `MandatoryWarningHandler` constructor can (in most cases) be inferred as well. > 1. The field `Check.sunApiHandler` (which has type `MandatoryWarningHandler`) is no longer used and can be removed. This pull request has now been integrated. Changeset: 2b82e2d5 Author: Archie Cobbs URL: https://git.openjdk.org/jdk/commit/2b82e2d57bdb8cb677764abc99d70f6d03295625 Stats: 48 lines in 3 files changed: 26 ins; 11 del; 11 mod 8347958: Minor compiler cleanups relating to MandatoryWarningHandler Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.org/jdk/pull/23167 From vromero at openjdk.org Thu Feb 6 15:07:16 2025 From: vromero at openjdk.org (Vicente Romero) Date: Thu, 6 Feb 2025 15:07:16 GMT Subject: RFR: 8349058: 'internal proprietary API' warnings make javac warnings unusable [v2] In-Reply-To: References: Message-ID: On Wed, 5 Feb 2025 18:34:26 GMT, Liam Miller-Cushon wrote: >> This change is a partial backout of [JDK-8332744](https://bugs.openjdk.org/browse/JDK-8332744). The logic was reverted, but the test was preserved and updated to reflect the updated behaviour, and some cleanups to benchmark code were kept. >> >> This restores the ability to use `-XDignore.symbol.file` as an ad-hoc suppression mechanism for `sunapi` diagnostics, see discussion in [JDK-8349058](https://bugs.openjdk.org/browse/JDK-8349058). > > Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: > > Improvements to test lgtm, thanks! ------------- Marked as reviewed by vromero (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23448#pullrequestreview-2598955464 From acobbs at openjdk.org Thu Feb 6 15:48:57 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Thu, 6 Feb 2025 15:48:57 GMT Subject: RFR: 8224228: No way to locally suppress lint warnings in parser/tokenizer or preview features [v9] In-Reply-To: References: Message-ID: > This PR updates the `DeferredLintHandler` so that deferred warnings can be registered during parsing, before any `JCTree` nodes have been created, and it uses this new capability to update the `"preview"` and `"text-blocks"` Lint warnings so that they can be suppressed via `@SuppressWarnings` annotations. More details are provided in additional comments. > > Note: This PR depends on (i.e., includes and extends) these other "cleanup" PR's: > * #23167 > * #23281 > * #23400 Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 24 commits: - Merge branch 'master' into JDK-8224228 - Revert gratuituous whitespace change. - Merge branch 'JDK-8349155' into JDK-8224228 - Refactor to remove the "log" parameter from Lint.logIfEnabled(). - Fix an inaccurate comment. - Refactor "dangling-doc-comments" logic to utilize new DeferredLintHandler. - Fix bugs when mapping lexical deferrals to declarations. - Refactor to eliminate the unnecessary MandatoryWarningHandler "verbose" field. - Instead of using EndPosTable, track ending positions of declarations explicitly. - Merge branch 'JDK-8347958' into JDK-8224228 - ... and 14 more: https://git.openjdk.org/jdk/compare/2b82e2d5...e83c88c2 ------------- Changes: https://git.openjdk.org/jdk/pull/23237/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23237&range=08 Stats: 855 lines in 26 files changed: 541 ins; 103 del; 211 mod Patch: https://git.openjdk.org/jdk/pull/23237.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23237/head:pull/23237 PR: https://git.openjdk.org/jdk/pull/23237 From cushon at openjdk.org Thu Feb 6 17:36:15 2025 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Thu, 6 Feb 2025 17:36:15 GMT Subject: Integrated: 8349058: 'internal proprietary API' warnings make javac warnings unusable In-Reply-To: References: Message-ID: On Tue, 4 Feb 2025 19:48:55 GMT, Liam Miller-Cushon wrote: > This change is a partial backout of [JDK-8332744](https://bugs.openjdk.org/browse/JDK-8332744). The logic was reverted, but the test was preserved and updated to reflect the updated behaviour, and some cleanups to benchmark code were kept. > > This restores the ability to use `-XDignore.symbol.file` as an ad-hoc suppression mechanism for `sunapi` diagnostics, see discussion in [JDK-8349058](https://bugs.openjdk.org/browse/JDK-8349058). This pull request has now been integrated. Changeset: 1ab1c1d5 Author: Liam Miller-Cushon URL: https://git.openjdk.org/jdk/commit/1ab1c1d53b86228be85aac96fa5d69db39ac6317 Stats: 103 lines in 2 files changed: 46 ins; 37 del; 20 mod 8349058: 'internal proprietary API' warnings make javac warnings unusable Reviewed-by: vromero ------------- PR: https://git.openjdk.org/jdk/pull/23448 From acobbs at openjdk.org Thu Feb 6 19:22:14 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Thu, 6 Feb 2025 19:22:14 GMT Subject: RFR: 8348427: DeferredLintHandler API should use JCTree instead of DiagnosticPosition [v2] In-Reply-To: References: <_n7hsThMGaGZhlj2DiHBN63oeiajVON_Qmn_gSdPpjM=.d075b726-061d-4054-850b-8d52bcf7ab37@github.com> Message-ID: On Wed, 5 Feb 2025 11:30:12 GMT, Maurizio Cimadamore wrote: > Question: what happens if we get rid of the "immediate" and we always defer? Does this only affect the order in which diagnostics are reported, or is there something deeper? I learn a little bit more about this. It looks like the only time immediate mode is used explicitly (i.e., other due to `DeferredLintHandler`'s default state) is when resolving imports ([here](https://github.com/openjdk/jdk/blob/89e5e7ab73472b7d02aac5b8b0c7e9f26db6ec32/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java#L368)). In that case, of course, there can be no enclosing `@SuppressWarnings` so that makes sense. It looks like the other apparent use ([here](https://github.com/openjdk/jdk/blob/89e5e7ab73472b7d02aac5b8b0c7e9f26db6ec32/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Annotate.java#L257)) never occurs because `annotateLater()` is never invoked with a null `deferPos` (I've cleaned this up and added an assertion). > This seems like a great plan. We don't have to get there in one step (and this PR can proceed separately). I just want to make sure that we end up somewhere around there :-) I did some more exploration of this idea. The main trip-up at this point is the speculative compilation stuff, because in that case warnings that occur as a side effect should be discarded because they're not "real". This is done via `Log.DeferredDiagnosticHandler`. So my initial strategy of "Just defer all warnings and actually execute them later" is too simplistic (although I do have a prototype which "almost works" I'm happy to share). If/when you have time I'd like to discuss how to proceed with you. That discussion probably belongs somewhere else e.g. on compiler-dev or a draft PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23281#issuecomment-2640782274 From mcimadamore at openjdk.org Thu Feb 6 21:47:17 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 6 Feb 2025 21:47:17 GMT Subject: RFR: 8348427: DeferredLintHandler API should use JCTree instead of DiagnosticPosition [v2] In-Reply-To: References: <_n7hsThMGaGZhlj2DiHBN63oeiajVON_Qmn_gSdPpjM=.d075b726-061d-4054-850b-8d52bcf7ab37@github.com> Message-ID: On Thu, 6 Feb 2025 19:19:18 GMT, Archie Cobbs wrote: > learn a little bit more about this. It looks like the only time immediate mode is used explicitly (i.e., other due to `DeferredLintHandler`'s default state) is when resolving imports ([here](https://github.com/openjdk/jdk/blob/89e5e7ab73472b7d02aac5b8b0c7e9f26db6ec32/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java#L368)). In that case, of course, there can be no enclosing `@SuppressWarnings` so that makes sense. Can we use a similar "flush" strategy ? E.g. make the warnings be part of an import declaration, and then process them as part of a flush? ------------- PR Comment: https://git.openjdk.org/jdk/pull/23281#issuecomment-2641123382 From mcimadamore at openjdk.org Thu Feb 6 22:06:11 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 6 Feb 2025 22:06:11 GMT Subject: RFR: 8348427: DeferredLintHandler API should use JCTree instead of DiagnosticPosition [v2] In-Reply-To: References: <_n7hsThMGaGZhlj2DiHBN63oeiajVON_Qmn_gSdPpjM=.d075b726-061d-4054-850b-8d52bcf7ab37@github.com> Message-ID: On Thu, 6 Feb 2025 21:45:01 GMT, Maurizio Cimadamore wrote: > > learn a little bit more about this. It looks like the only time immediate mode is used explicitly (i.e., other due to `DeferredLintHandler`'s default state) is when resolving imports ([here](https://github.com/openjdk/jdk/blob/89e5e7ab73472b7d02aac5b8b0c7e9f26db6ec32/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java#L368)). In that case, of course, there can be no enclosing `@SuppressWarnings` so that makes sense. > > Can we use a similar "flush" strategy ? E.g. make the warnings be part of an import declaration, and then process them as part of a flush? While it's good that you knocked one of the two usages off -- it's a bit sad to have this machinery "just" for one case. > > Separately, I wonder if warnings issued from import statements should be suppressible as well (perhaps piggy backing on the toplevel class `@SuppressWarnings` uhmmm). It seems bad that there's some warnings that can't be suppressed programmatically. I think it would be useful to understand which warnings can be generated during `resolveImports`. @jddarcy pointed me at: https://openjdk.org/jeps/211 See related change: https://hg.openjdk.org/jdk9/jdk9/langtools/rev/82384454947c Where we explicitly disable deprecation warnings on import since 9. Is there any other? ------------- PR Comment: https://git.openjdk.org/jdk/pull/23281#issuecomment-2641160532 From mcimadamore at openjdk.org Thu Feb 6 21:54:13 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 6 Feb 2025 21:54:13 GMT Subject: RFR: 8348427: DeferredLintHandler API should use JCTree instead of DiagnosticPosition [v3] In-Reply-To: References: Message-ID: On Thu, 6 Feb 2025 02:41:54 GMT, Archie Cobbs wrote: >> The purpose of `DeferredLintHandler` is to allow `@SuppressWarnings` to be applied to warnings that are generated before `@SuppressWarnings` annotations themselves have been processed. The way this currently works is that warning callbacks are kept in a `HashMap` keyed by the innermost containing module, package, class, method, or variable declarations (in the form of a `JCModuleDecl`, `JCPackageDecl`, `JCClassDecl`, `JCMethodDecl`, or `JCVariableDecl`). Later, when the compiler executes the attribution phase and the lint categories suppressed at each declaration are known, the corresponding warning callbacks are provided with an appropriately configured `Lint` instance and "flushed". >> >> However, the `DeferredLintHandler` API uses `DiagnosticPosition` instead of `JCTree` for registering and flushing deferred warnings. This opens the door for bugs where warnings are registered to an object which is not a declaration, and therefore ignored. >> >> In fact, this occurs once in the code ([here](https://github.com/openjdk/jdk/blob/48ece0721489c1b357aaa81e89fe59f486079d15/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Annotate.java#L679)) where a `JCExpression` is being passed, although in this case the bug appears to be harmless (because annotation values can't contain any type of declaration). >> >> The API should be tighted up, and furthermore an assertion should be added to verify that the JCTree being passed is actually a declaration supporting `@SuppressWarnings`. >> >> In addition, there is a design flaw in the API: it's not possible to obtain the current immediate mode `Lint` object, so if an immediate mode `Lint` object is pushed/popped more than once, the second `Lint` object will overwrite the first. >> >> To fix this, the API should be adjusted so the stack of current declarations and/or immediate mode `Lint` objects is managed by the `DeferredLintHandler` itself, by providing a `push()` and `pop()` methods in the API. > > Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: > > - Eliminate code branch that never occurs. > - Clean up imports. > - Merge branch 'master' into JDK-8348427 to resolve conflict. > - Merge branch 'master' into JDK-8348427 to fix conflict. > - Refactor the DeferredLintHandler API to maintain the "stack" itself. > - Add Javadoc to document a subtley in the API. > - Update DeferredLintHandler API to use JCTree instead of DiagnosticPosition. Regardless of the separate discussion re. "pushImmediate", this PR contains a lot of good changes, and I'm ok with it being integrated as is. We can see if we can get rid of the "immediate" state in a separate PR. ------------- Marked as reviewed by mcimadamore (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23281#pullrequestreview-2600082076 From mcimadamore at openjdk.org Thu Feb 6 22:13:12 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 6 Feb 2025 22:13:12 GMT Subject: RFR: 8348427: DeferredLintHandler API should use JCTree instead of DiagnosticPosition [v2] In-Reply-To: References: <_n7hsThMGaGZhlj2DiHBN63oeiajVON_Qmn_gSdPpjM=.d075b726-061d-4054-850b-8d52bcf7ab37@github.com> Message-ID: On Thu, 6 Feb 2025 22:03:27 GMT, Maurizio Cimadamore wrote: > > > learn a little bit more about this. It looks like the only time immediate mode is used explicitly (i.e., other due to `DeferredLintHandler`'s default state) is when resolving imports ([here](https://github.com/openjdk/jdk/blob/89e5e7ab73472b7d02aac5b8b0c7e9f26db6ec32/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java#L368)). In that case, of course, there can be no enclosing `@SuppressWarnings` so that makes sense. > > > > > > Can we use a similar "flush" strategy ? E.g. make the warnings be part of an import declaration, and then process them as part of a flush? While it's good that you knocked one of the two usages off -- it's a bit sad to have this machinery "just" for one case. > > Separately, I wonder if warnings issued from import statements should be suppressible as well (perhaps piggy backing on the toplevel class `@SuppressWarnings` uhmmm). It seems bad that there's some warnings that can't be suppressed programmatically. > > I think it would be useful to understand which warnings can be generated during `resolveImports`. @jddarcy pointed me at: > > https://openjdk.org/jeps/211 > > See related change: > > https://hg.openjdk.org/jdk9/jdk9/langtools/rev/82384454947c > > Where we explicitly disable deprecation warnings on import since 9. Is there any other? If this was indeed the only possible case, there is a possible silver lining, because either warnings in imports are enabled (e.g. `--source 8`) in which case we can just report them immediately, as they can't be suppressed, or they are disabled (e.g. `--source >= 9`) in which case no warning should even be generated, period. But I'm sure reality is more complex than that :-) ------------- PR Comment: https://git.openjdk.org/jdk/pull/23281#issuecomment-2641172482 From acobbs at openjdk.org Fri Feb 7 00:25:10 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Fri, 7 Feb 2025 00:25:10 GMT Subject: RFR: 8348427: DeferredLintHandler API should use JCTree instead of DiagnosticPosition [v2] In-Reply-To: References: <_n7hsThMGaGZhlj2DiHBN63oeiajVON_Qmn_gSdPpjM=.d075b726-061d-4054-850b-8d52bcf7ab37@github.com> Message-ID: On Thu, 6 Feb 2025 22:10:57 GMT, Maurizio Cimadamore wrote: >>> > learn a little bit more about this. It looks like the only time immediate mode is used explicitly (i.e., other due to `DeferredLintHandler`'s default state) is when resolving imports ([here](https://github.com/openjdk/jdk/blob/89e5e7ab73472b7d02aac5b8b0c7e9f26db6ec32/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java#L368)). In that case, of course, there can be no enclosing `@SuppressWarnings` so that makes sense. >>> >>> Can we use a similar "flush" strategy ? E.g. make the warnings be part of an import declaration, and then process them as part of a flush? While it's good that you knocked one of the two usages off -- it's a bit sad to have this machinery "just" for one case. >>> >>> Separately, I wonder if warnings issued from import statements should be suppressible as well (perhaps piggy backing on the toplevel class `@SuppressWarnings` uhmmm). It seems bad that there's some warnings that can't be suppressed programmatically. >> >> I think it would be useful to understand which warnings can be generated during `resolveImports`. @jddarcy pointed me at: >> >> https://openjdk.org/jeps/211 >> >> See related change: >> >> https://hg.openjdk.org/jdk9/jdk9/langtools/rev/82384454947c >> >> Where we explicitly disable deprecation warnings on import since 9. Is there any other? > >> > > learn a little bit more about this. It looks like the only time immediate mode is used explicitly (i.e., other due to `DeferredLintHandler`'s default state) is when resolving imports ([here](https://github.com/openjdk/jdk/blob/89e5e7ab73472b7d02aac5b8b0c7e9f26db6ec32/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java#L368)). In that case, of course, there can be no enclosing `@SuppressWarnings` so that makes sense. >> > >> > >> > Can we use a similar "flush" strategy ? E.g. make the warnings be part of an import declaration, and then process them as part of a flush? While it's good that you knocked one of the two usages off -- it's a bit sad to have this machinery "just" for one case. >> > Separately, I wonder if warnings issued from import statements should be suppressible as well (perhaps piggy backing on the toplevel class `@SuppressWarnings` uhmmm). It seems bad that there's some warnings that can't be suppressed programmatically. >> >> I think it would be useful to understand which warnings can be generated during `resolveImports`. @jddarcy pointed me at: >> >> https://openjdk.org/jeps/211 >> >> See related change: >> >> https://hg.openjdk.org/jdk9/jdk9/langtools/rev/82384454947c >> >> Where we explicitly disable deprecation warnings on import since 9. Is there any other? > > If this was indeed the only possible case, there is a possible silver lining, because either warnings in imports are enabled (e.g. `--source 8`) in which case we can just report them immediately, as they can't be suppressed, or they are disabled (e.g. `--source >= 9`) in which case no warning should even be generated, period. > > But I'm sure reality is more complex than that :-) Hi @mcimadamore, Thanks for the review & comments! > Can we use a similar "flush" strategy ? E.g. make the warnings be part of an import declaration, and then process them as part of a flush? While it's good that you knocked one of the two usages off -- it's a bit sad to have this machinery "just" for one case. Agreed - it seems to be a result of mixing the ordering of attributing things and flushing the `DeferredLintHandler`. An example is this program: import java.security.PolicySpi; public class A { @SuppressWarnings("deprecation") private PolicySpi foo; @SuppressWarnings("deprecation") public void m() throws Exception { A.class.newInstance(); } } If you comment out the one remaining `deferredLintHandler.pushImmediate()` invocation (in `TypeEnter.java`), then watch watch happens when compiling the above program, you'll see that `checkDeprecated()` is invoked twice for `PolicySpi`, and the first time (`other` = `unnamed package`) the current `Lint` instance is correct but the deferred instance is incorrect, and the second time (`other` = `A`) the reverse is true; when it's invoked for `newInstance()` (only once), the current instance is correct but the deferred instance is incorrect. So - all still very confusing to me. "When to flush" is indeed a key issue for other reasons too. For example, it appears that `JCTree` nodes tend to randomly disappear after attribution (well, it only seems random to me so far), so that deferring warning analysis for too long can set you up for a `NullPointerException` chasing exercise. A simple example is in `Gen.genClass()` where all of a class' declarations are discarded after the classfile is generate (whether that matters depends on the compiler execution mode), and there are others which I'm still chasing down. > I think it would be useful to understand which warnings can be generated during resolveImports. @jddarcy pointed me at: https://openjdk.org/jeps/211 I ran across this as well and accommodated it my prototype by effectively pretending there is a `@SuppressWarnings("deprecation", "removal", "preview")` on every `import` statement if source ? 9. This is possible because the `@SuppressWarning` analysis is a completely separate step. > Separately, I wonder if warnings issued from import statements should be suppressible as well (perhaps piggy backing on the toplevel class `@SuppressWarnings` uhmmm). It seems bad that there's some warnings that can't be suppressed programmatically. It would be nice if the compiler allowed `@SuppressWarnings` in more places. If/when it ever does, the proposed refactoring would hopefully make it easier to implement. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23281#issuecomment-2641503897 From cushon at openjdk.org Fri Feb 7 00:36:34 2025 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Fri, 7 Feb 2025 00:36:34 GMT Subject: RFR: 8349512: Duplicate PermittedSubclasses entries with doclint enabled Message-ID: This change avoids emitting duplicate `PermittedSubclasses` entries when `-Xdoclint` is enabled. `-Xdoclint` causes some trees to be re-attributed, and the second attribution was resulting in permitted subclasses being added again, and those side effects were not discarded. This fix causes `addPermittedSubclass` to not insert duplicate entries. ------------- Commit messages: - 8349512: Duplicate PermittedSubclasses entries with doclint enabled Changes: https://git.openjdk.org/jdk/pull/23507/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23507&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8349512 Stats: 35 lines in 2 files changed: 33 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23507.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23507/head:pull/23507 PR: https://git.openjdk.org/jdk/pull/23507 From kcr at openjdk.org Fri Feb 7 15:34:26 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 7 Feb 2025 15:34:26 GMT Subject: [jdk24] Withdrawn: 8343882: BasicAnnoTests doesn't handle multiple annotations at the same position In-Reply-To: References: Message-ID: On Tue, 24 Dec 2024 06:11:40 GMT, SendaoYan wrote: > Hi all, > > This pull request contains a backport of commit [d562d3c7](https://github.com/openjdk/jdk/commit/d562d3c7a9e1e857c095ef908b0957b033972949) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. Test-fix only, no risk. > > The commit being backported was authored by Liam Miller-Cushon on 20 Dec 2024 and was reviewed by Joe Darcy. > > Thanks! This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/22875 From kcr at openjdk.org Fri Feb 7 15:34:25 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 7 Feb 2025 15:34:25 GMT Subject: [jdk24] RFR: 8343882: BasicAnnoTests doesn't handle multiple annotations at the same position In-Reply-To: References: Message-ID: On Tue, 24 Dec 2024 06:11:40 GMT, SendaoYan wrote: > Hi all, > > This pull request contains a backport of commit [d562d3c7](https://github.com/openjdk/jdk/commit/d562d3c7a9e1e857c095ef908b0957b033972949) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. Test-fix only, no risk. > > The commit being backported was authored by Liam Miller-Cushon on 20 Dec 2024 and was reviewed by Joe Darcy. > > Thanks! As we are now in the [Release Candidate phase of JDK 24](https://openjdk.org/projects/jdk/24/), this fix is no longer suitable for JDK 24. See [JEP 3](https://openjdk.org/jeps/3) for more information. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22875#issuecomment-2643256892 From liach at openjdk.org Fri Feb 7 16:23:20 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 7 Feb 2025 16:23:20 GMT Subject: [jdk24] RFR: 8343882: BasicAnnoTests doesn't handle multiple annotations at the same position In-Reply-To: References: Message-ID: On Tue, 24 Dec 2024 06:11:40 GMT, SendaoYan wrote: > Hi all, > > This pull request contains a backport of commit [d562d3c7](https://github.com/openjdk/jdk/commit/d562d3c7a9e1e857c095ef908b0957b033972949) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. Test-fix only, no risk. > > The commit being backported was authored by Liam Miller-Cushon on 20 Dec 2024 and was reviewed by Joe Darcy. > > Thanks! You can backport this to openjdk/jdk24u repo instead; from there you can backport to 21u-dev, 17u-dev or earlier versions. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22875#issuecomment-2643388618 From syan at openjdk.org Fri Feb 7 16:26:16 2025 From: syan at openjdk.org (SendaoYan) Date: Fri, 7 Feb 2025 16:26:16 GMT Subject: [jdk24] RFR: 8343882: BasicAnnoTests doesn't handle multiple annotations at the same position In-Reply-To: References: Message-ID: On Fri, 7 Feb 2025 16:20:27 GMT, Chen Liang wrote: > You can backport this to openjdk/jdk24u repo instead; from there you can backport to 21u-dev, 17u-dev or earlier versions. Okey, thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22875#issuecomment-2643395274 From vromero at openjdk.org Fri Feb 7 16:50:11 2025 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 7 Feb 2025 16:50:11 GMT Subject: RFR: 8349512: Duplicate PermittedSubclasses entries with doclint enabled In-Reply-To: References: Message-ID: On Fri, 7 Feb 2025 00:31:36 GMT, Liam Miller-Cushon wrote: > This change avoids emitting duplicate `PermittedSubclasses` entries when `-Xdoclint` is enabled. > > `-Xdoclint` causes some trees to be re-attributed, and the second attribution was resulting in permitted subclasses being added again, and those side effects were not discarded. This fix causes `addPermittedSubclass` to not insert duplicate entries. lgtm ------------- Marked as reviewed by vromero (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23507#pullrequestreview-2602268447 From cushon at openjdk.org Fri Feb 7 18:19:51 2025 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Fri, 7 Feb 2025 18:19:51 GMT Subject: RFR: 8349512: Duplicate PermittedSubclasses entries with doclint enabled [v2] In-Reply-To: References: Message-ID: > This change avoids emitting duplicate `PermittedSubclasses` entries when `-Xdoclint` is enabled. > > `-Xdoclint` causes some trees to be re-attributed, and the second attribution was resulting in permitted subclasses being added again, and those side effects were not discarded. This fix causes `addPermittedSubclass` to not insert duplicate entries. Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: Update @test with new bug ID ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23507/files - new: https://git.openjdk.org/jdk/pull/23507/files/d8a803f9..6143b762 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23507&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23507&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23507.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23507/head:pull/23507 PR: https://git.openjdk.org/jdk/pull/23507 From vromero at openjdk.org Fri Feb 7 18:25:09 2025 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 7 Feb 2025 18:25:09 GMT Subject: RFR: 8349512: Duplicate PermittedSubclasses entries with doclint enabled [v2] In-Reply-To: References: Message-ID: <1zysNTtuPBlOqVeGjQj9qfk4rDM1Of31kx7A79qbXq4=.9e41d1bf-2f74-4656-ad7e-235ee4ba635d@github.com> On Fri, 7 Feb 2025 18:19:51 GMT, Liam Miller-Cushon wrote: >> This change avoids emitting duplicate `PermittedSubclasses` entries when `-Xdoclint` is enabled. >> >> `-Xdoclint` causes some trees to be re-attributed, and the second attribution was resulting in permitted subclasses being added again, and those side effects were not discarded. This fix causes `addPermittedSubclass` to not insert duplicate entries. > > Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: > > Update @test with new bug ID Marked as reviewed by vromero (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23507#pullrequestreview-2602499154 From cushon at openjdk.org Fri Feb 7 19:46:13 2025 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Fri, 7 Feb 2025 19:46:13 GMT Subject: Integrated: 8349512: Duplicate PermittedSubclasses entries with doclint enabled In-Reply-To: References: Message-ID: On Fri, 7 Feb 2025 00:31:36 GMT, Liam Miller-Cushon wrote: > This change avoids emitting duplicate `PermittedSubclasses` entries when `-Xdoclint` is enabled. > > `-Xdoclint` causes some trees to be re-attributed, and the second attribution was resulting in permitted subclasses being added again, and those side effects were not discarded. This fix causes `addPermittedSubclass` to not insert duplicate entries. This pull request has now been integrated. Changeset: bd9b24c0 Author: Liam Miller-Cushon URL: https://git.openjdk.org/jdk/commit/bd9b24c0f8e0db88ae9714cdb355dcd56d802ab4 Stats: 36 lines in 2 files changed: 33 ins; 1 del; 2 mod 8349512: Duplicate PermittedSubclasses entries with doclint enabled Reviewed-by: vromero ------------- PR: https://git.openjdk.org/jdk/pull/23507 From darcy at openjdk.org Fri Feb 7 22:36:20 2025 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 7 Feb 2025 22:36:20 GMT Subject: RFR: 8349475: Test tools/javac/api/TestJavacTaskWithWarning.java writes files in src dir Message-ID: Correct generating files into the work directory, not the directory of test sources. ------------- Commit messages: - JDK-8349475: Test tools/javac/api/TestJavacTaskWithWarning.java writes files in src dir Changes: https://git.openjdk.org/jdk/pull/23527/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23527&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8349475 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/23527.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23527/head:pull/23527 PR: https://git.openjdk.org/jdk/pull/23527 From liach at openjdk.org Fri Feb 7 23:42:09 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 7 Feb 2025 23:42:09 GMT Subject: RFR: 8349475: Test tools/javac/api/TestJavacTaskWithWarning.java writes files in src dir In-Reply-To: References: Message-ID: On Fri, 7 Feb 2025 22:31:41 GMT, Joe Darcy wrote: > Correct generating files into the work directory, not the directory of test sources. Good cleanup. ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23527#pullrequestreview-2603078275 From liangchenblue at gmail.com Mon Feb 10 00:58:32 2025 From: liangchenblue at gmail.com (Chen Liang) Date: Sun, 9 Feb 2025 18:58:32 -0600 Subject: Default interface methods aren't considered abstract method implementations In-Reply-To: References: Message-ID: Hello guys, amber is for new language features. Questions with java compilation or JLS/JVMS belong to the compiler group. That said, I believe this behavior is most likely a preservation of method resolution, that for instance methods, methods from superclass have higher priority than methods from interfaces. For example, before Java 8, static methods could not be defined in interfaces; and when they were added in 8, resolution rule states that they aren't shadowed to child types, so classes cannot "inherit" interface static methods, unlike interface static fields. Another fun fact is that superinterface fields take precedence in resolution over superclass fields. Also a legacy from old Java, but I don't think that is going to be changed to make things "consistent". Regards, Chen Liang On Sun, Feb 9, 2025 at 4:26?PM Pavel Rappo wrote: > Attila, > > Come to think of it, we should use some other, more narrowly focused, > mailing list. Apologies to subscribers of this list. Since lambda-dev > is defunct now, perhaps we could use compiler-dev, amber-dev, or > core-libs-dev instead. I'm voting for amber-dev, where Brian mostly > resides these days. > > -Pavel > > On Sun, Feb 9, 2025 at 10:12?PM Pavel Rappo wrote: > > > > You are not specifically asking Brian, are you? If so, sorry for > replying. > > > > My humble take is that the default method is something to use when > > there's nothing else there. When there's something, even if it's > > abstract, we use that. So, a default method is a minimally interfering > > fallback/extension scenario, if you will. > > > > That abstract A.m() effectively replaces default F.m() in C as if > > F.m() were never there. If F.m() were allowed to provide > > implementation for A.m() in C, then some uncompliable code could > > suddenly become compilable and operational at runtime. > > > > -Pavel. > > > > On Sun, Feb 9, 2025 at 9:04?PM Attila Szegedi > wrote: > > > > > > Hey folks, > > > > > > I found a somewhat puzzling behavior: default interface methods aren't > considered abstract method implementations. Trying to compile this minimal > reproducer: > > > > > > ------ C.java ------ > > > abstract class A { > > > abstract void m(); > > > } > > > > > > interface F { > > > default void m() {} > > > } > > > > > > class C extends A implements F {} > > > ------ C.java ------ > > > > > > $ javac C.java > > > C.java:9: error: C is not abstract and does not override abstract > method m() in A > > > class C extends A implements F { > > > ^ > > > 1 error > > > > > > I can accept this being valid according to JLS today (I tried with 11, > 21, and 23.) I admit this is one of rare occasions when I didn't go > scouring the JLS to figure out what exactly prevents the compiler from > accepting F.m() as implementation of A.m() in C. I'm wondering though if > this isn't something that could be improved upon in the future. (I'm sure > there's a gotcha somewhere. Right, Brian? ;-) ) > > > > > > Have a great day, > > > Attila. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpai at openjdk.org Mon Feb 10 04:32:15 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 10 Feb 2025 04:32:15 GMT Subject: RFR: 8349475: Test tools/javac/api/TestJavacTaskWithWarning.java writes files in src dir In-Reply-To: References: Message-ID: On Fri, 7 Feb 2025 22:31:41 GMT, Joe Darcy wrote: > Correct generating files into the work directory, not the directory of test sources. This looks good to me. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23527#pullrequestreview-2604667108 From jlahoda at openjdk.org Mon Feb 10 17:05:20 2025 From: jlahoda at openjdk.org (Jan Lahoda) Date: Mon, 10 Feb 2025 17:05:20 GMT Subject: RFR: 8349475: Test tools/javac/api/TestJavacTaskWithWarning.java writes files in src dir In-Reply-To: References: Message-ID: On Fri, 7 Feb 2025 22:31:41 GMT, Joe Darcy wrote: > Correct generating files into the work directory, not the directory of test sources. I think we usually use `"."`/current working directory as the target for temporary files. Like here: https://github.com/openjdk/jdk/blob/ab66c82ce9fdb5ee3fd7690f42b8ad4d78bf5e40/test/langtools/tools/javac/ClassPathTest/ClassPathTest.java#L87 I think it is a test's "working directory". But `test.classes` would probably work as well. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23527#issuecomment-2648687036 From darcy at openjdk.org Mon Feb 10 17:15:26 2025 From: darcy at openjdk.org (Joe Darcy) Date: Mon, 10 Feb 2025 17:15:26 GMT Subject: RFR: 8349475: Test tools/javac/api/TestJavacTaskWithWarning.java writes files in src dir [v2] In-Reply-To: References: Message-ID: > Correct generating files into the work directory, not the directory of test sources. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Respond to review feedback. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23527/files - new: https://git.openjdk.org/jdk/pull/23527/files/09c0bdd4..9f26b21d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23527&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23527&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23527.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23527/head:pull/23527 PR: https://git.openjdk.org/jdk/pull/23527 From darcy at openjdk.org Mon Feb 10 17:15:26 2025 From: darcy at openjdk.org (Joe Darcy) Date: Mon, 10 Feb 2025 17:15:26 GMT Subject: RFR: 8349475: Test tools/javac/api/TestJavacTaskWithWarning.java writes files in src dir In-Reply-To: References: Message-ID: <4T85KPhbZ94WjyUNGN3EXrfLE9NDlCA78UgZdR9OCIY=.b85551d7-429c-4458-bab2-6f7678eedc17@github.com> On Mon, 10 Feb 2025 17:03:02 GMT, Jan Lahoda wrote: > I think we usually use `"."`/current working directory as the target for temporary files. Like here: > > https://github.com/openjdk/jdk/blob/ab66c82ce9fdb5ee3fd7690f42b8ad4d78bf5e40/test/langtools/tools/javac/ClassPathTest/ClassPathTest.java#L87 > > I think it is a test's "working directory". > > But `test.classes` would probably work as well. Okay; changed to "." to conform to the broader conventions. Thanks @lahodaj . ------------- PR Comment: https://git.openjdk.org/jdk/pull/23527#issuecomment-2648710177 From archie.cobbs at gmail.com Mon Feb 10 17:21:15 2025 From: archie.cobbs at gmail.com (Archie Cobbs) Date: Mon, 10 Feb 2025 11:21:15 -0600 Subject: RFR: 8349475: Test tools/javac/api/TestJavacTaskWithWarning.java writes files in src dir In-Reply-To: <4T85KPhbZ94WjyUNGN3EXrfLE9NDlCA78UgZdR9OCIY=.b85551d7-429c-4458-bab2-6f7678eedc17@github.com> References: <4T85KPhbZ94WjyUNGN3EXrfLE9NDlCA78UgZdR9OCIY=.b85551d7-429c-4458-bab2-6f7678eedc17@github.com> Message-ID: Thanks for fixing! This was my cut & paste mistake. On Mon, Feb 10, 2025 at 11:16?AM Joe Darcy wrote: > On Mon, 10 Feb 2025 17:03:02 GMT, Jan Lahoda wrote: > > > I think we usually use `"."`/current working directory as the target for > temporary files. Like here: > > > > > https://github.com/openjdk/jdk/blob/ab66c82ce9fdb5ee3fd7690f42b8ad4d78bf5e40/test/langtools/tools/javac/ClassPathTest/ClassPathTest.java#L87 > > > > I think it is a test's "working directory". > > > > But `test.classes` would probably work as well. > > Okay; changed to "." to conform to the broader conventions. Thanks > @lahodaj . > > ------------- > > PR Comment: https://git.openjdk.org/jdk/pull/23527#issuecomment-2648710177 > -- Archie L. Cobbs -------------- next part -------------- An HTML attachment was scrubbed... URL: From jlahoda at openjdk.org Mon Feb 10 18:16:16 2025 From: jlahoda at openjdk.org (Jan Lahoda) Date: Mon, 10 Feb 2025 18:16:16 GMT Subject: RFR: 8349475: Test tools/javac/api/TestJavacTaskWithWarning.java writes files in src dir [v2] In-Reply-To: References: Message-ID: On Mon, 10 Feb 2025 17:15:26 GMT, Joe Darcy wrote: >> Correct generating files into the work directory, not the directory of test sources. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Respond to review feedback. test/langtools/tools/javac/api/TestJavacTaskWithWarning.java line 53: > 51: > 52: // Create a source file that will generate a warning > 53: String srcdir = System.getProperty("."); Sorry, I wasn't very precise, I mean something along these lines: Suggestion: String srcdir = "."; ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23527#discussion_r1949652483 From darcy at openjdk.org Mon Feb 10 18:30:55 2025 From: darcy at openjdk.org (Joe Darcy) Date: Mon, 10 Feb 2025 18:30:55 GMT Subject: RFR: 8349475: Test tools/javac/api/TestJavacTaskWithWarning.java writes files in src dir [v3] In-Reply-To: References: Message-ID: > Correct generating files into the work directory, not the directory of test sources. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Correct implementation of review feedback. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23527/files - new: https://git.openjdk.org/jdk/pull/23527/files/9f26b21d..c8bf9891 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23527&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23527&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23527.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23527/head:pull/23527 PR: https://git.openjdk.org/jdk/pull/23527 From jlahoda at openjdk.org Mon Feb 10 18:30:55 2025 From: jlahoda at openjdk.org (Jan Lahoda) Date: Mon, 10 Feb 2025 18:30:55 GMT Subject: RFR: 8349475: Test tools/javac/api/TestJavacTaskWithWarning.java writes files in src dir [v3] In-Reply-To: References: Message-ID: On Mon, 10 Feb 2025 18:27:16 GMT, Joe Darcy wrote: >> Correct generating files into the work directory, not the directory of test sources. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Correct implementation of review feedback. Looks good to me, thanks! ------------- Marked as reviewed by jlahoda (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23527#pullrequestreview-2606793589 From darcy at openjdk.org Mon Feb 10 18:30:55 2025 From: darcy at openjdk.org (Joe Darcy) Date: Mon, 10 Feb 2025 18:30:55 GMT Subject: Integrated: 8349475: Test tools/javac/api/TestJavacTaskWithWarning.java writes files in src dir In-Reply-To: References: Message-ID: On Fri, 7 Feb 2025 22:31:41 GMT, Joe Darcy wrote: > Correct generating files into the work directory, not the directory of test sources. This pull request has now been integrated. Changeset: f11a7377 Author: Joe Darcy URL: https://git.openjdk.org/jdk/commit/f11a737707414f35738b630e0ffb482431259b0c Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8349475: Test tools/javac/api/TestJavacTaskWithWarning.java writes files in src dir Reviewed-by: jlahoda, liach, jpai ------------- PR: https://git.openjdk.org/jdk/pull/23527 From acobbs at openjdk.org Mon Feb 10 20:56:42 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Mon, 10 Feb 2025 20:56:42 GMT Subject: RFR: 8349754: Invalid "early reference" error when class extends an outer class Message-ID: The compiler is generating a bogus error for this input: $ cat Outer.java class Outer { private int i; class Sub extends Outer { Sub() { i = 42; super(); } } } $ javac --enable-preview --source 24 Outer.java Outer.java:5: error: cannot reference i before supertype constructor has been called i = 42; ^ Note: Outer.java uses preview features of Java SE 24. Note: Recompile with -Xlint:preview for details. 1 error The trick here is that the expression `i` refers to `Outer.this.i`, not `this.i`, but the error checking logic is mistakenly assuming the latter. This patch adds an exception for this case, which happens when the field is `private` and declared in a class which is both a superclass and an outer class. ------------- Commit messages: - Fix incorrect "early reference" error. Changes: https://git.openjdk.org/jdk/pull/23545/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23545&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8349754 Stats: 41 lines in 2 files changed: 33 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/23545.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23545/head:pull/23545 PR: https://git.openjdk.org/jdk/pull/23545 From cushon at google.com Tue Feb 11 18:23:25 2025 From: cushon at google.com (Liam Miller-Cushon) Date: Tue, 11 Feb 2025 10:23:25 -0800 Subject: Capture conversion and switch selectors In-Reply-To: References: Message-ID: Thanks for the explanation! I filed https://bugs.openjdk.org/browse/JDK-8349857 to record this. On Wed, Feb 5, 2025 at 3:41?AM Maurizio Cimadamore < maurizio.cimadamore at oracle.com> wrote: > I'm not sure the capture is the issue here. Note that if the case is > rewritten to > > case B b > > Then everything works as expected and javac doesn't get confused by > capture conversion. Note that capture conversion is always problematic > when it comes to cast expressions -- because the cast has to "relax" > some of the captured variable that might be introduced by capture > conversion. This is an area of the specification that is underspecified, > so javac (and other implementations) have to workaround such issues the > best they can. > > The particular example you pose seems like it should work to me -- > there's only one possible parameterization for A coming up from B.C - > and that's A, so the conversion should be safe here. It seems to > me like a case of bad interplay between enums constants and patterns. > > Maurizio > > > On 28/01/2025 18:51, Liam Miller-Cushon wrote: > > Hi, > > > > Chris Povirk and I were trying to understand why examples like the > > following are rejected: > > > > sealed interface A { > > enum B implements A { > > C; > > } > > > > static void d(A a) { > > switch (a) { > > case B.C: > > } > > } > > } > > > > A.java:8: error: incompatible types: B cannot be converted to A > > case B.C: > > ^ > > where CAP#1 is a fresh type-variable: > > CAP#1 extends Object from capture of ? > > > > I think this is a consequence of JLS 6.5.6.1, which says that the type > > of the switch selector expression is subject to capture conversion, > > and then the captured type is not convertible. > > > > In the implementation, this is happening here [1], where attribExpr > > uses KindSelector.VAL, which causes the capture to happen. > > > > Has consideration been given to treating selector expressions > > differently, to avoid the capture conversion, and allow examples like > > this to compile? I couldn't find test coverage for this specific > > combination of features, which made me wonder if this was a corner > > case that hadn't been explored, rather than something that had > > definitely been ruled out. > > > > Liam > > > > [1] > > > https://github.com/openjdk/jdk/blob/a224f12cb701b45df4706a403a05c66de2d623af/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java#L1702 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From szegedia at gmail.com Mon Feb 10 09:44:47 2025 From: szegedia at gmail.com (Attila Szegedi) Date: Mon, 10 Feb 2025 10:44:47 +0100 Subject: Default interface methods aren't considered abstract method implementations In-Reply-To: References: Message-ID: Hi both Chen and Pavel, Thank you both for answering! I was not specifically asking Brian, of course, that?s why there?s a wink next to it :-) I now scoured JLS 23, specifically: ---- 8.1.1.1. abstract Classes A class C has abstract methods if either of the following is true: Any of the member methods (?8.2) of C - either declared or inherited - is abstract. Any of C's superclasses has an abstract method declared with package access, and there exists no method that overrides the abstract method from C or from a superclass of C. 8.2. Class Members The members of a class are all of the following: Members inherited from its direct superclass type (?8.1.4), except in the class Object, which has no direct superclass type Members inherited from any direct superinterface types (?8.1.5) Members declared in the body of the class (?8.1.7) 8.1.5. Superinterfaces: Each default method (?9.4.3) of a superinterface of the class may optionally be overridden by a method in the class; if not, the default method is typically inherited and its behavior is as specified by its default body. ----- And nothing in there tells me unambiguously that my example should?t work (the last quoted sentence from 8.1.1.1 is weird, but adding ?public? to declaration of ?m? circumvents it and it still doesn?t compile.) There are few phrases that seem open to interpretation though: "default method is _typically_ inherited? (typically is doing heavy lifting here: sometimes it isn?t?) and ?_any of the member methods_ (?8.2) of C - either declared or inherited - is abstract" (are A.m() and F.m() treated as separate member methods at this stage despite identical signatures?) Again, I?m not arguing current javac behavior is wrong, just trying to understand why is it right. I actually hit this in an IRL refactoring ? had several classes that both extended an abstract class (A) and implemented an interface (F), and all these classes had the same implementation for an abstract method (m) that was actually semantically related to F and it felt like a good example of DRY to implement the method only once as a default in F. (Yes, I could create an interim class AF and move the implementation there, but this felt like it would?ve been a good use of an interface as a mixin.) I wonder if I recreated the example in bytecode directly whether the JVM would load the class successfully (I might need to attempt to also call the method) or would I get some kind of IncompatibleClassChangeError. Attila. On 2025. Feb 10. at 1:58:32, Chen Liang wrote: > Hello guys, amber is for new language features. Questions with java > compilation or JLS/JVMS belong to the compiler group. > > That said, I believe this behavior is most likely a preservation of method > resolution, that for instance methods, methods from superclass have higher > priority than methods from interfaces. For example, before Java 8, static > methods could not be defined in interfaces; and when they were added in 8, > resolution rule states that they aren't shadowed to child types, so classes > cannot "inherit" interface static methods, unlike interface static fields. > > Another fun fact is that superinterface fields take precedence in > resolution over superclass fields. Also a legacy from old Java, but I don't > think that is going to be changed to make things "consistent". > > Regards, > Chen Liang > > On Sun, Feb 9, 2025 at 4:26?PM Pavel Rappo wrote: > >> Attila, >> >> Come to think of it, we should use some other, more narrowly focused, >> mailing list. Apologies to subscribers of this list. Since lambda-dev >> is defunct now, perhaps we could use compiler-dev, amber-dev, or >> core-libs-dev instead. I'm voting for amber-dev, where Brian mostly >> resides these days. >> >> -Pavel >> >> On Sun, Feb 9, 2025 at 10:12?PM Pavel Rappo >> wrote: >> > >> > You are not specifically asking Brian, are you? If so, sorry for >> replying. >> > >> > My humble take is that the default method is something to use when >> > there's nothing else there. When there's something, even if it's >> > abstract, we use that. So, a default method is a minimally interfering >> > fallback/extension scenario, if you will. >> > >> > That abstract A.m() effectively replaces default F.m() in C as if >> > F.m() were never there. If F.m() were allowed to provide >> > implementation for A.m() in C, then some uncompliable code could >> > suddenly become compilable and operational at runtime. >> > >> > -Pavel. >> > >> > On Sun, Feb 9, 2025 at 9:04?PM Attila Szegedi >> wrote: >> > > >> > > Hey folks, >> > > >> > > I found a somewhat puzzling behavior: default interface methods >> aren't considered abstract method implementations. Trying to compile this >> minimal reproducer: >> > > >> > > ------ C.java ------ >> > > abstract class A { >> > > abstract void m(); >> > > } >> > > >> > > interface F { >> > > default void m() {} >> > > } >> > > >> > > class C extends A implements F {} >> > > ------ C.java ------ >> > > >> > > $ javac C.java >> > > C.java:9: error: C is not abstract and does not override abstract >> method m() in A >> > > class C extends A implements F { >> > > ^ >> > > 1 error >> > > >> > > I can accept this being valid according to JLS today (I tried with >> 11, 21, and 23.) I admit this is one of rare occasions when I didn't go >> scouring the JLS to figure out what exactly prevents the compiler from >> accepting F.m() as implementation of A.m() in C. I'm wondering though if >> this isn't something that could be improved upon in the future. (I'm sure >> there's a gotcha somewhere. Right, Brian? ;-) ) >> > > >> > > Have a great day, >> > > Attila. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pavel.rappo at gmail.com Mon Feb 10 10:48:24 2025 From: pavel.rappo at gmail.com (Pavel Rappo) Date: Mon, 10 Feb 2025 10:48:24 +0000 Subject: Default interface methods aren't considered abstract method implementations In-Reply-To: References: Message-ID: Could your initial example be directly addressed by 8.4.8.4? On Mon 10 Feb 2025 at 09:44, Attila Szegedi wrote: > Hi both Chen and Pavel, > > Thank you both for answering! I was not specifically asking Brian, of > course, that?s why there?s a wink next to it :-) > I now scoured JLS 23, specifically: > > ---- > 8.1.1.1. abstract Classes > > A class C has abstract methods if either of the following is true: > > Any of the member methods (?8.2) of C - either declared or inherited - is > abstract. > > Any of C's superclasses has an abstract method declared with package > access, and there exists no method that overrides the abstract method from > C or from a superclass of C. > > 8.2. Class Members > > The members of a class are all of the following: > > Members inherited from its direct superclass type (?8.1.4), except in the > class Object, which has no direct superclass type > > Members inherited from any direct superinterface types (?8.1.5) > > Members declared in the body of the class (?8.1.7) > > 8.1.5. Superinterfaces: > > Each default method (?9.4.3) of a superinterface of the class may > optionally be overridden by a method in the class; if not, the default > method is typically inherited and its behavior is as specified by its > default body. > ----- > > And nothing in there tells me unambiguously that my example should?t work > (the last quoted sentence from 8.1.1.1 is weird, but adding ?public? to > declaration of ?m? circumvents it and it still doesn?t compile.) There are > few phrases that seem open to interpretation though: "default method is > _typically_ inherited? (typically is doing heavy lifting here: sometimes it > isn?t?) and ?_any of the member methods_ (?8.2) of C - either declared or > inherited - is abstract" (are A.m() and F.m() treated as separate member > methods at this stage despite identical signatures?) > > Again, I?m not arguing current javac behavior is wrong, just trying to > understand why is it right. I actually hit this in an IRL refactoring ? had > several classes that both extended an abstract class (A) and implemented an > interface (F), and all these classes had the same implementation for an > abstract method (m) that was actually semantically related to F and it felt > like a good example of DRY to implement the method only once as a default > in F. (Yes, I could create an interim class AF and move the implementation > there, but this felt like it would?ve been a good use of an interface as a > mixin.) > > I wonder if I recreated the example in bytecode directly whether the JVM > would load the class successfully (I might need to attempt to also call the > method) or would I get some kind of IncompatibleClassChangeError. > > Attila. > > On 2025. Feb 10. at 1:58:32, Chen Liang wrote: > >> Hello guys, amber is for new language features. Questions with java >> compilation or JLS/JVMS belong to the compiler group. >> >> That said, I believe this behavior is most likely a preservation of >> method resolution, that for instance methods, methods from superclass have >> higher priority than methods from interfaces. For example, before Java 8, >> static methods could not be defined in interfaces; and when they were added >> in 8, resolution rule states that they aren't shadowed to child types, so >> classes cannot "inherit" interface static methods, unlike interface static >> fields. >> >> Another fun fact is that superinterface fields take precedence in >> resolution over superclass fields. Also a legacy from old Java, but I don't >> think that is going to be changed to make things "consistent". >> >> Regards, >> Chen Liang >> >> On Sun, Feb 9, 2025 at 4:26?PM Pavel Rappo wrote: >> >>> Attila, >>> >>> Come to think of it, we should use some other, more narrowly focused, >>> mailing list. Apologies to subscribers of this list. Since lambda-dev >>> is defunct now, perhaps we could use compiler-dev, amber-dev, or >>> core-libs-dev instead. I'm voting for amber-dev, where Brian mostly >>> resides these days. >>> >>> -Pavel >>> >>> On Sun, Feb 9, 2025 at 10:12?PM Pavel Rappo >>> wrote: >>> > >>> > You are not specifically asking Brian, are you? If so, sorry for >>> replying. >>> > >>> > My humble take is that the default method is something to use when >>> > there's nothing else there. When there's something, even if it's >>> > abstract, we use that. So, a default method is a minimally interfering >>> > fallback/extension scenario, if you will. >>> > >>> > That abstract A.m() effectively replaces default F.m() in C as if >>> > F.m() were never there. If F.m() were allowed to provide >>> > implementation for A.m() in C, then some uncompliable code could >>> > suddenly become compilable and operational at runtime. >>> > >>> > -Pavel. >>> > >>> > On Sun, Feb 9, 2025 at 9:04?PM Attila Szegedi >>> wrote: >>> > > >>> > > Hey folks, >>> > > >>> > > I found a somewhat puzzling behavior: default interface methods >>> aren't considered abstract method implementations. Trying to compile this >>> minimal reproducer: >>> > > >>> > > ------ C.java ------ >>> > > abstract class A { >>> > > abstract void m(); >>> > > } >>> > > >>> > > interface F { >>> > > default void m() {} >>> > > } >>> > > >>> > > class C extends A implements F {} >>> > > ------ C.java ------ >>> > > >>> > > $ javac C.java >>> > > C.java:9: error: C is not abstract and does not override abstract >>> method m() in A >>> > > class C extends A implements F { >>> > > ^ >>> > > 1 error >>> > > >>> > > I can accept this being valid according to JLS today (I tried with >>> 11, 21, and 23.) I admit this is one of rare occasions when I didn't go >>> scouring the JLS to figure out what exactly prevents the compiler from >>> accepting F.m() as implementation of A.m() in C. I'm wondering though if >>> this isn't something that could be improved upon in the future. (I'm sure >>> there's a gotcha somewhere. Right, Brian? ;-) ) >>> > > >>> > > Have a great day, >>> > > Attila. >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe.darcy at oracle.com Tue Feb 11 21:56:58 2025 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Tue, 11 Feb 2025 13:56:58 -0800 Subject: Default interface methods aren't considered abstract method implementations In-Reply-To: References: Message-ID: <32198aff-15cd-428f-9599-89b664a3618a@oracle.com> Hi Attila, FYI, some of the documentation for Project Lambda https://openjdk.org/projects/lambda/ hints at the general design rationale here. For example, the default methods (nee "defender methods") doc [1] discusses "favor classes over interfaces" in method resolution and "if multiple methods from interfaces, the user has to choose." HTH, -Joe [1] https://cr.openjdk.org/~briangoetz/lambda/Defender%20Methods%20v4.pdf On 2/10/2025 1:44 AM, Attila Szegedi wrote: > Hi both Chen and Pavel, > > Thank you both for answering! I was not specifically asking Brian, of > course, that?s why there?s a wink next to it :-) > I now scoured JLS 23, specifically: > > ---- > 8.1.1.1. abstract Classes > > A class C has abstract methods if either of the following is true: > > Any of the member methods (?8.2) of C - either declared or inherited - > is abstract. > > Any of C's superclasses has an abstract method declared with package > access, and there exists no method that overrides the abstract method > from C or from a superclass of C. > > 8.2. Class Members > > The members of a class are all of the following: > > Members inherited from its direct superclass type (?8.1.4), except in > the class Object, which has no direct superclass type > > Members inherited from any direct superinterface types (?8.1.5) > > Members declared in the body of the class (?8.1.7) > > 8.1.5. Superinterfaces: > > Each default method (?9.4.3) of a superinterface of the class may > optionally be overridden by a method in the class; if not, the default > method is typically inherited and its behavior is as specified by its > default body. > ----- > > And nothing in there tells me unambiguously that my example should?t > work (the last quoted sentence from 8.1.1.1 is weird, but adding > ?public? to declaration of ?m? circumvents it and it still doesn?t > compile.) There are few phrases that seem open to interpretation > though: "default method is _typically_ inherited? (typically is doing > heavy lifting here: sometimes it isn?t?) and ?_any of the member > methods_ (?8.2) of C - either declared or inherited - is abstract" > (are A.m() and F.m() treated as separate member methods at this stage > despite identical signatures?) > > Again, I?m not arguing current javac behavior is wrong, just trying to > understand why is it right. I actually hit this in an IRL refactoring > ? had several classes that both extended an abstract class (A) and > implemented an interface (F), and all these classes had the same > implementation for an abstract method (m) that was actually > semantically related to F and it felt like a good example of DRY to > implement the method only once as a default in F. (Yes, I could create > an interim class AF and move the implementation there, but this felt > like it would?ve been a good use of an interface as a mixin.) > > I wonder if I recreated the example in bytecode directly whether the > JVM would load the class successfully (I might need to attempt to also > call the method) or would I get some kind of IncompatibleClassChangeError. > > Attila. > > On 2025. Feb 10. at 1:58:32, Chen Liang wrote: >> Hello guys, amber is for new language features. Questions with java >> compilation or JLS/JVMS belong to the compiler group. >> >> That said, I believe this behavior is most likely a preservation of >> method resolution, that for instance methods, methods from superclass >> have higher priority than methods from interfaces. For example, >> before Java 8, static methods could not be defined in interfaces; and >> when they were added in 8, resolution rule states that they aren't >> shadowed to child types, so classes cannot "inherit" interface static >> methods, unlike interface static fields. >> >> Another fun fact is that superinterface fields take precedence in >> resolution over superclass fields. Also a legacy from old Java, but I >> don't think that is going to be changed to make things "consistent". >> >> Regards, >> Chen Liang >> >> On Sun, Feb 9, 2025 at 4:26?PM Pavel Rappo wrote: >> >> Attila, >> >> Come to think of it, we should use some other, more narrowly focused, >> mailing list. Apologies to subscribers of this list. Since lambda-dev >> is defunct now, perhaps we could use compiler-dev, amber-dev, or >> core-libs-dev instead. I'm voting for amber-dev, where Brian mostly >> resides these days. >> >> -Pavel >> >> On Sun, Feb 9, 2025 at 10:12?PM Pavel Rappo >> wrote: >> > >> > You are not specifically asking Brian, are you? If so, sorry >> for replying. >> > >> > My humble take is that the default method is something to use when >> > there's nothing else there. When there's something, even if it's >> > abstract, we use that. So, a default method is a minimally >> interfering >> > fallback/extension scenario, if you will. >> > >> > That abstract A.m() effectively replaces default F.m() in C as if >> > F.m() were never there. If F.m() were allowed to provide >> > implementation for A.m() in C, then some uncompliable code could >> > suddenly become compilable and operational at runtime. >> > >> > -Pavel. >> > >> > On Sun, Feb 9, 2025 at 9:04?PM Attila Szegedi >> wrote: >> > > >> > > Hey folks, >> > > >> > > I found a somewhat puzzling behavior: default interface >> methods aren't considered abstract method implementations. Trying >> to compile this minimal reproducer: >> > > >> > > ------ C.java ------ >> > > abstract class A { >> > >? ?abstract void m(); >> > > } >> > > >> > > interface F { >> > >? ?default void m() {} >> > > } >> > > >> > > class C extends A implements F {} >> > > ------ C.java ------ >> > > >> > > $ javac C.java >> > > C.java:9: error: C is not abstract and does not override >> abstract method m() in A >> > > class C extends A implements F { >> > > ^ >> > > 1 error >> > > >> > > I can accept this being valid according to JLS today (I tried >> with 11, 21, and 23.) I admit this is one of rare occasions when >> I didn't go scouring the JLS to figure out what exactly prevents >> the compiler from accepting F.m() as implementation of A.m() in >> C. I'm wondering though if this isn't something that could be >> improved upon in the future. (I'm sure there's a gotcha >> somewhere. Right, Brian? ;-) ) >> > > >> > > Have a great day, >> > >? ?Attila. >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From mcimadamore at openjdk.org Wed Feb 12 10:19:11 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 12 Feb 2025 10:19:11 GMT Subject: RFR: 8349754: Invalid "early reference" error when class extends an outer class In-Reply-To: References: Message-ID: <7a1rGVyW2gzIC-RqyhZtlPARXlAgjCn9Vem8wUJMzs0=.df5151dc-8cc0-449d-bea6-8c2df52f77b6@github.com> On Mon, 10 Feb 2025 20:51:34 GMT, Archie Cobbs wrote: > The compiler is generating a bogus error for this input: > > $ cat Outer.java > class Outer { > private int i; > class Sub extends Outer { > Sub() { > i = 42; > super(); > } > } > } > $ javac --enable-preview --source 24 Outer.java > Outer.java:5: error: cannot reference i before supertype constructor has been called > i = 42; > ^ > Note: Outer.java uses preview features of Java SE 24. > Note: Recompile with -Xlint:preview for details. > 1 error > > > The trick here is that the expression `i` refers to `Outer.this.i`, not `this.i`, but the error checking logic is mistakenly assuming the latter. This patch adds an exception for this case, which happens when the field is `private` and declared in a class which is both a superclass and an outer class. src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java line 4015: > 4013: // declared in a superclass S if (a) the field is private, and (b) S is also an outer class. > 4014: // It's OK because the expression "x" then refers to the outer instance, not the current instance. > 4015: if (env.enclClass.type != v.owner.type && (v.flags() & PRIVATE) != 0) { My feeling is that we should deal with this from a membership point of view. That is, `x` here is NOT a member of the subclass because it is not inherited. I'd suggest to use `Symbol::isMemberOf` (which also does the subtype check). (Note that the subclass could declare _another_ field with same name, in which case the superclass field is not inherited, even if non-private. Better to rely on existing membership logic -- the rules are finicky) If I'm not mistaken, I hope you can rewrite the full check like this: if (env.info.ctorPrologue && (v.flags() & STATIC) == 0 && v.isMemberOf(env.enclClass.sym)) { ... } Honestly, I'm also reading the text in the spec draft for JEP 492, I'm not sure it deals with this case correctly: > If an expression name consists of a single Identifier, then there must be exactly one declaration denoting either a local variable, formal parameter, exception parameter, or field in scope at the point at which the identifier occurs. Otherwise, a compile-time error occurs. > If the declaration denotes an instance variable of a class C ([8.3.1.1](https://docs.oracle.com/javase/specs/jls/se22/html/jls-8.html#jls-8.3.1.1)), then both all of the following must be true, or a compile-time error occurs: > The expression name does not occur in a static context ([8.1.3](https://cr.openjdk.org/~gbierman/jep492/jep492-20241218/specs/flexible-constructor-bodies-jls.html#jls-8.1.3)). > If the expression name occurs in an early construction context of C ([8.8.7](https://cr.openjdk.org/~gbierman/jep492/jep492-20241218/specs/flexible-constructor-bodies-jls.html#jls-8.8.7)), then it is the left-hand operand of a simple assignment expression ([15.26](https://docs.oracle.com/javase/specs/jls/se22/html/jls-15.html#jls-15.26)), the declaration of the named variable lacks an initializer, and the simple assignment expression is not enclosed in a lambda expression or inner class declaration that is contained in the early construction context of C. > The expression name does not occur in an early construction context of a subclass of C. There's no reference to the fact that the instance variable being referred to must be a member of C. This is different, for instance, from what happens for 6.5.7.1 (simple method names), where membership is mentioned. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23545#discussion_r1952360600 From gavin.bierman at oracle.com Wed Feb 12 12:19:02 2025 From: gavin.bierman at oracle.com (Gavin Bierman) Date: Wed, 12 Feb 2025 12:19:02 +0000 Subject: RFR: 8349754: Invalid "early reference" error when class extends an outer class In-Reply-To: <7a1rGVyW2gzIC-RqyhZtlPARXlAgjCn9Vem8wUJMzs0=.df5151dc-8cc0-449d-bea6-8c2df52f77b6@github.com> References: <7a1rGVyW2gzIC-RqyhZtlPARXlAgjCn9Vem8wUJMzs0=.df5151dc-8cc0-449d-bea6-8c2df52f77b6@github.com> Message-ID: Thanks Maurizio. I?ll take a look at this for the spec for the next release. Gavin On 12 Feb 2025, at 10:19, Maurizio Cimadamore wrote: On Mon, 10 Feb 2025 20:51:34 GMT, Archie Cobbs > wrote: The compiler is generating a bogus error for this input: $ cat Outer.java class Outer { private int i; class Sub extends Outer { Sub() { i = 42; super(); } } } $ javac --enable-preview --source 24 Outer.java Outer.java:5: error: cannot reference i before supertype constructor has been called i = 42; ^ Note: Outer.java uses preview features of Java SE 24. Note: Recompile with -Xlint:preview for details. 1 error The trick here is that the expression `i` refers to `Outer.this.i`, not `this.i`, but the error checking logic is mistakenly assuming the latter. This patch adds an exception for this case, which happens when the field is `private` and declared in a class which is both a superclass and an outer class. src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java line 4015: 4013: // declared in a superclass S if (a) the field is private, and (b) S is also an outer class. 4014: // It's OK because the expression "x" then refers to the outer instance, not the current instance. 4015: if (env.enclClass.type != v.owner.type && (v.flags() & PRIVATE) != 0) { My feeling is that we should deal with this from a membership point of view. That is, `x` here is NOT a member of the subclass because it is not inherited. I'd suggest to use `Symbol::isMemberOf` (which also does the subtype check). (Note that the subclass could declare _another_ field with same name, in which case the superclass field is not inherited, even if non-private. Better to rely on existing membership logic -- the rules are finicky) If I'm not mistaken, I hope you can rewrite the full check like this: if (env.info.ctorPrologue && (v.flags() & STATIC) == 0 && v.isMemberOf(env.enclClass.sym)) { ... } Honestly, I'm also reading the text in the spec draft for JEP 492, I'm not sure it deals with this case correctly: If an expression name consists of a single Identifier, then there must be exactly one declaration denoting either a local variable, formal parameter, exception parameter, or field in scope at the point at which the identifier occurs. Otherwise, a compile-time error occurs. If the declaration denotes an instance variable of a class C ([8.3.1.1](https://docs.oracle.com/javase/specs/jls/se22/html/jls-8.html#jls-8.3.1.1)), then both all of the following must be true, or a compile-time error occurs: The expression name does not occur in a static context ([8.1.3](https://cr.openjdk.org/~gbierman/jep492/jep492-20241218/specs/flexible-constructor-bodies-jls.html#jls-8.1.3)). If the expression name occurs in an early construction context of C ([8.8.7](https://cr.openjdk.org/~gbierman/jep492/jep492-20241218/specs/flexible-constructor-bodies-jls.html#jls-8.8.7)), then it is the left-hand operand of a simple assignment expression ([15.26](https://docs.oracle.com/javase/specs/jls/se22/html/jls-15.html#jls-15.26)), the declaration of the named variable lacks an initializer, and the simple assignment expression is not enclosed in a lambda expression or inner class declaration that is contained in the early construction context of C. The expression name does not occur in an early construction context of a subclass of C. There's no reference to the fact that the instance variable being referred to must be a member of C. This is different, for instance, from what happens for 6.5.7.1 (simple method names), where membership is mentioned. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23545#discussion_r1952360600 -------------- next part -------------- An HTML attachment was scrubbed... URL: From acobbs at openjdk.org Wed Feb 12 15:38:06 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Wed, 12 Feb 2025 15:38:06 GMT Subject: RFR: 8349754: Invalid "early reference" error when class extends an outer class [v2] In-Reply-To: References: Message-ID: > The compiler is generating a bogus error for this input: > > $ cat Outer.java > class Outer { > private int i; > class Sub extends Outer { > Sub() { > i = 42; > super(); > } > } > } > $ javac --enable-preview --source 24 Outer.java > Outer.java:5: error: cannot reference i before supertype constructor has been called > i = 42; > ^ > Note: Outer.java uses preview features of Java SE 24. > Note: Recompile with -Xlint:preview for details. > 1 error > > > The trick here is that the expression `i` refers to `Outer.this.i`, not `this.i`, but the error checking logic is mistakenly assuming the latter. This patch adds an exception for this case, which happens when the field is `private` and declared in a class which is both a superclass and an outer class. Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision: Simplify logic using Symbol.isMemberOf() per review suggestion. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23545/files - new: https://git.openjdk.org/jdk/pull/23545/files/a632fe6d..589e6d7d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23545&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23545&range=00-01 Stats: 17 lines in 1 file changed: 0 ins; 14 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/23545.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23545/head:pull/23545 PR: https://git.openjdk.org/jdk/pull/23545 From acobbs at openjdk.org Wed Feb 12 15:38:07 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Wed, 12 Feb 2025 15:38:07 GMT Subject: RFR: 8349754: Invalid "early reference" error when class extends an outer class [v2] In-Reply-To: <7a1rGVyW2gzIC-RqyhZtlPARXlAgjCn9Vem8wUJMzs0=.df5151dc-8cc0-449d-bea6-8c2df52f77b6@github.com> References: <7a1rGVyW2gzIC-RqyhZtlPARXlAgjCn9Vem8wUJMzs0=.df5151dc-8cc0-449d-bea6-8c2df52f77b6@github.com> Message-ID: On Wed, 12 Feb 2025 10:15:27 GMT, Maurizio Cimadamore wrote: >> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision: >> >> Simplify logic using Symbol.isMemberOf() per review suggestion. > > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java line 4015: > >> 4013: // declared in a superclass S if (a) the field is private, and (b) S is also an outer class. >> 4014: // It's OK because the expression "x" then refers to the outer instance, not the current instance. >> 4015: if (env.enclClass.type != v.owner.type && (v.flags() & PRIVATE) != 0) { > > My feeling is that we should deal with this from a membership point of view. That is, `x` here is NOT a member of the subclass because it is not inherited. I'd suggest to use `Symbol::isMemberOf` (which also does the subtype check). > > (Note that the subclass could declare _another_ field with same name, in which case the superclass field is not inherited, even if non-private. Better to rely on existing membership logic -- the rules are finicky) > > If I'm not mistaken, I hope you can rewrite the full check like this: > > > if (env.info.ctorPrologue && > (v.flags() & STATIC) == 0 && > v.isMemberOf(env.enclClass.sym)) { ... } > > > Honestly, I'm also reading the text in the spec draft for JEP 492, I'm not sure it deals with this case correctly: > >> If an expression name consists of a single Identifier, then there must be exactly one declaration denoting either a local variable, formal parameter, exception parameter, or field in scope at the point at which the identifier occurs. Otherwise, a compile-time error occurs. > >> If the declaration denotes an instance variable of a class C ([8.3.1.1](https://docs.oracle.com/javase/specs/jls/se22/html/jls-8.html#jls-8.3.1.1)), then both all of the following must be true, or a compile-time error occurs: > >> The expression name does not occur in a static context ([8.1.3](https://cr.openjdk.org/~gbierman/jep492/jep492-20241218/specs/flexible-constructor-bodies-jls.html#jls-8.1.3)). > >> If the expression name occurs in an early construction context of C ([8.8.7](https://cr.openjdk.org/~gbierman/jep492/jep492-20241218/specs/flexible-constructor-bodies-jls.html#jls-8.8.7)), then it is the left-hand operand of a simple assignment expression ([15.26](https://docs.oracle.com/javase/specs/jls/se22/html/jls-15.html#jls-15.26)), the declaration of the named variable lacks an initializer, and the simple assignment expression is not enclosed in a lambda expression or inner class declaration that is contained in the early construction context of C. > >> The expression name does not occur in an early construction c... Thanks, that is a nice simplification. >From what I can tell we still need to make an exception for the `Foo.this.x` case, otherwise this example would fail: class Early { int x; class Sub extends Early { Sub() { Early.this.x = 3; super(); } } } Trying to explain this to myself: The current class here is `Foo`, and `Foo.this.x` does indeed refer to a member of class `Foo`. But it refers to a different _instance_ of class `Foo` from the one under construction. I suppose this question of "Which _instance_ of class S are we talking about?" only comes up in the compiler in the corner case when a class has S as both a superclass and an outer class, so there's not really "first class" support for answering this question, like there is for answering the question "Is x a member of S?". Fixed in 589e6d7d2fc. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23545#discussion_r1952895997 From acobbs at openjdk.org Wed Feb 12 19:20:28 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Wed, 12 Feb 2025 19:20:28 GMT Subject: Integrated: 8348427: DeferredLintHandler API should use JCTree instead of DiagnosticPosition In-Reply-To: References: Message-ID: On Thu, 23 Jan 2025 21:11:11 GMT, Archie Cobbs wrote: > The purpose of `DeferredLintHandler` is to allow `@SuppressWarnings` to be applied to warnings that are generated before `@SuppressWarnings` annotations themselves have been processed. The way this currently works is that warning callbacks are kept in a `HashMap` keyed by the innermost containing module, package, class, method, or variable declarations (in the form of a `JCModuleDecl`, `JCPackageDecl`, `JCClassDecl`, `JCMethodDecl`, or `JCVariableDecl`). Later, when the compiler executes the attribution phase and the lint categories suppressed at each declaration are known, the corresponding warning callbacks are provided with an appropriately configured `Lint` instance and "flushed". > > However, the `DeferredLintHandler` API uses `DiagnosticPosition` instead of `JCTree` for registering and flushing deferred warnings. This opens the door for bugs where warnings are registered to an object which is not a declaration, and therefore ignored. > > In fact, this occurs once in the code ([here](https://github.com/openjdk/jdk/blob/48ece0721489c1b357aaa81e89fe59f486079d15/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Annotate.java#L679)) where a `JCExpression` is being passed, although in this case the bug appears to be harmless (because annotation values can't contain any type of declaration). > > The API should be tighted up, and furthermore an assertion should be added to verify that the JCTree being passed is actually a declaration supporting `@SuppressWarnings`. > > In addition, there is a design flaw in the API: it's not possible to obtain the current immediate mode `Lint` object, so if an immediate mode `Lint` object is pushed/popped more than once, the second `Lint` object will overwrite the first. > > To fix this, the API should be adjusted so the stack of current declarations and/or immediate mode `Lint` objects is managed by the `DeferredLintHandler` itself, by providing a `push()` and `pop()` methods in the API. This pull request has now been integrated. Changeset: ba281196 Author: Archie Cobbs URL: https://git.openjdk.org/jdk/commit/ba28119642a7cfa850707a01ce8e589c3a80d416 Stats: 210 lines in 9 files changed: 50 ins; 34 del; 126 mod 8348427: DeferredLintHandler API should use JCTree instead of DiagnosticPosition Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.org/jdk/pull/23281 From acobbs at openjdk.org Wed Feb 12 19:41:27 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Wed, 12 Feb 2025 19:41:27 GMT Subject: RFR: 8224228: No way to locally suppress lint warnings in parser/tokenizer or preview features [v10] In-Reply-To: References: Message-ID: > This PR updates the `DeferredLintHandler` so that deferred warnings can be registered during parsing, before any `JCTree` nodes have been created, and it uses this new capability to update the `"preview"` and `"text-blocks"` Lint warnings so that they can be suppressed via `@SuppressWarnings` annotations. More details are provided in additional comments. > > Note: This PR depends on (i.e., includes and extends) these other "cleanup" PR's: > * #23167 > * #23281 > * #23400 Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits: - Merge branch 'master' into JDK-8224228 to fix conflicts. - Merge branch 'master' into JDK-8224228 - Revert gratuituous whitespace change. - Merge branch 'JDK-8349155' into JDK-8224228 - Refactor to remove the "log" parameter from Lint.logIfEnabled(). - Fix an inaccurate comment. - Refactor "dangling-doc-comments" logic to utilize new DeferredLintHandler. - Fix bugs when mapping lexical deferrals to declarations. - Refactor to eliminate the unnecessary MandatoryWarningHandler "verbose" field. - Instead of using EndPosTable, track ending positions of declarations explicitly. - ... and 15 more: https://git.openjdk.org/jdk/compare/ba281196...615d0148 ------------- Changes: https://git.openjdk.org/jdk/pull/23237/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23237&range=09 Stats: 673 lines in 22 files changed: 495 ins; 79 del; 99 mod Patch: https://git.openjdk.org/jdk/pull/23237.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23237/head:pull/23237 PR: https://git.openjdk.org/jdk/pull/23237 From acobbs at openjdk.org Wed Feb 12 19:49:54 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Wed, 12 Feb 2025 19:49:54 GMT Subject: RFR: 8224228: No way to locally suppress lint warnings in parser/tokenizer or preview features [v11] In-Reply-To: References: Message-ID: > This PR updates the `DeferredLintHandler` so that deferred warnings can be registered during parsing, before any `JCTree` nodes have been created, and it uses this new capability to update the `"preview"` and `"text-blocks"` Lint warnings so that they can be suppressed via `@SuppressWarnings` annotations. More details are provided in additional comments. > > Note: This PR depends on (i.e., includes and extends) these other "cleanup" PR's: > * #23167 > * #23281 > * #23400 Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision: Update copyright dates. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23237/files - new: https://git.openjdk.org/jdk/pull/23237/files/615d0148..65577822 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23237&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23237&range=09-10 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/23237.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23237/head:pull/23237 PR: https://git.openjdk.org/jdk/pull/23237 From mcimadamore at openjdk.org Thu Feb 13 18:41:10 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 13 Feb 2025 18:41:10 GMT Subject: RFR: 8349754: Invalid "early reference" error when class extends an outer class [v2] In-Reply-To: References: <7a1rGVyW2gzIC-RqyhZtlPARXlAgjCn9Vem8wUJMzs0=.df5151dc-8cc0-449d-bea6-8c2df52f77b6@github.com> Message-ID: On Wed, 12 Feb 2025 15:35:01 GMT, Archie Cobbs wrote: > From what I can tell we still need to make an exception for the `Foo.this.x` Sure - I was referring to the "simple name" part of the affair :-) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23545#discussion_r1955039154 From mcimadamore at openjdk.org Thu Feb 13 18:46:09 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 13 Feb 2025 18:46:09 GMT Subject: RFR: 8349754: Invalid "early reference" error when class extends an outer class [v2] In-Reply-To: References: <7a1rGVyW2gzIC-RqyhZtlPARXlAgjCn9Vem8wUJMzs0=.df5151dc-8cc0-449d-bea6-8c2df52f77b6@github.com> Message-ID: On Thu, 13 Feb 2025 18:38:10 GMT, Maurizio Cimadamore wrote: >> Thanks, that is a nice simplification. >> >> From what I can tell we still need to make an exception for the `Foo.this.x` case, otherwise this example would fail: >> >> class Early { >> int x; >> class Sub extends Early { >> Sub() { >> Early.this.x = 3; >> super(); >> } >> } >> } >> >> Trying to explain this to myself: The current class here is `Foo`, and `Foo.this.x` does indeed refer to a member of class `Foo`. But it refers to a different _instance_ of class `Foo` from the one under construction. >> >> I suppose this question of "Which _instance_ of class S are we talking about?" only comes up in the compiler in the corner case when a class has S as both a superclass and an outer class, so there's not really "first class" support for answering this question, like there is for answering the question "Is x a member of S?". >> >> Fixed in 589e6d7d2fc. > >> From what I can tell we still need to make an exception for the `Foo.this.x` > > Sure - I was referring to the "simple name" part of the affair :-) > Trying to explain this to myself: The current class here is `Foo`, and `Foo.this.x` does indeed refer to a member of class `Foo`. But it refers to a different _instance_ of class `Foo` from the one under construction. I will also re-read the JLS carefully, to make sure this is covered ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23545#discussion_r1955045911 From acobbs at openjdk.org Thu Feb 13 20:58:46 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Thu, 13 Feb 2025 20:58:46 GMT Subject: RFR: 8349847: Support configuring individual lint categories as errors Message-ID: This PR refines the `-Werror` flag to support lint categories just like `-Xlint` does. So, for example `-Werror:all,-preview` would cause an error if any warning other than a `preview` warning occurred. A few notes: * Some warnings emitted by the compiler do not have a corresponding `Lint` category. As always, they cause an error if `-Werror` is given, but what if `-Werror:all` is given instead? The answer given here is yes, an error will occur. * The `-Werror` works the same way as before, i.e., any warning results in an error. That means if `-Werror` is given `-Werror:foo` flags have no effect. * Refactoring has been done to allow `-Xlint` and `-Werror` to utilize the same "parsing" logic. The existing `-Xlint` flag has a particular behavior when conflicting flags are combined (e.g., `-Xlint:all -Xlint:none -Xlint:foo -Xlint:-foo` equals `-Xlint:all`). This behavior is been preserved and Javadocumented. * A few minor cleanups are included ------------- Commit messages: - Add support for -Werror:key. Changes: https://git.openjdk.org/jdk/pull/23622/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23622&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8349847 Stats: 269 lines in 15 files changed: 202 ins; 38 del; 29 mod Patch: https://git.openjdk.org/jdk/pull/23622.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23622/head:pull/23622 PR: https://git.openjdk.org/jdk/pull/23622 From mcimadamore at openjdk.org Fri Feb 14 10:14:16 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 14 Feb 2025 10:14:16 GMT Subject: RFR: 8349754: Invalid "early reference" error when class extends an outer class [v2] In-Reply-To: References: <7a1rGVyW2gzIC-RqyhZtlPARXlAgjCn9Vem8wUJMzs0=.df5151dc-8cc0-449d-bea6-8c2df52f77b6@github.com> Message-ID: On Thu, 13 Feb 2025 18:43:27 GMT, Maurizio Cimadamore wrote: >>> From what I can tell we still need to make an exception for the `Foo.this.x` >> >> Sure - I was referring to the "simple name" part of the affair :-) > >> Trying to explain this to myself: The current class here is `Foo`, and `Foo.this.x` does indeed refer to a member of class `Foo`. But it refers to a different _instance_ of class `Foo` from the one under construction. > > I will also re-read the JLS carefully, to make sure this is covered So... N.this is always used to denote an enclosing instance. So, if N is in early construction context, there are two cases: * this is a "simple assignment", in which case the spec says it's ok * it's not an assignment (but a field read), in which case it's an error. In your example above, `Early` is not in early construction context when we are in the `Sub` constructor, so none of the above applies? I guess in terms of code, what this means is that I'm surprised that we're handling the implicit and explicit cases in the same test. E.g. when using a qualified `X.this`, the membership check seems irrelevant (the only thing that matters is whether `X` is in early construction context). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23545#discussion_r1955892604 From nbenalla at openjdk.org Fri Feb 14 11:50:27 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Fri, 14 Feb 2025 11:50:27 GMT Subject: RFR: 8350007: Add usage message to the javadoc executable In-Reply-To: References: Message-ID: On Thu, 13 Feb 2025 16:41:54 GMT, Nizar Benalla wrote: > This patch adds a new message when you run the `javadoc` executable with any arguments. > Currently, unlike most other tools, running `javadoc` without any arguments does not show you how to use the tool or point you to use the `--help` option, this can be improved. > > Before change: > > W $ ./javadoc > error: No modules, packages or classes specified. > 1 error > > > After change: > > W $ ./javadoc > Usage: > javadoc [options] [packagenames] [sourcefiles] [@files] > For additional help on usage: javadoc --help I had only run the `langtools_javadoc` tests and missed this `javac` failure. There is a change to a compiler test. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23618#issuecomment-2659124543 PR Comment: https://git.openjdk.org/jdk/pull/23618#issuecomment-2659127237 From nbenalla at openjdk.org Fri Feb 14 11:50:27 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Fri, 14 Feb 2025 11:50:27 GMT Subject: RFR: 8350007: Add usage message to the javadoc executable [v2] In-Reply-To: References: Message-ID: > This patch adds a new message when you run the `javadoc` executable with any arguments. > Currently, unlike most other tools, running `javadoc` without any arguments does not show you how to use the tool or point you to use the `--help` option, this can be improved. > > Before change: > > W $ ./javadoc > error: No modules, packages or classes specified. > 1 error > > > After change: > > W $ ./javadoc > Usage: > javadoc [options] [packagenames] [sourcefiles] [@files] > For additional help on usage: javadoc --help Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision: update test with new usage message ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23618/files - new: https://git.openjdk.org/jdk/pull/23618/files/a248f98d..4572fe9a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23618&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23618&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/23618.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23618/head:pull/23618 PR: https://git.openjdk.org/jdk/pull/23618 From acobbs at openjdk.org Fri Feb 14 17:53:16 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Fri, 14 Feb 2025 17:53:16 GMT Subject: RFR: 8349754: Invalid "early reference" error when class extends an outer class [v2] In-Reply-To: References: <7a1rGVyW2gzIC-RqyhZtlPARXlAgjCn9Vem8wUJMzs0=.df5151dc-8cc0-449d-bea6-8c2df52f77b6@github.com> Message-ID: On Fri, 14 Feb 2025 10:11:47 GMT, Maurizio Cimadamore wrote: > So... N.this is always used to denote an enclosing instance... I think that's not always true... for example, this compiles just fine (with or without the explicit `super()`): class Myself { int x; Myself() { Myself.this.x = 42; super(); } } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23545#discussion_r1956524379 From acobbs at openjdk.org Fri Feb 14 21:15:35 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Fri, 14 Feb 2025 21:15:35 GMT Subject: RFR: 8349848: Support lint control of sunapi diagnostics Message-ID: <-FuJOJGuqnEWp6DseDoGMIf8JY8lTaK2_tVVf-o-1TY=.62b8d0eb-3398-49fd-a321-129c29817ff2@github.com> This PR creates a new lint category `proprietary` that controls the mandatory warning "Foo is internal proprietary API and may be removed in a future release". This allows developers to suppress this warning using `-Xlint:-proprietary` and/or `@SuppressWarnings`. ------------- Commit messages: - Add "proprietary" lint category for internal proprietary API warnings. Changes: https://git.openjdk.org/jdk/pull/23650/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23650&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8349848 Stats: 202 lines in 15 files changed: 190 ins; 2 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/23650.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23650/head:pull/23650 PR: https://git.openjdk.org/jdk/pull/23650 From acobbs at openjdk.org Fri Feb 14 23:37:10 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Fri, 14 Feb 2025 23:37:10 GMT Subject: RFR: 8349754: Invalid "early reference" error when class extends an outer class [v2] In-Reply-To: References: <7a1rGVyW2gzIC-RqyhZtlPARXlAgjCn9Vem8wUJMzs0=.df5151dc-8cc0-449d-bea6-8c2df52f77b6@github.com> Message-ID: On Fri, 14 Feb 2025 17:51:02 GMT, Archie Cobbs wrote: >> So... N.this is always used to denote an enclosing instance. So, if N is in early construction context, there are two cases: >> * this is a "simple assignment", in which case the spec says it's ok >> * it's not an assignment (but a field read), in which case it's an error. >> >> In your example above, `Early` is not in early construction context when we are in the `Sub` constructor, so none of the above applies? I guess in terms of code, what this means is that I'm surprised that we're handling the implicit and explicit cases in the same test. E.g. when using a qualified `X.this`, the membership check seems irrelevant (the only thing that matters is whether `X` is in early construction context). > >> So... N.this is always used to denote an enclosing instance... > > I think that's not always true... for example, this compiles just fine (with or without the explicit `super()`): > > class Myself { > int x; > Myself() { > Myself.this.x = 42; > super(); > } > } Hmm, re-reading that I think maybe I misinterpreted your statement... For clarity, let's just enumerate the possibilities. Suppose we are inside a class `C` and there is some instance field `x` accessible to us. Then any such `x` must be declared in one (_or both_) of these two "hierarchies": * **Inner hierarchy** - `x` is declared in `C` or (non-privately) in a superclass of `C` * **Outer hierarchy** - `x` is declared in a some outer class `O` containing `C` In the case `x` is declared in both hierarchies, it may _also_ be the case that `O` is a superclass of `C`, but for our purposes that's "just a coincidence" - it doesn't affect how many `x` field's are accessible to us (i.e., two). Now what can the various expressions mean depending on which of the two hierarchies `x` is declared in? | Inner? | Outer? | `C` extends `O` | `x` | `C.this.x` | `O.this.x` | Comments | | :---: | :---: | :---: | :---: | :---: | :---: | :--- | | Yes | No | N/A | Inner | Inner | _N/A_ | Simple inner case | | No | Yes | No | Outer | _N/A_ | Outer | Simple outer case | | No | Yes | Yes | _N/A_ | _N/A_ | _N/A_ | Not possible! | | | Yes | Yes | No | Inner | Inner | Outer | | | Yes | Yes | Yes | Inner | Inner | Outer | | So it looks like we can say this about an (presumably valid) expression of the form `N.this.x`: * If `N` = `C`, then we are always referring to the "inner" `x` - therefore, it's an early reference to `C` if and only if we are in an early construction context for `C` * If `N` ? `C`, then we are always referring to the "outer" `x` - therefore, an early reference if and only if we are in an early construction context for `N` So according to that logic, you are correct in saying, with regards to expressions like `N.this.x`, that "the only thing that matters is whether `N` is in early construction context". Please check my work... ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23545#discussion_r1956864467 From lmesnik at openjdk.org Sat Feb 15 19:48:45 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Sat, 15 Feb 2025 19:48:45 GMT Subject: RFR: 8350151: Support requires property to filer tests incompatible with --enable-preview Message-ID: It might be useful to be able to run testing with --enable-preview for feature development. The tests incompatible with this mode must be filtered out. I chose name 'java.enablePreview' , because it is more java property than vm or jdk. And 'enablePreview' to be similar with jtreg tag. Tested by running all test suites, and verifying that test is correctly selected. There are more tests incompatible with --enable-preview, will mark them in the following bug. ------------- Commit messages: - Update VPProps Changes: https://git.openjdk.org/jdk/pull/23653/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23653&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8350151 Stats: 27 lines in 5 files changed: 19 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/23653.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23653/head:pull/23653 PR: https://git.openjdk.org/jdk/pull/23653 From acobbs at openjdk.org Sat Feb 15 21:27:56 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Sat, 15 Feb 2025 21:27:56 GMT Subject: RFR: 8343478: Remove unnecessary @SuppressWarnings annotations (core-libs) [v12] In-Reply-To: <9ZqHljyJeMr8fPG4-iU6bfQT9hQxTAwrGCl4xsQn3LA=.0b01f899-d849-4e23-8d50-8f186aade664@github.com> References: <9ZqHljyJeMr8fPG4-iU6bfQT9hQxTAwrGCl4xsQn3LA=.0b01f899-d849-4e23-8d50-8f186aade664@github.com> Message-ID: > Please review this patch which removes unnecessary `@SuppressWarnings` annotations. Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits: - Merge branch 'master' into SuppressWarningsCleanup-core-libs to fix conflicts. - Remove a few more unnecessary suppressions. - Merge branch 'master' into SuppressWarningsCleanup-core-libs - Update @LastModified tags. - Revert changes under src/java.desktop (to be moved into a separate PR). - Bump copyright year to 2025. - Merge branch 'master' into SuppressWarningsCleanup-core-libs - Remove more unnecessary suppressions. - Merge branch 'master' into SuppressWarningsCleanup-core-libs - Remove more unnecessary @SuppressWarnings annotations. - ... and 12 more: https://git.openjdk.org/jdk/compare/ba281196...340ca514 ------------- Changes: https://git.openjdk.org/jdk/pull/21852/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21852&range=11 Stats: 211 lines in 93 files changed: 0 ins; 90 del; 121 mod Patch: https://git.openjdk.org/jdk/pull/21852.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21852/head:pull/21852 PR: https://git.openjdk.org/jdk/pull/21852 From acobbs at openjdk.org Mon Feb 17 02:43:36 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Mon, 17 Feb 2025 02:43:36 GMT Subject: RFR: 8349991: GraphUtils.java can use String.replace() instead of String.replaceAll() Message-ID: This is a tiny performance improvement that replaces a few invocations of `String.replaceAll()` with equivalent invocations of `String.replace(char, char)` and avoids the unnecessary use of regular expressions. ------------- Commit messages: - Simplify invocations of replaceAll() where replace() would work. Changes: https://git.openjdk.org/jdk/pull/23658/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23658&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8349991 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/23658.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23658/head:pull/23658 PR: https://git.openjdk.org/jdk/pull/23658 From alanb at openjdk.org Mon Feb 17 08:31:15 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 17 Feb 2025 08:31:15 GMT Subject: RFR: 8350151: Support requires property to filer tests incompatible with --enable-preview In-Reply-To: References: Message-ID: <1iY92LjhRPbtuENrxBQlsCOKx2EHI6leLAfbkorEGzE=.e964726d-cf2c-4715-91fc-c76fc3e6668d@github.com> On Sat, 15 Feb 2025 19:43:39 GMT, Leonid Mesnik wrote: > It might be useful to be able to run testing with --enable-preview for feature development. The tests incompatible with this mode must be filtered out. > > I chose name 'java.enablePreview' , because it is more java property than vm or jdk. And 'enablePreview' to be similar with jtreg tag. > > Tested by running all test suites, and verifying that test is correctly selected. > There are more tests incompatible with --enable-preview, will mark them in the following bug. test/jdk/java/lang/System/SecurityManagerWarnings.java line 28: > 26: * @bug 8266459 8268349 8269543 8270380 > 27: * @summary check various warnings > 28: * @requires !java.enablePreview What it the reason that this. test failures with --enable-preview? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23653#discussion_r1957804120 From alanb at openjdk.org Mon Feb 17 09:58:10 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 17 Feb 2025 09:58:10 GMT Subject: RFR: 8349848: Support lint control of sunapi diagnostics In-Reply-To: <-FuJOJGuqnEWp6DseDoGMIf8JY8lTaK2_tVVf-o-1TY=.62b8d0eb-3398-49fd-a321-129c29817ff2@github.com> References: <-FuJOJGuqnEWp6DseDoGMIf8JY8lTaK2_tVVf-o-1TY=.62b8d0eb-3398-49fd-a321-129c29817ff2@github.com> Message-ID: On Fri, 14 Feb 2025 21:07:36 GMT, Archie Cobbs wrote: > This PR creates a new lint category `proprietary` that controls the mandatory warning "Foo is internal proprietary API and may be removed in a future release". > > This allows developers to suppress this warning using `-Xlint:-proprietary` and/or `@SuppressWarnings`. @archiecobbs I think it's a bit premature to create a PR for this as it sends a confusing message to developers about the future of these APIs. The APIs in the jdk.unsupported module, otherwise known as the "critical internal APIs" (see JEP 260), have no future. It's a feature that javac generates a warning that can't be suppressed with `@SuppressWarnings` when compiling code that uses classes in this module. The roadmap to remove these classes has now progressed to a warning at runtime (see JEP 498). A future JEP will remove the ability to suppress the warning at runtime. The long standing (undocumented) workaround to use `-XDignore.symbol.file` when compiling with `-Werror` requires a nose peg but I think we are stuck with it, and the status quo, until jdk.unsupported module is removed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23650#issuecomment-2662598684 From mcimadamore at openjdk.org Mon Feb 17 10:11:10 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 17 Feb 2025 10:11:10 GMT Subject: RFR: 8349848: Support lint control of sunapi diagnostics In-Reply-To: <-FuJOJGuqnEWp6DseDoGMIf8JY8lTaK2_tVVf-o-1TY=.62b8d0eb-3398-49fd-a321-129c29817ff2@github.com> References: <-FuJOJGuqnEWp6DseDoGMIf8JY8lTaK2_tVVf-o-1TY=.62b8d0eb-3398-49fd-a321-129c29817ff2@github.com> Message-ID: <629TKs4lgTK1HXwX6kL5Y8YI9Pp5QHjUUYUqvkGgWjc=.9de7853f-f6e6-46f8-80c3-ceb0d940f556@github.com> On Fri, 14 Feb 2025 21:07:36 GMT, Archie Cobbs wrote: > This PR creates a new lint category `proprietary` that controls the mandatory warning "Foo is internal proprietary API and may be removed in a future release". > > This allows developers to suppress this warning using `-Xlint:-proprietary` and/or `@SuppressWarnings`. Hi @archiecobbs, as @AlanBateman says, the use of critical internal API is discussed here: https://openjdk.org/jeps/260#Description While these APIs are still available under the _jdk specific_ `jdk.unsupported` module, their use is generally discouraged, as in most cases safe/better alternatives are available. The (hacky) way to suppress these warnings is there -- but raising that at the level of a supported `lint` warning is something that I'm not comfortable with. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23650#issuecomment-2662632397 From jlahoda at openjdk.org Mon Feb 17 12:59:22 2025 From: jlahoda at openjdk.org (Jan Lahoda) Date: Mon, 17 Feb 2025 12:59:22 GMT Subject: RFR: 8349848: Support lint control of sunapi diagnostics In-Reply-To: <-FuJOJGuqnEWp6DseDoGMIf8JY8lTaK2_tVVf-o-1TY=.62b8d0eb-3398-49fd-a321-129c29817ff2@github.com> References: <-FuJOJGuqnEWp6DseDoGMIf8JY8lTaK2_tVVf-o-1TY=.62b8d0eb-3398-49fd-a321-129c29817ff2@github.com> Message-ID: On Fri, 14 Feb 2025 21:07:36 GMT, Archie Cobbs wrote: > This PR creates a new lint category `proprietary` that controls the mandatory warning "Foo is internal proprietary API and may be removed in a future release". > > This allows developers to suppress this warning using `-Xlint:-proprietary` and/or `@SuppressWarnings`. +1 for not including this PR. I would prefer to not give the unsupported APIs, and handling of thereof, more attention than absolutely needed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23650#issuecomment-2663038202 From duke at openjdk.org Mon Feb 17 12:59:22 2025 From: duke at openjdk.org (Benoit Daloze) Date: Mon, 17 Feb 2025 12:59:22 GMT Subject: RFR: 8349848: Support lint control of sunapi diagnostics In-Reply-To: <-FuJOJGuqnEWp6DseDoGMIf8JY8lTaK2_tVVf-o-1TY=.62b8d0eb-3398-49fd-a321-129c29817ff2@github.com> References: <-FuJOJGuqnEWp6DseDoGMIf8JY8lTaK2_tVVf-o-1TY=.62b8d0eb-3398-49fd-a321-129c29817ff2@github.com> Message-ID: On Fri, 14 Feb 2025 21:07:36 GMT, Archie Cobbs wrote: > This PR creates a new lint category `proprietary` that controls the mandatory warning "Foo is internal proprietary API and may be removed in a future release". > > This allows developers to suppress this warning using `-Xlint:-proprietary` and/or `@SuppressWarnings`. Note this comes relates to https://bugs.openjdk.org/browse/JDK-8349056 and comes from https://bugs.openjdk.org/browse/JDK-8349058 So it's notably about sun.misc.Signal, which has no replacement available (https://bugs.openjdk.org/browse/JDK-8087286). Given the replies on that issue it may takes years until a replacement is available. JEP 498 only covers Unsafe. (BTW Unsafe already has separate deprecation & runtime warnings, the sun API warnings for Unsafe are at this point more noise & confusing than helpful.) > The APIs in the jdk.unsupported module, otherwise known as the "critical internal APIs" (see JEP 260), have no future. No future but no replacement planned yet seems contradictory to me. `-XDignore.symbol.file` is not a good workaround, it has many undesirable side effects besides suppressing the sun API warnings (e.g. not using the symbol file and so missing the code is using methods not available in the target JDK). It's also brittle as JDK-8331081 has been needed to be redone twice already due to this. I think this change makes a lot of sense, in fact every warning system should always have a way to suppress warnings, and if it has categories then every warning should fall into some category. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23650#issuecomment-2663044278 From acobbs at openjdk.org Mon Feb 17 17:07:26 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Mon, 17 Feb 2025 17:07:26 GMT Subject: RFR: 8349848: Support lint control of sunapi diagnostics In-Reply-To: References: <-FuJOJGuqnEWp6DseDoGMIf8JY8lTaK2_tVVf-o-1TY=.62b8d0eb-3398-49fd-a321-129c29817ff2@github.com> Message-ID: On Mon, 17 Feb 2025 09:55:31 GMT, Alan Bateman wrote: >> This PR creates a new lint category `proprietary` that controls the mandatory warning "Foo is internal proprietary API and may be removed in a future release". >> >> This allows developers to suppress this warning using `-Xlint:-proprietary` and/or `@SuppressWarnings`. > > @archiecobbs I think it's a bit premature to create a PR for this as it sends a confusing message to developers about the future of these APIs. The APIs in the jdk.unsupported module, otherwise known as the "critical internal APIs" (see JEP 260), have no future. It's a feature that javac generates a warning that can't be suppressed with `@SuppressWarnings` when compiling code that uses classes in this module. The roadmap to remove these classes has now progressed to a warning at runtime (see JEP 498). A future JEP will remove the ability to suppress the warning at runtime. The long standing (undocumented) workaround to use `-XDignore.symbol.file` when compiling with `-Werror` requires a nose peg but I think we are stuck with it, and the status quo, until jdk.unsupported module is removed. @AlanBateman @lahodaj @mcimadamore , Thanks for your comments. Sounds like this idea isn't very popular :) I feel that before throwing in the towel on this one and in the interest of due diligence I should do my best to provide my rationale on the other side of the coin and if that doesn't persuade you (which it probably won't) then I'm happy to drop it. First, let's not conflate the existence of a technical mechanism with specific policy goals about specific API's. I'm in complete agreement with JEP 260 and the steps & timeline for deprecating then removing these dangerous APIs. This PR is simply providing a technical mechanism for people to manage their compilations - is that really such a bad thing? The existence of this mechanism doesn't imply any opinion about the wisdom of relying on deprecated API's. The default behavior is always going to be a mandatory warning - great! To suppress the warning, a developer has to make a deliberate choice. By way of analogy, consider how the deprecation and removal of old API's has a symmetry with the addition and preview of new API's. In both cases, there is a three-step process. For the removal of API's: 1. Fully Available 2. Available but Deprecated 3. Removed For the addition of API's: 1. Not Available (does not exist yet) 2. Available as Preview 3. Fully Available In both cases, Step 2 serves as a transition period where, without special compiler flags, a mandatory warning or compiler error is generated. The point is to say "You are being officially warned that this feature is in transition". Now why do we allow suppressing the mandatory preview error/warning, even though the feature being relied upon has a non-trivial chance of disappearing (string templates, anyone?). Because when a developer adds those flags they are saying "I am explicitly acknowledging and accepting this risk, now stop bothering me". We're in the same situation with critical API's - the status of the feature is tenuous, so by default they get the warning. If they then choose to suppress it with `-Xlint:-proprietary` they are saying "I am explicitly acknowledging and accepting this risk, now stop bothering me". Let's not patronize developers. They are capable of understanding the risks and trade-offs. Anyway, practically speaking, if you believe that the verbosity of a warning is what determines whether a developer chooses to rely on `Unsafe` or not, you are kidding yourself. People use `Unsafe` because it gets the job done, warnings be damned, so they can deal with higher priority stuff. When it eventually disappears, they'll deal with it however they have to; you don't need to worry about their being surprised. They will have been sufficiently warned - which is the whole point here, isn't it? ------------- PR Comment: https://git.openjdk.org/jdk/pull/23650#issuecomment-2663674687 From mcimadamore at openjdk.org Mon Feb 17 17:17:09 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 17 Feb 2025 17:17:09 GMT Subject: RFR: 8349754: Invalid "early reference" error when class extends an outer class [v2] In-Reply-To: References: <7a1rGVyW2gzIC-RqyhZtlPARXlAgjCn9Vem8wUJMzs0=.df5151dc-8cc0-449d-bea6-8c2df52f77b6@github.com> Message-ID: On Fri, 14 Feb 2025 23:34:53 GMT, Archie Cobbs wrote: >>> So... N.this is always used to denote an enclosing instance... >> >> I think that's not always true... for example, this compiles just fine (with or without the explicit `super()`): >> >> class Myself { >> int x; >> Myself() { >> Myself.this.x = 42; >> super(); >> } >> } > > Hmm, re-reading that I think maybe I misinterpreted your statement... For clarity, let's just enumerate the possibilities. > > Suppose we are inside a class `C` and there is some instance field `x` accessible to us. > > Then any such `x` must be declared in one (_or both_) of these two "hierarchies": > * **Inner hierarchy** - `x` is declared in `C` or (non-privately) in a superclass of `C` > * **Outer hierarchy** - `x` is declared in a some outer class `O` containing `C` > > In the case `x` is declared in both hierarchies, it may _also_ be the case that `O` is a superclass of `C`, but for our purposes that's "just a coincidence" - it doesn't affect how many `x` field's are accessible to us (i.e., two). > > Now what can the various expressions mean depending on which of the two hierarchies `x` is declared in? > > | Inner? | Outer? | `C` extends `O` | `x` | `C.this.x` | `O.this.x` | Comments | > | :---: | :---: | :---: | :---: | :---: | :---: | :--- | > | Yes | No | N/A | Inner | Inner | _N/A_ | Simple inner case | > | No | Yes | No | Outer | _N/A_ | Outer | Simple outer case | > | No | Yes | Yes | Outer | _N/A_ | Outer | `x` must be private | | > | Yes | Yes | No | Inner | Inner | Outer | | > | Yes | Yes | Yes | Inner | Inner | Outer | | > > So it looks like we can say this about an (presumably valid) expression of the form `N.this.x`: > * If `N` = `C`, then we are always referring to the "inner" `x` - therefore, it's an early reference to `C` if and only if we are in an early construction context for `C` > * If `N` ? `C`, then we are always referring to the "outer" `x` - therefore, an early reference if and only if we are in an early construction context for `N` > > So according to that logic, you are correct in saying, with regards to expressions like `N.this.x`, that "the only thing that matters is whether `N` is in early construction context". > > Please check my work... Yes, the spec is clear in saying: > A class or interface O is the zeroth lexically enclosing class or interface declaration of itself. And > Let n be an integer such that TypeName denotes the n'th lexically enclosing class or interface declaration of the class or interface whose declaration immediately encloses the qualified this expression. The value of a qualified this expression TypeName.this is the n'th lexically enclosing instance of this. So, if we are inside N and we see N.this, we have to assume it's the 0-th enclosing instance we're talking about (e.g. the class being declared). Your table looks correct - when you say `x must be private`, I'd add that this is true only for the implicit case where access is just `x`. E.g. if `x` is not inherited, then it's resolved to the Outer, otherwise it's resolved to the class being declared (which might create early construction issues). This situation is not dissimilar from the one we have encountered here: https://git.openjdk.org/jdk/pull/19904 Where my initial prototype was "skipping" over early references if non-early enclosing references were available. While in that case it was deemed too subtle (for good reasons), I think in this case we're bound by the existing meaning of `x` -- which depends on whether `x` is, or is not a member of the current class. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23545#discussion_r1958571432 From mcimadamore at openjdk.org Mon Feb 17 17:20:09 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 17 Feb 2025 17:20:09 GMT Subject: RFR: 8349848: Support lint control of sunapi diagnostics In-Reply-To: <-FuJOJGuqnEWp6DseDoGMIf8JY8lTaK2_tVVf-o-1TY=.62b8d0eb-3398-49fd-a321-129c29817ff2@github.com> References: <-FuJOJGuqnEWp6DseDoGMIf8JY8lTaK2_tVVf-o-1TY=.62b8d0eb-3398-49fd-a321-129c29817ff2@github.com> Message-ID: On Fri, 14 Feb 2025 21:07:36 GMT, Archie Cobbs wrote: > This PR creates a new lint category `proprietary` that controls the mandatory warning "Foo is internal proprietary API and may be removed in a future release". > > This allows developers to suppress this warning using `-Xlint:-proprietary` and/or `@SuppressWarnings`. Meta comment. The discussion you are bringing up, while completely valid, is completely out of scope for a PR. We have relevant mailing lists where to discuss issues like these (compiler-dev, jigsaw-dev, corelibs-dev to name a few). Having a far-reaching policy change discussion "hidden" inside a PR is a bug, not a feature :-) ------------- PR Comment: https://git.openjdk.org/jdk/pull/23650#issuecomment-2663708887 From acobbs at openjdk.org Mon Feb 17 17:49:10 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Mon, 17 Feb 2025 17:49:10 GMT Subject: RFR: 8349848: Support lint control of sunapi diagnostics In-Reply-To: References: <-FuJOJGuqnEWp6DseDoGMIf8JY8lTaK2_tVVf-o-1TY=.62b8d0eb-3398-49fd-a321-129c29817ff2@github.com> Message-ID: On Mon, 17 Feb 2025 17:18:00 GMT, Maurizio Cimadamore wrote: > Meta comment. The discussion you are bringing up, while completely valid, is completely out of scope for a PR. We have relevant mailing lists where to discuss issues like these (compiler-dev, jigsaw-dev, corelibs-dev to name a few). Having a far-reaching policy change discussion "hidden" inside a PR is a bug, not a feature :-) That's a completely fair point - if you believe the current behavior was the result of an explicit policy choice. I didn't think it was - it seemed to me to be a simple technical oversight - but that's probably because I'm oblivious to the full history & background. OK I'll close this in a day or two unless some new/different groundswell of opinion emerges. Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23650#issuecomment-2663778631 From acobbs at openjdk.org Mon Feb 17 19:11:10 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Mon, 17 Feb 2025 19:11:10 GMT Subject: RFR: 8349754: Invalid "early reference" error when class extends an outer class [v2] In-Reply-To: References: <7a1rGVyW2gzIC-RqyhZtlPARXlAgjCn9Vem8wUJMzs0=.df5151dc-8cc0-449d-bea6-8c2df52f77b6@github.com> Message-ID: On Mon, 17 Feb 2025 17:14:10 GMT, Maurizio Cimadamore wrote: >> Hmm, re-reading that I think maybe I misinterpreted your statement... For clarity, let's just enumerate the possibilities. >> >> Suppose we are inside a class `C` and there is some instance field `x` accessible to us. >> >> Then any such `x` must be declared in one (_or both_) of these two "hierarchies": >> * **Inner hierarchy** - `x` is declared in `C` or (non-privately) in a superclass of `C` >> * **Outer hierarchy** - `x` is declared in a some outer class `O` containing `C` >> >> In the case `x` is declared in both hierarchies, it may _also_ be the case that `O` is a superclass of `C`, but for our purposes that's "just a coincidence" - it doesn't affect how many `x` field's are accessible to us (i.e., two). >> >> Now what can the various expressions mean depending on which of the two hierarchies `x` is declared in? >> >> | Inner? | Outer? | `C` extends `O` | `x` | `C.this.x` | `O.this.x` | Comments | >> | :---: | :---: | :---: | :---: | :---: | :---: | :--- | >> | Yes | No | N/A | Inner | Inner | _N/A_ | Simple inner case | >> | No | Yes | No | Outer | _N/A_ | Outer | Simple outer case | >> | No | Yes | Yes | Outer | _N/A_ | Outer | `x` must be private | | >> | Yes | Yes | No | Inner | Inner | Outer | | >> | Yes | Yes | Yes | Inner | Inner | Outer | | >> >> So it looks like we can say this about an (presumably valid) expression of the form `N.this.x`: >> * If `N` = `C`, then we are always referring to the "inner" `x` - therefore, it's an early reference to `C` if and only if we are in an early construction context for `C` >> * If `N` ? `C`, then we are always referring to the "outer" `x` - therefore, an early reference if and only if we are in an early construction context for `N` >> >> So according to that logic, you are correct in saying, with regards to expressions like `N.this.x`, that "the only thing that matters is whether `N` is in early construction context". >> >> Please check my work... > > Yes, the spec is clear in saying: > >> A class or interface O is the zeroth lexically enclosing class or interface declaration of itself. > > And > >> Let n be an integer such that TypeName denotes the n'th lexically enclosing class or interface declaration of the class or interface whose declaration immediately encloses the qualified this expression. The value of a qualified this expression TypeName.this is the n'th lexically enclosing instance of this. > > So, if we are inside N and we see N.this, we have to assume it's the 0-th enclosing instance we're talking about (e.g. the class being declared). > > Your table looks correct - when you say `x must be private`, I'd add that this is true only for the implicit case where access is just `x`. E.g. if `x` is not inherited, then it's resolved to the Outer, otherwise it's resolved to the class being declared (which might create early construction issues). > > This situation is not dissimilar from the one we have encountered here: > > https://git.openjdk.org/jdk/pull/19904 > > Where my initial prototype was "skipping" over early references if non-early enclosing references were available. While in that case it was deemed too subtle (for good reasons), I think in this case we're bound by the existing meaning of `x` -- which depends on whether `x` is, or is not a member of the current class. OK thanks. In all the discussion I've lost track of what needs to actually change here. Is there a further simplification of `Resolve.isEarlyReference()` possible? You previously said: > I guess in terms of code, what this means is that I'm surprised that we're handling the implicit and explicit cases in the same test. E.g. when using a qualified `X.this`, the membership check seems irrelevant (the only thing that matters is whether `X` is in early construction context). But this method is testing whether the variable reference is an early reference for the current class, not just whatever class it's a member of... so isn't the membership test appropriate? Having said that, there's probably some refactoring of these checks that would make more sense. `Resolve.isEarlyReference()` is probably being invoked from too many places. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23545#discussion_r1958693623 From acobbs at openjdk.org Tue Feb 18 02:44:39 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Tue, 18 Feb 2025 02:44:39 GMT Subject: RFR: 8350212: Track source end positions of declarations that support @SuppressWarnings Message-ID: This PR is a sub-task split off from [JDK-8224228](https://bugs.openjdk.org/browse/JDK-8224228), which seeks to add `@SuppressWarnings` support for lexical features. Lexical features don't know about classes, members or symbols, so their source file positions must be matched to the source file character offset range of the innermost containing `JCModuleDecl`, `JCPackageDecl`, `JCClassDecl`, `JCMethodDecl`, or `JCVariableDecl`. That means we need the end positions of all such declarations to be available. The parser doesn't normally store lexical end positions unless explicitly requested, and we don't want to mandate it for performance reasons. Instead, we can just add an `int endPos` field to these five AST nodes. This field can be populated as part of the normal parsing of these node types, which already supports the (optional) tracking of end positions. ------------- Commit messages: - Track source end positions of declarations that support @SuppressWarnings. Changes: https://git.openjdk.org/jdk/pull/23669/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23669&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8350212 Stats: 212 lines in 5 files changed: 189 ins; 2 del; 21 mod Patch: https://git.openjdk.org/jdk/pull/23669.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23669/head:pull/23669 PR: https://git.openjdk.org/jdk/pull/23669 From acobbs at openjdk.org Tue Feb 18 03:46:52 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Tue, 18 Feb 2025 03:46:52 GMT Subject: RFR: 8350212: Track source end positions of declarations that support @SuppressWarnings [v2] In-Reply-To: References: Message-ID: > This PR is a sub-task split off from [JDK-8224228](https://bugs.openjdk.org/browse/JDK-8224228), which seeks to add `@SuppressWarnings` support for lexical features. > > Lexical features don't know about classes, members or symbols, so their source file positions must be matched to the source file character offset range of the innermost containing `JCModuleDecl`, `JCPackageDecl`, `JCClassDecl`, `JCMethodDecl`, or `JCVariableDecl`. That means we need the end positions of all such declarations to be available. > > The parser doesn't normally store lexical end positions unless explicitly requested, and we don't want to mandate it for performance reasons. > > Instead, we can just add an `int endPos` field to these five AST nodes. This field can be populated as part of the normal parsing of these node types, which already supports the (optional) tracking of end positions. Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision: Add end position for variables coming from variableDeclaratorId(). ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23669/files - new: https://git.openjdk.org/jdk/pull/23669/files/4fcc6126..e2352287 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23669&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23669&range=00-01 Stats: 20 lines in 2 files changed: 8 ins; 8 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/23669.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23669/head:pull/23669 PR: https://git.openjdk.org/jdk/pull/23669 From acobbs at openjdk.org Tue Feb 18 03:57:41 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Tue, 18 Feb 2025 03:57:41 GMT Subject: RFR: 8224228: No way to locally suppress lint warnings in parser/tokenizer or preview features [v12] In-Reply-To: References: Message-ID: > This PR updates the `DeferredLintHandler` so that deferred warnings can be registered during parsing, before any `JCTree` nodes have been created, and it uses this new capability to update the `"preview"` and `"text-blocks"` Lint warnings so that they can be suppressed via `@SuppressWarnings` annotations. More details are provided in additional comments. > > Note: This PR depends on (i.e., includes and extends) these other "cleanup" PR's: > * #23167 > * #23281 > * #23400 > * #23669 Archie Cobbs has updated the pull request incrementally with four additional commits since the last revision: - Remove unneeded end position tracking. - Merge branch 'JDK-8350212' (end positions sub-task) into JDK-8224228. - Add end position for variables coming from variableDeclaratorId(). - Track source end positions of declarations that support @SuppressWarnings. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23237/files - new: https://git.openjdk.org/jdk/pull/23237/files/65577822..8ac827ce Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23237&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23237&range=10-11 Stats: 161 lines in 3 files changed: 140 ins; 4 del; 17 mod Patch: https://git.openjdk.org/jdk/pull/23237.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23237/head:pull/23237 PR: https://git.openjdk.org/jdk/pull/23237 From hannesw at openjdk.org Tue Feb 18 19:22:07 2025 From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Tue, 18 Feb 2025 19:22:07 GMT Subject: RFR: 8350007: Add usage message to the javadoc executable [v2] In-Reply-To: References: Message-ID: On Fri, 14 Feb 2025 11:50:27 GMT, Nizar Benalla wrote: >> This patch adds a new message when you run the `javadoc` executable with any arguments. >> Currently, unlike most other tools, running `javadoc` without any arguments does not show you how to use the tool or point you to use the `--help` option, this can be improved. >> >> Before change: >> >> W $ ./javadoc >> error: No modules, packages or classes specified. >> 1 error >> >> >> After change: >> >> W $ ./javadoc >> Usage: >> javadoc [options] [packagenames] [sourcefiles] [@files] >> For additional help on usage: javadoc --help > > Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision: > > update test with new usage message src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/resources/javadoc.properties line 39: > 37: main.no-arg=Usage:\n\ > 38: \ javadoc [options] [packagenames] [sourcefiles] [@files]\n\ > 39: For additional help on usage: javadoc --help Maybe call the property `main.usage.short` to tie it to the main usage message above and make it clear they should be kept in sync? The extra whitespace in the second line looks unmotivated. Could we use the existing `main.for-more-details-see-usage` message below instead of the second line? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23618#discussion_r1959974402 From kvn at openjdk.org Wed Feb 19 03:17:54 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 19 Feb 2025 03:17:54 GMT Subject: RFR: 8350287: Cleanup SA's support for CodeBlob subclasses In-Reply-To: References: Message-ID: On Wed, 19 Feb 2025 02:08:28 GMT, Chris Plummer wrote: > Basically for these 3 CodeBlob types getName() will no longer include the CodeBlob type. I think this is fine: output is informative enough to figure out type of blob. Please check SA tests if they look for old output. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23684#issuecomment-2667409688 From kvn at openjdk.org Wed Feb 19 03:25:52 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 19 Feb 2025 03:25:52 GMT Subject: RFR: 8350287: Cleanup SA's support for CodeBlob subclasses In-Reply-To: References: Message-ID: On Wed, 19 Feb 2025 02:08:28 GMT, Chris Plummer wrote: > There is a lot of subclassing of CodeBlob types done in SA to mimic hotspot, but most of it is unnecessary. The generic CodeBlob class can handle all support needed by most of the subclasses. The only subclasses we need to keep around around NMethod, RuntimeStub, and UpcallStub, since they all have special support in SA. I also kept around RuntimeBlob so RuntimeStub can continue to inherit from it and be consistent with hotspot, but it's not actually necessary, and I'm more than happy to remove it also. > > I also cleaned up the PStack support for CodeBlobs. It can just use CodeBlob.getName() rather than trying to figure out the type of the CodeBlob instance to print out type name. This allows us to get rid of most isXXX() APIs. It also provides more useful output in some cases. > > There is some minor loss of functionality in some of the CodeBlob subtypes I removed. For example this is what AdapterBlob.getName() looked like (it is now gone): > > > public String getName() { > return "AdapterBlob: " + super.getName(); > } > > > So now we just use the default CodeBlob.getName(), which is what super.getName() would up execute. I think for AdapterBlob this always returns "I2C/C2I adapters", so now you only get this rather than "AdapterBlob: I2C/C2I adapters". We have a similar loss of getName() detail with MethodHandlesAdapterBlob (now returns "MethodHandles adapters") and VtableBlob (now returns "vtable chunks"). Basically for these 3 CodeBlob types getName() will no longer include the CodeBlob type. I could special case them in CodeBlob.getName() by fetching the kind to determine what the proper name should be. Let me know if you think it is worth it. src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/RuntimeStub.java line 47: > 45: private static void initialize(TypeDataBase db) { > 46: Type type = db.lookupType("RuntimeStub"); > 47: callerMustGCArgumentsField = type.getCIntegerField("_caller_must_gc_arguments"); This field is in `CodeBlob` since JDK 23 [JDK-8329433](https://bugs.openjdk.org/browse/JDK-8329433) https://github.com/openjdk/jdk/blob/master/src/hotspot/share/code/codeBlob.hpp#L126 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23684#discussion_r1960893284 From cjplummer at openjdk.org Wed Feb 19 04:34:53 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 19 Feb 2025 04:34:53 GMT Subject: RFR: 8350287: Cleanup SA's support for CodeBlob subclasses In-Reply-To: References: Message-ID: On Wed, 19 Feb 2025 03:14:49 GMT, Vladimir Kozlov wrote: > > Basically for these 3 CodeBlob types getName() will no longer include the CodeBlob type. > > I think this is fine: output is informative enough to figure out type of blob. Please check SA tests if they look for old output. The tests are all passing. > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/RuntimeStub.java line 47: > >> 45: private static void initialize(TypeDataBase db) { >> 46: Type type = db.lookupType("RuntimeStub"); >> 47: callerMustGCArgumentsField = type.getCIntegerField("_caller_must_gc_arguments"); > > This field is in `CodeBlob` since JDK 23 [JDK-8329433](https://bugs.openjdk.org/browse/JDK-8329433) https://github.com/openjdk/jdk/blob/master/src/hotspot/share/code/codeBlob.hpp#L126 Ah, right. I forgot you had mentioned that. I think that means I can rid of RuntimeStub and RuntimeBlob once this code is moved to CodeBlob. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23684#issuecomment-2667484513 PR Review Comment: https://git.openjdk.org/jdk/pull/23684#discussion_r1960935263 From cjplummer at openjdk.org Wed Feb 19 05:49:56 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 19 Feb 2025 05:49:56 GMT Subject: RFR: 8350287: Cleanup SA's support for CodeBlob subclasses [v2] In-Reply-To: References: Message-ID: > There is a lot of subclassing of CodeBlob types done in SA to mimic hotspot, but most of it is unnecessary. The generic CodeBlob class can handle all support needed by most of the subclasses. The only subclasses we need to keep around around NMethod, RuntimeStub, and UpcallStub, since they all have special support in SA. I also kept around RuntimeBlob so RuntimeStub can continue to inherit from it and be consistent with hotspot, but it's not actually necessary, and I'm more than happy to remove it also. > > I also cleaned up the PStack support for CodeBlobs. It can just use CodeBlob.getName() rather than trying to figure out the type of the CodeBlob instance to print out type name. This allows us to get rid of most isXXX() APIs. It also provides more useful output in some cases. > > There is some minor loss of functionality in some of the CodeBlob subtypes I removed. For example this is what AdapterBlob.getName() looked like (it is now gone): > > > public String getName() { > return "AdapterBlob: " + super.getName(); > } > > > So now we just use the default CodeBlob.getName(), which is what super.getName() would up execute. I think for AdapterBlob this always returns "I2C/C2I adapters", so now you only get this rather than "AdapterBlob: I2C/C2I adapters". We have a similar loss of getName() detail with MethodHandlesAdapterBlob (now returns "MethodHandles adapters") and VtableBlob (now returns "vtable chunks"). Basically for these 3 CodeBlob types getName() will no longer include the CodeBlob type. I could special case them in CodeBlob.getName() by fetching the kind to determine what the proper name should be. Let me know if you think it is worth it. Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: Minor improvements. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23684/files - new: https://git.openjdk.org/jdk/pull/23684/files/138fed50..e965c310 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23684&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23684&range=00-01 Stats: 110 lines in 4 files changed: 4 ins; 104 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/23684.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23684/head:pull/23684 PR: https://git.openjdk.org/jdk/pull/23684 From cjplummer at openjdk.org Wed Feb 19 06:26:53 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 19 Feb 2025 06:26:53 GMT Subject: RFR: 8350287: Cleanup SA's support for CodeBlob subclasses [v2] In-Reply-To: References: Message-ID: On Wed, 19 Feb 2025 04:31:11 GMT, Chris Plummer wrote: >> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/RuntimeStub.java line 47: >> >>> 45: private static void initialize(TypeDataBase db) { >>> 46: Type type = db.lookupType("RuntimeStub"); >>> 47: callerMustGCArgumentsField = type.getCIntegerField("_caller_must_gc_arguments"); >> >> This field is in `CodeBlob` since JDK 23 [JDK-8329433](https://bugs.openjdk.org/browse/JDK-8329433) https://github.com/openjdk/jdk/blob/master/src/hotspot/share/code/codeBlob.hpp#L126 > > Ah, right. I forgot you had mentioned that. I think that means I can rid of RuntimeStub and RuntimeBlob once this code is moved to CodeBlob. Ready for another review. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23684#discussion_r1961019487 From acobbs at openjdk.org Wed Feb 19 15:44:30 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Wed, 19 Feb 2025 15:44:30 GMT Subject: RFR: 8329951: `var` emits deprecation warnings that do not point to the file or position Message-ID: This PR fixes a bug that causes certain warnings to be emitted without source file location information. Consider this example: import java.util.*; import java.util.function.*; public class Example { @SuppressWarnings("deprecation") List m1() { return null; } void m2() { for (var o : m1()) { } } } the compiler outputs this: $ javac -Xlint:deprecation Example.java warning: [deprecation] Observable in java.util has been deprecated 1 warning but it should instead output this: Example.java:9: warning: [deprecation] Observable in java.util has been deprecated for (var o : m1()) { } ^ 1 warning The bug happens because the "synthetic" type that is installed dynamically for implicitly typed variables is not given a source code position. This makes some sense (?) because that type doesn't literally appear in the variable declaration; however, certain error messages expect to be able to point to the type portion of a variable declaration, so it also causes this bug (and presumably similar variants). To fix this, we just copy the position of the variable declaration itself to the synthetic type. However, this change necessitated another change: The fix for [JDK-8200199](https://bugs.openjdk.org/browse/JDK-8200199) added back in 2018 relies on the fact that the position of an implicitly typed variable is always null, so this change breaks that fix. But since then, a new method `JCVariableDecl.declaredUsingVar()` was added, so we can just use that test instead. This also makes the code a little clearer. ------------- Commit messages: - Fix bug where some warnings didn't have a source file position. Changes: https://git.openjdk.org/jdk/pull/23683/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23683&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8329951 Stats: 33 lines in 4 files changed: 30 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/23683.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23683/head:pull/23683 PR: https://git.openjdk.org/jdk/pull/23683 From kvn at openjdk.org Wed Feb 19 15:50:53 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 19 Feb 2025 15:50:53 GMT Subject: RFR: 8350287: Cleanup SA's support for CodeBlob subclasses [v2] In-Reply-To: References: Message-ID: On Wed, 19 Feb 2025 05:49:56 GMT, Chris Plummer wrote: >> There is a lot of subclassing of CodeBlob types done in SA to mimic hotspot, but most of it is unnecessary. The generic CodeBlob class can handle all support needed by most of the subclasses. The only subclasses we need to keep around around NMethod, RuntimeStub, and UpcallStub, since they all have special support in SA. I also kept around RuntimeBlob so RuntimeStub can continue to inherit from it and be consistent with hotspot, but it's not actually necessary, and I'm more than happy to remove it also. >> >> I also cleaned up the PStack support for CodeBlobs. It can just use CodeBlob.getName() rather than trying to figure out the type of the CodeBlob instance to print out type name. This allows us to get rid of most isXXX() APIs. It also provides more useful output in some cases. >> >> There is some minor loss of functionality in some of the CodeBlob subtypes I removed. For example this is what AdapterBlob.getName() looked like (it is now gone): >> >> >> public String getName() { >> return "AdapterBlob: " + super.getName(); >> } >> >> >> So now we just use the default CodeBlob.getName(), which is what super.getName() would up execute. I think for AdapterBlob this always returns "I2C/C2I adapters", so now you only get this rather than "AdapterBlob: I2C/C2I adapters". We have a similar loss of getName() detail with MethodHandlesAdapterBlob (now returns "MethodHandles adapters") and VtableBlob (now returns "vtable chunks"). Basically for these 3 CodeBlob types getName() will no longer include the CodeBlob type. I could special case them in CodeBlob.getName() by fetching the kind to determine what the proper name should be. Let me know if you think it is worth it. > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > Minor improvements. LGTM ------------- Marked as reviewed by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23684#pullrequestreview-2627250925 From lmesnik at openjdk.org Wed Feb 19 17:49:57 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 19 Feb 2025 17:49:57 GMT Subject: RFR: 8350151: Support requires property to filter tests incompatible with --enable-preview [v2] In-Reply-To: References: Message-ID: > It might be useful to be able to run testing with --enable-preview for feature development. The tests incompatible with this mode must be filtered out. > > I chose name 'java.enablePreview' , because it is more java property than vm or jdk. And 'enablePreview' to be similar with jtreg tag. > > Tested by running all test suites, and verifying that test is correctly selected. > There are more tests incompatible with --enable-preview, will mark them in the following bug. Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: change other test to exclude ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23653/files - new: https://git.openjdk.org/jdk/pull/23653/files/fafdff14..8019bec1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23653&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23653&range=00-01 Stats: 4 lines in 2 files changed: 1 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/23653.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23653/head:pull/23653 PR: https://git.openjdk.org/jdk/pull/23653 From lmesnik at openjdk.org Wed Feb 19 17:49:58 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 19 Feb 2025 17:49:58 GMT Subject: RFR: 8350151: Support requires property to filter tests incompatible with --enable-preview [v2] In-Reply-To: <1iY92LjhRPbtuENrxBQlsCOKx2EHI6leLAfbkorEGzE=.e964726d-cf2c-4715-91fc-c76fc3e6668d@github.com> References: <1iY92LjhRPbtuENrxBQlsCOKx2EHI6leLAfbkorEGzE=.e964726d-cf2c-4715-91fc-c76fc3e6668d@github.com> Message-ID: On Mon, 17 Feb 2025 08:28:05 GMT, Alan Bateman wrote: >> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: >> >> change other test to exclude > > test/jdk/java/lang/System/SecurityManagerWarnings.java line 28: > >> 26: * @bug 8266459 8268349 8269543 8270380 >> 27: * @summary check various warnings >> 28: * @requires !java.enablePreview > > What is the reason that this test fails with --enable-preview? Ough, this test puzzled me. It fails with --enable-preview. However, I think I need more time to investigate the issue. So I update PR to exclude test that explicitly says that it shouldn't be executed with --enable-preview. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23653#discussion_r1962116805 From rriggs at openjdk.org Wed Feb 19 19:39:53 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 19 Feb 2025 19:39:53 GMT Subject: RFR: 8350151: Support requires property to filter tests incompatible with --enable-preview [v2] In-Reply-To: References: <1iY92LjhRPbtuENrxBQlsCOKx2EHI6leLAfbkorEGzE=.e964726d-cf2c-4715-91fc-c76fc3e6668d@github.com> Message-ID: On Wed, 19 Feb 2025 17:43:10 GMT, Leonid Mesnik wrote: >> test/jdk/java/lang/System/SecurityManagerWarnings.java line 28: >> >>> 26: * @bug 8266459 8268349 8269543 8270380 >>> 27: * @summary check various warnings >>> 28: * @requires !java.enablePreview >> >> What is the reason that this test fails with --enable-preview? > > Ough, this test puzzled me. It fails with --enable-preview. However, I think I need more time to investigate the issue. So I update PR to exclude test that explicitly says that it shouldn't be executed with --enable-preview. It ran ok for me, once I got the command line flags correct. It ran ok if I added `@enablePreview`. It also ran ok with an explicit @run command: (it does not currently have an @run command). * @run main/othervm --enable-preview SecurityManagerWarnings ``` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23653#discussion_r1962264733 From alanb at openjdk.org Wed Feb 19 19:45:53 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 19 Feb 2025 19:45:53 GMT Subject: RFR: 8350151: Support requires property to filter tests incompatible with --enable-preview [v2] In-Reply-To: References: Message-ID: On Wed, 19 Feb 2025 17:49:57 GMT, Leonid Mesnik wrote: >> It might be useful to be able to run testing with --enable-preview for feature development. The tests incompatible with this mode must be filtered out. >> >> I chose name 'java.enablePreview' , because it is more java property than vm or jdk. And 'enablePreview' to be similar with jtreg tag. >> >> Tested by running all test suites, and verifying that test is correctly selected. >> There are more tests incompatible with --enable-preview, will mark them in the following bug. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > change other test to exclude Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23653#pullrequestreview-2627805876 From lmesnik at openjdk.org Wed Feb 19 20:35:53 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 19 Feb 2025 20:35:53 GMT Subject: RFR: 8350151: Support requires property to filter tests incompatible with --enable-preview [v2] In-Reply-To: References: <1iY92LjhRPbtuENrxBQlsCOKx2EHI6leLAfbkorEGzE=.e964726d-cf2c-4715-91fc-c76fc3e6668d@github.com> Message-ID: On Wed, 19 Feb 2025 19:36:59 GMT, Roger Riggs wrote: >> Ough, this test puzzled me. It fails with --enable-preview. However, I think I need more time to investigate the issue. So I update PR to exclude test that explicitly says that it shouldn't be executed with --enable-preview. > > It ran ok for me, once I got the command line flags correct. > It ran ok if I added `@enablePreview`. > > It also ran ok with an explicit @run command: (it does not currently have an @run command). > > * @run main/othervm --enable-preview SecurityManagerWarnings > ``` For me it fails with ----------System.err:(18/917)---------- stdout: []; stderr: [Error: Unable to initialize main class SecurityManagerWarnings Caused by: java.lang.NoClassDefFoundError: jdk/test/lib/process/OutputAnalyzer ] exitValue = 1 that seems pretty strange, might be test library issue? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23653#discussion_r1962334975 From rriggs at openjdk.org Thu Feb 20 15:16:56 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 20 Feb 2025 15:16:56 GMT Subject: RFR: 8350151: Support requires property to filter tests incompatible with --enable-preview [v2] In-Reply-To: References: <1iY92LjhRPbtuENrxBQlsCOKx2EHI6leLAfbkorEGzE=.e964726d-cf2c-4715-91fc-c76fc3e6668d@github.com> Message-ID: On Wed, 19 Feb 2025 20:32:56 GMT, Leonid Mesnik wrote: >> It ran ok for me, once I got the command line flags correct. >> It ran ok if I added `@enablePreview`. >> >> It also ran ok with an explicit @run command: (it does not currently have an @run command). >> >> * @run main/othervm --enable-preview SecurityManagerWarnings >> ``` > > For me it fails with > ----------System.err:(18/917)---------- > stdout: []; > stderr: [Error: Unable to initialize main class SecurityManagerWarnings > Caused by: java.lang.NoClassDefFoundError: jdk/test/lib/process/OutputAnalyzer > ] > exitValue = 1 > that seems pretty strange, might be test library issue? I haven't been able to reproduce that locally. Even with mis-matched compilation of the test library and test code. I noticed the NoClassDefFoundError message comes from the child process. The child is invoked with test.noclasspath=true and no path to the test library. (intentionally) The SecurityManagerWarning class explicitly refers to OutputAnalyzer. There might be a path in which the new VM tries to load the OutputAnalyzer (and throw an error) Finding a way to reproduce locally might be necessary to track down the cause. Perhaps adding -Xlog (for the child) might provider more information about the sequence of events. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23653#discussion_r1963767231 From rriggs at openjdk.org Thu Feb 20 15:20:52 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 20 Feb 2025 15:20:52 GMT Subject: RFR: 8350151: Support requires property to filter tests incompatible with --enable-preview [v2] In-Reply-To: References: Message-ID: On Wed, 19 Feb 2025 17:49:57 GMT, Leonid Mesnik wrote: >> It might be useful to be able to run testing with --enable-preview for feature development. The tests incompatible with this mode must be filtered out. >> >> I chose name 'java.enablePreview' , because it is more java property than vm or jdk. And 'enablePreview' to be similar with jtreg tag. >> >> Tested by running all test suites, and verifying that test is correctly selected. >> There are more tests incompatible with --enable-preview, will mark them in the following bug. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > change other test to exclude Marked as reviewed by rriggs (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23653#pullrequestreview-2630226768 From rriggs at openjdk.org Thu Feb 20 15:20:53 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 20 Feb 2025 15:20:53 GMT Subject: RFR: 8350151: Support requires property to filter tests incompatible with --enable-preview [v2] In-Reply-To: References: <1iY92LjhRPbtuENrxBQlsCOKx2EHI6leLAfbkorEGzE=.e964726d-cf2c-4715-91fc-c76fc3e6668d@github.com> Message-ID: On Thu, 20 Feb 2025 15:13:47 GMT, Roger Riggs wrote: >> For me it fails with >> ----------System.err:(18/917)---------- >> stdout: []; >> stderr: [Error: Unable to initialize main class SecurityManagerWarnings >> Caused by: java.lang.NoClassDefFoundError: jdk/test/lib/process/OutputAnalyzer >> ] >> exitValue = 1 >> that seems pretty strange, might be test library issue? > > I haven't been able to reproduce that locally. Even with mis-matched compilation of the test library and test code. > > I noticed the NoClassDefFoundError message comes from the child process. > The child is invoked with test.noclasspath=true and no path to the test library. (intentionally) > The SecurityManagerWarning class explicitly refers to OutputAnalyzer. > There might be a path in which the new VM tries to load the OutputAnalyzer (and throw an error) > > Finding a way to reproduce locally might be necessary to track down the cause. > Perhaps adding -Xlog (for the child) might provider more information about the sequence of events. Please file a separate bug for the failure, so further investigation can be done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23653#discussion_r1963775424 From acobbs at openjdk.org Thu Feb 20 16:12:05 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Thu, 20 Feb 2025 16:12:05 GMT Subject: Withdrawn: 8349848: Support lint control of sunapi diagnostics In-Reply-To: <-FuJOJGuqnEWp6DseDoGMIf8JY8lTaK2_tVVf-o-1TY=.62b8d0eb-3398-49fd-a321-129c29817ff2@github.com> References: <-FuJOJGuqnEWp6DseDoGMIf8JY8lTaK2_tVVf-o-1TY=.62b8d0eb-3398-49fd-a321-129c29817ff2@github.com> Message-ID: On Fri, 14 Feb 2025 21:07:36 GMT, Archie Cobbs wrote: > This PR creates a new lint category `proprietary` that controls the mandatory warning "Foo is internal proprietary API and may be removed in a future release". > > This allows developers to suppress this warning using `-Xlint:-proprietary` and/or `@SuppressWarnings`. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/23650 From nbenalla at openjdk.org Thu Feb 20 16:12:10 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Thu, 20 Feb 2025 16:12:10 GMT Subject: RFR: 8174840: Elements.overrides does not check the return type of the methods [v2] In-Reply-To: References: Message-ID: On Thu, 23 Jan 2025 13:56:35 GMT, Nizar Benalla wrote: >> Please review this PR to clarify the documentation of `Elements.overrides` through an `@apiNote`, this PR is essentially a doc-only change. This PR supersedes https://github.com/openjdk/jdk/pull/22244. >> >> TIA. > > Nizar Benalla 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 seven additional commits since the last revision: > > - whitespace > - Update according to review comments. > - Merge remote-tracking branch 'upstream/master' into elements-api-note > - Respond to feedback around the wording. > - Respond to feedback. Using Jan's comment to not imply particular requirement on the implementation. > - (C) 2025 > - Initial commit obtained from a cherry pick/squash of a now superseded PR. @jddarcy, could you re-review this PR? ------------- PR Comment: https://git.openjdk.org/jdk/pull/22920#issuecomment-2671960686 From nbenalla at openjdk.org Thu Feb 20 16:25:33 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Thu, 20 Feb 2025 16:25:33 GMT Subject: RFR: 8350007: Add usage message to the javadoc executable [v3] In-Reply-To: References: Message-ID: > This patch adds a new message when you run the `javadoc` executable with any arguments. > Currently, unlike most other tools, running `javadoc` without any arguments does not show you how to use the tool or point you to use the `--help` option, this can be improved. > > Before change: > > W $ ./javadoc > error: No modules, packages or classes specified. > 1 error > > > After change: > > W $ ./javadoc > Usage: > javadoc [options] [packagenames] [sourcefiles] [@files] > For additional help on usage: javadoc --help Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - respond to feedback - Merge branch 'master' into javadoc-usage-message - update test with new usage message - improve javadoc executable message ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23618/files - new: https://git.openjdk.org/jdk/pull/23618/files/4572fe9a..3d83cbd5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23618&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23618&range=01-02 Stats: 8289 lines in 319 files changed: 5499 ins; 1706 del; 1084 mod Patch: https://git.openjdk.org/jdk/pull/23618.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23618/head:pull/23618 PR: https://git.openjdk.org/jdk/pull/23618 From nbenalla at openjdk.org Thu Feb 20 16:25:34 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Thu, 20 Feb 2025 16:25:34 GMT Subject: RFR: 8350007: Add usage message to the javadoc executable [v2] In-Reply-To: References: Message-ID: <2BO363-FbkeAHXmkDMD1ffgXbkx-aEePokhmdPWJWzw=.2e37bdee-bb30-4eff-a1b0-d6da75f6da56@github.com> On Tue, 18 Feb 2025 15:24:22 GMT, Hannes Walln?fer wrote: >> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision: >> >> update test with new usage message > > src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/resources/javadoc.properties line 39: > >> 37: main.no-arg=Usage:\n\ >> 38: \ javadoc [options] [packagenames] [sourcefiles] [@files]\n\ >> 39: For additional help on usage: javadoc --help > > Maybe call the property `main.usage.short` to tie it to the main usage message above and make it clear they should be kept in sync? > > The extra whitespace in the second line looks unmotivated. Could we use the existing `main.for-more-details-see-usage` message below instead of the second line? Fixed in [3d83cbd](https://github.com/openjdk/jdk/pull/23618/commits/3d83cbd577d4706ad408faf7df53d8a30f3482bf). The extra whitespace was indeed too much. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23618#discussion_r1963929578 From duke at openjdk.org Thu Feb 20 17:12:30 2025 From: duke at openjdk.org (David Beaumont) Date: Thu, 20 Feb 2025 17:12:30 GMT Subject: RFR: 8338675: javac shouldn't silently change .jar files on the classpath Message-ID: Modifying `JavacFileManager` to skip creating sibling output class files for source files found in JARs. This should match older (JDK 8) behavior whereby the JAR was not writable, and results in any newly generated class files being written to the current working directory (the output of class files into current directory isn't good, but it should match the old behavior). ------------- Commit messages: - 8338675: javac shouldn't silently change .jar files on the classpath - 8338675: javac shouldn't silently change .jar files on the classpath - 8338675: javac shouldn't silently change .jar files on the classpath - Work in progress. Changes: https://git.openjdk.org/jdk/pull/23699/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23699&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8338675 Stats: 200 lines in 3 files changed: 196 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/23699.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23699/head:pull/23699 PR: https://git.openjdk.org/jdk/pull/23699 From lmesnik at openjdk.org Thu Feb 20 18:02:59 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 20 Feb 2025 18:02:59 GMT Subject: Integrated: 8350151: Support requires property to filter tests incompatible with --enable-preview In-Reply-To: References: Message-ID: On Sat, 15 Feb 2025 19:43:39 GMT, Leonid Mesnik wrote: > It might be useful to be able to run testing with --enable-preview for feature development. The tests incompatible with this mode must be filtered out. > > I chose name 'java.enablePreview' , because it is more java property than vm or jdk. And 'enablePreview' to be similar with jtreg tag. > > Tested by running all test suites, and verifying that test is correctly selected. > There are more tests incompatible with --enable-preview, will mark them in the following bug. This pull request has now been integrated. Changeset: 1eb0db37 Author: Leonid Mesnik URL: https://git.openjdk.org/jdk/commit/1eb0db37608ae1dd05accc1e22c57d76fa2c72ce Stats: 27 lines in 5 files changed: 19 ins; 0 del; 8 mod 8350151: Support requires property to filter tests incompatible with --enable-preview Reviewed-by: alanb, rriggs ------------- PR: https://git.openjdk.org/jdk/pull/23653 From acobbs at openjdk.org Thu Feb 20 21:05:22 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Thu, 20 Feb 2025 21:05:22 GMT Subject: RFR: 8261669: Add lint warning for widening primitive conversions that lose information Message-ID: This PR is a prototype to stimulate discussion of [JDK-8261669](https://bugs.openjdk.org/browse/JDK-8261669), which seeks to add more warnings when an implicit cast of a primitive value might lose information. This can possibly happen when converting an `int` to `float`, or when converting a `long` to `float` or `double`. Java does not require an explicit cast for such assignments, even though they may result in information loss. I'm interested in feedback both on whether this is a good idea and also the approach taken - thanks! Currently, we generate this warning, but only for assignment operators, e.g.: int x = 0; x += 1.0f; // warning here This PR would add warnings for two additional cases, (a) regular assignments and (b) method parameters, e.g.: void method(float f) { } ... float a = 0x10000001; // warning here method(0x10000001); // warning here It would _not_ generate a warning in cases (a) and (b) when the value is a constant value and we can determine that no information would be lost, e.g.: float f1 = 0x10000000; // no warning here The definition of "no information would be lost" is that a round trip results in the same value, e.g., `(int)(float)x == x`. In the examples above, `0x10000000` survives the round trip but `0x10000001` does not. As usual, warnings can be suppressed via `@SuppressWarnings` or by adding an explicit cast: float a = (float)0x10000001; // no warning here ------------- Commit messages: - Warn for more widening primitive conversions that lose information. Changes: https://git.openjdk.org/jdk/pull/23718/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23718&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8261669 Stats: 187 lines in 15 files changed: 149 ins; 0 del; 38 mod Patch: https://git.openjdk.org/jdk/pull/23718.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23718/head:pull/23718 PR: https://git.openjdk.org/jdk/pull/23718 From acobbs at openjdk.org Thu Feb 20 22:26:51 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Thu, 20 Feb 2025 22:26:51 GMT Subject: RFR: 8261669: Add lint warning for widening primitive conversions that lose information In-Reply-To: References: Message-ID: On Thu, 20 Feb 2025 20:57:47 GMT, Archie Cobbs wrote: > This PR is a prototype to stimulate discussion of [JDK-8261669](https://bugs.openjdk.org/browse/JDK-8261669), which seeks to add more warnings when an implicit cast of a primitive value might lose information. This can possibly happen when converting an `int` to `float`, or when converting a `long` to `float` or `double`. Java does not require an explicit cast for such assignments, even though they may result in information loss. > > I'm interested in feedback both on whether this is a good idea and also the approach taken - thanks! > > Currently, we generate this warning, but only for assignment operators, e.g.: > > int x = 0; > x += 1.0f; // warning here > > > This PR would add warnings for two additional cases, (a) regular assignments and (b) method parameters, e.g.: > > void method(float f) { } > ... > float a = 0x10000001; // warning here > method(0x10000001); // warning here > > > It would _not_ generate a warning in cases (a) and (b) when the value is a constant value and we can determine that no information would be lost, e.g.: > > float f1 = 0x10000000; // no warning here > > The definition of "no information would be lost" is that a round trip results in the same value, e.g., `(int)(float)x == x`. In the examples above, `0x10000000` survives the round trip but `0x10000001` does not. > > As usual, warnings can be suppressed via `@SuppressWarnings` or by adding an explicit cast: > > > float a = (float)0x10000001; // no warning here Sorry for the mailing list spam - this PR discussion really only belongs on `compiler-dev`, but the bot added the others due to the changes to the corresponding makefile (which add `-Xlint:-lossy-conversions` to suppress the new warnings). I'll remove `client`, `core-libs`, `hotspot-jfr` and `serviceability` but feel free to add them back if needed/desired. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23718#issuecomment-2672826679 From acobbs at openjdk.org Thu Feb 20 23:50:04 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Thu, 20 Feb 2025 23:50:04 GMT Subject: RFR: 8320220: Compilation of cyclic hierarchy causes infinite recursion Message-ID: This input currently causes an infinite loop: interface A extends B, C {} interface B extends A {} interface C extends A {} However, less complicated cycles are handled properly. When a cycle is found, we currently: (a) Emit a warning; and (b) Set the symbol's type to the error type. These two steps are done in `Check.noteCyclic()`. Step (b) is what normally prevents the infinite loop from happening later in the compilation. But we only do this for the first class in the loop, presumably because it would be too verbose to do (a) for every class in the loop. But that means we're also only doing (b) for the first class in the loop. In more complicated scenarios like the bug example, that means some classes in the cycle can escape without (b) being applied. But this is incorrect (or, at least, weirdly indeterminate) because a loop is a loop no matter which class you start with. So the solution is to continue to do (a) only to the first class in the cycle but do (b) for every class in the cycle. ------------- Commit messages: - Fix infinite loop in cyclic inheritance scenario. Changes: https://git.openjdk.org/jdk/pull/23704/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23704&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8320220 Stats: 24 lines in 3 files changed: 19 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/23704.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23704/head:pull/23704 PR: https://git.openjdk.org/jdk/pull/23704 From sspitsyn at openjdk.org Fri Feb 21 06:17:01 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 21 Feb 2025 06:17:01 GMT Subject: RFR: 8350287: Cleanup SA's support for CodeBlob subclasses [v2] In-Reply-To: References: Message-ID: <2CJil-5PMv-VPzBH_Otga48W7AGMybgy0Kr8_XIztJY=.36640c32-77af-4166-96be-488784190ff3@github.com> On Wed, 19 Feb 2025 05:49:56 GMT, Chris Plummer wrote: >> There is a lot of subclassing of CodeBlob types done in SA to mimic hotspot, but most of it is unnecessary. The generic CodeBlob class can handle all support needed by most of the subclasses. The only subclasses we need to keep around around NMethod, RuntimeStub, and UpcallStub, since they all have special support in SA. I also kept around RuntimeBlob so RuntimeStub can continue to inherit from it and be consistent with hotspot, but it's not actually necessary, and I'm more than happy to remove it also. >> >> I also cleaned up the PStack support for CodeBlobs. It can just use CodeBlob.getName() rather than trying to figure out the type of the CodeBlob instance to print out type name. This allows us to get rid of most isXXX() APIs. It also provides more useful output in some cases. >> >> There is some minor loss of functionality in some of the CodeBlob subtypes I removed. For example this is what AdapterBlob.getName() looked like (it is now gone): >> >> >> public String getName() { >> return "AdapterBlob: " + super.getName(); >> } >> >> >> So now we just use the default CodeBlob.getName(), which is what super.getName() would up execute. I think for AdapterBlob this always returns "I2C/C2I adapters", so now you only get this rather than "AdapterBlob: I2C/C2I adapters". We have a similar loss of getName() detail with MethodHandlesAdapterBlob (now returns "MethodHandles adapters") and VtableBlob (now returns "vtable chunks"). Basically for these 3 CodeBlob types getName() will no longer include the CodeBlob type. I could special case them in CodeBlob.getName() by fetching the kind to determine what the proper name should be. Let me know if you think it is worth it. > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > Minor improvements. Looks good. ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23684#pullrequestreview-2632089455 From jlahoda at openjdk.org Fri Feb 21 08:49:57 2025 From: jlahoda at openjdk.org (Jan Lahoda) Date: Fri, 21 Feb 2025 08:49:57 GMT Subject: RFR: 8338675: javac shouldn't silently change .jar files on the classpath In-Reply-To: References: Message-ID: On Wed, 19 Feb 2025 15:46:34 GMT, David Beaumont wrote: > Modifying `JavacFileManager` to skip creating sibling output class files for source files found in JARs. > > This should match older (JDK 8) behavior whereby the JAR was not writable, and results in any newly generated class files being written to the current working directory (the output of class files into current directory isn't good, but it should match the old behavior). The fix as such seems reasonable to me. The test is good, but I added some comments for possible improvements for the test. test/langtools/tools/javac/T8338675/NoOverwriteJarClassFilesByDefault.java line 1: > 1: /* I would suggest to move the file into `test/langtools/tools/javac/file`. The filenames and directory names based on bug numbers are mostly historical, and are being frowned upon nowadays. Overall, the test is not bad at all, but I'll leave some comments that I think would make fit better with the other tests. test/langtools/tools/javac/T8338675/NoOverwriteJarClassFilesByDefault.java line 66: > 64: * current directory may not be usable. > 65: */ > 66: public class NoOverwriteJarClassFilesByDefault { Overall, I think I would mildly prefer if the test used either `TestRunner`, or junit: https://github.com/openjdk/jdk/blob/master/test/langtools/tools/javac/ImportModule.java https://github.com/openjdk/jdk/blob/master/test/langtools/tools/javac/util/IteratorsTest.java so that it is easier to add or have multiple testcases. test/langtools/tools/javac/T8338675/NoOverwriteJarClassFilesByDefault.java line 68: > 66: public class NoOverwriteJarClassFilesByDefault { > 67: > 68: private static final String OLD_LIB_SOURCE = """ Possibly a personal preference, but I think I would put the opening `"""` on the next line, so that the text block is visibly joint. test/langtools/tools/javac/T8338675/NoOverwriteJarClassFilesByDefault.java line 95: > 93: ToolBox tb = new ToolBox(); > 94: tb.createDirectories("lib"); > 95: tb.writeFile(LIB_SOURCE_NAME, OLD_LIB_SOURCE); Using `Path`s based on relative paths is not wrong, I think, but I think I would suggest to create same `Path base = Paths.get("");`, and in the rest of the test use `Path` derived from the `base` path. So that it is easier to e.g. change the location of the working directory. Also note `ToolBox` has `writeJavaFile`, which infers the relative path automatically in almost all cases (not so useful in this case, of course, as this test needs to know the real path anyway). test/langtools/tools/javac/T8338675/NoOverwriteJarClassFilesByDefault.java line 100: > 98: // The class file generated he is in the lib/ directory, which we delete > 99: // after making the JAR (just to be sure). > 100: new JavacTask(tb).files(LIB_SOURCE_NAME).run(); I tend to use `.writeAll()` after `.run()`, so that if there's any output, it is written out. (Admittedly, the run method could be changed to do that automatically, but I don't think it does currently.) Also, nit: might be nicer to format this using a "builder" style: new JavacTask(tb) .file(LIB_SOURCE_NAME) .run() .writeAll(); Also note there's `ToolBox.findJavaFiles`, which finds Java sources in the given directories. No that useful here, but might be useful in some cases. test/langtools/tools/javac/T8338675/NoOverwriteJarClassFilesByDefault.java line 105: > 103: // it proves it's getting it from the source file in the JAR. > 104: Instant olderTime = Instant.now(); > 105: Instant newerTime = olderTime.plusSeconds(1); I would slightly prefer to make the time distance longer - maybe 60s. Mostly because (historically?) IIRC some timestamp precision was 2s. It is not a factor here, but given the timestamp is only a number here, we can make the difference larger. There could also be a second test that would not include the classfile at all - the test would work the same, and would be immune to changes in timestamp/ordering. test/langtools/tools/javac/T8338675/NoOverwriteJarClassFilesByDefault.java line 130: > 128: > 129: // Before running the test itself, get the CRC of the class file in the JAR. > 130: long originalLibCrc = getLibCrc(); I think I would suggest to compute some hash for the whole jar, not only for the classfile. There should be no changes to the jar at all. ------------- PR Review: https://git.openjdk.org/jdk/pull/23699#pullrequestreview-2632199994 PR Review Comment: https://git.openjdk.org/jdk/pull/23699#discussion_r1964978046 PR Review Comment: https://git.openjdk.org/jdk/pull/23699#discussion_r1964981518 PR Review Comment: https://git.openjdk.org/jdk/pull/23699#discussion_r1964985930 PR Review Comment: https://git.openjdk.org/jdk/pull/23699#discussion_r1964991373 PR Review Comment: https://git.openjdk.org/jdk/pull/23699#discussion_r1964995081 PR Review Comment: https://git.openjdk.org/jdk/pull/23699#discussion_r1965068517 PR Review Comment: https://git.openjdk.org/jdk/pull/23699#discussion_r1965096206 From mcimadamore at openjdk.org Fri Feb 21 09:53:58 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 21 Feb 2025 09:53:58 GMT Subject: RFR: 8349754: Invalid "early reference" error when class extends an outer class [v2] In-Reply-To: References: <7a1rGVyW2gzIC-RqyhZtlPARXlAgjCn9Vem8wUJMzs0=.df5151dc-8cc0-449d-bea6-8c2df52f77b6@github.com> Message-ID: On Mon, 17 Feb 2025 19:08:38 GMT, Archie Cobbs wrote: > OK thanks. In all the discussion I've lost track of what needs to actually change here. I think where we are now is: your changes look correct -- but we need to wait for some backing JLS text (which might possibly reveal more things that need fixing). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23545#discussion_r1965189213 From abimpoudis at openjdk.org Fri Feb 21 09:59:55 2025 From: abimpoudis at openjdk.org (Aggelos Biboudis) Date: Fri, 21 Feb 2025 09:59:55 GMT Subject: RFR: 8261669: Add lint warning for widening primitive conversions that lose information In-Reply-To: References: Message-ID: On Thu, 20 Feb 2025 22:24:01 GMT, Archie Cobbs wrote: >> This PR is a prototype to stimulate discussion of [JDK-8261669](https://bugs.openjdk.org/browse/JDK-8261669), which seeks to add more warnings when an implicit cast of a primitive value might lose information. This can possibly happen when converting an `int` to `float`, or when converting a `long` to `float` or `double`. Java does not require an explicit cast for such assignments, even though they may result in information loss. >> >> I'm interested in feedback both on whether this is a good idea and also the approach taken - thanks! >> >> Currently, we generate this warning, but only for assignment operators, e.g.: >> >> int x = 0; >> x += 1.0f; // warning here >> >> >> This PR would add warnings for two additional cases, (a) regular assignments and (b) method parameters, e.g.: >> >> void method(float f) { } >> ... >> float a = 0x10000001; // warning here >> method(0x10000001); // warning here >> >> >> It would _not_ generate a warning in cases (a) and (b) when the value is a constant value and we can determine that no information would be lost, e.g.: >> >> float f1 = 0x10000000; // no warning here >> >> The definition of "no information would be lost" is that a round trip results in the same value, e.g., `(int)(float)x == x`. In the examples above, `0x10000000` survives the round trip but `0x10000001` does not. >> >> As usual, warnings can be suppressed via `@SuppressWarnings` or by adding an explicit cast: >> >> >> float a = (float)0x10000001; // no warning here > > Sorry for the mailing list spam - this PR discussion really only belongs on `compiler-dev`, but the bot added the others due to the changes to the corresponding makefile (which add `-Xlint:-lossy-conversions` to suppress the new warnings). > > I'll remove `client`, `core-libs`, `hotspot-jfr` and `serviceability` but feel free to add them back if needed/desired. @archiecobbs this is excellent work! Thank you for the initiative and the patch which was on the right direction to address this issue. There are several reasons that it would be ideal to hold this PR off, for now. There is an ongoing effort to study conversions and contexts holistically in Java and possibly regularizing various contexts across the board. That study will build upon the implementation (and terminology) realised by JEP 488 regarding exact and lossy conversions which might well include the warnings contained in your PR. I am re-assigning this to me on JBS and I will link back to it when the new JBS ticket is created. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23718#issuecomment-2674096146 From duke at openjdk.org Fri Feb 21 10:05:53 2025 From: duke at openjdk.org (David Beaumont) Date: Fri, 21 Feb 2025 10:05:53 GMT Subject: RFR: 8338675: javac shouldn't silently change .jar files on the classpath In-Reply-To: References: Message-ID: <9Ioc_-YujNzyrfG0Hyx9VMqbAefFWYU-hr5-Lr2Ntho=.57772d95-7194-4a14-b1f5-fb8dcaf3a9be@github.com> On Fri, 21 Feb 2025 07:06:38 GMT, Jan Lahoda wrote: >> Modifying `JavacFileManager` to skip creating sibling output class files for source files found in JARs. >> >> This should match older (JDK 8) behavior whereby the JAR was not writable, and results in any newly generated class files being written to the current working directory (the output of class files into current directory isn't good, but it should match the old behavior). > > test/langtools/tools/javac/T8338675/NoOverwriteJarClassFilesByDefault.java line 1: > >> 1: /* > > I would suggest to move the file into `test/langtools/tools/javac/file`. The filenames and directory names based on bug numbers are mostly historical, and are being frowned upon nowadays. > > Overall, the test is not bad at all, but I'll leave some comments that I think would make fit better with the other tests. Ahh cool, I was just copying prior precedent. > test/langtools/tools/javac/T8338675/NoOverwriteJarClassFilesByDefault.java line 66: > >> 64: * current directory may not be usable. >> 65: */ >> 66: public class NoOverwriteJarClassFilesByDefault { > > Overall, I think I would mildly prefer if the test used either `TestRunner`, or junit: > https://github.com/openjdk/jdk/blob/master/test/langtools/tools/javac/ImportModule.java > https://github.com/openjdk/jdk/blob/master/test/langtools/tools/javac/util/IteratorsTest.java > > so that it is easier to add or have multiple testcases. I've seen so many different styles of test runner/setup that I'm just copying what's nearby for now. Is there a public document explaining current best practice around this? > test/langtools/tools/javac/T8338675/NoOverwriteJarClassFilesByDefault.java line 68: > >> 66: public class NoOverwriteJarClassFilesByDefault { >> 67: >> 68: private static final String OLD_LIB_SOURCE = """ > > Possibly a personal preference, but I think I would put the opening `"""` on the next line, so that the text block is visibly joint. Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23699#discussion_r1965203857 PR Review Comment: https://git.openjdk.org/jdk/pull/23699#discussion_r1965206095 PR Review Comment: https://git.openjdk.org/jdk/pull/23699#discussion_r1965207209 From duke at openjdk.org Fri Feb 21 10:10:54 2025 From: duke at openjdk.org (David Beaumont) Date: Fri, 21 Feb 2025 10:10:54 GMT Subject: RFR: 8338675: javac shouldn't silently change .jar files on the classpath In-Reply-To: References: Message-ID: On Fri, 21 Feb 2025 07:19:24 GMT, Jan Lahoda wrote: >> Modifying `JavacFileManager` to skip creating sibling output class files for source files found in JARs. >> >> This should match older (JDK 8) behavior whereby the JAR was not writable, and results in any newly generated class files being written to the current working directory (the output of class files into current directory isn't good, but it should match the old behavior). > > test/langtools/tools/javac/T8338675/NoOverwriteJarClassFilesByDefault.java line 95: > >> 93: ToolBox tb = new ToolBox(); >> 94: tb.createDirectories("lib"); >> 95: tb.writeFile(LIB_SOURCE_NAME, OLD_LIB_SOURCE); > > Using `Path`s based on relative paths is not wrong, I think, but I think I would suggest to create same `Path base = Paths.get("");`, and in the rest of the test use `Path` derived from the `base` path. So that it is easier to e.g. change the location of the working directory. > > Also note `ToolBox` has `writeJavaFile`, which infers the relative path automatically in almost all cases (not so useful in this case, of course, as this test needs to know the real path anyway). I was under the impression that JTreg already moves into a test-specific scratch directory which is guaranteed empty at test start, so it's fine to write test files from the "current" directory. Since I'm still learning best-practice around this, if you have docs or other links giving best practice for test file naming, I'd be very grateful. > test/langtools/tools/javac/T8338675/NoOverwriteJarClassFilesByDefault.java line 100: > >> 98: // The class file generated he is in the lib/ directory, which we delete >> 99: // after making the JAR (just to be sure). >> 100: new JavacTask(tb).files(LIB_SOURCE_NAME).run(); > > I tend to use `.writeAll()` after `.run()`, so that if there's any output, it is written out. (Admittedly, the run method could be changed to do that automatically, but I don't think it does currently.) > > Also, nit: might be nicer to format this using a "builder" style: > > new JavacTask(tb) > .file(LIB_SOURCE_NAME) > .run() > .writeAll(); > > > Also note there's `ToolBox.findJavaFiles`, which finds Java sources in the given directories. No that useful here, but might be useful in some cases. IntelliJ formatting did this. If there was a recommended IJ formatter setup that would would "just work (tm)" I'd love to know about it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23699#discussion_r1965212556 PR Review Comment: https://git.openjdk.org/jdk/pull/23699#discussion_r1965215620 From duke at openjdk.org Fri Feb 21 10:16:55 2025 From: duke at openjdk.org (David Beaumont) Date: Fri, 21 Feb 2025 10:16:55 GMT Subject: RFR: 8338675: javac shouldn't silently change .jar files on the classpath In-Reply-To: References: Message-ID: On Fri, 21 Feb 2025 08:31:19 GMT, Jan Lahoda wrote: >> Modifying `JavacFileManager` to skip creating sibling output class files for source files found in JARs. >> >> This should match older (JDK 8) behavior whereby the JAR was not writable, and results in any newly generated class files being written to the current working directory (the output of class files into current directory isn't good, but it should match the old behavior). > > test/langtools/tools/javac/T8338675/NoOverwriteJarClassFilesByDefault.java line 105: > >> 103: // it proves it's getting it from the source file in the JAR. >> 104: Instant olderTime = Instant.now(); >> 105: Instant newerTime = olderTime.plusSeconds(1); > > I would slightly prefer to make the time distance longer - maybe 60s. Mostly because (historically?) IIRC some timestamp precision was 2s. It is not a factor here, but given the timestamp is only a number here, we can make the difference larger. > > There could also be a second test that would not include the classfile at all - the test would work the same, and would be immune to changes in timestamp/ordering. Since this is being written manually, and read programatically, I'd rather make the difference as *small* as possible to demonstrate the tie break is performed for any "newer" source file. I did think about the 2nd test, but that would seem to only check a subset of what this test already checks for. I happy with this as-is (assuming the 1 second thing doesn't actually cause a failure). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23699#discussion_r1965224900 From duke at openjdk.org Fri Feb 21 10:24:57 2025 From: duke at openjdk.org (David Beaumont) Date: Fri, 21 Feb 2025 10:24:57 GMT Subject: RFR: 8338675: javac shouldn't silently change .jar files on the classpath In-Reply-To: References: Message-ID: On Fri, 21 Feb 2025 10:07:45 GMT, David Beaumont wrote: >> test/langtools/tools/javac/T8338675/NoOverwriteJarClassFilesByDefault.java line 100: >> >>> 98: // The class file generated he is in the lib/ directory, which we delete >>> 99: // after making the JAR (just to be sure). >>> 100: new JavacTask(tb).files(LIB_SOURCE_NAME).run(); >> >> I tend to use `.writeAll()` after `.run()`, so that if there's any output, it is written out. (Admittedly, the run method could be changed to do that automatically, but I don't think it does currently.) >> >> Also, nit: might be nicer to format this using a "builder" style: >> >> new JavacTask(tb) >> .file(LIB_SOURCE_NAME) >> .run() >> .writeAll(); >> >> >> Also note there's `ToolBox.findJavaFiles`, which finds Java sources in the given directories. No that useful here, but might be useful in some cases. > > IntelliJ formatting did this. If there was a recommended IJ formatter setup that would would "just work (tm)" I'd love to know about it. > > I didn't know about the `writeAll()` thing, and several tests I looked at don't do this (and appear to work reliably) so I think it always writes things out. I will double check for my own edification. Ahh I see, `writeAll()` is for stream output, not file writing. It's flushed for cases where compilation doesn't proceed as expected, but not "normally". So adding it here only affects the currency of stream output while the test is running. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23699#discussion_r1965235482 From duke at openjdk.org Fri Feb 21 10:29:01 2025 From: duke at openjdk.org (David Beaumont) Date: Fri, 21 Feb 2025 10:29:01 GMT Subject: RFR: 8338675: javac shouldn't silently change .jar files on the classpath In-Reply-To: References: Message-ID: On Fri, 21 Feb 2025 08:46:34 GMT, Jan Lahoda wrote: >> Modifying `JavacFileManager` to skip creating sibling output class files for source files found in JARs. >> >> This should match older (JDK 8) behavior whereby the JAR was not writable, and results in any newly generated class files being written to the current working directory (the output of class files into current directory isn't good, but it should match the old behavior). > > test/langtools/tools/javac/T8338675/NoOverwriteJarClassFilesByDefault.java line 130: > >> 128: >> 129: // Before running the test itself, get the CRC of the class file in the JAR. >> 130: long originalLibCrc = getLibCrc(); > > I think I would suggest to compute some hash for the whole jar, not only for the classfile. There should be no changes to the jar at all. Good point. Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23699#discussion_r1965240725 From duke at openjdk.org Fri Feb 21 11:24:17 2025 From: duke at openjdk.org (David Beaumont) Date: Fri, 21 Feb 2025 11:24:17 GMT Subject: RFR: 8338675: javac shouldn't silently change .jar files on the classpath [v2] In-Reply-To: References: Message-ID: > Modifying `JavacFileManager` to skip creating sibling output class files for source files found in JARs. > > This should match older (JDK 8) behavior whereby the JAR was not writable, and results in any newly generated class files being written to the current working directory (the output of class files into current directory isn't good, but it should match the old behavior). David Beaumont has updated the pull request incrementally with one additional commit since the last revision: Changes based on PR feedback. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23699/files - new: https://git.openjdk.org/jdk/pull/23699/files/5d47fdf1..39d24c9a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23699&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23699&range=00-01 Stats: 378 lines in 2 files changed: 197 ins; 181 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/23699.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23699/head:pull/23699 PR: https://git.openjdk.org/jdk/pull/23699 From rgiulietti at openjdk.org Fri Feb 21 11:33:52 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Fri, 21 Feb 2025 11:33:52 GMT Subject: RFR: 8261669: Add lint warning for widening primitive conversions that lose information In-Reply-To: References: Message-ID: On Thu, 20 Feb 2025 20:57:47 GMT, Archie Cobbs wrote: > This PR is a prototype to stimulate discussion of [JDK-8261669](https://bugs.openjdk.org/browse/JDK-8261669), which seeks to add more warnings when an implicit cast of a primitive value might lose information. This can possibly happen when converting an `int` to `float`, or when converting a `long` to `float` or `double`. Java does not require an explicit cast for such assignments, even though they may result in information loss. > > I'm interested in feedback both on whether this is a good idea and also the approach taken - thanks! > > Currently, we generate this warning, but only for assignment operators, e.g.: > > int x = 0; > x += 1.0f; // warning here > > > This PR would add warnings for two additional cases, (a) regular assignments and (b) method parameters, e.g.: > > void method(float f) { } > ... > float a = 0x10000001; // warning here > method(0x10000001); // warning here > > > It would _not_ generate a warning in cases (a) and (b) when the value is a constant value and we can determine that no information would be lost, e.g.: > > float f1 = 0x10000000; // no warning here > > The definition of "no information would be lost" is that a round trip results in the same value, e.g., `(int)(float)x == x`. In the examples above, `0x10000000` survives the round trip but `0x10000001` does not. > > As usual, warnings can be suppressed via `@SuppressWarnings` or by adding an explicit cast: > > > float a = (float)0x10000001; // no warning here The "roundtrip technique" is not always sufficient. For example, `(int) (float) Integer.MAX_VALUE == Integer.MAX_VALUE` evaluates to `true`, despite `Integer.MAX_VALUE)` not being exactly representable by `float`. You may want to take a look at `java.lang.runtime.ExactConversionsSupport`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23718#issuecomment-2674307463 From duke at openjdk.org Fri Feb 21 12:18:21 2025 From: duke at openjdk.org (David Beaumont) Date: Fri, 21 Feb 2025 12:18:21 GMT Subject: RFR: 8338675: javac shouldn't silently change .jar files on the classpath [v3] In-Reply-To: References: Message-ID: <4efJygBoE1wIQ_8cFcFdrfjMbfl_FifK3sroTwcxVWc=.8c049200-6cc9-45a8-a448-ceadc1fa9f81@github.com> > Modifying `JavacFileManager` to skip creating sibling output class files for source files found in JARs. > > This should match older (JDK 8) behavior whereby the JAR was not writable, and results in any newly generated class files being written to the current working directory (the output of class files into current directory isn't good, but it should match the old behavior). David Beaumont has updated the pull request incrementally with one additional commit since the last revision: Changes based on PR feedback. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23699/files - new: https://git.openjdk.org/jdk/pull/23699/files/39d24c9a..8b913484 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23699&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23699&range=01-02 Stats: 24 lines in 1 file changed: 10 ins; 7 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/23699.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23699/head:pull/23699 PR: https://git.openjdk.org/jdk/pull/23699 From duke at openjdk.org Fri Feb 21 12:18:21 2025 From: duke at openjdk.org (David Beaumont) Date: Fri, 21 Feb 2025 12:18:21 GMT Subject: RFR: 8338675: javac shouldn't silently change .jar files on the classpath [v3] In-Reply-To: <9Ioc_-YujNzyrfG0Hyx9VMqbAefFWYU-hr5-Lr2Ntho=.57772d95-7194-4a14-b1f5-fb8dcaf3a9be@github.com> References: <9Ioc_-YujNzyrfG0Hyx9VMqbAefFWYU-hr5-Lr2Ntho=.57772d95-7194-4a14-b1f5-fb8dcaf3a9be@github.com> Message-ID: On Fri, 21 Feb 2025 10:02:22 GMT, David Beaumont wrote: >> test/langtools/tools/javac/T8338675/NoOverwriteJarClassFilesByDefault.java line 66: >> >>> 64: * current directory may not be usable. >>> 65: */ >>> 66: public class NoOverwriteJarClassFilesByDefault { >> >> Overall, I think I would mildly prefer if the test used either `TestRunner`, or junit: >> https://github.com/openjdk/jdk/blob/master/test/langtools/tools/javac/ImportModule.java >> https://github.com/openjdk/jdk/blob/master/test/langtools/tools/javac/util/IteratorsTest.java >> >> so that it is easier to add or have multiple testcases. > > I've seen so many different styles of test runner/setup that I'm just copying what's nearby for now. Is there a public document explaining current best practice around this? I switched to JUnit and changed the test name to match "best practice". >> test/langtools/tools/javac/T8338675/NoOverwriteJarClassFilesByDefault.java line 68: >> >>> 66: public class NoOverwriteJarClassFilesByDefault { >>> 67: >>> 68: private static final String OLD_LIB_SOURCE = """ >> >> Possibly a personal preference, but I think I would put the opening `"""` on the next line, so that the text block is visibly joint. > > Done. Though annoying now, IntelliJ wants to format that like: > > private static final String OLD_LIB_SOURCE = > """ > package lib; > public class LibClass { > public static final String OLD_FIELD = "This will not compile with Target"; > } > """; > > which isn't great. FYI: There's an IntelliJ Java formatter setting that fixes this ("Text Blocks" -> "Align when multiline") ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23699#discussion_r1965382280 PR Review Comment: https://git.openjdk.org/jdk/pull/23699#discussion_r1965384438 From acobbs at openjdk.org Fri Feb 21 16:51:38 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Fri, 21 Feb 2025 16:51:38 GMT Subject: RFR: 8261669: Add lint warning for widening primitive conversions that lose information [v2] In-Reply-To: References: Message-ID: > This PR is a prototype to stimulate discussion of [JDK-8261669](https://bugs.openjdk.org/browse/JDK-8261669), which seeks to add more warnings when an implicit cast of a primitive value might lose information. This can possibly happen when converting an `int` to `float`, or when converting a `long` to `float` or `double`. Java does not require an explicit cast for such assignments, even though they may result in information loss. > > I'm interested in feedback both on whether this is a good idea and also the approach taken - thanks! > > Currently, we generate this warning, but only for assignment operators, e.g.: > > int x = 0; > x += 1.0f; // warning here > > > This PR would add warnings for two additional cases, (a) regular assignments and (b) method parameters, e.g.: > > void method(float f) { } > ... > float a = 0x10000001; // warning here > method(0x10000001); // warning here > > > It would _not_ generate a warning in cases (a) and (b) when the value is a constant value and we can determine that no information would be lost, e.g.: > > float f1 = 0x10000000; // no warning here > > The definition of "no information would be lost" is that a round trip results in the same value, e.g., `(int)(float)x == x`. In the examples above, `0x10000000` survives the round trip but `0x10000001` does not. > > As usual, warnings can be suppressed via `@SuppressWarnings` or by adding an explicit cast: > > > float a = (float)0x10000001; // no warning here Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision: Check exactness of conversions using ExactConversionsSupport. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23718/files - new: https://git.openjdk.org/jdk/pull/23718/files/48680ecb..92b479a9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23718&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23718&range=00-01 Stats: 98 lines in 5 files changed: 64 ins; 2 del; 32 mod Patch: https://git.openjdk.org/jdk/pull/23718.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23718/head:pull/23718 PR: https://git.openjdk.org/jdk/pull/23718 From acobbs at openjdk.org Fri Feb 21 16:51:38 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Fri, 21 Feb 2025 16:51:38 GMT Subject: RFR: 8261669: Add lint warning for widening primitive conversions that lose information In-Reply-To: References: Message-ID: <1bEXTqphBLHTtvUwT4nmNwTttIyspwpfOLwF1m9wxOc=.d8d78754-fdf5-4e6d-8a38-0dbdbc7e8439@github.com> On Fri, 21 Feb 2025 11:31:34 GMT, Raffaello Giulietti wrote: > You may want to take a look at `java.lang.runtime.ExactConversionsSupport`. Thanks! That's exactly what I needed. Fixed in 92b479a94ff. > There are several reasons that it would be ideal to hold this PR off, for now. There is an ongoing effort to study conversions and contexts holistically in Java and possibly regularizing various contexts across the board. > > That study will build upon the implementation (and terminology) realised by JEP 488 regarding exact and lossy conversions which might well include the warnings contained in your PR. > > I am re-assigning this to me on JBS and I will link back to it when the new JBS ticket is created. OK sounds good - it's all yours :) I will close this PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23718#issuecomment-2675056823 From acobbs at openjdk.org Fri Feb 21 16:51:38 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Fri, 21 Feb 2025 16:51:38 GMT Subject: Withdrawn: 8261669: Add lint warning for widening primitive conversions that lose information In-Reply-To: References: Message-ID: On Thu, 20 Feb 2025 20:57:47 GMT, Archie Cobbs wrote: > This PR is a prototype to stimulate discussion of [JDK-8261669](https://bugs.openjdk.org/browse/JDK-8261669), which seeks to add more warnings when an implicit cast of a primitive value might lose information. This can possibly happen when converting an `int` to `float`, or when converting a `long` to `float` or `double`. Java does not require an explicit cast for such assignments, even though they may result in information loss. > > I'm interested in feedback both on whether this is a good idea and also the approach taken - thanks! > > Currently, we generate this warning, but only for assignment operators, e.g.: > > int x = 0; > x += 1.0f; // warning here > > > This PR would add warnings for two additional cases, (a) regular assignments and (b) method parameters, e.g.: > > void method(float f) { } > ... > float a = 0x10000001; // warning here > method(0x10000001); // warning here > > > It would _not_ generate a warning in cases (a) and (b) when the value is a constant value and we can determine that no information would be lost, e.g.: > > float f1 = 0x10000000; // no warning here > > The definition of "no information would be lost" is that a round trip results in the same value, e.g., `(int)(float)x == x`. In the examples above, `0x10000000` survives the round trip but `0x10000001` does not. > > As usual, warnings can be suppressed via `@SuppressWarnings` or by adding an explicit cast: > > > float a = (float)0x10000001; // no warning here This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/23718 From cjplummer at openjdk.org Fri Feb 21 19:12:00 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 21 Feb 2025 19:12:00 GMT Subject: RFR: 8350287: Cleanup SA's support for CodeBlob subclasses [v2] In-Reply-To: References: Message-ID: <3R9wsUs6rIJPcbg5Rwd2zBfc-PcAur1HquvuL52jh9I=.4896d421-78f9-4dbd-91b4-52c39075cf9d@github.com> On Wed, 19 Feb 2025 05:49:56 GMT, Chris Plummer wrote: >> There is a lot of subclassing of CodeBlob types done in SA to mimic hotspot, but most of it is unnecessary. The generic CodeBlob class can handle all support needed by most of the subclasses. The only subclasses we need to keep around around NMethod, RuntimeStub, and UpcallStub, since they all have special support in SA. I also kept around RuntimeBlob so RuntimeStub can continue to inherit from it and be consistent with hotspot, but it's not actually necessary, and I'm more than happy to remove it also. >> >> I also cleaned up the PStack support for CodeBlobs. It can just use CodeBlob.getName() rather than trying to figure out the type of the CodeBlob instance to print out type name. This allows us to get rid of most isXXX() APIs. It also provides more useful output in some cases. >> >> There is some minor loss of functionality in some of the CodeBlob subtypes I removed. For example this is what AdapterBlob.getName() looked like (it is now gone): >> >> >> public String getName() { >> return "AdapterBlob: " + super.getName(); >> } >> >> >> So now we just use the default CodeBlob.getName(), which is what super.getName() would up execute. I think for AdapterBlob this always returns "I2C/C2I adapters", so now you only get this rather than "AdapterBlob: I2C/C2I adapters". We have a similar loss of getName() detail with MethodHandlesAdapterBlob (now returns "MethodHandles adapters") and VtableBlob (now returns "vtable chunks"). Basically for these 3 CodeBlob types getName() will no longer include the CodeBlob type. I could special case them in CodeBlob.getName() by fetching the kind to determine what the proper name should be. Let me know if you think it is worth it. > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > Minor improvements. Thanks for the reviews Vladimir and Serguei! ------------- PR Comment: https://git.openjdk.org/jdk/pull/23684#issuecomment-2675336648 From cjplummer at openjdk.org Fri Feb 21 19:12:00 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 21 Feb 2025 19:12:00 GMT Subject: Integrated: 8350287: Cleanup SA's support for CodeBlob subclasses In-Reply-To: References: Message-ID: On Wed, 19 Feb 2025 02:08:28 GMT, Chris Plummer wrote: > There is a lot of subclassing of CodeBlob types done in SA to mimic hotspot, but most of it is unnecessary. The generic CodeBlob class can handle all support needed by most of the subclasses. The only subclasses we need to keep around around NMethod, RuntimeStub, and UpcallStub, since they all have special support in SA. I also kept around RuntimeBlob so RuntimeStub can continue to inherit from it and be consistent with hotspot, but it's not actually necessary, and I'm more than happy to remove it also. > > I also cleaned up the PStack support for CodeBlobs. It can just use CodeBlob.getName() rather than trying to figure out the type of the CodeBlob instance to print out type name. This allows us to get rid of most isXXX() APIs. It also provides more useful output in some cases. > > There is some minor loss of functionality in some of the CodeBlob subtypes I removed. For example this is what AdapterBlob.getName() looked like (it is now gone): > > > public String getName() { > return "AdapterBlob: " + super.getName(); > } > > > So now we just use the default CodeBlob.getName(), which is what super.getName() would up execute. I think for AdapterBlob this always returns "I2C/C2I adapters", so now you only get this rather than "AdapterBlob: I2C/C2I adapters". We have a similar loss of getName() detail with MethodHandlesAdapterBlob (now returns "MethodHandles adapters") and VtableBlob (now returns "vtable chunks"). Basically for these 3 CodeBlob types getName() will no longer include the CodeBlob type. I could special case them in CodeBlob.getName() by fetching the kind to determine what the proper name should be. Let me know if you think it is worth it. This pull request has now been integrated. Changeset: b45c32cd Author: Chris Plummer URL: https://git.openjdk.org/jdk/commit/b45c32cd4fb55fac4fc5161b9cd76415c69b203b Stats: 698 lines in 15 files changed: 13 ins; 680 del; 5 mod 8350287: Cleanup SA's support for CodeBlob subclasses Reviewed-by: kvn, sspitsyn ------------- PR: https://git.openjdk.org/jdk/pull/23684 From acobbs at openjdk.org Fri Feb 21 21:29:09 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Fri, 21 Feb 2025 21:29:09 GMT Subject: RFR: 8224228: No way to locally suppress lint warnings in parser/tokenizer or preview features [v13] In-Reply-To: References: Message-ID: <4wmgls23vON4kW3mE-tuza_zAD4mJkVhNXBoPn2ibRA=.917c3fd4-a32b-4911-939b-9718fb5243c9@github.com> > This PR updates the `DeferredLintHandler` so that deferred warnings can be registered during parsing, before any `JCTree` nodes have been created, and it uses this new capability to update the `"preview"` and `"text-blocks"` Lint warnings so that they can be suppressed via `@SuppressWarnings` annotations. More details are provided in additional comments. > > Note: This PR depends on (i.e., includes and extends) these other "cleanup" PR's: > * #23167 > * #23281 > * #23400 > * #23669 > * #23730 Archie Cobbs has updated the pull request incrementally with two additional commits since the last revision: - Merge branch 'JDK-8350514' (split out as sub-task) into JDK-8224228. - Refactor MandatoryWarningHandler to support dynamic verbosity. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23237/files - new: https://git.openjdk.org/jdk/pull/23237/files/8ac827ce..f1e2a593 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23237&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23237&range=11-12 Stats: 35 lines in 4 files changed: 9 ins; 11 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/23237.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23237/head:pull/23237 PR: https://git.openjdk.org/jdk/pull/23237 From acobbs at openjdk.org Fri Feb 21 21:49:02 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Fri, 21 Feb 2025 21:49:02 GMT Subject: RFR: 8350514: Refactor MandatoryWarningHandler to support dynamic verbosity Message-ID: <1F8PWZXfI4GP2YUyuO5C_49j5LV2GM_vBm3vs7Z6PA0=.e530aaf5-3842-4d84-923e-7e86d348688a@github.com> This PR is a sub-task split off from [JDK-8224228](https://bugs.openjdk.org/browse/JDK-8224228), which seeks to add `@SuppressWarnings` support for lexical features. The `MandatoryWarningHandler` is used by the `preview`, `deprecation`, `removal`, and `unchecked` mandatory warnings. The constructor takes a boolean `verbose` flag which is documented to "Specify whether or not detailed messages about individual instances should be given, or whether an aggregate message should be generated at the end of the compilation." The problem is that this flag doesn't really make sense for warnings that are suppressible via `@SuppressWarnings`: for such warnings, what we actually want to do is trigger the aggregate message at the end of compilation if and only if there were any warnings that were not suppressed by `@SuppressWarnings` but _were_ suppressed because the corresponding lint category was not enabled, either because it wasn't enabled by default, or due to an explicit `-Xlint:-foo` flag. Currently, we get that same net result, because `preview` is not suppressible via `@SuppressWarnings`, and for the other three categories there is logic around the calls to `MandatoryWarningHandler.report()` to ensure the right thing happens. It would be simpler and more straightforward for the users of `MandatoryWarningHandler` to just pass along the currently applicable `Lint` instance and let `MandatoryWarningHandler` keep track of whether to generate the aggregate message at the end of the compilation. ------------- Commit messages: - Refactor MandatoryWarningHandler to support dynamic verbosity. Changes: https://git.openjdk.org/jdk/pull/23730/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23730&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8350514 Stats: 60 lines in 3 files changed: 14 ins; 25 del; 21 mod Patch: https://git.openjdk.org/jdk/pull/23730.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23730/head:pull/23730 PR: https://git.openjdk.org/jdk/pull/23730 From mcimadamore at openjdk.org Mon Feb 24 11:43:52 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 24 Feb 2025 11:43:52 GMT Subject: RFR: 8349991: GraphUtils.java can use String.replace() instead of String.replaceAll() In-Reply-To: References: Message-ID: On Mon, 17 Feb 2025 02:38:20 GMT, Archie Cobbs wrote: > This is a tiny performance improvement that replaces a few invocations of `String.replaceAll()` with equivalent invocations of `String.replace(char, char)` and avoids the unnecessary use of regular expressions. src/jdk.compiler/share/classes/com/sun/tools/javac/util/GraphUtils.java line 254: > 252: > 253: protected String formatProperties(Properties p) { > 254: return p.toString().replace(',', ' ') can't there be more than one `,` in the `toString` of `Properties` object? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23658#discussion_r1967481347 From mcimadamore at openjdk.org Mon Feb 24 11:48:54 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 24 Feb 2025 11:48:54 GMT Subject: RFR: 8349991: GraphUtils.java can use String.replace() instead of String.replaceAll() In-Reply-To: References: Message-ID: On Mon, 24 Feb 2025 11:41:00 GMT, Maurizio Cimadamore wrote: >> This is a tiny performance improvement that replaces a few invocations of `String.replaceAll()` with equivalent invocations of `String.replace(char, char)` and avoids the unnecessary use of regular expressions. > > src/jdk.compiler/share/classes/com/sun/tools/javac/util/GraphUtils.java line 254: > >> 252: >> 253: protected String formatProperties(Properties p) { >> 254: return p.toString().replace(',', ' ') > > can't there be more than one `,` in the `toString` of `Properties` object? I know that javac only ever uses two properties at most... but this class is rather general, and the proposed change would introduce subtle bugs if a third property is ever added to inference nodes -- or any other node using in javac implementation ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23658#discussion_r1967486886 From mcimadamore at openjdk.org Mon Feb 24 11:48:54 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 24 Feb 2025 11:48:54 GMT Subject: RFR: 8349991: GraphUtils.java can use String.replace() instead of String.replaceAll() In-Reply-To: References: Message-ID: On Mon, 24 Feb 2025 11:45:26 GMT, Maurizio Cimadamore wrote: >> src/jdk.compiler/share/classes/com/sun/tools/javac/util/GraphUtils.java line 254: >> >>> 252: >>> 253: protected String formatProperties(Properties p) { >>> 254: return p.toString().replace(',', ' ') >> >> can't there be more than one `,` in the `toString` of `Properties` object? > > I know that javac only ever uses two properties at most... but this class is rather general, and the proposed change would introduce subtle bugs if a third property is ever added to inference nodes -- or any other node using in javac implementation (separately, I'm also curious of when such a change makes a real impact -- `toDot()` is mostly used when debugging... but I'm ok with replacing complex methods with simpler forms -- where possible) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23658#discussion_r1967488241 From duke at openjdk.org Mon Feb 24 14:13:55 2025 From: duke at openjdk.org (Florent Guillaume) Date: Mon, 24 Feb 2025 14:13:55 GMT Subject: RFR: 8349991: GraphUtils.java can use String.replace() instead of String.replaceAll() In-Reply-To: References: Message-ID: On Mon, 24 Feb 2025 11:46:33 GMT, Maurizio Cimadamore wrote: >> I know that javac only ever uses two properties at most... but this class is rather general, and the proposed change would introduce subtle bugs if a third property is ever added to inference nodes -- or any other node using in javac implementation > > (separately, I'm also curious of when such a change makes a real impact -- `toDot()` is mostly used when debugging... but I'm ok with replacing complex methods with simpler forms -- where possible) But `replace` replaces all occurrences already. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23658#discussion_r1967713977 From vromero at openjdk.org Mon Feb 24 15:26:01 2025 From: vromero at openjdk.org (Vicente Romero) Date: Mon, 24 Feb 2025 15:26:01 GMT Subject: RFR: 8320220: Compilation of cyclic hierarchy causes infinite recursion In-Reply-To: References: Message-ID: <9ei59jNCNfQo2jsi-74yihMX0QLtp6eQq-5c4pNz3fc=.5415d53d-8385-4295-b9ed-22ae3d06b3ff@github.com> On Wed, 19 Feb 2025 18:15:51 GMT, Archie Cobbs wrote: > This input currently causes an infinite loop: > > interface A extends B, C {} > interface B extends A {} > interface C extends A {} > > However, less complicated cycles are handled properly. > > When a cycle is found, we currently: > (a) Emit a warning; and > (b) Set the symbol's type to the error type. > > These two steps are done in `Check.noteCyclic()`. > > Step (b) is what normally prevents the infinite loop from happening later in the compilation. But we only do this for the first class in the loop, presumably because it would be too verbose to do (a) for every class in the loop. But that means we're also only doing (b) for the first class in the loop. > > In more complicated scenarios like the bug example, that means some classes in the cycle can escape without (b) being applied. But this is incorrect (or, at least, weirdly indeterminate) because a loop is a loop no matter which class you start with. > > So the solution is to continue to do (a) only to the first class in the cycle but do (b) for every class in the cycle. src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 2380: > 2378: seenClasses.stream() > 2379: .filter(s -> !s.type.isErroneous()) > 2380: .filter(ClassSymbol.class::isInstance) wouldn't a ClassSymbol method be better here like ClassSymbol::isSubClass? src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 2381: > 2379: .filter(s -> !s.type.isErroneous()) > 2380: .filter(ClassSymbol.class::isInstance) > 2381: .map(ClassSymbol.class::cast) this method will invoke Class::isInstance again, probably better to just do `(c -> (ClassSymbol)c)`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23704#discussion_r1967861336 PR Review Comment: https://git.openjdk.org/jdk/pull/23704#discussion_r1967865748 From acobbs at openjdk.org Mon Feb 24 15:50:55 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Mon, 24 Feb 2025 15:50:55 GMT Subject: RFR: 8320220: Compilation of cyclic hierarchy causes infinite recursion In-Reply-To: <9ei59jNCNfQo2jsi-74yihMX0QLtp6eQq-5c4pNz3fc=.5415d53d-8385-4295-b9ed-22ae3d06b3ff@github.com> References: <9ei59jNCNfQo2jsi-74yihMX0QLtp6eQq-5c4pNz3fc=.5415d53d-8385-4295-b9ed-22ae3d06b3ff@github.com> Message-ID: On Mon, 24 Feb 2025 15:21:24 GMT, Vicente Romero wrote: >> This input currently causes an infinite loop: >> >> interface A extends B, C {} >> interface B extends A {} >> interface C extends A {} >> >> However, less complicated cycles are handled properly. >> >> When a cycle is found, we currently: >> (a) Emit a warning; and >> (b) Set the symbol's type to the error type. >> >> These two steps are done in `Check.noteCyclic()`. >> >> Step (b) is what normally prevents the infinite loop from happening later in the compilation. But we only do this for the first class in the loop, presumably because it would be too verbose to do (a) for every class in the loop. But that means we're also only doing (b) for the first class in the loop. >> >> In more complicated scenarios like the bug example, that means some classes in the cycle can escape without (b) being applied. But this is incorrect (or, at least, weirdly indeterminate) because a loop is a loop no matter which class you start with. >> >> So the solution is to continue to do (a) only to the first class in the cycle but do (b) for every class in the cycle. > > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 2380: > >> 2378: seenClasses.stream() >> 2379: .filter(s -> !s.type.isErroneous()) >> 2380: .filter(ClassSymbol.class::isInstance) > > wouldn't a ClassSymbol method be better here like ClassSymbol::isSubClass? > wouldn't a ClassSymbol method be better here like ClassSymbol::isSubClass? > ... > this method will invoke Class::isInstance again, probably better to just do (c -> (ClassSymbol)c)? My goal was to replicate the existing logic, but do it for every class in `seenClasses` instead of just the current one. But I was not able to prove to myself that every symbol in `seenClasses` is in fact a `ClassSymbol`, although that may actually be true in practice. So that's why the code is being careful not to blind casting everything in `seenClasses` to `ClassSymbol`. If you're confident that every symbol in `seenClasses` is always a `ClassSymbol` then we can simplify this... but if so, why wasn't `seenClasses` declared as a `Set` instead of a `Set` in the first place? I'm wondering there is some weird (probably invalid) input that could cause that assumption to be violated. Thanks for taking a look. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23704#discussion_r1967927130 From acobbs at openjdk.org Mon Feb 24 16:48:54 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Mon, 24 Feb 2025 16:48:54 GMT Subject: RFR: 8320220: Compilation of cyclic hierarchy causes infinite recursion In-Reply-To: References: <9ei59jNCNfQo2jsi-74yihMX0QLtp6eQq-5c4pNz3fc=.5415d53d-8385-4295-b9ed-22ae3d06b3ff@github.com> Message-ID: On Mon, 24 Feb 2025 15:48:36 GMT, Archie Cobbs wrote: >> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 2380: >> >>> 2378: seenClasses.stream() >>> 2379: .filter(s -> !s.type.isErroneous()) >>> 2380: .filter(ClassSymbol.class::isInstance) >> >> wouldn't a ClassSymbol method be better here like ClassSymbol::isSubClass? > >> wouldn't a ClassSymbol method be better here like ClassSymbol::isSubClass? >> ... >> this method will invoke Class::isInstance again, probably better to just do (c -> (ClassSymbol)c)? > > My goal was to replicate the existing logic, but do it for every class in `seenClasses` instead of just the current one. But I was not able to prove to myself that every symbol in `seenClasses` is in fact a `ClassSymbol`, although that may actually be true in practice. So that's why the code is being careful not to blind casting everything in `seenClasses` to `ClassSymbol`. > > If you're confident that every symbol in `seenClasses` is always a `ClassSymbol` then we can simplify this... but if so, why wasn't `seenClasses` declared as a `Set` instead of a `Set` in the first place? I'm wondering there is some weird (probably invalid) input that could cause that assumption to be violated. > > Thanks for taking a look. Following up on previous comment... > I'm wondering there is some weird (probably invalid) input that could cause that assumption to be violated. In fact, if we just blindly cast then there are 3 regression test failures. In particular, this input crashes the compiler: public class Cyclic { static class Outer { class Inner {} } static class Test { class InnerTest extends X.Inner { InnerTest(Outer o) {o.super();} } } } with this error: Finished building target 'interim-langtools' in configuration 'macosx-aarch64-server-release' An exception has occurred in the compiler (25-internal). 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.ClassCastException: class com.sun.tools.javac.code.Symbol$TypeVariableSymbol cannot be cast to class com.sun.tools.javac.code.Symbol$ClassSymbol (com.sun.tools.javac.code.Symbol$TypeVariableSymbol and com.sun.tools.javac.code.Symbol$ClassSymbol are in module jdk.compiler.interim of loader 'app') at jdk.compiler.interim/com.sun.tools.javac.comp.Check$CycleChecker.checkSymbol(Check.java:2329) at jdk.compiler.interim/com.sun.tools.javac.comp.Check$CycleChecker.visitIdent(Check.java:2345) at jdk.compiler.interim/com.sun.tools.javac.tree.JCTree$JCIdent.accept(JCTree.java:2710) at jdk.compiler.interim/com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:50) ... ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23704#discussion_r1968030240 From acobbs at openjdk.org Mon Feb 24 16:56:55 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Mon, 24 Feb 2025 16:56:55 GMT Subject: RFR: 8320220: Compilation of cyclic hierarchy causes infinite recursion In-Reply-To: <9ei59jNCNfQo2jsi-74yihMX0QLtp6eQq-5c4pNz3fc=.5415d53d-8385-4295-b9ed-22ae3d06b3ff@github.com> References: <9ei59jNCNfQo2jsi-74yihMX0QLtp6eQq-5c4pNz3fc=.5415d53d-8385-4295-b9ed-22ae3d06b3ff@github.com> Message-ID: On Mon, 24 Feb 2025 15:23:22 GMT, Vicente Romero wrote: > this method will invoke Class::isInstance again, probably better to just do `(c -> (ClassSymbol)c)`? I was under the impression that with Hotspot, there was no performance difference between `ClassSymbol.class::cast` and `c -> (ClassSymbol)c`. Is that not correct? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23704#discussion_r1968047747 From vromero at openjdk.org Mon Feb 24 17:02:55 2025 From: vromero at openjdk.org (Vicente Romero) Date: Mon, 24 Feb 2025 17:02:55 GMT Subject: RFR: 8320220: Compilation of cyclic hierarchy causes infinite recursion In-Reply-To: References: <9ei59jNCNfQo2jsi-74yihMX0QLtp6eQq-5c4pNz3fc=.5415d53d-8385-4295-b9ed-22ae3d06b3ff@github.com> Message-ID: On Mon, 24 Feb 2025 16:46:35 GMT, Archie Cobbs wrote: >>> wouldn't a ClassSymbol method be better here like ClassSymbol::isSubClass? >>> ... >>> this method will invoke Class::isInstance again, probably better to just do (c -> (ClassSymbol)c)? >> >> My goal was to replicate the existing logic, but do it for every class in `seenClasses` instead of just the current one. But I was not able to prove to myself that every symbol in `seenClasses` is in fact a `ClassSymbol`, although that may actually be true in practice. So that's why the code is being careful not to blind casting everything in `seenClasses` to `ClassSymbol`. >> >> If you're confident that every symbol in `seenClasses` is always a `ClassSymbol` then we can simplify this... but if so, why wasn't `seenClasses` declared as a `Set` instead of a `Set` in the first place? I'm wondering there is some weird (probably invalid) input that could cause that assumption to be violated. >> >> Thanks for taking a look. > > Following up on previous comment... > >> I'm wondering there is some weird (probably invalid) input that could cause that assumption to be violated. > > In fact, if we just blindly cast then there are 3 regression test failures. In particular, this input crashes the compiler: > > public class Cyclic { > static class Outer { > class Inner {} > } > static class Test { > class InnerTest extends X.Inner { InnerTest(Outer o) {o.super();} } > } > } > > with this error: > > Finished building target 'interim-langtools' in configuration 'macosx-aarch64-server-release' > An exception has occurred in the compiler (25-internal). 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.ClassCastException: class com.sun.tools.javac.code.Symbol$TypeVariableSymbol cannot be cast to class com.sun.tools.javac.code.Symbol$ClassSymbol (com.sun.tools.javac.code.Symbol$TypeVariableSymbol and com.sun.tools.javac.code.Symbol$ClassSymbol are in module jdk.compiler.interim of loader 'app') > at jdk.compiler.interim/com.sun.tools.javac.comp.Check$CycleChecker.checkSymbol(Check.java:2329) > at jdk.compiler.interim/com.sun.tools.javac.comp.Check$CycleChecker.visitIdent(Check.java:2345) > at jdk.compiler.interim/com.sun.tools.javac.tree.JCTree$JCIdent.accept(JCTree.java:2710) > at jdk.compiler.interim/com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:50) > ... yep I was thinking that tests will tell us if we could go or not with my proposal, nice that we have tests covering this, thanks for trying out ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23704#discussion_r1968057627 From vromero at openjdk.org Mon Feb 24 17:17:52 2025 From: vromero at openjdk.org (Vicente Romero) Date: Mon, 24 Feb 2025 17:17:52 GMT Subject: RFR: 8320220: Compilation of cyclic hierarchy causes infinite recursion In-Reply-To: References: Message-ID: On Wed, 19 Feb 2025 18:15:51 GMT, Archie Cobbs wrote: > This input currently causes an infinite loop: > > interface A extends B, C {} > interface B extends A {} > interface C extends A {} > > However, less complicated cycles are handled properly. > > When a cycle is found, we currently: > (a) Emit a warning; and > (b) Set the symbol's type to the error type. > > These two steps are done in `Check.noteCyclic()`. > > Step (b) is what normally prevents the infinite loop from happening later in the compilation. But we only do this for the first class in the loop, presumably because it would be too verbose to do (a) for every class in the loop. But that means we're also only doing (b) for the first class in the loop. > > In more complicated scenarios like the bug example, that means some classes in the cycle can escape without (b) being applied. But this is incorrect (or, at least, weirdly indeterminate) because a loop is a loop no matter which class you start with. > > So the solution is to continue to do (a) only to the first class in the cycle but do (b) for every class in the cycle. looks sensible ------------- Marked as reviewed by vromero (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23704#pullrequestreview-2637883766 From vromero at openjdk.org Mon Feb 24 17:17:53 2025 From: vromero at openjdk.org (Vicente Romero) Date: Mon, 24 Feb 2025 17:17:53 GMT Subject: RFR: 8320220: Compilation of cyclic hierarchy causes infinite recursion In-Reply-To: References: <9ei59jNCNfQo2jsi-74yihMX0QLtp6eQq-5c4pNz3fc=.5415d53d-8385-4295-b9ed-22ae3d06b3ff@github.com> Message-ID: On Mon, 24 Feb 2025 16:54:18 GMT, Archie Cobbs wrote: >> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 2381: >> >>> 2379: .filter(s -> !s.type.isErroneous()) >>> 2380: .filter(ClassSymbol.class::isInstance) >>> 2381: .map(ClassSymbol.class::cast) >> >> this method will invoke Class::isInstance again, probably better to just do `(c -> (ClassSymbol)c)`? > >> this method will invoke Class::isInstance again, probably better to just do `(c -> (ClassSymbol)c)`? > > I was under the impression that with Hotspot, there was no performance difference between `ClassSymbol.class::cast` and `c -> (ClassSymbol)c`. Is that not correct? yep we should be fine here, probably just a matter of personal preference I guess ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23704#discussion_r1968081303 From acobbs at openjdk.org Mon Feb 24 17:28:55 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Mon, 24 Feb 2025 17:28:55 GMT Subject: RFR: 8320220: Compilation of cyclic hierarchy causes infinite recursion In-Reply-To: References: Message-ID: On Wed, 19 Feb 2025 18:15:51 GMT, Archie Cobbs wrote: > This input currently causes an infinite loop: > > interface A extends B, C {} > interface B extends A {} > interface C extends A {} > > However, less complicated cycles are handled properly. > > When a cycle is found, we currently: > (a) Emit a warning; and > (b) Set the symbol's type to the error type. > > These two steps are done in `Check.noteCyclic()`. > > Step (b) is what normally prevents the infinite loop from happening later in the compilation. But we only do this for the first class in the loop, presumably because it would be too verbose to do (a) for every class in the loop. But that means we're also only doing (b) for the first class in the loop. > > In more complicated scenarios like the bug example, that means some classes in the cycle can escape without (b) being applied. But this is incorrect (or, at least, weirdly indeterminate) because a loop is a loop no matter which class you start with. > > So the solution is to continue to do (a) only to the first class in the cycle but do (b) for every class in the cycle. Thanks for the review! ------------- PR Comment: https://git.openjdk.org/jdk/pull/23704#issuecomment-2679169395 From jlahoda at openjdk.org Mon Feb 24 17:35:57 2025 From: jlahoda at openjdk.org (Jan Lahoda) Date: Mon, 24 Feb 2025 17:35:57 GMT Subject: RFR: 8320220: Compilation of cyclic hierarchy causes infinite recursion In-Reply-To: References: Message-ID: On Wed, 19 Feb 2025 18:15:51 GMT, Archie Cobbs wrote: > This input currently causes an infinite loop: > > interface A extends B, C {} > interface B extends A {} > interface C extends A {} > > However, less complicated cycles are handled properly. > > When a cycle is found, we currently: > (a) Emit a warning; and > (b) Set the symbol's type to the error type. > > These two steps are done in `Check.noteCyclic()`. > > Step (b) is what normally prevents the infinite loop from happening later in the compilation. But we only do this for the first class in the loop, presumably because it would be too verbose to do (a) for every class in the loop. But that means we're also only doing (b) for the first class in the loop. > > In more complicated scenarios like the bug example, that means some classes in the cycle can escape without (b) being applied. But this is incorrect (or, at least, weirdly indeterminate) because a loop is a loop no matter which class you start with. > > So the solution is to continue to do (a) only to the first class in the cycle but do (b) for every class in the cycle. FWIW, looks OK to me. It is difficult to estimate if there will be an impact from making the errors for the whole cycle erroneous, but we'll see. FWIW, I tried to find out an example that wouldn't be fixed by this patch, but I couldn't. ------------- Marked as reviewed by jlahoda (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23704#pullrequestreview-2637925931 From acobbs at openjdk.org Mon Feb 24 17:46:58 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Mon, 24 Feb 2025 17:46:58 GMT Subject: RFR: 8320220: Compilation of cyclic hierarchy causes infinite recursion In-Reply-To: References: Message-ID: On Mon, 24 Feb 2025 17:33:24 GMT, Jan Lahoda wrote: > It is difficult to estimate if there will be an impact from making the errors for the whole cycle erroneous, but we'll see. Thanks for taking a look. My hope is that (other than the minor performance hit) this change can only help avoid problems, because when you have a loop, the choice of starting class is fundamentally arbitrary. So if we assume the previous code, which only marked the first class in the loop as erroneous, was correct, then it must have been correct if it started with any other class in the loop (i.e., there is no "order"). Therefore, it must be correct to mark every class in the loop as erroneous ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/23704#issuecomment-2679211904 From mcimadamore at openjdk.org Mon Feb 24 18:02:03 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 24 Feb 2025 18:02:03 GMT Subject: RFR: 8349991: GraphUtils.java can use String.replace() instead of String.replaceAll() In-Reply-To: References: Message-ID: On Mon, 17 Feb 2025 02:38:20 GMT, Archie Cobbs wrote: > This is a tiny performance improvement that replaces a few invocations of `String.replaceAll()` with equivalent invocations of `String.replace(char, char)` and avoids the unnecessary use of regular expressions. Marked as reviewed by mcimadamore (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23658#pullrequestreview-2637980296 From acobbs at openjdk.org Mon Feb 24 18:02:03 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Mon, 24 Feb 2025 18:02:03 GMT Subject: RFR: 8349991: GraphUtils.java can use String.replace() instead of String.replaceAll() In-Reply-To: References: Message-ID: <7pnXtGZmQmlJC1dEhRj08jVbLRz_Z-bCXfvySb3eRLg=.2c33501f-1cfc-4aca-bcbf-3f67f44367fa@github.com> On Mon, 17 Feb 2025 02:38:20 GMT, Archie Cobbs wrote: > This is a tiny performance improvement that replaces a few invocations of `String.replaceAll()` with equivalent invocations of `String.replace(char, char)` and avoids the unnecessary use of regular expressions. Thanks for the review! ------------- PR Comment: https://git.openjdk.org/jdk/pull/23658#issuecomment-2679247388 From mcimadamore at openjdk.org Mon Feb 24 18:02:03 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 24 Feb 2025 18:02:03 GMT Subject: RFR: 8349991: GraphUtils.java can use String.replace() instead of String.replaceAll() In-Reply-To: References: Message-ID: On Mon, 24 Feb 2025 14:11:10 GMT, Florent Guillaume wrote: > But `replace` replaces all occurrences already. Ah yes - that's where I got confused - thanks. (`replace` vs. `replaceAll` vs. `replaceFirst` mix a number of different concerns - such as one vs. many and string vs. char). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23658#discussion_r1968141310 From mcimadamore at openjdk.org Tue Feb 25 12:38:56 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 25 Feb 2025 12:38:56 GMT Subject: RFR: 8224228: No way to locally suppress lint warnings in parser/tokenizer or preview features [v13] In-Reply-To: <4wmgls23vON4kW3mE-tuza_zAD4mJkVhNXBoPn2ibRA=.917c3fd4-a32b-4911-939b-9718fb5243c9@github.com> References: <4wmgls23vON4kW3mE-tuza_zAD4mJkVhNXBoPn2ibRA=.917c3fd4-a32b-4911-939b-9718fb5243c9@github.com> Message-ID: On Fri, 21 Feb 2025 21:29:09 GMT, Archie Cobbs wrote: >> This PR updates the `DeferredLintHandler` so that deferred warnings can be registered during parsing, before any `JCTree` nodes have been created, and it uses this new capability to update the `"preview"` and `"text-blocks"` Lint warnings so that they can be suppressed via `@SuppressWarnings` annotations. More details are provided in additional comments. >> >> Note: This PR depends on (i.e., includes and extends) these other "cleanup" PR's: >> * #23167 >> * #23281 >> * #23400 >> * #23669 >> * #23730 > > Archie Cobbs has updated the pull request incrementally with two additional commits since the last revision: > > - Merge branch 'JDK-8350514' (split out as sub-task) into JDK-8224228. > - Refactor MandatoryWarningHandler to support dynamic verbosity. Question -- in a [related change](https://github.com/openjdk/jdk/pull/23281) we cleaned up the deferred lint handler code to use trees instead of positions, as positions were too weak. This PR now adds a parsing mode which effectively uses position again. The fact that we have two ways of doing things worries me a bit -- if we want to keep using deferred lint handler in all places (both parser and after parsing) either it works on the lowest common denominator (the position), or we make some extra work in contexts where we only have a position but we need a tree. Now, in Parser, I see that `reportDanglingComment` was using a tree (which should be better?) but is reverted to work on position by this PR. There's also a couple of lexer warnings issued by the tokenizer -- I wonder if it should be possible to find a tree in there (but I'll come back to that) As for preview warnings, all the usages of such warnings in the parser are of the kind: checkSourceLevel(pos, Feature.XYZ); // keep parsing The problem is, of course that, in parsing we're not in a top-down visitor, so we can't push/pop the deferred lint handler correctly (to make sure that all lint warnings are associated to the correct program element). That said, instead of reporting the warning directly, we could *buffer* them, and then report them against the deferred lint handler once we know to which declaration they belong to (which we can do once the parser creates such declaration node). I guess what I'm envisioning is something like this: * the compiler sees use of a preview feature deep inside the body of method `m` * the compiler stash the lint warning for this preview feature as an action in a todo list * eventually, the compiler will create the tree node for the enclosing method `m` * at this point we have a suitable tree, so we can "push" `m` onto the deferred lint handler * run all the pending lint actions in the queue * pop `m` from the deferred lint handler If we get this right, I think such a mechanism can also be reused by the tokenizer, and seems less invasive on deferred lint handler -- which will now be back to one "mode", and won't have to do expensive things such as trying to figure out which tree is associated to which lint warning pos. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23237#issuecomment-2681830676 From jlahoda at openjdk.org Tue Feb 25 14:07:04 2025 From: jlahoda at openjdk.org (Jan Lahoda) Date: Tue, 25 Feb 2025 14:07:04 GMT Subject: RFR: 8224228: No way to locally suppress lint warnings in parser/tokenizer or preview features [v13] In-Reply-To: <4wmgls23vON4kW3mE-tuza_zAD4mJkVhNXBoPn2ibRA=.917c3fd4-a32b-4911-939b-9718fb5243c9@github.com> References: <4wmgls23vON4kW3mE-tuza_zAD4mJkVhNXBoPn2ibRA=.917c3fd4-a32b-4911-939b-9718fb5243c9@github.com> Message-ID: On Fri, 21 Feb 2025 21:29:09 GMT, Archie Cobbs wrote: >> This PR updates the `DeferredLintHandler` so that deferred warnings can be registered during parsing, before any `JCTree` nodes have been created, and it uses this new capability to update the `"preview"` and `"text-blocks"` Lint warnings so that they can be suppressed via `@SuppressWarnings` annotations. More details are provided in additional comments. >> >> Note: This PR depends on (i.e., includes and extends) these other "cleanup" PR's: >> * #23167 >> * #23281 >> * #23400 >> * #23669 >> * #23730 > > Archie Cobbs has updated the pull request incrementally with two additional commits since the last revision: > > - Merge branch 'JDK-8350514' (split out as sub-task) into JDK-8224228. > - Refactor MandatoryWarningHandler to support dynamic verbosity. I agree with Maurizio - can this be done mostly in the parser, keeping a side list of pending warning handlers only in parser, and pushing it to the `DeferredLintHandler` only when a declaration is done/created? Not only the `DeferredLintHandler` could presumably remain more or less as it is, maybe we wouldn't need to track the end positions so precisely? ------------- PR Comment: https://git.openjdk.org/jdk/pull/23237#issuecomment-2682084548 From acobbs at openjdk.org Tue Feb 25 19:42:00 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Tue, 25 Feb 2025 19:42:00 GMT Subject: Integrated: 8349991: GraphUtils.java can use String.replace() instead of String.replaceAll() In-Reply-To: References: Message-ID: On Mon, 17 Feb 2025 02:38:20 GMT, Archie Cobbs wrote: > This is a tiny performance improvement that replaces a few invocations of `String.replaceAll()` with equivalent invocations of `String.replace(char, char)` and avoids the unnecessary use of regular expressions. This pull request has now been integrated. Changeset: a3188e04 Author: Archie Cobbs URL: https://git.openjdk.org/jdk/commit/a3188e0406bcd69468de0444038525d3d069699f Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod 8349991: GraphUtils.java can use String.replace() instead of String.replaceAll() Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.org/jdk/pull/23658 From acobbs at openjdk.org Tue Feb 25 19:42:08 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Tue, 25 Feb 2025 19:42:08 GMT Subject: Integrated: 8320220: Compilation of cyclic hierarchy causes infinite recursion In-Reply-To: References: Message-ID: On Wed, 19 Feb 2025 18:15:51 GMT, Archie Cobbs wrote: > This input currently causes an infinite loop: > > interface A extends B, C {} > interface B extends A {} > interface C extends A {} > > However, less complicated cycles are handled properly. > > When a cycle is found, we currently: > (a) Emit a warning; and > (b) Set the symbol's type to the error type. > > These two steps are done in `Check.noteCyclic()`. > > Step (b) is what normally prevents the infinite loop from happening later in the compilation. But we only do this for the first class in the loop, presumably because it would be too verbose to do (a) for every class in the loop. But that means we're also only doing (b) for the first class in the loop. > > In more complicated scenarios like the bug example, that means some classes in the cycle can escape without (b) being applied. But this is incorrect (or, at least, weirdly indeterminate) because a loop is a loop no matter which class you start with. > > So the solution is to continue to do (a) only to the first class in the cycle but do (b) for every class in the cycle. This pull request has now been integrated. Changeset: b78043fd Author: Archie Cobbs URL: https://git.openjdk.org/jdk/commit/b78043fdc64dba62293631ad0cc263029e8dfb1e Stats: 24 lines in 3 files changed: 19 ins; 0 del; 5 mod 8320220: Compilation of cyclic hierarchy causes infinite recursion Reviewed-by: vromero, jlahoda ------------- PR: https://git.openjdk.org/jdk/pull/23704 From acobbs at openjdk.org Tue Feb 25 20:05:56 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Tue, 25 Feb 2025 20:05:56 GMT Subject: RFR: 8224228: No way to locally suppress lint warnings in parser/tokenizer or preview features [v13] In-Reply-To: References: <4wmgls23vON4kW3mE-tuza_zAD4mJkVhNXBoPn2ibRA=.917c3fd4-a32b-4911-939b-9718fb5243c9@github.com> Message-ID: On Tue, 25 Feb 2025 12:36:12 GMT, Maurizio Cimadamore wrote: > Question -- in a [related change](https://github.com/openjdk/jdk/pull/23281) we cleaned up the deferred lint handler code to use trees instead of positions, as positions were too weak. This PR now adds a parsing mode which effectively uses position again. Well to be precise, the earlier change didn't really alter how we tracked anything, it just tightened up the declared types in the Java source (from `DiagnosticPosition` to `JCTree`) - the same actual objects are being used for tracking as before. So the code was "pretending" to use positions before, but it really was using trees. > The fact that we have two ways of doing things worries me a bit -- if we want to keep using deferred lint handler in all places (both parser and after parsing) either it works on the lowest common denominator (the position), or we make some extra work in contexts where we only have a position but we need a tree. I agree with the gist of what you're saying, i.e., Why have two ways of doing something? So if I understand correctly, you and @lahodaj are suggesting the following: 1. Don't change how `DeferredLintHandler` tracks pending warnings, i.e., by their innermost containing `JCTree` declaration node. 1. Add another layer of "deferral", this one private to the parser, in which lexical warnings are deferred until their innermost `JCTree` declaration is created, at which time they can then be passed on to `DeferredLintHandler` like normal. In my opinion Step 2 must be done in such a way that any future lexical warnings are able to "easily" use it, as we have several lexical lint warning feature requests queued up such as [JDK-8271171](https://bugs.openjdk.org/browse/JDK-8271171), [JDK-8210681](https://bugs.openjdk.org/browse/JDK-8210681), [JDK-6764629](https://bugs.openjdk.org/browse/JDK-6764629). I will take a look at doing something like this in the parser. Basically, following Maurizio's steps. We still have two ways of doing things but at least this way they'll be a little more compartmentalized... :) Thanks for the comments. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23237#issuecomment-2683161693 From mcimadamore at openjdk.org Wed Feb 26 12:59:56 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 26 Feb 2025 12:59:56 GMT Subject: RFR: 8224228: No way to locally suppress lint warnings in parser/tokenizer or preview features [v13] In-Reply-To: References: <4wmgls23vON4kW3mE-tuza_zAD4mJkVhNXBoPn2ibRA=.917c3fd4-a32b-4911-939b-9718fb5243c9@github.com> Message-ID: On Tue, 25 Feb 2025 20:02:56 GMT, Archie Cobbs wrote: > We still have two ways of doing things but at least this way they'll be a little more compartmentalized... :) Well yes, but from the perspective of user model (and deferred lint handler) -- a lint warning would be _always_ be associated with some declaration. So it's up to the clients that have special requirements (such as parser and tokenizer) to make up for the difference -- rather than coming up with a more general way to map positions back to tree (which, if done, well at that point you could well be using positions everywhere). Thanks for taking a look. P.S. I see a lot of changes related to positions -- @lahodaj @archiecobbs do you thing that https://github.com/openjdk/jdk/pull/23669 would still be nice to have even if we don't need to map positions back to trees? ------------- PR Comment: https://git.openjdk.org/jdk/pull/23237#issuecomment-2684884768 From jlahoda at openjdk.org Wed Feb 26 13:25:03 2025 From: jlahoda at openjdk.org (Jan Lahoda) Date: Wed, 26 Feb 2025 13:25:03 GMT Subject: RFR: 8224228: No way to locally suppress lint warnings in parser/tokenizer or preview features [v13] In-Reply-To: <4wmgls23vON4kW3mE-tuza_zAD4mJkVhNXBoPn2ibRA=.917c3fd4-a32b-4911-939b-9718fb5243c9@github.com> References: <4wmgls23vON4kW3mE-tuza_zAD4mJkVhNXBoPn2ibRA=.917c3fd4-a32b-4911-939b-9718fb5243c9@github.com> Message-ID: On Fri, 21 Feb 2025 21:29:09 GMT, Archie Cobbs wrote: >> This PR updates the `DeferredLintHandler` so that deferred warnings can be registered during parsing, before any `JCTree` nodes have been created, and it uses this new capability to update the `"preview"` and `"text-blocks"` Lint warnings so that they can be suppressed via `@SuppressWarnings` annotations. More details are provided in additional comments. >> >> Note: This PR depends on (i.e., includes and extends) these other "cleanup" PR's: >> * #23167 >> * #23281 >> * #23400 >> * #23669 >> * #23730 > > Archie Cobbs has updated the pull request incrementally with two additional commits since the last revision: > > - Merge branch 'JDK-8350514' (split out as sub-task) into JDK-8224228. > - Refactor MandatoryWarningHandler to support dynamic verbosity. I think I would prefer not to augment the trees with end positions until/unless we need them. Regarding the new lint warnings - we probably should be careful with introducing new lints until we have some time to think about both conceptual and implementation directions for lints inside javac. (Although I admit I may have to introduce a new lint sometime soon.) ------------- PR Comment: https://git.openjdk.org/jdk/pull/23237#issuecomment-2684946293 From hannesw at openjdk.org Wed Feb 26 15:57:01 2025 From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Wed, 26 Feb 2025 15:57:01 GMT Subject: RFR: 8350007: Add usage message to the javadoc executable [v3] In-Reply-To: References: Message-ID: On Thu, 20 Feb 2025 16:25:33 GMT, Nizar Benalla wrote: >> This patch adds a new message when you run the `javadoc` executable with any arguments. >> Currently, unlike most other tools, running `javadoc` without any arguments does not show you how to use the tool or point you to use the `--help` option, this can be improved. >> >> Before change: >> >> W $ ./javadoc >> error: No modules, packages or classes specified. >> 1 error >> >> >> After change: >> >> W $ ./javadoc >> Usage: >> javadoc [options] [packagenames] [sourcefiles] [@files] >> For additional help on usage: javadoc --help > > Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - respond to feedback > - Merge branch 'master' into javadoc-usage-message > - update test with new usage message > - improve javadoc executable message Nice, the new message is definitely an improvement over the old one. I assume the other JDK tools also exit with OK with no args? ------------- PR Review: https://git.openjdk.org/jdk/pull/23618#pullrequestreview-2645012976 From hannesw at openjdk.org Wed Feb 26 17:34:53 2025 From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Wed, 26 Feb 2025 17:34:53 GMT Subject: RFR: 8350007: Add usage message to the javadoc executable [v3] In-Reply-To: References: Message-ID: On Thu, 20 Feb 2025 16:25:33 GMT, Nizar Benalla wrote: >> This patch adds a new message when you run the `javadoc` executable with any arguments. >> Currently, unlike most other tools, running `javadoc` without any arguments does not show you how to use the tool or point you to use the `--help` option, this can be improved. >> >> Before change: >> >> W $ ./javadoc >> error: No modules, packages or classes specified. >> 1 error >> >> >> After change: >> >> W $ ./javadoc >> Usage: >> javadoc [options] [packagenames] [sourcefiles] [@files] >> For additional help on usage: javadoc --help > > Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - respond to feedback > - Merge branch 'master' into javadoc-usage-message > - update test with new usage message > - improve javadoc executable message src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/Start.java line 560: > 558: showLinesUsingKey("main.usage.short"); > 559: showLinesUsingKey("main.for-more-details-see-usage"); > 560: return OK; The currently used exit code is `2`, and the message is written to `stderr`, not `stdout`. I think these things should not be changed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23618#discussion_r1972045539 From nbenalla at openjdk.org Wed Feb 26 18:39:54 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Wed, 26 Feb 2025 18:39:54 GMT Subject: RFR: 8350007: Add usage message to the javadoc executable [v3] In-Reply-To: References: Message-ID: On Wed, 26 Feb 2025 17:32:37 GMT, Hannes Walln?fer wrote: >> Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: >> >> - respond to feedback >> - Merge branch 'master' into javadoc-usage-message >> - update test with new usage message >> - improve javadoc executable message > > src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/Start.java line 560: > >> 558: showLinesUsingKey("main.usage.short"); >> 559: showLinesUsingKey("main.for-more-details-see-usage"); >> 560: return OK; > > The currently used exit code is `2`, and the message is written to `stderr`, not `stdout`. I think these things should not be changed. `jpackage` and `jar` return 0 if there are no args. `javap` returns `2`/`EXIT_CMDERR` so it's not very consistent. This is the behavior when returning `CMDERR` nizar-mac! $ javadoc error: an unknown error has occurred Usage: javadoc [options] [packagenames] [sourcefiles] [@files] For more details on available options, use --help or --help-extra 1 error I'm not sure we want to emit an error? Returning 0 or 1 might better. But I can understand why we would want to keep those things the same. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23618#discussion_r1972143868 From acobbs at openjdk.org Wed Feb 26 19:02:21 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Wed, 26 Feb 2025 19:02:21 GMT Subject: RFR: 8224228: No way to locally suppress lint warnings in parser/tokenizer or preview features [v13] In-Reply-To: References: <4wmgls23vON4kW3mE-tuza_zAD4mJkVhNXBoPn2ibRA=.917c3fd4-a32b-4911-939b-9718fb5243c9@github.com> Message-ID: On Wed, 26 Feb 2025 12:57:11 GMT, Maurizio Cimadamore wrote: > rather than coming up with a more general way to map positions back to tree (which, if done, well at that point you could well be using positions everywhere) Yes that was the original idea... i.e., eventually use positions everywhere, but "using positions everywhere" would require a larger refactoring of how warnings are handled that is a little too far in the future to assume right now. > I think I would prefer not to augment the trees with end positions until/unless we need them. Agreed - I'll plan to remove that part and close #23669 as part of the next update here. > Regarding the new lint warnings - we probably should be careful with introducing new lints until we have some time to think about both conceptual and implementation directions for lints inside javac. That's fine, right now I'm interested in simply making suppressible lexical warnings feasible. Actually adding (more of) them is a separate issue we can consider later. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23237#issuecomment-2685933603 From nbenalla at openjdk.org Wed Feb 26 20:19:06 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Wed, 26 Feb 2025 20:19:06 GMT Subject: RFR: 8350007: Add usage message to the javadoc executable [v3] In-Reply-To: References: Message-ID: On Wed, 26 Feb 2025 18:36:50 GMT, Nizar Benalla wrote: >> src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/Start.java line 560: >> >>> 558: showLinesUsingKey("main.usage.short"); >>> 559: showLinesUsingKey("main.for-more-details-see-usage"); >>> 560: return OK; >> >> The currently used exit code is `2`, and the message is written to `stderr`, not `stdout`. I think these things should not be changed. > > `jpackage` and `jar` return 0 if there are no args. `javap` returns `2`/`EXIT_CMDERR` so it's not very consistent. > > This is the behavior when returning `CMDERR` > > > nizar-mac! $ javadoc > error: an unknown error has occurred > Usage: > javadoc [options] [packagenames] [sourcefiles] [@files] > For more details on available options, use --help or --help-extra > 1 error > > > I'm not sure we want to emit an error? Returning 0 or 1 might better. > But I can understand why we would want to keep those things the same. For the record, I discussed this offline with a couple of people. Since the user didn't ask for the help message, this is indeed be an invalid run and returning a non-zero value might be the right thing to do. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23618#discussion_r1972341508 From nbenalla at openjdk.org Wed Feb 26 21:29:30 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Wed, 26 Feb 2025 21:29:30 GMT Subject: RFR: 8350007: Add usage message to the javadoc executable [v4] In-Reply-To: References: Message-ID: > This patch adds a new message when you run the `javadoc` executable with any arguments. > Currently, unlike most other tools, running `javadoc` without any arguments does not show you how to use the tool or point you to use the `--help` option, this can be improved. > > Before change: > > W $ ./javadoc > error: No modules, packages or classes specified. > 1 error > > > After change: > > W $ ./javadoc > Usage: > javadoc [options] [packagenames] [sourcefiles] [@files] > For additional help on usage: javadoc --help Nizar Benalla has updated the pull request incrementally with two additional commits since the last revision: - update test - keep the same return value and write to STDERR ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23618/files - new: https://git.openjdk.org/jdk/pull/23618/files/3d83cbd5..d67e033b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23618&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23618&range=02-03 Stats: 5 lines in 2 files changed: 1 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/23618.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23618/head:pull/23618 PR: https://git.openjdk.org/jdk/pull/23618 From vromero at openjdk.org Thu Feb 27 18:23:54 2025 From: vromero at openjdk.org (Vicente Romero) Date: Thu, 27 Feb 2025 18:23:54 GMT Subject: RFR: 8224228: No way to locally suppress lint warnings in parser/tokenizer or preview features [v13] In-Reply-To: <4wmgls23vON4kW3mE-tuza_zAD4mJkVhNXBoPn2ibRA=.917c3fd4-a32b-4911-939b-9718fb5243c9@github.com> References: <4wmgls23vON4kW3mE-tuza_zAD4mJkVhNXBoPn2ibRA=.917c3fd4-a32b-4911-939b-9718fb5243c9@github.com> Message-ID: On Fri, 21 Feb 2025 21:29:09 GMT, Archie Cobbs wrote: >> This PR updates the `DeferredLintHandler` so that deferred warnings can be registered during parsing, before any `JCTree` nodes have been created, and it uses this new capability to update the `"preview"` and `"text-blocks"` Lint warnings so that they can be suppressed via `@SuppressWarnings` annotations. More details are provided in additional comments. >> >> Note: This PR depends on (i.e., includes and extends) these other "cleanup" PR's: >> * #23167 >> * #23281 >> * #23400 >> * #23669 >> * #23730 > > Archie Cobbs has updated the pull request incrementally with two additional commits since the last revision: > > - Merge branch 'JDK-8350514' (split out as sub-task) into JDK-8224228. > - Refactor MandatoryWarningHandler to support dynamic verbosity. `` would the design be simpler if we add a post-parser phase for this? `` ------------- PR Comment: https://git.openjdk.org/jdk/pull/23237#issuecomment-2688753519 From liach at openjdk.org Thu Feb 27 20:33:34 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 27 Feb 2025 20:33:34 GMT Subject: RFR: 8343251: Facelift for Type and AnnotatedType specifications [v9] In-Reply-To: References: Message-ID: > The Type and AnnotatedType hierarchies have been enigmatic to new users: users have no clue how to categorize arbitrary type objects, when it is safe to cast to more specific types, and the exact conditions for method contracts. > > A manifest is [JDK-8306039](https://bugs.openjdk.org/browse/JDK-8306039), where people are massively confused by the conditions for `ParameterizedType::getOwnerType` to return `null`. > > To fix these problems, I consulted the JLS, used some terms from there and added JLS links to make the definitions concise and accurate. > > Here are some actions: > 1. Add section for hierarchy overview for both Type and AnnotatedType > 2. Specify the underlying type for different AnnotatedType subinterfaces > 3. Define "inner member class" for `getOwnerType`, and refer to it in `AnnotatedType::getAnnotatedOwnerType`. > 4. Improve the specification for `ParameterizedType::getActualTypeArguments` to note the existence of owner types; also for annotated version > 5. Minor improvements to `ParameterizedType::getRawType` > 6. Move the equals specification for `ParameterizedType` to the actual `equals` method. > > ApiDiff: https://cr.openjdk.org/~liach/apidiff/types-facelift/java.base/java/lang/reflect/package-summary.html > Javadoc: https://cr.openjdk.org/~liach/javadoc/types-facelift/java.base/java/lang/reflect/package-summary.html > > Please review the associated CSR as well. Chen Liang 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: - TypeVariable fixup - Merge branch 'master' of https://github.com/openjdk/jdk into doc/owner-type - Notes about the design - Merge branch 'master' of https://github.com/openjdk/jdk into doc/owner-type - Year and typos - Merge branch 'm5' into doc/owner-type - Problems with owner type, kevin suggestions - Slightly improve snippet - Merge branch 'master' of https://github.com/openjdk/jdk into doc/owner-type - Merge branch 'master' of https://github.com/openjdk/jdk into doc/owner-type - ... and 11 more: https://git.openjdk.org/jdk/compare/7828c8a0...c237c2ad ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19977/files - new: https://git.openjdk.org/jdk/pull/19977/files/4f4d9b91..c237c2ad Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19977&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19977&range=07-08 Stats: 211326 lines in 5010 files changed: 106495 ins; 83078 del; 21753 mod Patch: https://git.openjdk.org/jdk/pull/19977.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19977/head:pull/19977 PR: https://git.openjdk.org/jdk/pull/19977 From liach at openjdk.org Thu Feb 27 20:33:37 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 27 Feb 2025 20:33:37 GMT Subject: RFR: 8343251: Facelift for Type and AnnotatedType specifications [v8] In-Reply-To: References: Message-ID: On Fri, 10 Jan 2025 21:53:20 GMT, Chen Liang wrote: >> The Type and AnnotatedType hierarchies have been enigmatic to new users: users have no clue how to categorize arbitrary type objects, when it is safe to cast to more specific types, and the exact conditions for method contracts. >> >> A manifest is [JDK-8306039](https://bugs.openjdk.org/browse/JDK-8306039), where people are massively confused by the conditions for `ParameterizedType::getOwnerType` to return `null`. >> >> To fix these problems, I consulted the JLS, used some terms from there and added JLS links to make the definitions concise and accurate. >> >> Here are some actions: >> 1. Add section for hierarchy overview for both Type and AnnotatedType >> 2. Specify the underlying type for different AnnotatedType subinterfaces >> 3. Define "inner member class" for `getOwnerType`, and refer to it in `AnnotatedType::getAnnotatedOwnerType`. >> 4. Improve the specification for `ParameterizedType::getActualTypeArguments` to note the existence of owner types; also for annotated version >> 5. Minor improvements to `ParameterizedType::getRawType` >> 6. Move the equals specification for `ParameterizedType` to the actual `equals` method. >> >> ApiDiff: https://cr.openjdk.org/~liach/apidiff/types-facelift/java.base/java/lang/reflect/package-summary.html >> Javadoc: https://cr.openjdk.org/~liach/javadoc/types-facelift/java.base/java/lang/reflect/package-summary.html >> >> Please review the associated CSR as well. > > Chen Liang 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 17 additional commits since the last revision: > > - Year and typos > - Merge branch 'm5' into doc/owner-type > - Problems with owner type, kevin suggestions > - Slightly improve snippet > - Merge branch 'master' of https://github.com/openjdk/jdk into doc/owner-type > - Merge branch 'master' of https://github.com/openjdk/jdk into doc/owner-type > - Improve getRawType > - Intro and other various improvements > - Merge branch 'master' of https://github.com/openjdk/jdk into doc/owner-type > - Cleanup > - ... and 7 more: https://git.openjdk.org/jdk/compare/878b88cd...4f4d9b91 I have updated the CR preview and did some minor updates; please review again. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19977#issuecomment-2689045628 From mcimadamore at openjdk.org Fri Feb 28 10:04:57 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 28 Feb 2025 10:04:57 GMT Subject: RFR: 8224228: No way to locally suppress lint warnings in parser/tokenizer or preview features [v13] In-Reply-To: References: <4wmgls23vON4kW3mE-tuza_zAD4mJkVhNXBoPn2ibRA=.917c3fd4-a32b-4911-939b-9718fb5243c9@github.com> Message-ID: On Thu, 27 Feb 2025 18:21:00 GMT, Vicente Romero wrote: > `` would the design be simpler if we add a post-parser phase for this? `` Not a crazy idea at all. Something similar was tried here: https://github.com/openjdk/jdk/pull/23281#issuecomment-2640782274 An attempt was made to avoid deferral of lint warnings in general, and put all checks in the new pass we have. But it turned out to be more than we can chew -- at least in the sense that it's hard to get there in one single shot. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23237#issuecomment-2690231622 From duke at openjdk.org Fri Feb 28 15:06:04 2025 From: duke at openjdk.org (David Beaumont) Date: Fri, 28 Feb 2025 15:06:04 GMT Subject: RFR: 8338675: javac shouldn't silently change .jar files on the classpath [v3] In-Reply-To: References: Message-ID: On Fri, 21 Feb 2025 08:47:27 GMT, Jan Lahoda wrote: >> David Beaumont has updated the pull request incrementally with one additional commit since the last revision: >> >> Changes based on PR feedback. > > The fix as such seems reasonable to me. The test is good, but I added some comments for possible improvements for the test. @lahodaj Is there anything else you think needs to be done for this PR? I think the CSR will be finalized very soon. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23699#issuecomment-2690867673 From acobbs at openjdk.org Fri Feb 28 17:27:33 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Fri, 28 Feb 2025 17:27:33 GMT Subject: RFR: 8224228: No way to locally suppress lint warnings in parser/tokenizer or preview features [v14] In-Reply-To: References: Message-ID: > This PR updates the `DeferredLintHandler` so that deferred warnings can be registered during parsing, before any `JCTree` nodes have been created, and it uses this new capability to update the `"preview"` and `"text-blocks"` Lint warnings so that they can be suppressed via `@SuppressWarnings` annotations. More details are provided in additional comments. > > Note: This PR depends on (i.e., includes and extends) these other "cleanup" PR's: > * #23167 > * #23281 > * #23400 > * #23669 > * #23730 Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision: Refactor to map positions to declarations all within the parser. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23237/files - new: https://git.openjdk.org/jdk/pull/23237/files/f1e2a593..1161e80c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23237&range=13 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23237&range=12-13 Stats: 786 lines in 14 files changed: 258 ins; 465 del; 63 mod Patch: https://git.openjdk.org/jdk/pull/23237.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23237/head:pull/23237 PR: https://git.openjdk.org/jdk/pull/23237 From acobbs at openjdk.org Fri Feb 28 17:29:08 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Fri, 28 Feb 2025 17:29:08 GMT Subject: RFR: 8350212: Track source end positions of declarations that support @SuppressWarnings [v2] In-Reply-To: References: Message-ID: On Tue, 18 Feb 2025 03:46:52 GMT, Archie Cobbs wrote: >> This PR is a sub-task split off from [JDK-8224228](https://bugs.openjdk.org/browse/JDK-8224228), which seeks to add `@SuppressWarnings` support for lexical features. >> >> Lexical features don't know about classes, members or symbols, so their source file positions must be matched to the source file character offset range of the innermost containing `JCModuleDecl`, `JCPackageDecl`, `JCClassDecl`, `JCMethodDecl`, or `JCVariableDecl`. That means we need the end positions of all such declarations to be available. >> >> The parser doesn't normally store lexical end positions unless explicitly requested, and we don't want to mandate it for performance reasons. >> >> Instead, we can just add an `int endPos` field to these five AST nodes. This field can be populated as part of the normal parsing of these node types, which already supports the (optional) tracking of end positions. > > Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision: > > Add end position for variables coming from variableDeclaratorId(). Closing this PR; we decided not to do this in #23237. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23669#issuecomment-2691183379 From acobbs at openjdk.org Fri Feb 28 17:29:08 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Fri, 28 Feb 2025 17:29:08 GMT Subject: Withdrawn: 8350212: Track source end positions of declarations that support @SuppressWarnings In-Reply-To: References: Message-ID: On Tue, 18 Feb 2025 02:39:37 GMT, Archie Cobbs wrote: > This PR is a sub-task split off from [JDK-8224228](https://bugs.openjdk.org/browse/JDK-8224228), which seeks to add `@SuppressWarnings` support for lexical features. > > Lexical features don't know about classes, members or symbols, so their source file positions must be matched to the source file character offset range of the innermost containing `JCModuleDecl`, `JCPackageDecl`, `JCClassDecl`, `JCMethodDecl`, or `JCVariableDecl`. That means we need the end positions of all such declarations to be available. > > The parser doesn't normally store lexical end positions unless explicitly requested, and we don't want to mandate it for performance reasons. > > Instead, we can just add an `int endPos` field to these five AST nodes. This field can be populated as part of the normal parsing of these node types, which already supports the (optional) tracking of end positions. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/23669 From acobbs at openjdk.org Fri Feb 28 17:31:54 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Fri, 28 Feb 2025 17:31:54 GMT Subject: RFR: 8224228: No way to locally suppress lint warnings in parser/tokenizer or preview features [v14] In-Reply-To: References: Message-ID: <5AYzMAuS-cqMjIUntIrwhWVKIv3UdjeWURhv5Wg9D1c=.a487dca7-f537-46a6-91d5-011d8007bdca@github.com> On Fri, 28 Feb 2025 17:27:33 GMT, Archie Cobbs wrote: >> This PR updates the `DeferredLintHandler` so that deferred warnings can be registered during parsing, before any `JCTree` nodes have been created, and it uses this new capability to update the `"preview"` and `"text-blocks"` Lint warnings so that they can be suppressed via `@SuppressWarnings` annotations. More details are provided in additional comments. >> >> Note: This PR depends on (i.e., includes and extends) these other "cleanup" PR's: >> * #23167 >> * #23281 >> * #23400 >> * #23730 > > Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision: > > Refactor to map positions to declarations all within the parser. I've take a stab at the refactoring we discussed above. Now all of the work of mapping source code positions to `JCTree` declarations is handled entirely within the parser by a new class `LexicalLintManager`. Fire away :) ------------- PR Comment: https://git.openjdk.org/jdk/pull/23237#issuecomment-2691190576 From jlahoda at openjdk.org Fri Feb 28 17:45:53 2025 From: jlahoda at openjdk.org (Jan Lahoda) Date: Fri, 28 Feb 2025 17:45:53 GMT Subject: RFR: 8338675: javac shouldn't silently change .jar files on the classpath [v3] In-Reply-To: <4efJygBoE1wIQ_8cFcFdrfjMbfl_FifK3sroTwcxVWc=.8c049200-6cc9-45a8-a448-ceadc1fa9f81@github.com> References: <4efJygBoE1wIQ_8cFcFdrfjMbfl_FifK3sroTwcxVWc=.8c049200-6cc9-45a8-a448-ceadc1fa9f81@github.com> Message-ID: On Fri, 21 Feb 2025 12:18:21 GMT, David Beaumont wrote: >> Modifying `JavacFileManager` to skip creating sibling output class files for source files found in JARs. >> >> This should match older (JDK 8) behavior whereby the JAR was not writable, and results in any newly generated class files being written to the current working directory (the output of class files into current directory isn't good, but it should match the old behavior). > > David Beaumont has updated the pull request incrementally with one additional commit since the last revision: > > Changes based on PR feedback. I think it would be useful to have an answer to this CSR question: https://bugs.openjdk.org/browse/JDK-8350492?focusedId=14755916&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14755916 I suspect best would be to have some tests for the Filer methods. Please note you'll have to mark the CSR Finalized before it is considered again. Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/23699#issuecomment-2691214687 From mcimadamore at openjdk.org Fri Feb 28 17:50:09 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 28 Feb 2025 17:50:09 GMT Subject: RFR: 8224228: No way to locally suppress lint warnings in parser/tokenizer or preview features [v14] In-Reply-To: <5AYzMAuS-cqMjIUntIrwhWVKIv3UdjeWURhv5Wg9D1c=.a487dca7-f537-46a6-91d5-011d8007bdca@github.com> References: <5AYzMAuS-cqMjIUntIrwhWVKIv3UdjeWURhv5Wg9D1c=.a487dca7-f537-46a6-91d5-011d8007bdca@github.com> Message-ID: On Fri, 28 Feb 2025 17:29:45 GMT, Archie Cobbs wrote: > I've take a stab at the refactoring we discussed above. Now all of the work of mapping source code positions to `JCTree` declarations is handled entirely within the parser by a new class `LexicalLintManager`. Fire away :) Thanks for giving a try. I have an initial question about the code. It seems like it stores all the "reports" and all the "declarations" in flat lists. Then we flush the reports once per compilation unit. This means we still have to do a lot of work to associate reports with declarations. What I had in mind was to basically do the association when `endDecl` is called. E.g. once you see a field declaration, at that point you can defer all the lint warnings that have been created for that field. This probably needs some `startDecl` (maybe). I'm sure you considered this alternative -- I'm curious as to why it was rejected? ------------- PR Comment: https://git.openjdk.org/jdk/pull/23237#issuecomment-2691221832 From mcimadamore at openjdk.org Fri Feb 28 17:58:53 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 28 Feb 2025 17:58:53 GMT Subject: RFR: 8224228: No way to locally suppress lint warnings in parser/tokenizer or preview features [v14] In-Reply-To: References: <5AYzMAuS-cqMjIUntIrwhWVKIv3UdjeWURhv5Wg9D1c=.a487dca7-f537-46a6-91d5-011d8007bdca@github.com> Message-ID: On Fri, 28 Feb 2025 17:46:46 GMT, Maurizio Cimadamore wrote: > > I've take a stab at the refactoring we discussed above. Now all of the work of mapping source code positions to `JCTree` declarations is handled entirely within the parser by a new class `LexicalLintManager`. Fire away :) > > Thanks for giving a try. I have an initial question about the code. It seems like it stores all the "reports" and all the "declarations" in flat lists. Then we flush the reports once per compilation unit. > > This means we still have to do a lot of work to associate reports with declarations. > > What I had in mind was to basically do the association when `endDecl` is called. E.g. once you see a field declaration, at that point you can defer all the lint warnings that have been created for that field. This probably needs some `startDecl` (maybe). I'm sure you considered this alternative -- I'm curious as to why it was rejected? Separately, I feel we're calling `endDecl` way more than what I had in mind. E.g. in my mental model the start/end of a "decl" is only relevant if it can have some suppression attached to it. I see the code calls out `endDecl` for things like binding variables in patterns and method parameters -- so I'm not sure I follow... ------------- PR Comment: https://git.openjdk.org/jdk/pull/23237#issuecomment-2691239401 From mcimadamore at openjdk.org Fri Feb 28 18:05:53 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 28 Feb 2025 18:05:53 GMT Subject: RFR: 8224228: No way to locally suppress lint warnings in parser/tokenizer or preview features [v14] In-Reply-To: References: <5AYzMAuS-cqMjIUntIrwhWVKIv3UdjeWURhv5Wg9D1c=.a487dca7-f537-46a6-91d5-011d8007bdca@github.com> Message-ID: <2cN_I8lU8gVirjeaSHntDKcRyvAYZpZmKKTZCC22Kxo=.89293ce9-3887-457f-b399-5e7fa446d9a4@github.com> On Fri, 28 Feb 2025 17:56:15 GMT, Maurizio Cimadamore wrote: > E.g. in my mental model the start/end of a "decl" is only relevant if it can have some suppression attached to it. What I mean is, one of these: https://github.com/openjdk/jdk/blob/master/src/jdk.compiler/share/classes/com/sun/tools/javac/code/DeferredLintHandler.java#L119 ------------- PR Comment: https://git.openjdk.org/jdk/pull/23237#issuecomment-2691251308 From mcimadamore at openjdk.org Fri Feb 28 18:11:55 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 28 Feb 2025 18:11:55 GMT Subject: RFR: 8224228: No way to locally suppress lint warnings in parser/tokenizer or preview features [v14] In-Reply-To: <2cN_I8lU8gVirjeaSHntDKcRyvAYZpZmKKTZCC22Kxo=.89293ce9-3887-457f-b399-5e7fa446d9a4@github.com> References: <5AYzMAuS-cqMjIUntIrwhWVKIv3UdjeWURhv5Wg9D1c=.a487dca7-f537-46a6-91d5-011d8007bdca@github.com> <2cN_I8lU8gVirjeaSHntDKcRyvAYZpZmKKTZCC22Kxo=.89293ce9-3887-457f-b399-5e7fa446d9a4@github.com> Message-ID: On Fri, 28 Feb 2025 18:03:07 GMT, Maurizio Cimadamore wrote: > > E.g. in my mental model the start/end of a "decl" is only relevant if it can have some suppression attached to it. > > What I mean is, one of these: https://github.com/openjdk/jdk/blob/master/src/jdk.compiler/share/classes/com/sun/tools/javac/code/DeferredLintHandler.java#L119 Ok, I think I get it -- e.g. stuff like deprecation warnings (since it's type-related) can be triggered by any variable declaration... But... the parser doesn't know what types are (yet), so IMHO, a lot of these declarations are not very interesting? ------------- PR Comment: https://git.openjdk.org/jdk/pull/23237#issuecomment-2691262487 From mcimadamore at openjdk.org Fri Feb 28 18:30:54 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 28 Feb 2025 18:30:54 GMT Subject: RFR: 8224228: No way to locally suppress lint warnings in parser/tokenizer or preview features [v14] In-Reply-To: References: Message-ID: On Fri, 28 Feb 2025 17:27:33 GMT, Archie Cobbs wrote: >> This PR updates the `DeferredLintHandler` so that deferred warnings can be registered during parsing, before any `JCTree` nodes have been created, and it uses this new capability to update the `"preview"` and `"text-blocks"` Lint warnings so that they can be suppressed via `@SuppressWarnings` annotations. More details are provided in additional comments. >> >> Note: This PR depends on (i.e., includes and extends) these other "cleanup" PR's: >> * #23167 >> * #23281 >> * #23400 >> * #23730 > > Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision: > > Refactor to map positions to declarations all within the parser. Some interesting (and extreme) cases: class Test1 { @interface A { String value(); } @SuppressWarnings("text-blocks") @A(""" trailing space here:\u0020 """) void m() { } } Or, even class Test2 { @SuppressWarnings(""" text-blocks\u0020 """) void m() { } } I'm not saying we should handle them -- more pointing out that, perhaps, trying to come up with the "perfect"/"most general" scheme here might be very difficult (if at all possible). ------------- PR Comment: https://git.openjdk.org/jdk/pull/23237#issuecomment-2691295561 From mcimadamore at openjdk.org Fri Feb 28 18:44:54 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 28 Feb 2025 18:44:54 GMT Subject: RFR: 8224228: No way to locally suppress lint warnings in parser/tokenizer or preview features [v14] In-Reply-To: References: Message-ID: On Fri, 28 Feb 2025 18:28:33 GMT, Maurizio Cimadamore wrote: > Some interesting (and extreme) cases: The first actually works correctly with the changes in this PR (presumably because the start of the method decl includes the annotation). The second is just a buggy test I think -- if there's a space after the lint category, I don't think javac can recognize it. I believe the simpler approach I proposed earlier will probably struggle to deal with the first example -- because annotations are parsed very early in a declaration (sometimes when we still don't know what we're parsing). ------------- PR Comment: https://git.openjdk.org/jdk/pull/23237#issuecomment-2691315694 From acobbs at openjdk.org Fri Feb 28 19:52:18 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Fri, 28 Feb 2025 19:52:18 GMT Subject: RFR: 8224228: No way to locally suppress lint warnings in parser/tokenizer or preview features [v15] In-Reply-To: References: Message-ID: > This PR updates the `DeferredLintHandler` so that deferred warnings can be registered during parsing, before any `JCTree` nodes have been created, and it uses this new capability to update the `"preview"` and `"text-blocks"` Lint warnings so that they can be suppressed via `@SuppressWarnings` annotations. More details are provided in additional comments. > > Note: This PR depends on (i.e., includes and extends) these other "cleanup" PR's: > * #23167 > * #23281 > * #23400 > * #23730 Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision: Add node type assertion check to endDecl() per review suggestion. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23237/files - new: https://git.openjdk.org/jdk/pull/23237/files/1161e80c..45c2aacf Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23237&range=14 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23237&range=13-14 Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/23237.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23237/head:pull/23237 PR: https://git.openjdk.org/jdk/pull/23237 From acobbs at openjdk.org Fri Feb 28 19:52:19 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Fri, 28 Feb 2025 19:52:19 GMT Subject: RFR: 8224228: No way to locally suppress lint warnings in parser/tokenizer or preview features [v14] In-Reply-To: References: <5AYzMAuS-cqMjIUntIrwhWVKIv3UdjeWURhv5Wg9D1c=.a487dca7-f537-46a6-91d5-011d8007bdca@github.com> Message-ID: On Fri, 28 Feb 2025 17:56:15 GMT, Maurizio Cimadamore wrote: > Thanks for giving a try. I have an initial question about the code. It seems like it stores all the "reports" and all the "declarations" in flat lists. Then we flush the reports once per compilation unit. > > This means we still have to do a lot of work to associate reports with declarations. I originally was handling things "as they come", based on the assumption that reports always occur prior to the completion of their containing declaration, but that's not true (`dangling-doc-comment` violates it). So I switched to storing everything then doing the match up at the end, but the flushing process still needs to be optimized to make it linear time. > What I had in mind was to basically do the association when `endDecl` is called. E.g. once you see a field declaration, at that point you can defer all the lint warnings that have been created for that field. This probably needs some `startDecl` (maybe). I'm sure you considered this alternative -- I'm curious as to why it was rejected? See previous comment - reports can come in "late", after their containing declaration. I did have a `startDecl` before but it was no longer needed once I added the logic to accommodate late reports. > Separately, I feel we're calling endDecl way more than what I had in mind. E.g. in my mental model the start/end of a "decl" is only relevant if it can have some suppression attached to it. I see the code calls out endDecl for things like binding variables in patterns and method parameters -- so I'm not sure I follow... First, we are only calling `endDecl` on declarations of: methods, packages, classes, variables, methods. I just added an assertion check similar to the one you linked to in 45c2aacff7a and it isn't firing so that's good. As for _which_ variable declarations, we need to handle any that support `@SuppressWarnings` annotations, plain and simple - even if they can't have initializers. including variables in patterns and method parameters. The reason is because we may want to handle any future _lexical_ issues contained therein. For example, after implementing [JDK-8271171](https://bugs.openjdk.org/browse/JDK-8271171), we would still want the following suppression to work: public record Example(int x) { public void method(Object f) { switch (f) { case Example(@SuppressWarnings("funky-unicode-escapes") int funkyVariable\u004Eame): break; default: break; } } } ------------- PR Comment: https://git.openjdk.org/jdk/pull/23237#issuecomment-2691431424 From mcimadamore at openjdk.org Fri Feb 28 21:54:54 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 28 Feb 2025 21:54:54 GMT Subject: RFR: 8224228: No way to locally suppress lint warnings in parser/tokenizer or preview features [v15] In-Reply-To: References: Message-ID: On Fri, 28 Feb 2025 19:52:18 GMT, Archie Cobbs wrote: >> This PR updates the `DeferredLintHandler` so that deferred warnings can be registered during parsing, before any `JCTree` nodes have been created, and it uses this new capability to update the `"preview"` and `"text-blocks"` Lint warnings so that they can be suppressed via `@SuppressWarnings` annotations. More details are provided in additional comments. >> >> Note: This PR depends on (i.e., includes and extends) these other "cleanup" PR's: >> * #23167 >> * #23281 >> * #23400 >> * #23730 > > Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision: > > Add node type assertion check to endDecl() per review suggestion. Thanks for the explanation. I think we'd probably would like to think some more on what is best to do here. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23237#issuecomment-2691608334 From mcimadamore at openjdk.org Fri Feb 28 22:06:54 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 28 Feb 2025 22:06:54 GMT Subject: RFR: 8224228: No way to locally suppress lint warnings in parser/tokenizer or preview features [v14] In-Reply-To: References: <5AYzMAuS-cqMjIUntIrwhWVKIv3UdjeWURhv5Wg9D1c=.a487dca7-f537-46a6-91d5-011d8007bdca@github.com> Message-ID: On Fri, 28 Feb 2025 19:49:35 GMT, Archie Cobbs wrote: > I originally was handling things "as they come", based on the assumption that reports always occur prior to the completion of their containing declaration, but that's not true (`dangling-doc-comment` violates it). Just one question: looking at your code, it seems that `saveDanglingDocComments` is always called _before_ `endDecl`. So I'm not sure how to read your comment. Perhaps you were hoping for all the warnings to be "contained" in the declaration body (and this would indeed be violated by comments, but also warnings on annotations). ------------- PR Comment: https://git.openjdk.org/jdk/pull/23237#issuecomment-2691622984 From mcimadamore at openjdk.org Fri Feb 28 22:12:54 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 28 Feb 2025 22:12:54 GMT Subject: RFR: 8224228: No way to locally suppress lint warnings in parser/tokenizer or preview features [v14] In-Reply-To: References: <5AYzMAuS-cqMjIUntIrwhWVKIv3UdjeWURhv5Wg9D1c=.a487dca7-f537-46a6-91d5-011d8007bdca@github.com> Message-ID: On Fri, 28 Feb 2025 22:03:55 GMT, Maurizio Cimadamore wrote: > > I originally was handling things "as they come", based on the assumption that reports always occur prior to the completion of their containing declaration, but that's not true (`dangling-doc-comment` violates it). > > Just one question: looking at your code, it seems that `saveDanglingDocComments` is always called _before_ `endDecl`. So I'm not sure how to read your comment. Perhaps you were hoping for all the warnings to be "contained" in the declaration body (and this would indeed be violated by comments, but also warnings on annotations). Maybe you mean this: class Test { /* one */ void test(/** two */ int i, /** three */ int y) { } } The two dangling warnings would be reported before the start of the method body -- but if we just flush things when we get to the closest `endDecl`, we'd report them as part of the method parameter declarations. Is that what you mean? ------------- PR Comment: https://git.openjdk.org/jdk/pull/23237#issuecomment-2691630697 From mcimadamore at openjdk.org Fri Feb 28 22:15:54 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 28 Feb 2025 22:15:54 GMT Subject: RFR: 8224228: No way to locally suppress lint warnings in parser/tokenizer or preview features [v14] In-Reply-To: References: <5AYzMAuS-cqMjIUntIrwhWVKIv3UdjeWURhv5Wg9D1c=.a487dca7-f537-46a6-91d5-011d8007bdca@github.com> Message-ID: On Fri, 28 Feb 2025 22:09:55 GMT, Maurizio Cimadamore wrote: > The two dangling warnings would be reported before the start of the method body -- but if we just flush things when we get to the closest `endDecl`, we'd report them as part of the method parameter declarations. Is that what you mean? Still, I'm confused because if I do this with the code in this PR: class Test { /** one */ void test(@SuppressWarnings("dangling-doc-comments") /** two */ int i, /** three */ int y) { } } One of the two warnings actually gets suppressed -- suggesting that the warning -- after all - is being attributed to the method parameter (which seems odd, given that method parameters cannot have javadoc comments). ------------- PR Comment: https://git.openjdk.org/jdk/pull/23237#issuecomment-2691634913 From acobbs at openjdk.org Fri Feb 28 22:59:15 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Fri, 28 Feb 2025 22:59:15 GMT Subject: RFR: 8224228: No way to locally suppress lint warnings in parser/tokenizer or preview features [v16] In-Reply-To: References: Message-ID: > This PR updates the `DeferredLintHandler` so that deferred warnings can be registered during parsing, before any `JCTree` nodes have been created, and it uses this new capability to update the `"preview"` and `"text-blocks"` Lint warnings so that they can be suppressed via `@SuppressWarnings` annotations. More details are provided in additional comments. > > Note: This PR depends on (i.e., includes and extends) these other "cleanup" PR's: > * #23167 > * #23281 > * #23400 > * #23730 Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision: Rejigger LexicalLintHandler so it runs in linear time; add unit test. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23237/files - new: https://git.openjdk.org/jdk/pull/23237/files/45c2aacf..12d8c730 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23237&range=15 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23237&range=14-15 Stats: 310 lines in 5 files changed: 240 ins; 50 del; 20 mod Patch: https://git.openjdk.org/jdk/pull/23237.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23237/head:pull/23237 PR: https://git.openjdk.org/jdk/pull/23237 From acobbs at openjdk.org Fri Feb 28 22:59:15 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Fri, 28 Feb 2025 22:59:15 GMT Subject: RFR: 8224228: No way to locally suppress lint warnings in parser/tokenizer or preview features [v14] In-Reply-To: References: <5AYzMAuS-cqMjIUntIrwhWVKIv3UdjeWURhv5Wg9D1c=.a487dca7-f537-46a6-91d5-011d8007bdca@github.com> Message-ID: On Fri, 28 Feb 2025 22:09:55 GMT, Maurizio Cimadamore wrote: > > I originally was handling things "as they come", based on the assumption that reports always occur prior to the completion of their containing declaration, but that's not true (`dangling-doc-comment` violates it). > > Just one question: looking at your code, it seems that `saveDanglingDocComments` is always called _before_ `endDecl`. So I'm not sure how to read your comment. Well I may just be confused. I saw that problem at the same time I was fighting with `VirtualParser`, so the "backwards" reports may have actually just been bogus duplicates. In any case, it's a moot point now because the issue is no longer relevant in linear time refactoring (just pushed as 12d8c730c1f0051c52bd0d5362597ab0971867c7). > One of the two warnings actually gets suppressed -- suggesting that the warning -- after all - is being attributed to the method parameter (which seems odd, given that method parameters cannot have javadoc comments). I think the behavior of that example is correct. It doesn't matter if you put a Javadoc comment in front of something that doesn't support Javadoc comments - that just makes it definitely dangling, as opposed to maybe dangling! The other thing playing into this example is that the lexical extent of variable declarations is defined to include any annotations on the declaration. Therefore the offending dangling Javadoc comment is contained by it, and therefore the suppression specified by the annotation applies. Therefore, the warning is suppressed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23237#issuecomment-2691682549 From acobbs at openjdk.org Fri Feb 28 23:02:31 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Fri, 28 Feb 2025 23:02:31 GMT Subject: RFR: 8224228: No way to locally suppress lint warnings in parser/tokenizer or preview features [v17] In-Reply-To: References: Message-ID: > This PR updates the `DeferredLintHandler` so that deferred warnings can be registered during parsing, before any `JCTree` nodes have been created, and it uses this new capability to update the `"preview"` and `"text-blocks"` Lint warnings so that they can be suppressed via `@SuppressWarnings` annotations. More details are provided in additional comments. > > Note: This PR depends on (i.e., includes and extends) these other "cleanup" PR's: > * #23167 > * #23281 > * #23400 > * #23730 Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision: Fix inconsistent bracket styling. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23237/files - new: https://git.openjdk.org/jdk/pull/23237/files/12d8c730..31ef44b1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23237&range=16 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23237&range=15-16 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23237.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23237/head:pull/23237 PR: https://git.openjdk.org/jdk/pull/23237