From jan.lahoda at oracle.com Wed Aug 6 15:54:09 2025 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 6 Aug 2025 17:54:09 +0200 Subject: Result: Dissolve the Kulla project In-Reply-To: References: Message-ID: <5b26a26f-cb75-4125-8b87-77930c0b6450@oracle.com> The vote for dissolution of the Kulla project [1] is now closed. Yes: 4 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the motion, and the Kulla project should now be dissolved. Lets use compiler-dev[2] for future JShell discussions and development. Thanks to all that contributed to this project! Jan [1] https://mail.openjdk.org/pipermail/kulla-dev/2025-July/005954.html [2] compiler-dev at openjdk.org On 18. 07. 25 14:01, Jan Lahoda wrote: > > Hello Kulla committers, > > The "Kulla" project was founded to develop JShell, and bring it into the > JDK. That happened in JDK 9, almost 8 years ago. Since then JShell has > been an integral part of the JDK. Given the Kulla project achieved its > goal and JShell is no longer any different than any other JDK component, > I am hereby proposing to dissolve[1] and archive the Kulla project. > > Votes are due by midnight UTC on August 3rd. > > Only current Kulla Committers [2] are eligible to vote on this > motion.? Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thank you, > ??? Jan > > [1] https://openjdk.org/bylaws#_6 > [2] https://openjdk.org/census#kulla > [3] https://openjdk.org/bylaws#lazy-consensus > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From acobbs at openjdk.org Mon Aug 11 19:23:59 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Mon, 11 Aug 2025 19:23:59 GMT Subject: RFR: 8348611: Eliminate DeferredLintHandler and emit warnings after attribution [v10] In-Reply-To: <08zj2WBmFFeEQbGegExwyGLIDLQV71_TmkqDA4lYad8=.50f5befe-7d49-4865-92e8-fcbbf1f5ea32@github.com> References: <08zj2WBmFFeEQbGegExwyGLIDLQV71_TmkqDA4lYad8=.50f5befe-7d49-4865-92e8-fcbbf1f5ea32@github.com> Message-ID: > This is a cleanup/refactoring of how lint warnings are logged and `@SuppressWarnings` annotations applied. > > A central challenge with lint warnings is that warnings can be generated during any compiler phase, but whether a particular lint warning is suppressed via `@SuppressWarnings` can't be known until after attribution. For example, the parser doesn't have enough information to interpret and apply `@SuppressWarnings("text-blocks")` to text blocks, or `@SuppressWarnings("preview")` to preview lexical features; instead, the `DeferredLintHandler` is used to workaround this limitation. > > In addition, several other factors complicate things: > * Knowing the current applicable `Lint` instance requires manually tracking it with each declaration visited and applying/removing the `@SuppressWarnings` annotation there, if any > * Some warnings are "suppressibly mandatory" (i.e., they are _emitted if not suppressed_ instead of _emitted if enabled_) > * Some warnings are "unsuppressibly mandatory" (e.g., the "internal proprietary API" warning) > * Some mandatory warnings are _aggregated_ into notes that are emitted at the end of compilation when not enabled > * Some warnings are _lint_ warnings, with a corresponding lint category, while others are just "plain" warnings > * Some lint warnings are suppressible via `@SuppressWarnings`, while others are only suppressible via `-Xlint:-foo` flags > * Speculative compilation requires holding log messages in purgatory until the speculation resolves, after which they are then either discarded or emitted. But this creates a tricky interaction with `DeferredLintHandler` because even after speculation is complete, we may still not yet know whether a warning should be suppressed. > > Previously the logic to get all of this right was non-obviously woven around the code base. In particular, you needed to know somehow whether or not to use `DeferredLintHandler`, and in what "mode". > > The overall goal of this PR is to simplify usage so that **no matter where you are in the compiler, you can just invoke `log.warning()` to log a warning** and (mostly) forget about all of the details listed above. Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits: - Merge branch 'master' into JDK-8348611 to fix conflict. - Remove an unnecessary field. - More simplification of LintMapper per review suggestions. - More simplification of LintMapper per review suggestions. - More refactoring to simplify LintMapper per review. - Refactor LintMapper to clean up internal type hierarchy per review. - Address a couple of review comments. - Merge branch 'master' into JDK-8348611 - Add DEFAULT_ENABLED flags to fix some mandatory warnings. - Merge branch 'master' into JDK-8348611 to fix conflicts. - ... and 87 more: https://git.openjdk.org/jdk/compare/8cd79752...18eaa8ef ------------- Changes: https://git.openjdk.org/jdk/pull/24584/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24584&range=09 Stats: 1925 lines in 56 files changed: 981 ins; 584 del; 360 mod Patch: https://git.openjdk.org/jdk/pull/24584.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24584/head:pull/24584 PR: https://git.openjdk.org/jdk/pull/24584 From vromero at openjdk.org Tue Aug 12 18:35:17 2025 From: vromero at openjdk.org (Vicente Romero) Date: Tue, 12 Aug 2025 18:35:17 GMT Subject: RFR: 8348611: Eliminate DeferredLintHandler and emit warnings after attribution [v10] In-Reply-To: References: <08zj2WBmFFeEQbGegExwyGLIDLQV71_TmkqDA4lYad8=.50f5befe-7d49-4865-92e8-fcbbf1f5ea32@github.com> Message-ID: <2l891gFnDGSFtpxiZNb7mGOzVKNpB05NHzwIXqwCihI=.48a2b2b4-6fe5-4df5-b53e-0566cba2aeb9@github.com> On Mon, 11 Aug 2025 19:23:59 GMT, Archie Cobbs wrote: >> This is a cleanup/refactoring of how lint warnings are logged and `@SuppressWarnings` annotations applied. >> >> A central challenge with lint warnings is that warnings can be generated during any compiler phase, but whether a particular lint warning is suppressed via `@SuppressWarnings` can't be known until after attribution. For example, the parser doesn't have enough information to interpret and apply `@SuppressWarnings("text-blocks")` to text blocks, or `@SuppressWarnings("preview")` to preview lexical features; instead, the `DeferredLintHandler` is used to workaround this limitation. >> >> In addition, several other factors complicate things: >> * Knowing the current applicable `Lint` instance requires manually tracking it with each declaration visited and applying/removing the `@SuppressWarnings` annotation there, if any >> * Some warnings are "suppressibly mandatory" (i.e., they are _emitted if not suppressed_ instead of _emitted if enabled_) >> * Some warnings are "unsuppressibly mandatory" (e.g., the "internal proprietary API" warning) >> * Some mandatory warnings are _aggregated_ into notes that are emitted at the end of compilation when not enabled >> * Some warnings are _lint_ warnings, with a corresponding lint category, while others are just "plain" warnings >> * Some lint warnings are suppressible via `@SuppressWarnings`, while others are only suppressible via `-Xlint:-foo` flags >> * Speculative compilation requires holding log messages in purgatory until the speculation resolves, after which they are then either discarded or emitted. But this creates a tricky interaction with `DeferredLintHandler` because even after speculation is complete, we may still not yet know whether a warning should be suppressed. >> >> Previously the logic to get all of this right was non-obviously woven around the code base. In particular, you needed to know somehow whether or not to use `DeferredLintHandler`, and in what "mode". >> >> The overall goal of this PR is to simplify usage so that **no matter where you are in the compiler, you can just invoke `log.warning()` to log a warning** and (mostly) forget about all of the details listed above. > > Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits: > > - Merge branch 'master' into JDK-8348611 to fix conflict. > - Remove an unnecessary field. > - More simplification of LintMapper per review suggestions. > - More simplification of LintMapper per review suggestions. > - More refactoring to simplify LintMapper per review. > - Refactor LintMapper to clean up internal type hierarchy per review. > - Address a couple of review comments. > - Merge branch 'master' into JDK-8348611 > - Add DEFAULT_ENABLED flags to fix some mandatory warnings. > - Merge branch 'master' into JDK-8348611 to fix conflicts. > - ... and 87 more: https://git.openjdk.org/jdk/compare/8cd79752...18eaa8ef wow, very nice! ------------- Marked as reviewed by vromero (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24584#pullrequestreview-3112215380 From acobbs at openjdk.org Tue Aug 12 19:26:21 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Tue, 12 Aug 2025 19:26:21 GMT Subject: RFR: 8348611: Eliminate DeferredLintHandler and emit warnings after attribution [v10] In-Reply-To: <2l891gFnDGSFtpxiZNb7mGOzVKNpB05NHzwIXqwCihI=.48a2b2b4-6fe5-4df5-b53e-0566cba2aeb9@github.com> References: <08zj2WBmFFeEQbGegExwyGLIDLQV71_TmkqDA4lYad8=.50f5befe-7d49-4865-92e8-fcbbf1f5ea32@github.com> <2l891gFnDGSFtpxiZNb7mGOzVKNpB05NHzwIXqwCihI=.48a2b2b4-6fe5-4df5-b53e-0566cba2aeb9@github.com> Message-ID: On Tue, 12 Aug 2025 18:32:44 GMT, Vicente Romero 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 97 commits: >> >> - Merge branch 'master' into JDK-8348611 to fix conflict. >> - Remove an unnecessary field. >> - More simplification of LintMapper per review suggestions. >> - More simplification of LintMapper per review suggestions. >> - More refactoring to simplify LintMapper per review. >> - Refactor LintMapper to clean up internal type hierarchy per review. >> - Address a couple of review comments. >> - Merge branch 'master' into JDK-8348611 >> - Add DEFAULT_ENABLED flags to fix some mandatory warnings. >> - Merge branch 'master' into JDK-8348611 to fix conflicts. >> - ... and 87 more: https://git.openjdk.org/jdk/compare/8cd79752...18eaa8ef > > wow, very nice! Hi @vicente-romero-oracle, thanks for the review, much appreciated! ------------- PR Comment: https://git.openjdk.org/jdk/pull/24584#issuecomment-3180703198 From jlahoda at openjdk.org Wed Aug 13 08:14:22 2025 From: jlahoda at openjdk.org (Jan Lahoda) Date: Wed, 13 Aug 2025 08:14:22 GMT Subject: RFR: 8348611: Eliminate DeferredLintHandler and emit warnings after attribution [v10] In-Reply-To: References: <08zj2WBmFFeEQbGegExwyGLIDLQV71_TmkqDA4lYad8=.50f5befe-7d49-4865-92e8-fcbbf1f5ea32@github.com> Message-ID: On Mon, 11 Aug 2025 19:23:59 GMT, Archie Cobbs wrote: >> This is a cleanup/refactoring of how lint warnings are logged and `@SuppressWarnings` annotations applied. >> >> A central challenge with lint warnings is that warnings can be generated during any compiler phase, but whether a particular lint warning is suppressed via `@SuppressWarnings` can't be known until after attribution. For example, the parser doesn't have enough information to interpret and apply `@SuppressWarnings("text-blocks")` to text blocks, or `@SuppressWarnings("preview")` to preview lexical features; instead, the `DeferredLintHandler` is used to workaround this limitation. >> >> In addition, several other factors complicate things: >> * Knowing the current applicable `Lint` instance requires manually tracking it with each declaration visited and applying/removing the `@SuppressWarnings` annotation there, if any >> * Some warnings are "suppressibly mandatory" (i.e., they are _emitted if not suppressed_ instead of _emitted if enabled_) >> * Some warnings are "unsuppressibly mandatory" (e.g., the "internal proprietary API" warning) >> * Some mandatory warnings are _aggregated_ into notes that are emitted at the end of compilation when not enabled >> * Some warnings are _lint_ warnings, with a corresponding lint category, while others are just "plain" warnings >> * Some lint warnings are suppressible via `@SuppressWarnings`, while others are only suppressible via `-Xlint:-foo` flags >> * Speculative compilation requires holding log messages in purgatory until the speculation resolves, after which they are then either discarded or emitted. But this creates a tricky interaction with `DeferredLintHandler` because even after speculation is complete, we may still not yet know whether a warning should be suppressed. >> >> Previously the logic to get all of this right was non-obviously woven around the code base. In particular, you needed to know somehow whether or not to use `DeferredLintHandler`, and in what "mode". >> >> The overall goal of this PR is to simplify usage so that **no matter where you are in the compiler, you can just invoke `log.warning()` to log a warning** and (mostly) forget about all of the details listed above. > > Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits: > > - Merge branch 'master' into JDK-8348611 to fix conflict. > - Remove an unnecessary field. > - More simplification of LintMapper per review suggestions. > - More simplification of LintMapper per review suggestions. > - More refactoring to simplify LintMapper per review. > - Refactor LintMapper to clean up internal type hierarchy per review. > - Address a couple of review comments. > - Merge branch 'master' into JDK-8348611 > - Add DEFAULT_ENABLED flags to fix some mandatory warnings. > - Merge branch 'master' into JDK-8348611 to fix conflicts. > - ... and 87 more: https://git.openjdk.org/jdk/compare/8cd79752...18eaa8ef Looks good to me. Two overall comments: - nice to see `ThisEscapeAnalyzer` is short-circuited, we'll see if there are more than needs to be short-circuited, but probably good to do it when there's a need, rather than pro-actively. - the semantics for `BaseFileManager`/`Locations` is slightly complex (the `Context` there may be a different `Context` than used by the rest of javac, e.g. when created through `javax.tools.JavaCompiler.getStandardFileManager`). I *think* the current code is OK with that - the warnings should be reported using the root Lint, but I am not sure if there are any tests for that. I'll see if I can add a test, but it may be done separately. src/jdk.compiler/share/classes/com/sun/tools/javac/util/Log.java line 198: > 196: lintWaitersMap.entrySet().removeIf(entry -> { > 197: > 198: // Is the source file no longer recognized? If so, discard warnings (e.g., this can happen with JShell) Just for information, do you know/recall what's the exact path to get here with JShell? ------------- Marked as reviewed by jlahoda (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24584#pullrequestreview-3114447229 PR Review Comment: https://git.openjdk.org/jdk/pull/24584#discussion_r2272448421 From acobbs at openjdk.org Wed Aug 13 15:11:22 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Wed, 13 Aug 2025 15:11:22 GMT Subject: RFR: 8348611: Eliminate DeferredLintHandler and emit warnings after attribution [v10] In-Reply-To: References: <08zj2WBmFFeEQbGegExwyGLIDLQV71_TmkqDA4lYad8=.50f5befe-7d49-4865-92e8-fcbbf1f5ea32@github.com> Message-ID: On Mon, 11 Aug 2025 19:23:59 GMT, Archie Cobbs wrote: >> This is a cleanup/refactoring of how lint warnings are logged and `@SuppressWarnings` annotations applied. >> >> A central challenge with lint warnings is that warnings can be generated during any compiler phase, but whether a particular lint warning is suppressed via `@SuppressWarnings` can't be known until after attribution. For example, the parser doesn't have enough information to interpret and apply `@SuppressWarnings("text-blocks")` to text blocks, or `@SuppressWarnings("preview")` to preview lexical features; instead, the `DeferredLintHandler` is used to workaround this limitation. >> >> In addition, several other factors complicate things: >> * Knowing the current applicable `Lint` instance requires manually tracking it with each declaration visited and applying/removing the `@SuppressWarnings` annotation there, if any >> * Some warnings are "suppressibly mandatory" (i.e., they are _emitted if not suppressed_ instead of _emitted if enabled_) >> * Some warnings are "unsuppressibly mandatory" (e.g., the "internal proprietary API" warning) >> * Some mandatory warnings are _aggregated_ into notes that are emitted at the end of compilation when not enabled >> * Some warnings are _lint_ warnings, with a corresponding lint category, while others are just "plain" warnings >> * Some lint warnings are suppressible via `@SuppressWarnings`, while others are only suppressible via `-Xlint:-foo` flags >> * Speculative compilation requires holding log messages in purgatory until the speculation resolves, after which they are then either discarded or emitted. But this creates a tricky interaction with `DeferredLintHandler` because even after speculation is complete, we may still not yet know whether a warning should be suppressed. >> >> Previously the logic to get all of this right was non-obviously woven around the code base. In particular, you needed to know somehow whether or not to use `DeferredLintHandler`, and in what "mode". >> >> The overall goal of this PR is to simplify usage so that **no matter where you are in the compiler, you can just invoke `log.warning()` to log a warning** and (mostly) forget about all of the details listed above. > > Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits: > > - Merge branch 'master' into JDK-8348611 to fix conflict. > - Remove an unnecessary field. > - More simplification of LintMapper per review suggestions. > - More simplification of LintMapper per review suggestions. > - More refactoring to simplify LintMapper per review. > - Refactor LintMapper to clean up internal type hierarchy per review. > - Address a couple of review comments. > - Merge branch 'master' into JDK-8348611 > - Add DEFAULT_ENABLED flags to fix some mandatory warnings. > - Merge branch 'master' into JDK-8348611 to fix conflicts. > - ... and 87 more: https://git.openjdk.org/jdk/compare/8cd79752...18eaa8ef Hi Jan, thanks for taking a look. > nice to see `ThisEscapeAnalyzer` is short-circuited, we'll see if there are more than needs to be short-circuited, but probably good to do it when there's a need, rather than pro-actively. Right - and to elaborate on this a bit: We added the new `WARN` phase a while back as a comfortable home for `ThisEscapeAnalyzer` and any other future non-trivial warning calculators. Since `WARN` comes after `ATTR`, all attribution and `Lint` calculations are complete, and so you can always ask, "Is Lint category X enabled here... or here... or over there...?" without worry. > the semantics for `BaseFileManager`/`Locations` is slightly complex (the `Context` there may be a different `Context` than used by the rest of javac, e.g. when created through `javax.tools.JavaCompiler.getStandardFileManager`). I _think_ the current code is OK with that - the warnings should be reported using the root Lint, but I am not sure if there are any tests for that. I'll see if I can add a test, but it may be done separately. Ah, I didn't realize that. In any case it should have the same semantics as before, because in both cases (before and after this change), the `Lint` and the `Log` singletons derive from the same `Context`. > Just for information, do you know/recall what's the exact path to get here with JShell? If you throw an `AssertionError` in that particular case, you get a failure in `ToolEnablePreviewTest.java` that looks like this (but I haven't investigated it any further): test ToolEnablePreviewTest.testCompilerTestFlag(): failure [406ms] java.lang.AssertionError: unknown source file: WrappedJavaFileObject[jdk.jshell.MemoryFileManager$SourceMemoryJavaFileObject[string:///$NeverUsedName$.java]] at jdk.compiler/com.sun.tools.javac.util.Log$DiagnosticHandler.lambda$flushLintWaiters$0(Log.java:201) at java.base/java.util.Collection.removeIf(Collection.java:581) at jdk.compiler/com.sun.tools.javac.util.Log$DiagnosticHandler.flushLintWaiters(Log.java:196) at jdk.compiler/com.sun.tools.javac.util.Log.reportOutstandingWarnings(Log.java:832) at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.errorCount(JavaCompiler.java:583) at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.invocationHelper(JavacTaskImpl.java:177) at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.parse(JavacTaskImpl.java:248) at jdk.jshell/jdk.jshell.TaskFactory$ParseTask.parse(TaskFactory.java:384) at jdk.jshell/jdk.jshell.TaskFactory$ParseTask.(TaskFactory.java:373) at jdk.jshell/jdk.jshell.TaskFactory.lambda$parse$0(TaskFactory.java:149) at jdk.jshell/jdk.jshell.TaskFactory.lambda$runTask$1(TaskFactory.java:218) at jdk.compiler/com.sun.tools.javac.api.JavacTaskPool.getTask(JavacTaskPool.java:194) at jdk.jshell/jdk.jshell.TaskFactory.runTask(TaskFactory.java:211) at jdk.jshell/jdk.jshell.TaskFactory.parse(TaskFactory.java:145) at jdk.jshell/jdk.jshell.TaskFactory.parse(TaskFactory.java:245) at jdk.jshell/jdk.jshell.CompletenessAnalyzer.lambda$scan$1(CompletenessAnalyzer.java:96) at jdk.jshell/jdk.jshell.CompletenessAnalyzer$Parser.disambiguateDeclarationVsExpression(CompletenessAnalyzer.java:769) at jdk.jshell/jdk.jshell.CompletenessAnalyzer$Parser.parseUnit(CompletenessAnalyzer.java:669) at jdk.jshell/jdk.jshell.CompletenessAnalyzer.scan(CompletenessAnalyzer.java:97) at jdk.jshell/jdk.jshell.SourceCodeAnalysisImpl.analyzeCompletion(SourceCodeAnalysisImpl.java:199) at jdk.jshell/jdk.internal.jshell.tool.JShellTool.isComplete(JShellTool.java:1356) at jdk.jshell/jdk.internal.jshell.tool.JShellTool.getInput(JShellTool.java:1297) at jdk.jshell/jdk.internal.jshell.tool.JShellTool.run(JShellTool.java:1246) at jdk.jshell/jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:1031) at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder.run(JShellToolBuilder.java:259) at ReplToolTesting.testRawRun(ReplToolTesting.java:319) at ReplToolTesting.testRaw(ReplToolTesting.java:302) at ReplToolTesting.test(ReplToolTesting.java:254) at ReplToolTesting.test(ReplToolTesting.java:241) at ReplToolTesting.test(ReplToolTesting.java:233) at ReplToolTesting.test(ReplToolTesting.java:224) at ToolEnablePreviewTest.testCompilerTestFlag(ToolEnablePreviewTest.java:97) ------------- PR Comment: https://git.openjdk.org/jdk/pull/24584#issuecomment-3184318491 From vromero at openjdk.org Wed Aug 13 16:59:22 2025 From: vromero at openjdk.org (Vicente Romero) Date: Wed, 13 Aug 2025 16:59:22 GMT Subject: RFR: 8348611: Eliminate DeferredLintHandler and emit warnings after attribution [v10] In-Reply-To: References: <08zj2WBmFFeEQbGegExwyGLIDLQV71_TmkqDA4lYad8=.50f5befe-7d49-4865-92e8-fcbbf1f5ea32@github.com> Message-ID: <8hd3w_O3ZkXfrfaKlt4tO7xaMNqMwDsq9nO326Sfaso=.f7ee7ff4-8326-47cb-85da-904582db31d7@github.com> On Mon, 11 Aug 2025 19:23:59 GMT, Archie Cobbs wrote: >> This is a cleanup/refactoring of how lint warnings are logged and `@SuppressWarnings` annotations applied. >> >> A central challenge with lint warnings is that warnings can be generated during any compiler phase, but whether a particular lint warning is suppressed via `@SuppressWarnings` can't be known until after attribution. For example, the parser doesn't have enough information to interpret and apply `@SuppressWarnings("text-blocks")` to text blocks, or `@SuppressWarnings("preview")` to preview lexical features; instead, the `DeferredLintHandler` is used to workaround this limitation. >> >> In addition, several other factors complicate things: >> * Knowing the current applicable `Lint` instance requires manually tracking it with each declaration visited and applying/removing the `@SuppressWarnings` annotation there, if any >> * Some warnings are "suppressibly mandatory" (i.e., they are _emitted if not suppressed_ instead of _emitted if enabled_) >> * Some warnings are "unsuppressibly mandatory" (e.g., the "internal proprietary API" warning) >> * Some mandatory warnings are _aggregated_ into notes that are emitted at the end of compilation when not enabled >> * Some warnings are _lint_ warnings, with a corresponding lint category, while others are just "plain" warnings >> * Some lint warnings are suppressible via `@SuppressWarnings`, while others are only suppressible via `-Xlint:-foo` flags >> * Speculative compilation requires holding log messages in purgatory until the speculation resolves, after which they are then either discarded or emitted. But this creates a tricky interaction with `DeferredLintHandler` because even after speculation is complete, we may still not yet know whether a warning should be suppressed. >> >> Previously the logic to get all of this right was non-obviously woven around the code base. In particular, you needed to know somehow whether or not to use `DeferredLintHandler`, and in what "mode". >> >> The overall goal of this PR is to simplify usage so that **no matter where you are in the compiler, you can just invoke `log.warning()` to log a warning** and (mostly) forget about all of the details listed above. > > Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits: > > - Merge branch 'master' into JDK-8348611 to fix conflict. > - Remove an unnecessary field. > - More simplification of LintMapper per review suggestions. > - More simplification of LintMapper per review suggestions. > - More refactoring to simplify LintMapper per review. > - Refactor LintMapper to clean up internal type hierarchy per review. > - Address a couple of review comments. > - Merge branch 'master' into JDK-8348611 > - Add DEFAULT_ENABLED flags to fix some mandatory warnings. > - Merge branch 'master' into JDK-8348611 to fix conflicts. > - ... and 87 more: https://git.openjdk.org/jdk/compare/8cd79752...18eaa8ef src/jdk.compiler/share/classes/com/sun/tools/javac/code/LintMapper.java line 75: > 73: > 74: // Per-source file information. Note: during the parsing of a file, an entry exists but the FileInfo value is null > 75: private final Map fileInfoMap = new HashMap<>(); would it makes sense to make this map a WeakHashMap? I'm thinking about cases where we are not using a ReusableContext and thus this map wont be cleared. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24584#discussion_r2274068210 From vromero at openjdk.org Wed Aug 13 17:57:17 2025 From: vromero at openjdk.org (Vicente Romero) Date: Wed, 13 Aug 2025 17:57:17 GMT Subject: RFR: 8348611: Eliminate DeferredLintHandler and emit warnings after attribution [v10] In-Reply-To: References: <08zj2WBmFFeEQbGegExwyGLIDLQV71_TmkqDA4lYad8=.50f5befe-7d49-4865-92e8-fcbbf1f5ea32@github.com> Message-ID: On Mon, 11 Aug 2025 19:23:59 GMT, Archie Cobbs wrote: >> This is a cleanup/refactoring of how lint warnings are logged and `@SuppressWarnings` annotations applied. >> >> A central challenge with lint warnings is that warnings can be generated during any compiler phase, but whether a particular lint warning is suppressed via `@SuppressWarnings` can't be known until after attribution. For example, the parser doesn't have enough information to interpret and apply `@SuppressWarnings("text-blocks")` to text blocks, or `@SuppressWarnings("preview")` to preview lexical features; instead, the `DeferredLintHandler` is used to workaround this limitation. >> >> In addition, several other factors complicate things: >> * Knowing the current applicable `Lint` instance requires manually tracking it with each declaration visited and applying/removing the `@SuppressWarnings` annotation there, if any >> * Some warnings are "suppressibly mandatory" (i.e., they are _emitted if not suppressed_ instead of _emitted if enabled_) >> * Some warnings are "unsuppressibly mandatory" (e.g., the "internal proprietary API" warning) >> * Some mandatory warnings are _aggregated_ into notes that are emitted at the end of compilation when not enabled >> * Some warnings are _lint_ warnings, with a corresponding lint category, while others are just "plain" warnings >> * Some lint warnings are suppressible via `@SuppressWarnings`, while others are only suppressible via `-Xlint:-foo` flags >> * Speculative compilation requires holding log messages in purgatory until the speculation resolves, after which they are then either discarded or emitted. But this creates a tricky interaction with `DeferredLintHandler` because even after speculation is complete, we may still not yet know whether a warning should be suppressed. >> >> Previously the logic to get all of this right was non-obviously woven around the code base. In particular, you needed to know somehow whether or not to use `DeferredLintHandler`, and in what "mode". >> >> The overall goal of this PR is to simplify usage so that **no matter where you are in the compiler, you can just invoke `log.warning()` to log a warning** and (mostly) forget about all of the details listed above. > > Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits: > > - Merge branch 'master' into JDK-8348611 to fix conflict. > - Remove an unnecessary field. > - More simplification of LintMapper per review suggestions. > - More simplification of LintMapper per review suggestions. > - More refactoring to simplify LintMapper per review. > - Refactor LintMapper to clean up internal type hierarchy per review. > - Address a couple of review comments. > - Merge branch 'master' into JDK-8348611 > - Add DEFAULT_ENABLED flags to fix some mandatory warnings. > - Merge branch 'master' into JDK-8348611 to fix conflicts. > - ... and 87 more: https://git.openjdk.org/jdk/compare/8cd79752...18eaa8ef src/jdk.compiler/share/classes/com/sun/tools/javac/code/LintMapper.java line 250: > 248: Span span, // declaration's lexical range > 249: Lint lint, // the Lint configuration that applies at this declaration > 250: Symbol symbol, // declaration symbol (for debug purposes only; null for root) nit: should we keep this field in the final version? we can add it while debugging if needed ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24584#discussion_r2274219819 From acobbs at openjdk.org Wed Aug 13 18:13:16 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Wed, 13 Aug 2025 18:13:16 GMT Subject: RFR: 8348611: Eliminate DeferredLintHandler and emit warnings after attribution [v10] In-Reply-To: <8hd3w_O3ZkXfrfaKlt4tO7xaMNqMwDsq9nO326Sfaso=.f7ee7ff4-8326-47cb-85da-904582db31d7@github.com> References: <08zj2WBmFFeEQbGegExwyGLIDLQV71_TmkqDA4lYad8=.50f5befe-7d49-4865-92e8-fcbbf1f5ea32@github.com> <8hd3w_O3ZkXfrfaKlt4tO7xaMNqMwDsq9nO326Sfaso=.f7ee7ff4-8326-47cb-85da-904582db31d7@github.com> Message-ID: On Wed, 13 Aug 2025 16:56:10 GMT, Vicente Romero wrote: > would it makes sense to make this map a WeakHashMap? I'm thinking about cases where we are not using a ReusableContext and thus this map wont be cleared. Frankly I'm a little fuzzy on that. If there were an issue with `LintMapper.fileInfoMap`, then wouldn't the same issue exist with `AbstractLog.sourceMap`? Note `LintMapper.clear()` and `Log.clear()` are called at the same time, so it seems in any given scenario, they are going to either both be cleared or both not be cleared. > nit: should we keep this field in the final version? we can add it while debugging if needed I can remove it. Besides, this symbol is always the same object as the one that the `Lint` instance was created with, so if debugging were a concern, a better place to store it would be with the `Lint` instance anyway. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24584#discussion_r2274249547 PR Review Comment: https://git.openjdk.org/jdk/pull/24584#discussion_r2274250193 From vromero at openjdk.org Wed Aug 13 19:02:16 2025 From: vromero at openjdk.org (Vicente Romero) Date: Wed, 13 Aug 2025 19:02:16 GMT Subject: RFR: 8348611: Eliminate DeferredLintHandler and emit warnings after attribution [v10] In-Reply-To: References: <08zj2WBmFFeEQbGegExwyGLIDLQV71_TmkqDA4lYad8=.50f5befe-7d49-4865-92e8-fcbbf1f5ea32@github.com> <8hd3w_O3ZkXfrfaKlt4tO7xaMNqMwDsq9nO326Sfaso=.f7ee7ff4-8326-47cb-85da-904582db31d7@github.com> Message-ID: On Wed, 13 Aug 2025 18:10:14 GMT, Archie Cobbs wrote: >> src/jdk.compiler/share/classes/com/sun/tools/javac/code/LintMapper.java line 75: >> >>> 73: >>> 74: // Per-source file information. Note: during the parsing of a file, an entry exists but the FileInfo value is null >>> 75: private final Map fileInfoMap = new HashMap<>(); >> >> would it makes sense to make this map a WeakHashMap? I'm thinking about cases where we are not using a ReusableContext and thus this map wont be cleared. > >> would it makes sense to make this map a WeakHashMap? I'm thinking about cases where we are not using a ReusableContext and thus this map wont be cleared. > > Frankly I'm a little fuzzy on that. If there were an issue with `LintMapper.fileInfoMap`, then wouldn't the same issue exist with `AbstractLog.sourceMap`? Note `LintMapper.clear()` and `Log.clear()` are called at the same time, so it seems in any given scenario, they are going to either both be cleared or both not be cleared. yes you are right we have other DSs with the same `issue` if any. I guess discuss and address it as a separate issue ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24584#discussion_r2274354834 From acobbs at openjdk.org Wed Aug 13 19:41:15 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Wed, 13 Aug 2025 19:41:15 GMT Subject: RFR: 8348611: Eliminate DeferredLintHandler and emit warnings after attribution [v10] In-Reply-To: References: <08zj2WBmFFeEQbGegExwyGLIDLQV71_TmkqDA4lYad8=.50f5befe-7d49-4865-92e8-fcbbf1f5ea32@github.com> <8hd3w_O3ZkXfrfaKlt4tO7xaMNqMwDsq9nO326Sfaso=.f7ee7ff4-8326-47cb-85da-904582db31d7@github.com> Message-ID: On Wed, 13 Aug 2025 18:59:26 GMT, Vicente Romero wrote: > yes you are right we have other DSs with the same `issue` if any. I guess discuss and address it as a separate issue I'm not familiar with all of the various compiler life-cycle variants, but I guess it would boil down to the question, "In what scenarios would a `Context` that's not a `ReusableContext` be reused for multiple compilations?" ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24584#discussion_r2274432201 From jlahoda at openjdk.org Wed Aug 13 19:41:16 2025 From: jlahoda at openjdk.org (Jan Lahoda) Date: Wed, 13 Aug 2025 19:41:16 GMT Subject: RFR: 8348611: Eliminate DeferredLintHandler and emit warnings after attribution [v10] In-Reply-To: References: <08zj2WBmFFeEQbGegExwyGLIDLQV71_TmkqDA4lYad8=.50f5befe-7d49-4865-92e8-fcbbf1f5ea32@github.com> <8hd3w_O3ZkXfrfaKlt4tO7xaMNqMwDsq9nO326Sfaso=.f7ee7ff4-8326-47cb-85da-904582db31d7@github.com> Message-ID: On Wed, 13 Aug 2025 19:36:59 GMT, Archie Cobbs wrote: >> yes you are right we have other DSs with the same `issue` if any. I guess discuss and address it as a separate issue > >> yes you are right we have other DSs with the same `issue` if any. I guess discuss and address it as a separate issue > > I'm not familiar with all of the various compiler life-cycle variants, but I guess it would boil down to the question, "In what scenarios would a `Context` that's not a `ReusableContext` be reused for multiple compilations?" FWIW, this is an instance field on a `Context` service - it will be GCed when the given javac instance is GCed. I think in most cases, use of weak maps is not necessary. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24584#discussion_r2274438431 From vromero at openjdk.org Wed Aug 13 19:49:14 2025 From: vromero at openjdk.org (Vicente Romero) Date: Wed, 13 Aug 2025 19:49:14 GMT Subject: RFR: 8348611: Eliminate DeferredLintHandler and emit warnings after attribution [v10] In-Reply-To: References: <08zj2WBmFFeEQbGegExwyGLIDLQV71_TmkqDA4lYad8=.50f5befe-7d49-4865-92e8-fcbbf1f5ea32@github.com> <8hd3w_O3ZkXfrfaKlt4tO7xaMNqMwDsq9nO326Sfaso=.f7ee7ff4-8326-47cb-85da-904582db31d7@github.com> Message-ID: On Wed, 13 Aug 2025 19:38:41 GMT, Jan Lahoda wrote: >>> yes you are right we have other DSs with the same `issue` if any. I guess discuss and address it as a separate issue >> >> I'm not familiar with all of the various compiler life-cycle variants, but I guess it would boil down to the question, "In what scenarios would a `Context` that's not a `ReusableContext` be reused for multiple compilations?" > > FWIW, this is an instance field on a `Context` service - it will be GCed when the given javac instance is GCed. I think in most cases, use of weak maps is not necessary. I was worried about holding unnecessary memory withing one javac instance ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24584#discussion_r2274464640 From vromero at openjdk.org Wed Aug 13 20:46:18 2025 From: vromero at openjdk.org (Vicente Romero) Date: Wed, 13 Aug 2025 20:46:18 GMT Subject: RFR: 8348611: Eliminate DeferredLintHandler and emit warnings after attribution [v10] In-Reply-To: References: <08zj2WBmFFeEQbGegExwyGLIDLQV71_TmkqDA4lYad8=.50f5befe-7d49-4865-92e8-fcbbf1f5ea32@github.com> Message-ID: On Mon, 11 Aug 2025 19:23:59 GMT, Archie Cobbs wrote: >> This is a cleanup/refactoring of how lint warnings are logged and `@SuppressWarnings` annotations applied. >> >> A central challenge with lint warnings is that warnings can be generated during any compiler phase, but whether a particular lint warning is suppressed via `@SuppressWarnings` can't be known until after attribution. For example, the parser doesn't have enough information to interpret and apply `@SuppressWarnings("text-blocks")` to text blocks, or `@SuppressWarnings("preview")` to preview lexical features; instead, the `DeferredLintHandler` is used to workaround this limitation. >> >> In addition, several other factors complicate things: >> * Knowing the current applicable `Lint` instance requires manually tracking it with each declaration visited and applying/removing the `@SuppressWarnings` annotation there, if any >> * Some warnings are "suppressibly mandatory" (i.e., they are _emitted if not suppressed_ instead of _emitted if enabled_) >> * Some warnings are "unsuppressibly mandatory" (e.g., the "internal proprietary API" warning) >> * Some mandatory warnings are _aggregated_ into notes that are emitted at the end of compilation when not enabled >> * Some warnings are _lint_ warnings, with a corresponding lint category, while others are just "plain" warnings >> * Some lint warnings are suppressible via `@SuppressWarnings`, while others are only suppressible via `-Xlint:-foo` flags >> * Speculative compilation requires holding log messages in purgatory until the speculation resolves, after which they are then either discarded or emitted. But this creates a tricky interaction with `DeferredLintHandler` because even after speculation is complete, we may still not yet know whether a warning should be suppressed. >> >> Previously the logic to get all of this right was non-obviously woven around the code base. In particular, you needed to know somehow whether or not to use `DeferredLintHandler`, and in what "mode". >> >> The overall goal of this PR is to simplify usage so that **no matter where you are in the compiler, you can just invoke `log.warning()` to log a warning** and (mostly) forget about all of the details listed above. > > Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits: > > - Merge branch 'master' into JDK-8348611 to fix conflict. > - Remove an unnecessary field. > - More simplification of LintMapper per review suggestions. > - More simplification of LintMapper per review suggestions. > - More refactoring to simplify LintMapper per review. > - Refactor LintMapper to clean up internal type hierarchy per review. > - Address a couple of review comments. > - Merge branch 'master' into JDK-8348611 > - Add DEFAULT_ENABLED flags to fix some mandatory warnings. > - Merge branch 'master' into JDK-8348611 to fix conflicts. > - ... and 87 more: https://git.openjdk.org/jdk/compare/8cd79752...18eaa8ef src/jdk.compiler/share/classes/com/sun/tools/javac/code/LintMapper.java line 251: > 249: Lint lint, // the Lint configuration that applies at this declaration > 250: Symbol symbol, // declaration symbol (for debug purposes only; null for root) > 251: List children // the nested declarations one level below this node not a proposal to do any change, but I think that if instead of having a tree-like structure in which each range has, potentially, a number of children, we had one list of ranges sorted by its starting point. I think that we could find the right range doing a binary search. We could actually have both: the current tree and a flat list of lint ranges for searches. Again probably not necessary for general cases but there could be corner cases as in machine generated code for which having a faster retrieval could make the difference. But again we can do that if needed in the future ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24584#discussion_r2274581943 From acobbs at openjdk.org Wed Aug 13 22:44:16 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Wed, 13 Aug 2025 22:44:16 GMT Subject: RFR: 8348611: Eliminate DeferredLintHandler and emit warnings after attribution [v10] In-Reply-To: References: <08zj2WBmFFeEQbGegExwyGLIDLQV71_TmkqDA4lYad8=.50f5befe-7d49-4865-92e8-fcbbf1f5ea32@github.com> Message-ID: <1Yhf56lsX7-JRw2sM9E3E0zb0R6sjqvEZlvSRX28EYI=.3b02f424-b25a-4dad-a216-fe033fb1e8f3@github.com> On Wed, 13 Aug 2025 20:42:44 GMT, Vicente Romero 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 97 commits: >> >> - Merge branch 'master' into JDK-8348611 to fix conflict. >> - Remove an unnecessary field. >> - More simplification of LintMapper per review suggestions. >> - More simplification of LintMapper per review suggestions. >> - More refactoring to simplify LintMapper per review. >> - Refactor LintMapper to clean up internal type hierarchy per review. >> - Address a couple of review comments. >> - Merge branch 'master' into JDK-8348611 >> - Add DEFAULT_ENABLED flags to fix some mandatory warnings. >> - Merge branch 'master' into JDK-8348611 to fix conflicts. >> - ... and 87 more: https://git.openjdk.org/jdk/compare/8cd79752...18eaa8ef > > src/jdk.compiler/share/classes/com/sun/tools/javac/code/LintMapper.java line 251: > >> 249: Lint lint, // the Lint configuration that applies at this declaration >> 250: Symbol symbol, // declaration symbol (for debug purposes only; null for root) >> 251: List children // the nested declarations one level below this node > > not a proposal to do any change, but I think that if instead of having a tree-like structure in which each range has, potentially, a number of children, we had one list of ranges sorted by its starting point. I think that we could find the right range doing a binary search. We could actually have both: the current tree and a flat list of lint ranges for searches. Again probably not necessary for general cases but there could be corner cases as in machine generated code for which having a faster retrieval could make the difference. But again we can do that if needed in the future I think at one point I had something like that, but it made things more complicated. Plain binary search doesn't work when you are searching in a list of (possibly nested) intervals instead of a list of points, because there can be multiple matches (arbitrarily many in fact). I think it would require an [Interval tree](https://en.wikipedia.org/wiki/Interval_tree). There is also another annoying detail, which is that the nesting is not always proper: in some oddball cases (none of which I can specifically remember) there can be an AST node whose starting position is before the starting position of its parent AST node (or ending position after its parent). These instances could cause an Interval tree type of algorithm to glitch out. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24584#discussion_r2274793914 From acobbs at openjdk.org Thu Aug 14 04:00:13 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Thu, 14 Aug 2025 04:00:13 GMT Subject: RFR: 8348611: Eliminate DeferredLintHandler and emit warnings after attribution [v10] In-Reply-To: References: <08zj2WBmFFeEQbGegExwyGLIDLQV71_TmkqDA4lYad8=.50f5befe-7d49-4865-92e8-fcbbf1f5ea32@github.com> <8hd3w_O3ZkXfrfaKlt4tO7xaMNqMwDsq9nO326Sfaso=.f7ee7ff4-8326-47cb-85da-904582db31d7@github.com> Message-ID: On Wed, 13 Aug 2025 18:10:28 GMT, Archie Cobbs wrote: >> src/jdk.compiler/share/classes/com/sun/tools/javac/code/LintMapper.java line 250: >> >>> 248: Span span, // declaration's lexical range >>> 249: Lint lint, // the Lint configuration that applies at this declaration >>> 250: Symbol symbol, // declaration symbol (for debug purposes only; null for root) >> >> nit: should we keep this field in the final version? we can add it while debugging if needed > >> nit: should we keep this field in the final version? we can add it while debugging if needed > > I can remove it. Besides, this symbol is always the same object as the one that the `Lint` instance was created with, so if debugging were a concern, a better place to store it would be with the `Lint` instance anyway. Unused field removed in 1f1247bc5cf. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24584#discussion_r2275275487 From acobbs at openjdk.org Thu Aug 14 04:00:12 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Thu, 14 Aug 2025 04:00:12 GMT Subject: RFR: 8348611: Eliminate DeferredLintHandler and emit warnings after attribution [v11] In-Reply-To: <08zj2WBmFFeEQbGegExwyGLIDLQV71_TmkqDA4lYad8=.50f5befe-7d49-4865-92e8-fcbbf1f5ea32@github.com> References: <08zj2WBmFFeEQbGegExwyGLIDLQV71_TmkqDA4lYad8=.50f5befe-7d49-4865-92e8-fcbbf1f5ea32@github.com> Message-ID: > This is a cleanup/refactoring of how lint warnings are logged and `@SuppressWarnings` annotations applied. > > A central challenge with lint warnings is that warnings can be generated during any compiler phase, but whether a particular lint warning is suppressed via `@SuppressWarnings` can't be known until after attribution. For example, the parser doesn't have enough information to interpret and apply `@SuppressWarnings("text-blocks")` to text blocks, or `@SuppressWarnings("preview")` to preview lexical features; instead, the `DeferredLintHandler` is used to workaround this limitation. > > In addition, several other factors complicate things: > * Knowing the current applicable `Lint` instance requires manually tracking it with each declaration visited and applying/removing the `@SuppressWarnings` annotation there, if any > * Some warnings are "suppressibly mandatory" (i.e., they are _emitted if not suppressed_ instead of _emitted if enabled_) > * Some warnings are "unsuppressibly mandatory" (e.g., the "internal proprietary API" warning) > * Some mandatory warnings are _aggregated_ into notes that are emitted at the end of compilation when not enabled > * Some warnings are _lint_ warnings, with a corresponding lint category, while others are just "plain" warnings > * Some lint warnings are suppressible via `@SuppressWarnings`, while others are only suppressible via `-Xlint:-foo` flags > * Speculative compilation requires holding log messages in purgatory until the speculation resolves, after which they are then either discarded or emitted. But this creates a tricky interaction with `DeferredLintHandler` because even after speculation is complete, we may still not yet know whether a warning should be suppressed. > > Previously the logic to get all of this right was non-obviously woven around the code base. In particular, you needed to know somehow whether or not to use `DeferredLintHandler`, and in what "mode". > > The overall goal of this PR is to simplify usage so that **no matter where you are in the compiler, you can just invoke `log.warning()` to log a warning** and (mostly) forget about all of the details listed above. Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision: Remove unused field from "LintRange" record. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24584/files - new: https://git.openjdk.org/jdk/pull/24584/files/18eaa8ef..1f1247bc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24584&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24584&range=09-10 Stats: 5 lines in 1 file changed: 0 ins; 1 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/24584.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24584/head:pull/24584 PR: https://git.openjdk.org/jdk/pull/24584 From jlahoda at openjdk.org Thu Aug 14 08:31:08 2025 From: jlahoda at openjdk.org (Jan Lahoda) Date: Thu, 14 Aug 2025 08:31:08 GMT Subject: RFR: 8177650: JShell tool: packages in classpath don't appear in completions [v3] In-Reply-To: References: Message-ID: > JShell provides the code completion feature, where it suggests possible follow ups for a given snippet prefix. To allow completion for packages, JShell uses a background task to go through known classes and create an index for them. > > There are two problems with this background task: > - the classpath is read from the JShell's FileManager, but the FileManager may not be configured with the compile options yet, so the classpath may not be filled yet, > - the module path is not included in the list of paths to paths to search > > This PR proposes to: > - use FileManager configured by passing the compile options through javac > - include the module path in the search path Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: - Reading module paths directly from the FileManager, to avoid playing with JRT FS. - Merge branch 'master' into JDK-8177650 - Avoiding problems with locked files on Windows. - Correcting handling of modular paths. - Improving test reliability. - 8177650: JShell tool: packages in classpath don't appear in completions ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26137/files - new: https://git.openjdk.org/jdk/pull/26137/files/54eed125..b4e0b0f0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26137&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26137&range=01-02 Stats: 69596 lines in 1762 files changed: 41124 ins; 19092 del; 9380 mod Patch: https://git.openjdk.org/jdk/pull/26137.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26137/head:pull/26137 PR: https://git.openjdk.org/jdk/pull/26137 From jlahoda at openjdk.org Thu Aug 14 08:31:09 2025 From: jlahoda at openjdk.org (Jan Lahoda) Date: Thu, 14 Aug 2025 08:31:09 GMT Subject: RFR: 8177650: JShell tool: packages in classpath don't appear in completions [v2] In-Reply-To: References: Message-ID: On Mon, 7 Jul 2025 13:05:28 GMT, Jan Lahoda wrote: >> JShell provides the code completion feature, where it suggests possible follow ups for a given snippet prefix. To allow completion for packages, JShell uses a background task to go through known classes and create an index for them. >> >> There are two problems with this background task: >> - the classpath is read from the JShell's FileManager, but the FileManager may not be configured with the compile options yet, so the classpath may not be filled yet, >> - the module path is not included in the list of paths to paths to search >> >> This PR proposes to: >> - use FileManager configured by passing the compile options through javac >> - include the module path in the search path > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Avoiding problems with locked files on Windows. During discussion with @david-beaumont, it turned out it might be better to read module content directly from the `JavaFileManager`, using methods like `listLocationsForModules`, rather than manually try to inspect the JRT FileSystem from JShell. So that is what: https://github.com/openjdk/jdk/pull/26137/commits/b4e0b0f0efc1f263dc775d2447b4b531d82badfa is trying to do. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26137#issuecomment-3187468393 From vromero at openjdk.org Thu Aug 14 13:26:25 2025 From: vromero at openjdk.org (Vicente Romero) Date: Thu, 14 Aug 2025 13:26:25 GMT Subject: RFR: 8348611: Eliminate DeferredLintHandler and emit warnings after attribution [v10] In-Reply-To: <1Yhf56lsX7-JRw2sM9E3E0zb0R6sjqvEZlvSRX28EYI=.3b02f424-b25a-4dad-a216-fe033fb1e8f3@github.com> References: <08zj2WBmFFeEQbGegExwyGLIDLQV71_TmkqDA4lYad8=.50f5befe-7d49-4865-92e8-fcbbf1f5ea32@github.com> <1Yhf56lsX7-JRw2sM9E3E0zb0R6sjqvEZlvSRX28EYI=.3b02f424-b25a-4dad-a216-fe033fb1e8f3@github.com> Message-ID: On Wed, 13 Aug 2025 22:40:54 GMT, Archie Cobbs wrote: >> src/jdk.compiler/share/classes/com/sun/tools/javac/code/LintMapper.java line 251: >> >>> 249: Lint lint, // the Lint configuration that applies at this declaration >>> 250: Symbol symbol, // declaration symbol (for debug purposes only; null for root) >>> 251: List children // the nested declarations one level below this node >> >> not a proposal to do any change, but I think that if instead of having a tree-like structure in which each range has, potentially, a number of children, we had one list of ranges sorted by its starting point. I think that we could find the right range doing a binary search. We could actually have both: the current tree and a flat list of lint ranges for searches. Again probably not necessary for general cases but there could be corner cases as in machine generated code for which having a faster retrieval could make the difference. But again we can do that if needed in the future > > I think at one point I had something like that, but it made things more complicated. Plain binary search doesn't work when you are searching in a list of (possibly nested) intervals instead of a list of points, because there can be multiple matches (arbitrarily many in fact). I think it would require an [Interval tree](https://en.wikipedia.org/wiki/Interval_tree). > > There is also another annoying detail, which is that the nesting is not always proper: in some oddball cases (none of which I can specifically remember) there can be an AST node whose starting position is before the starting position of its parent AST node (or ending position after its parent). These instances could cause an Interval tree type of algorithm to glitch out. I see, interesting that you explored those options. Yes I also saw the interval tree solution but that seemed like an overkill, at least as an starting point. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24584#discussion_r2276627752 From vromero at openjdk.org Fri Aug 15 14:53:17 2025 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 15 Aug 2025 14:53:17 GMT Subject: RFR: 8348611: Eliminate DeferredLintHandler and emit warnings after attribution [v11] In-Reply-To: References: <08zj2WBmFFeEQbGegExwyGLIDLQV71_TmkqDA4lYad8=.50f5befe-7d49-4865-92e8-fcbbf1f5ea32@github.com> Message-ID: On Thu, 14 Aug 2025 04:00:12 GMT, Archie Cobbs wrote: >> This is a cleanup/refactoring of how lint warnings are logged and `@SuppressWarnings` annotations applied. >> >> A central challenge with lint warnings is that warnings can be generated during any compiler phase, but whether a particular lint warning is suppressed via `@SuppressWarnings` can't be known until after attribution. For example, the parser doesn't have enough information to interpret and apply `@SuppressWarnings("text-blocks")` to text blocks, or `@SuppressWarnings("preview")` to preview lexical features; instead, the `DeferredLintHandler` is used to workaround this limitation. >> >> In addition, several other factors complicate things: >> * Knowing the current applicable `Lint` instance requires manually tracking it with each declaration visited and applying/removing the `@SuppressWarnings` annotation there, if any >> * Some warnings are "suppressibly mandatory" (i.e., they are _emitted if not suppressed_ instead of _emitted if enabled_) >> * Some warnings are "unsuppressibly mandatory" (e.g., the "internal proprietary API" warning) >> * Some mandatory warnings are _aggregated_ into notes that are emitted at the end of compilation when not enabled >> * Some warnings are _lint_ warnings, with a corresponding lint category, while others are just "plain" warnings >> * Some lint warnings are suppressible via `@SuppressWarnings`, while others are only suppressible via `-Xlint:-foo` flags >> * Speculative compilation requires holding log messages in purgatory until the speculation resolves, after which they are then either discarded or emitted. But this creates a tricky interaction with `DeferredLintHandler` because even after speculation is complete, we may still not yet know whether a warning should be suppressed. >> >> Previously the logic to get all of this right was non-obviously woven around the code base. In particular, you needed to know somehow whether or not to use `DeferredLintHandler`, and in what "mode". >> >> The overall goal of this PR is to simplify usage so that **no matter where you are in the compiler, you can just invoke `log.warning()` to log a warning** and (mostly) forget about all of the details listed above. > > Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision: > > Remove unused field from "LintRange" record. Marked as reviewed by vromero (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24584#pullrequestreview-3124046040 From acobbs at openjdk.org Fri Aug 15 16:22:16 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Fri, 15 Aug 2025 16:22:16 GMT Subject: RFR: 8348611: Eliminate DeferredLintHandler and emit warnings after attribution [v11] In-Reply-To: References: <08zj2WBmFFeEQbGegExwyGLIDLQV71_TmkqDA4lYad8=.50f5befe-7d49-4865-92e8-fcbbf1f5ea32@github.com> Message-ID: On Fri, 15 Aug 2025 14:50:38 GMT, Vicente Romero wrote: >> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove unused field from "LintRange" record. > > Marked as reviewed by vromero (Reviewer). @vicente-romero-oracle thanks for the re-review. @lahodaj @mcimadamore please re-review after 1f1247bc5c whenever convenient. Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/24584#issuecomment-3192072246 From mcimadamore at openjdk.org Wed Aug 20 12:54:48 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 20 Aug 2025 12:54:48 GMT Subject: RFR: 8348611: Eliminate DeferredLintHandler and emit warnings after attribution [v11] In-Reply-To: References: <08zj2WBmFFeEQbGegExwyGLIDLQV71_TmkqDA4lYad8=.50f5befe-7d49-4865-92e8-fcbbf1f5ea32@github.com> Message-ID: <6EdDbdhTX9yB2tpmy-jLjs4b5UG5fAOKjHvx6WKgi4Q=.bd4dd5ee-bdff-4a6a-b63c-dcb3f089e173@github.com> On Thu, 14 Aug 2025 04:00:12 GMT, Archie Cobbs wrote: >> This is a cleanup/refactoring of how lint warnings are logged and `@SuppressWarnings` annotations applied. >> >> A central challenge with lint warnings is that warnings can be generated during any compiler phase, but whether a particular lint warning is suppressed via `@SuppressWarnings` can't be known until after attribution. For example, the parser doesn't have enough information to interpret and apply `@SuppressWarnings("text-blocks")` to text blocks, or `@SuppressWarnings("preview")` to preview lexical features; instead, the `DeferredLintHandler` is used to workaround this limitation. >> >> In addition, several other factors complicate things: >> * Knowing the current applicable `Lint` instance requires manually tracking it with each declaration visited and applying/removing the `@SuppressWarnings` annotation there, if any >> * Some warnings are "suppressibly mandatory" (i.e., they are _emitted if not suppressed_ instead of _emitted if enabled_) >> * Some warnings are "unsuppressibly mandatory" (e.g., the "internal proprietary API" warning) >> * Some mandatory warnings are _aggregated_ into notes that are emitted at the end of compilation when not enabled >> * Some warnings are _lint_ warnings, with a corresponding lint category, while others are just "plain" warnings >> * Some lint warnings are suppressible via `@SuppressWarnings`, while others are only suppressible via `-Xlint:-foo` flags >> * Speculative compilation requires holding log messages in purgatory until the speculation resolves, after which they are then either discarded or emitted. But this creates a tricky interaction with `DeferredLintHandler` because even after speculation is complete, we may still not yet know whether a warning should be suppressed. >> >> Previously the logic to get all of this right was non-obviously woven around the code base. In particular, you needed to know somehow whether or not to use `DeferredLintHandler`, and in what "mode". >> >> The overall goal of this PR is to simplify usage so that **no matter where you are in the compiler, you can just invoke `log.warning()` to log a warning** and (mostly) forget about all of the details listed above. > > Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision: > > Remove unused field from "LintRange" record. Still looks good to me :-) ------------- Marked as reviewed by mcimadamore (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24584#pullrequestreview-3136451924 From jlahoda at openjdk.org Wed Aug 20 12:59:49 2025 From: jlahoda at openjdk.org (Jan Lahoda) Date: Wed, 20 Aug 2025 12:59:49 GMT Subject: RFR: 8348611: Eliminate DeferredLintHandler and emit warnings after attribution [v11] In-Reply-To: References: <08zj2WBmFFeEQbGegExwyGLIDLQV71_TmkqDA4lYad8=.50f5befe-7d49-4865-92e8-fcbbf1f5ea32@github.com> Message-ID: On Thu, 14 Aug 2025 04:00:12 GMT, Archie Cobbs wrote: >> This is a cleanup/refactoring of how lint warnings are logged and `@SuppressWarnings` annotations applied. >> >> A central challenge with lint warnings is that warnings can be generated during any compiler phase, but whether a particular lint warning is suppressed via `@SuppressWarnings` can't be known until after attribution. For example, the parser doesn't have enough information to interpret and apply `@SuppressWarnings("text-blocks")` to text blocks, or `@SuppressWarnings("preview")` to preview lexical features; instead, the `DeferredLintHandler` is used to workaround this limitation. >> >> In addition, several other factors complicate things: >> * Knowing the current applicable `Lint` instance requires manually tracking it with each declaration visited and applying/removing the `@SuppressWarnings` annotation there, if any >> * Some warnings are "suppressibly mandatory" (i.e., they are _emitted if not suppressed_ instead of _emitted if enabled_) >> * Some warnings are "unsuppressibly mandatory" (e.g., the "internal proprietary API" warning) >> * Some mandatory warnings are _aggregated_ into notes that are emitted at the end of compilation when not enabled >> * Some warnings are _lint_ warnings, with a corresponding lint category, while others are just "plain" warnings >> * Some lint warnings are suppressible via `@SuppressWarnings`, while others are only suppressible via `-Xlint:-foo` flags >> * Speculative compilation requires holding log messages in purgatory until the speculation resolves, after which they are then either discarded or emitted. But this creates a tricky interaction with `DeferredLintHandler` because even after speculation is complete, we may still not yet know whether a warning should be suppressed. >> >> Previously the logic to get all of this right was non-obviously woven around the code base. In particular, you needed to know somehow whether or not to use `DeferredLintHandler`, and in what "mode". >> >> The overall goal of this PR is to simplify usage so that **no matter where you are in the compiler, you can just invoke `log.warning()` to log a warning** and (mostly) forget about all of the details listed above. > > Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision: > > Remove unused field from "LintRange" record. Marked as reviewed by jlahoda (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24584#pullrequestreview-3136468316 From acobbs at openjdk.org Wed Aug 20 15:08:01 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Wed, 20 Aug 2025 15:08:01 GMT Subject: Integrated: 8348611: Eliminate DeferredLintHandler and emit warnings after attribution In-Reply-To: <08zj2WBmFFeEQbGegExwyGLIDLQV71_TmkqDA4lYad8=.50f5befe-7d49-4865-92e8-fcbbf1f5ea32@github.com> References: <08zj2WBmFFeEQbGegExwyGLIDLQV71_TmkqDA4lYad8=.50f5befe-7d49-4865-92e8-fcbbf1f5ea32@github.com> Message-ID: On Thu, 10 Apr 2025 20:23:15 GMT, Archie Cobbs wrote: > This is a cleanup/refactoring of how lint warnings are logged and `@SuppressWarnings` annotations applied. > > A central challenge with lint warnings is that warnings can be generated during any compiler phase, but whether a particular lint warning is suppressed via `@SuppressWarnings` can't be known until after attribution. For example, the parser doesn't have enough information to interpret and apply `@SuppressWarnings("text-blocks")` to text blocks, or `@SuppressWarnings("preview")` to preview lexical features; instead, the `DeferredLintHandler` is used to workaround this limitation. > > In addition, several other factors complicate things: > * Knowing the current applicable `Lint` instance requires manually tracking it with each declaration visited and applying/removing the `@SuppressWarnings` annotation there, if any > * Some warnings are "suppressibly mandatory" (i.e., they are _emitted if not suppressed_ instead of _emitted if enabled_) > * Some warnings are "unsuppressibly mandatory" (e.g., the "internal proprietary API" warning) > * Some mandatory warnings are _aggregated_ into notes that are emitted at the end of compilation when not enabled > * Some warnings are _lint_ warnings, with a corresponding lint category, while others are just "plain" warnings > * Some lint warnings are suppressible via `@SuppressWarnings`, while others are only suppressible via `-Xlint:-foo` flags > * Speculative compilation requires holding log messages in purgatory until the speculation resolves, after which they are then either discarded or emitted. But this creates a tricky interaction with `DeferredLintHandler` because even after speculation is complete, we may still not yet know whether a warning should be suppressed. > > Previously the logic to get all of this right was non-obviously woven around the code base. In particular, you needed to know somehow whether or not to use `DeferredLintHandler`, and in what "mode". > > The overall goal of this PR is to simplify usage so that **no matter where you are in the compiler, you can just invoke `log.warning()` to log a warning** and (mostly) forget about all of the details listed above. This pull request has now been integrated. Changeset: 3e60ab51 Author: Archie Cobbs URL: https://git.openjdk.org/jdk/commit/3e60ab51fea17098d852931a06f4f5a827ae0e78 Stats: 1924 lines in 56 files changed: 980 ins; 584 del; 360 mod 8348611: Eliminate DeferredLintHandler and emit warnings after attribution 8224228: No way to locally suppress lint warnings in parser/tokenizer or preview features 8353758: Missing calls to Log.useSource() in JavacTrees Reviewed-by: mcimadamore, vromero, jlahoda ------------- PR: https://git.openjdk.org/jdk/pull/24584 From mcimadamore at openjdk.org Wed Aug 20 17:09:51 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 20 Aug 2025 17:09:51 GMT Subject: RFR: 8348611: Eliminate DeferredLintHandler and emit warnings after attribution [v11] In-Reply-To: References: <08zj2WBmFFeEQbGegExwyGLIDLQV71_TmkqDA4lYad8=.50f5befe-7d49-4865-92e8-fcbbf1f5ea32@github.com> Message-ID: On Fri, 15 Aug 2025 16:19:13 GMT, Archie Cobbs wrote: >> Marked as reviewed by vromero (Reviewer). > > @vicente-romero-oracle thanks for the re-review. > > @lahodaj @mcimadamore please re-review after 1f1247bc5c whenever convenient. > > Thanks! Thanks @archiecobbs for all your hard work on this issue. I'm glad to see this integrated! ------------- PR Comment: https://git.openjdk.org/jdk/pull/24584#issuecomment-3207311498 From acobbs at openjdk.org Wed Aug 20 17:23:52 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Wed, 20 Aug 2025 17:23:52 GMT Subject: RFR: 8348611: Eliminate DeferredLintHandler and emit warnings after attribution [v11] In-Reply-To: References: <08zj2WBmFFeEQbGegExwyGLIDLQV71_TmkqDA4lYad8=.50f5befe-7d49-4865-92e8-fcbbf1f5ea32@github.com> Message-ID: On Wed, 20 Aug 2025 17:06:33 GMT, Maurizio Cimadamore wrote: >> @vicente-romero-oracle thanks for the re-review. >> >> @lahodaj @mcimadamore please re-review after 1f1247bc5c whenever convenient. >> >> Thanks! > > Thanks @archiecobbs for all your hard work on this issue. I'm glad to see this integrated! @mcimadamore thanks very much for your reviews and helpful discussions. "Cleanups" like this are sometimes tedious to review so I appreciate your time on it! ------------- PR Comment: https://git.openjdk.org/jdk/pull/24584#issuecomment-3207365659 From jlahoda at openjdk.org Thu Aug 21 12:48:15 2025 From: jlahoda at openjdk.org (Jan Lahoda) Date: Thu, 21 Aug 2025 12:48:15 GMT Subject: RFR: 8285150: Improve tab completion for annotations [v2] In-Reply-To: References: Message-ID: <7Kf2DP33mHnr8xDKHCMyQumRA2Oaa2TBIqoq08N5lTA=.acd42389-a3d2-4fc8-a2ae-f4bd58c8aec0@github.com> > When using types code like: > > @Deprecated( > > > and presses ``, there should be a sensible completion, but currently there is nothing. This PR proposes to add code completion for annotation attributes. Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: - Fixing completion prefix behavior - Merge branch 'master' into JDK-8285150-dev2 - Improving the handling of annotation attributes that are annotations and enum constants. - Merge branch 'master' into JDK-8285150 - Merge branch 'master' into JDK-8285150 - 8285150: Improve tab completion for annotations ------------- Changes: https://git.openjdk.org/jdk/pull/22840/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22840&range=01 Stats: 321 lines in 4 files changed: 300 ins; 0 del; 21 mod Patch: https://git.openjdk.org/jdk/pull/22840.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22840/head:pull/22840 PR: https://git.openjdk.org/jdk/pull/22840 From asotona at openjdk.org Tue Aug 26 12:06:39 2025 From: asotona at openjdk.org (Adam Sotona) Date: Tue, 26 Aug 2025 12:06:39 GMT Subject: RFR: 8177650: JShell tool: packages in classpath don't appear in completions [v3] In-Reply-To: References: Message-ID: On Thu, 14 Aug 2025 08:31:08 GMT, Jan Lahoda wrote: >> JShell provides the code completion feature, where it suggests possible follow ups for a given snippet prefix. To allow completion for packages, JShell uses a background task to go through known classes and create an index for them. >> >> There are two problems with this background task: >> - the classpath is read from the JShell's FileManager, but the FileManager may not be configured with the compile options yet, so the classpath may not be filled yet, >> - the module path is not included in the list of paths to paths to search >> >> This PR proposes to: >> - use FileManager configured by passing the compile options through javac >> - include the module path in the search path > > Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: > > - Reading module paths directly from the FileManager, to avoid playing with JRT FS. > - Merge branch 'master' into JDK-8177650 > - Avoiding problems with locked files on Windows. > - Correcting handling of modular paths. > - Improving test reliability. > - 8177650: JShell tool: packages in classpath don't appear in completions Marked as reviewed by asotona (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26137#pullrequestreview-3155330016