From jjg at openjdk.org Fri Mar 1 21:49:29 2024 From: jjg at openjdk.org (Jonathan Gibbons) Date: Fri, 1 Mar 2024 21:49:29 GMT Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v44] In-Reply-To: References: Message-ID: > Please review a patch to add support for Markdown syntax in documentation comments, as described in the associated JEP. > > Notable features: > > * support for `///` documentation comments in `JavaTokenizer` > * new module `jdk.internal.md` -- a private copy of the `commonmark-java` library > * updates to `DocCommentParser` to treat `///` comments as Markdown > * updates to the standard doclet to render Markdown comments in HTML Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: Revise `Markdown.update` to better handle container blocks. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16388/files - new: https://git.openjdk.org/jdk/pull/16388/files/398f93fc..0b4d9b3c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16388&range=43 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16388&range=42-43 Stats: 348 lines in 3 files changed: 226 ins; 43 del; 79 mod Patch: https://git.openjdk.org/jdk/pull/16388.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16388/head:pull/16388 PR: https://git.openjdk.org/jdk/pull/16388 From cstein at openjdk.org Mon Mar 4 08:18:25 2024 From: cstein at openjdk.org (Christian Stein) Date: Mon, 4 Mar 2024 08:18:25 GMT Subject: RFR: 8323605: Java source launcher should not require `--source ...` to enable preview [v4] In-Reply-To: References: Message-ID: <18o5YIblHul4zgTjQ_zbQbORH-NPgvbiY0mTMhqYD4Y=.14d86d1c-4fb0-4e5c-8ec8-1430fb131bb5@github.com> > Please review this PR targeting the source launcher that instead of throwing an error reading _"--enable-preview must be used with --source"_ adds the required compiler arguments on-the-fly. > > The add arguments are `--release` and `feature`, with `feature` being the release feature number of the current Java runtime as acquired by `Runtime.version().feature()`. Christian Stein has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: - Update `java`'s man page - Merge branch 'refs/heads/master' into JDK-8323605-launch-with-source-by-default - Remove now outdated workaround [skip ci] - Update copyright dates [skip ci] - 8323605: Java source launcher should not require `--source ...` to enable preview ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17731/files - new: https://git.openjdk.org/jdk/pull/17731/files/23fba2bf..bb8eac9a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17731&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17731&range=02-03 Stats: 48207 lines in 2199 files changed: 22996 ins; 14625 del; 10586 mod Patch: https://git.openjdk.org/jdk/pull/17731.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17731/head:pull/17731 PR: https://git.openjdk.org/jdk/pull/17731 From prappo at openjdk.org Mon Mar 4 14:43:03 2024 From: prappo at openjdk.org (Pavel Rappo) Date: Mon, 4 Mar 2024 14:43:03 GMT Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v44] In-Reply-To: References: Message-ID: <0Ni2FJg13P97mkOqv-C_J-i2pyHagmCc5wrcXuzNYMw=.d3d617eb-42dc-4e54-93fb-2afe679202c8@github.com> On Fri, 1 Mar 2024 21:49:29 GMT, Jonathan Gibbons wrote: >> Please review a patch to add support for Markdown syntax in documentation comments, as described in the associated JEP. >> >> Notable features: >> >> * support for `///` documentation comments in `JavaTokenizer` >> * new module `jdk.internal.md` -- a private copy of the `commonmark-java` library >> * updates to `DocCommentParser` to treat `///` comments as Markdown >> * updates to the standard doclet to render Markdown comments in HTML > > Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: > > Revise `Markdown.update` to better handle container blocks. I have a test case to report. The following results in no `@param` information being rendered, which I think is a bug: /// Hello, _Markdown_ world! /// ///

/// @param hello ///

/// public class C { } ------------- PR Comment: https://git.openjdk.org/jdk/pull/16388#issuecomment-1976734010 From prappo at openjdk.org Mon Mar 4 15:19:05 2024 From: prappo at openjdk.org (Pavel Rappo) Date: Mon, 4 Mar 2024 15:19:05 GMT Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v44] In-Reply-To: <0Ni2FJg13P97mkOqv-C_J-i2pyHagmCc5wrcXuzNYMw=.d3d617eb-42dc-4e54-93fb-2afe679202c8@github.com> References: <0Ni2FJg13P97mkOqv-C_J-i2pyHagmCc5wrcXuzNYMw=.d3d617eb-42dc-4e54-93fb-2afe679202c8@github.com> Message-ID: On Mon, 4 Mar 2024 14:40:06 GMT, Pavel Rappo wrote: > I have a test case to report. The following results in no `@param` information being rendered, which I think is a bug: > > ``` > /// Hello, _Markdown_ world! > /// > ///

> /// @param hello > ///

> /// > public class C { } > ``` Scratch that. After experimenting a bit more with **traditional** javadoc comments, I realised that it might be expected that `@param` would be lost in that `

...

` block; okay. Still, I find it surprising that the description of the `@param` tag in the above comment, hosted in `///` or `/**...*/`, is a single node of type `RawText` with the following content: hello

(Note, the content includes `

`.) ------------- PR Comment: https://git.openjdk.org/jdk/pull/16388#issuecomment-1976818803 From jjg at openjdk.org Mon Mar 4 21:32:20 2024 From: jjg at openjdk.org (Jonathan Gibbons) Date: Mon, 4 Mar 2024 21:32:20 GMT Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v45] In-Reply-To: References: Message-ID: > Please review a patch to add support for Markdown syntax in documentation comments, as described in the associated JEP. > > Notable features: > > * support for `///` documentation comments in `JavaTokenizer` > * new module `jdk.internal.md` -- a private copy of the `commonmark-java` library > * updates to `DocCommentParser` to treat `///` comments as Markdown > * updates to the standard doclet to render Markdown comments in HTML Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 63 commits: - fix test after merge - Merge remote-tracking branch 'upstream/master' into 8298405.doclet-markdown-v3 - Revise `Markdown.update` to better handle container blocks. - Refactor most of TestMarkdown.java into separate tests, grouped by functionality - add support for (top-level) trailing code blocks add simple test case with tabs add TestMarkdownCodeBlocks.testTypical - fix whitespace - fix Markdown.update for new POST_LIST_INDENT test case given in review feedback - refactor tests for Markdown headings into a separate test class. - update DocCommentParser and tests to improve handling of code blocks and code spans in Markdown documentation comments - fix indentation, for consistency - ... and 53 more: https://git.openjdk.org/jdk/compare/6f8d351e...292ff0f1 ------------- Changes: https://git.openjdk.org/jdk/pull/16388/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16388&range=44 Stats: 23548 lines in 205 files changed: 22863 ins; 252 del; 433 mod Patch: https://git.openjdk.org/jdk/pull/16388.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16388/head:pull/16388 PR: https://git.openjdk.org/jdk/pull/16388 From jjg at openjdk.org Tue Mar 5 19:08:59 2024 From: jjg at openjdk.org (Jonathan Gibbons) Date: Tue, 5 Mar 2024 19:08:59 GMT Subject: RFR: JDK-8298405: Implement JEP 467: Markdown Documentation Comments [v44] In-Reply-To: References: <0Ni2FJg13P97mkOqv-C_J-i2pyHagmCc5wrcXuzNYMw=.d3d617eb-42dc-4e54-93fb-2afe679202c8@github.com> Message-ID: <7j2wY4Kerf2flBeZbxOeSz35u0VYgKsctgcDvui1Ctk=.abd1e15b-861e-4e7e-a86e-e7451e47d8c9@github.com> On Mon, 4 Mar 2024 15:16:32 GMT, Pavel Rappo wrote: > > I have a test case to report. The following results in no `@param` information being rendered, which I think is a bug: > > ``` > > /// Hello, _Markdown_ world! > > /// > > ///

> > /// @param hello > > ///

> > /// > > public class C { } > > ``` > > Scratch that. After experimenting a bit more with **traditional** javadoc comments, I realised that it might be expected that `@param` would be lost in that `

...

` block; okay. > > Still, I find it surprising that the description of the `@param` tag in the above comment, hosted in `///` or `/**...*/`, is a single node of type `RawText` with the following content: > > ``` > hello >

> ``` > > (Note, the content includes `

`.) The Markdown aspect of this is behaving about as well as can be expected. But the generated form is certainly confusing and can be considered a less-than-optimal presentation of a paragraph within a definition list. You can see the same behavior in a traditional comment with `@param

hello

`. Ideally, we could/should tweak the CSS for this situation, in a separate changeset. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16388#issuecomment-1979452615 From cushon at openjdk.org Tue Mar 5 20:30:10 2024 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Tue, 5 Mar 2024 20:30:10 GMT Subject: RFR: 8043226: Better diagnostics for non-applicable type annotations [v3] In-Reply-To: References: Message-ID: > Hi, > > Please consider this improvement to diagnostics on inadmissable type annotations. > > [JDK-8057683: clarify error messages trying to annotate scoping](https://bugs.openjdk.org/browse/JDK-8057683) is closely related to JDK-8043226 and I think could be made a duplicate of that bug. [JDK-8057683: improve ordering of errors with type annotations](https://bugs.openjdk.org/browse/JDK-8057683) is also closely related, and this PR partially fixes the issues described in that bug. > > I have some notes on details of the proposed changes below. > > --- > > Currently javac reports 'scoping construct cannot be annotated' diagnostics for type annotations at locations where they are not admissable. > > As discussed in [JDK-8043226](https://bugs.openjdk.org/browse/JDK-8043226) and [JDK-8057683](https://bugs.openjdk.org/browse/JDK-8057683), the current language is unclear. The 'scoping construct' language was used in JSR-308 discussions but didn't end up in the final specification, JLS ?9.7.4 talks about where annotations are 'admissable', and that language is mirrored in JVMS ?4.7.20.2. > > This change updates the diagnostics to state that type annotations 'not admissible at this location' and removed the reference to 'scoping constructs'. Additionally, the diagnostic now includes an explanation of a location in the type where annotations would be admissible, to make it easier to understand how to annotate qualified type names. > > Before: > > > test/langtools/tools/javac/annotations/typeAnnotations/failures/CantAnnotateScoping.java:38: error: scoping construct cannot be annotated with type-use annotation: @TA > @TA Outer.SInner osi; > ^ > > > After: > > > test/langtools/tools/javac/annotations/typeAnnotations/failures/CantAnnotateScoping.java:38: error: type annotations are not admissible at this location: @TA > @TA Outer.SInner osi; > ^ > (to annotate a qualified type, write Outer. at TA SInner) > > > --- > > Attribution currently assumes `@TA java.lang.Object` in `List<@TA java.lang.Object>` will be a type (not a package), and reports a resolution failure when it can't find a class named `java`. > > This change modifies attribution to search for packages as well as types when resolving annotated types, and relies on the subsequent error checking for annotated types to report that type annotations are not admissible at that location. > > This also improves the ordering of the diagnostic in the output, since attribution errors are report before type annotation validation errors in the l... Liam Miller-Cushon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Merge branch 'master' into JDK-8043226 - Update src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java Co-authored-by: Werner Dietl - 8043226: Better diagnostics for non-applicable type annotations ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16592/files - new: https://git.openjdk.org/jdk/pull/16592/files/568eb387..77aca669 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16592&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16592&range=01-02 Stats: 919411 lines in 7225 files changed: 244205 ins; 574251 del; 100955 mod Patch: https://git.openjdk.org/jdk/pull/16592.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16592/head:pull/16592 PR: https://git.openjdk.org/jdk/pull/16592 From cushon at openjdk.org Tue Mar 5 20:30:11 2024 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Tue, 5 Mar 2024 20:30:11 GMT Subject: RFR: 8043226: Better diagnostics for non-applicable type annotations [v2] In-Reply-To: <4ymqDKx7z9VqfAjr93Dx7tVCUnJDoz_1TIY4oarSkoc=.26f92336-85b6-4549-a4a1-cb1d5a424d78@github.com> References: <4ymqDKx7z9VqfAjr93Dx7tVCUnJDoz_1TIY4oarSkoc=.26f92336-85b6-4549-a4a1-cb1d5a424d78@github.com> Message-ID: On Mon, 8 Jan 2024 19:12:34 GMT, Liam Miller-Cushon wrote: >> Hi, >> >> Please consider this improvement to diagnostics on inadmissable type annotations. >> >> [JDK-8057683: clarify error messages trying to annotate scoping](https://bugs.openjdk.org/browse/JDK-8057683) is closely related to JDK-8043226 and I think could be made a duplicate of that bug. [JDK-8057683: improve ordering of errors with type annotations](https://bugs.openjdk.org/browse/JDK-8057683) is also closely related, and this PR partially fixes the issues described in that bug. >> >> I have some notes on details of the proposed changes below. >> >> --- >> >> Currently javac reports 'scoping construct cannot be annotated' diagnostics for type annotations at locations where they are not admissable. >> >> As discussed in [JDK-8043226](https://bugs.openjdk.org/browse/JDK-8043226) and [JDK-8057683](https://bugs.openjdk.org/browse/JDK-8057683), the current language is unclear. The 'scoping construct' language was used in JSR-308 discussions but didn't end up in the final specification, JLS ?9.7.4 talks about where annotations are 'admissable', and that language is mirrored in JVMS ?4.7.20.2. >> >> This change updates the diagnostics to state that type annotations 'not admissible at this location' and removed the reference to 'scoping constructs'. Additionally, the diagnostic now includes an explanation of a location in the type where annotations would be admissible, to make it easier to understand how to annotate qualified type names. >> >> Before: >> >> >> test/langtools/tools/javac/annotations/typeAnnotations/failures/CantAnnotateScoping.java:38: error: scoping construct cannot be annotated with type-use annotation: @TA >> @TA Outer.SInner osi; >> ^ >> >> >> After: >> >> >> test/langtools/tools/javac/annotations/typeAnnotations/failures/CantAnnotateScoping.java:38: error: type annotations are not admissible at this location: @TA >> @TA Outer.SInner osi; >> ^ >> (to annotate a qualified type, write Outer. at TA SInner) >> >> >> --- >> >> Attribution currently assumes `@TA java.lang.Object` in `List<@TA java.lang.Object>` will be a type (not a package), and reports a resolution failure when it can't find a class named `java`. >> >> This change modifies attribution to search for packages as well as types when resolving annotated types, and relies on the subsequent error checking for annotated types to report that type annotations are not admissible at that location. >> >> This also improves the ordering of the diagnostic in the output, since... > > Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: > > Update src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java > > Co-authored-by: Werner Dietl > Feel free to ask for assistance if you need help with progressing this pull request towards integration! Any suggestions on how to progress this pull request are welcome. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16592#issuecomment-1979582358 From cushon at openjdk.org Wed Mar 6 20:35:20 2024 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Wed, 6 Mar 2024 20:35:20 GMT Subject: RFR: 8291643: Consider omitting type annotations from type error diagnostics [v2] In-Reply-To: References: Message-ID: > Hi, > > Please consider this fix for [JDK-8291643](https://bugs.openjdk.org/browse/JDK-8291643), which causes javac to remove type-use annotations when formatting types in diagnostics. > > For the example like the one in the bug, this change causes javac to emit the diagnostic like `incompatible types: List cannot be converted to List` rather than `incompatible types: List cannot be converted to List<@Nullable Number>`. Including the type annotations can be confusing, because they do not impact the type checking done by the compiler. > > An alternative I considered was to remove type annotations from types for specific diagnostics, instead of doing it unconditionally in diagnostic formatting. I can revisit that if the current approach seems too broad. > > The test update to `test/langtools/tools/javac/lambda/LambdaConv25.out` is because a `ForAll` is being formatted, and `stripMetadata()` uses a `StructuralTypeMapping` which rewrites away the `ForAll`. Liam Miller-Cushon 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: - Use Type stripping logic added for JDK-8042981 - Merge branch 'master' into JDK-8291643 - Updates based on review thread * Support optionally printing types with type annotations * Move handling of types in AbstractDiagnosticFormatter * Make annotation removal more robust, don't rely on stripMetadata - 8291643: Consider omitting type annotations from type error diagnostics ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16578/files - new: https://git.openjdk.org/jdk/pull/16578/files/f28bbf4d..7331c7cb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16578&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16578&range=00-01 Stats: 919426 lines in 7228 files changed: 244212 ins; 574254 del; 100960 mod Patch: https://git.openjdk.org/jdk/pull/16578.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16578/head:pull/16578 PR: https://git.openjdk.org/jdk/pull/16578 From cushon at openjdk.org Wed Mar 6 20:35:20 2024 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Wed, 6 Mar 2024 20:35:20 GMT Subject: RFR: 8291643: Consider omitting type annotations from type error diagnostics In-Reply-To: References: Message-ID: <8tpqGL_mTN5EvRmDlFG360fIX1cH7U_bmGYvJVcItv0=.726c025d-5215-410a-8d3d-d2c20af96a37@github.com> On Thu, 9 Nov 2023 00:47:10 GMT, Liam Miller-Cushon wrote: > Hi, > > Please consider this fix for [JDK-8291643](https://bugs.openjdk.org/browse/JDK-8291643), which causes javac to remove type-use annotations when formatting types in diagnostics. > > For the example like the one in the bug, this change causes javac to emit the diagnostic like `incompatible types: List cannot be converted to List` rather than `incompatible types: List cannot be converted to List<@Nullable Number>`. Including the type annotations can be confusing, because they do not impact the type checking done by the compiler. > > An alternative I considered was to remove type annotations from types for specific diagnostics, instead of doing it unconditionally in diagnostic formatting. I can revisit that if the current approach seems too broad. > > The test update to `test/langtools/tools/javac/lambda/LambdaConv25.out` is because a `ForAll` is being formatted, and `stripMetadata()` uses a `StructuralTypeMapping` which rewrites away the `ForAll`. I pushed a demo of some of the changes mentioned earlier, including an implementation of a `stripAnnotations` method that uses the approach I mentioned in https://github.com/openjdk/jdk/pull/8984#issuecomment-1806211798 > One possibility would be to have a trivial wrapper around the types used in diagnostic arguments, and then have the diagnostic formatter unwrap them and leave the annotations on `AbstractDiagnosticFormatter` now removes type annotations from printed types by default, and there's a `JCDiagnostic.AnnotatedType` wrapper for diagnostics that want to opt-in to printing types with annotations. This isn't currently used in the PR, but https://github.com/openjdk/jdk/pull/16592 is an example of a diagnostic that wants to include type annotations. Please keep this open for now I updated this to use the `Type#stripMetadata` method added in https://bugs.openjdk.org/browse/JDK-8042981 to remove the type annotations, now that change has landed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16578#issuecomment-1811517580 PR Comment: https://git.openjdk.org/jdk/pull/16578#issuecomment-1884004866 PR Comment: https://git.openjdk.org/jdk/pull/16578#issuecomment-1981730529 From jjg at openjdk.org Wed Mar 6 22:23:24 2024 From: jjg at openjdk.org (Jonathan Gibbons) Date: Wed, 6 Mar 2024 22:23:24 GMT Subject: RFR: JDK-8298405: Implement JEP 467: Markdown Documentation Comments [v46] In-Reply-To: References: Message-ID: > Please review a patch to add support for Markdown syntax in documentation comments, as described in the associated JEP. > > Notable features: > > * support for `///` documentation comments in `JavaTokenizer` > * new module `jdk.internal.md` -- a private copy of the `commonmark-java` library > * updates to `DocCommentParser` to treat `///` comments as Markdown > * updates to the standard doclet to render Markdown comments in HTML Jonathan Gibbons has updated the pull request incrementally with two additional commits since the last revision: - fix `textOf` method to accommodate Markdown content. - avoid relying on unspecified behavior `List.toString` ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16388/files - new: https://git.openjdk.org/jdk/pull/16388/files/292ff0f1..fc76e8c7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16388&range=45 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16388&range=44-45 Stats: 43 lines in 3 files changed: 34 ins; 0 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/16388.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16388/head:pull/16388 PR: https://git.openjdk.org/jdk/pull/16388 From jlahoda at openjdk.org Thu Mar 7 08:39:19 2024 From: jlahoda at openjdk.org (Jan Lahoda) Date: Thu, 7 Mar 2024 08:39:19 GMT Subject: RFR: 8325362: Allow to create a simple in-memory input JavaFileObject Message-ID: <6KbXE6d6CHtDEoQ03C66d8eFAUyoUM_WhFjJYQiQkqk=.10b93b93-ab06-4b31-bb70-c82eda99a8db@github.com> There are many subtypes of `SimpleJavaFileObject` scattered through various codebases, majority of them looking like: private static class JavaSource extends SimpleJavaFileObject { private String code; public JavaSource(String code) { super(URI.create("myfo:/Test.java"), JavaFileObject.Kind.SOURCE); this.code = code; } @Override public CharSequence getCharContent(boolean ignoreEncodingErrors) { return code; } } The proposal herein is a to add a factory method that would return an implementation of `SimpleJavaFileObject` based on the provided `URI` and source content. The CSR for this change is available for review here: https://bugs.openjdk.org/browse/JDK-8327536 ------------- Commit messages: - Updating copyright year. - Merge branch 'master' into JDK-8325362 - Adding test. - Merge branch 'master' into JDK-8325362 - 8325362: Allow to create a simple in-memory input JavaFileObject Changes: https://git.openjdk.org/jdk/pull/18149/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18149&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8325362 Stats: 162 lines in 2 files changed: 162 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/18149.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18149/head:pull/18149 PR: https://git.openjdk.org/jdk/pull/18149 From jlaskey at openjdk.org Thu Mar 7 08:45:52 2024 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 7 Mar 2024 08:45:52 GMT Subject: RFR: 8325362: Allow to create a simple in-memory input JavaFileObject In-Reply-To: <6KbXE6d6CHtDEoQ03C66d8eFAUyoUM_WhFjJYQiQkqk=.10b93b93-ab06-4b31-bb70-c82eda99a8db@github.com> References: <6KbXE6d6CHtDEoQ03C66d8eFAUyoUM_WhFjJYQiQkqk=.10b93b93-ab06-4b31-bb70-c82eda99a8db@github.com> Message-ID: On Thu, 7 Mar 2024 08:34:32 GMT, Jan Lahoda wrote: > There are many subtypes of `SimpleJavaFileObject` scattered through various codebases, majority of them looking like: > > > private static class JavaSource extends SimpleJavaFileObject { > > private String code; > > public JavaSource(String code) { > super(URI.create("myfo:/Test.java"), JavaFileObject.Kind.SOURCE); > this.code = code; > } > > @Override > public CharSequence getCharContent(boolean ignoreEncodingErrors) { > return code; > } > } > > > The proposal herein is a to add a factory method that would return an implementation of `SimpleJavaFileObject` based on the provided `URI` and source content. > > The CSR for this change is available for review here: > https://bugs.openjdk.org/browse/JDK-8327536 Marked as reviewed by jlaskey (Reviewer). This is great. ------------- PR Review: https://git.openjdk.org/jdk/pull/18149#pullrequestreview-1921805607 PR Comment: https://git.openjdk.org/jdk/pull/18149#issuecomment-1982971100 From jlaskey at openjdk.org Thu Mar 7 08:53:52 2024 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 7 Mar 2024 08:53:52 GMT Subject: RFR: 8325362: Allow to create a simple in-memory input JavaFileObject In-Reply-To: <6KbXE6d6CHtDEoQ03C66d8eFAUyoUM_WhFjJYQiQkqk=.10b93b93-ab06-4b31-bb70-c82eda99a8db@github.com> References: <6KbXE6d6CHtDEoQ03C66d8eFAUyoUM_WhFjJYQiQkqk=.10b93b93-ab06-4b31-bb70-c82eda99a8db@github.com> Message-ID: On Thu, 7 Mar 2024 08:34:32 GMT, Jan Lahoda wrote: > There are many subtypes of `SimpleJavaFileObject` scattered through various codebases, majority of them looking like: > > > private static class JavaSource extends SimpleJavaFileObject { > > private String code; > > public JavaSource(String code) { > super(URI.create("myfo:/Test.java"), JavaFileObject.Kind.SOURCE); > this.code = code; > } > > @Override > public CharSequence getCharContent(boolean ignoreEncodingErrors) { > return code; > } > } > > > The proposal herein is a to add a factory method that would return an implementation of `SimpleJavaFileObject` based on the provided `URI` and source content. > > The CSR for this change is available for review here: > https://bugs.openjdk.org/browse/JDK-8327536 Should consider including an end to end compile a text block example. I for one am always hunting around for the model when I need it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18149#issuecomment-1982993882 From jpai at openjdk.org Thu Mar 7 10:51:59 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 7 Mar 2024 10:51:59 GMT Subject: RFR: 8325362: Allow to create a simple in-memory input JavaFileObject In-Reply-To: <6KbXE6d6CHtDEoQ03C66d8eFAUyoUM_WhFjJYQiQkqk=.10b93b93-ab06-4b31-bb70-c82eda99a8db@github.com> References: <6KbXE6d6CHtDEoQ03C66d8eFAUyoUM_WhFjJYQiQkqk=.10b93b93-ab06-4b31-bb70-c82eda99a8db@github.com> Message-ID: On Thu, 7 Mar 2024 08:34:32 GMT, Jan Lahoda wrote: > There are many subtypes of `SimpleJavaFileObject` scattered through various codebases, majority of them looking like: > > > private static class JavaSource extends SimpleJavaFileObject { > > private String code; > > public JavaSource(String code) { > super(URI.create("myfo:/Test.java"), JavaFileObject.Kind.SOURCE); > this.code = code; > } > > @Override > public CharSequence getCharContent(boolean ignoreEncodingErrors) { > return code; > } > } > > > The proposal herein is a to add a factory method that would return an implementation of `SimpleJavaFileObject` based on the provided `URI` and source content. > > The CSR for this change is available for review here: > https://bugs.openjdk.org/browse/JDK-8327536 src/java.compiler/share/classes/javax/tools/SimpleJavaFileObject.java line 228: > 226: > 227: /** > 228: * Creates a {@link JavaFileObject} which will be represents the given source content. Hello Jan, should this have been `which represents the given source content.` ? src/java.compiler/share/classes/javax/tools/SimpleJavaFileObject.java line 235: > 233: * > 234: *

All other methods will behave as described in the documentation in this class, > 235: * if the constructor is called with {@code uri} and {@code Kind.SOURCE}. Should this have been `as if the constructor ...` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18149#discussion_r1515949515 PR Review Comment: https://git.openjdk.org/jdk/pull/18149#discussion_r1515949948 From jpai at openjdk.org Thu Mar 7 10:55:56 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 7 Mar 2024 10:55:56 GMT Subject: RFR: 8325362: Allow to create a simple in-memory input JavaFileObject In-Reply-To: <6KbXE6d6CHtDEoQ03C66d8eFAUyoUM_WhFjJYQiQkqk=.10b93b93-ab06-4b31-bb70-c82eda99a8db@github.com> References: <6KbXE6d6CHtDEoQ03C66d8eFAUyoUM_WhFjJYQiQkqk=.10b93b93-ab06-4b31-bb70-c82eda99a8db@github.com> Message-ID: On Thu, 7 Mar 2024 08:34:32 GMT, Jan Lahoda wrote: > There are many subtypes of `SimpleJavaFileObject` scattered through various codebases, majority of them looking like: > > > private static class JavaSource extends SimpleJavaFileObject { > > private String code; > > public JavaSource(String code) { > super(URI.create("myfo:/Test.java"), JavaFileObject.Kind.SOURCE); > this.code = code; > } > > @Override > public CharSequence getCharContent(boolean ignoreEncodingErrors) { > return code; > } > } > > > The proposal herein is a to add a factory method that would return an implementation of `SimpleJavaFileObject` based on the provided `URI` and source content. > > The CSR for this change is available for review here: > https://bugs.openjdk.org/browse/JDK-8327536 src/java.compiler/share/classes/javax/tools/SimpleJavaFileObject.java line 237: > 235: * if the constructor is called with {@code uri} and {@code Kind.SOURCE}. > 236: * > 237: * @param uri that should be used for this {@code JavaFileObject} I realize this is a static method, but the use of "this" might mean to imply the current instance on which the method is invoked. Perhaps, we should change it to `that should be used by the returned {@code JavaFileObject}` ? Or maybe just replace "this" with "the"? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18149#discussion_r1515954825 From darcy at openjdk.org Thu Mar 7 17:20:56 2024 From: darcy at openjdk.org (Joe Darcy) Date: Thu, 7 Mar 2024 17:20:56 GMT Subject: RFR: 8325362: Allow to create a simple in-memory input JavaFileObject In-Reply-To: <6KbXE6d6CHtDEoQ03C66d8eFAUyoUM_WhFjJYQiQkqk=.10b93b93-ab06-4b31-bb70-c82eda99a8db@github.com> References: <6KbXE6d6CHtDEoQ03C66d8eFAUyoUM_WhFjJYQiQkqk=.10b93b93-ab06-4b31-bb70-c82eda99a8db@github.com> Message-ID: On Thu, 7 Mar 2024 08:34:32 GMT, Jan Lahoda wrote: > There are many subtypes of `SimpleJavaFileObject` scattered through various codebases, majority of them looking like: > > > private static class JavaSource extends SimpleJavaFileObject { > > private String code; > > public JavaSource(String code) { > super(URI.create("myfo:/Test.java"), JavaFileObject.Kind.SOURCE); > this.code = code; > } > > @Override > public CharSequence getCharContent(boolean ignoreEncodingErrors) { > return code; > } > } > > > The proposal herein is a to add a factory method that would return an implementation of `SimpleJavaFileObject` based on the provided `URI` and source content. > > The CSR for this change is available for review here: > https://bugs.openjdk.org/browse/JDK-8327536 Are there existing uses of this pattern in the regression tests that can be converted to use the new API? ------------- PR Comment: https://git.openjdk.org/jdk/pull/18149#issuecomment-1984042522 From jlahoda at openjdk.org Thu Mar 7 23:13:06 2024 From: jlahoda at openjdk.org (Jan Lahoda) Date: Thu, 7 Mar 2024 23:13:06 GMT Subject: RFR: 8325362: Allow to create a simple in-memory input JavaFileObject [v2] In-Reply-To: <6KbXE6d6CHtDEoQ03C66d8eFAUyoUM_WhFjJYQiQkqk=.10b93b93-ab06-4b31-bb70-c82eda99a8db@github.com> References: <6KbXE6d6CHtDEoQ03C66d8eFAUyoUM_WhFjJYQiQkqk=.10b93b93-ab06-4b31-bb70-c82eda99a8db@github.com> Message-ID: > There are many subtypes of `SimpleJavaFileObject` scattered through various codebases, majority of them looking like: > > > private static class JavaSource extends SimpleJavaFileObject { > > private String code; > > public JavaSource(String code) { > super(URI.create("myfo:/Test.java"), JavaFileObject.Kind.SOURCE); > this.code = code; > } > > @Override > public CharSequence getCharContent(boolean ignoreEncodingErrors) { > return code; > } > } > > > The proposal herein is a to add a factory method that would return an implementation of `SimpleJavaFileObject` based on the provided `URI` and source content. > > The CSR for this change is available for review here: > https://bugs.openjdk.org/browse/JDK-8327536 Jan Lahoda has updated the pull request incrementally with six additional commits since the last revision: - Removing trailing whitespaces. - Updating tests to use the new SimpleJavaFileObject.forSource - Not using schema in the URI. - Using URI.create instead of new URI in the sample. - Reflecting review comments. - Adding a sample code snippet. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/18149/files - new: https://git.openjdk.org/jdk/pull/18149/files/56efc6e1..52416a1b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=18149&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18149&range=00-01 Stats: 200 lines in 22 files changed: 19 ins; 111 del; 70 mod Patch: https://git.openjdk.org/jdk/pull/18149.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18149/head:pull/18149 PR: https://git.openjdk.org/jdk/pull/18149 From jlahoda at openjdk.org Thu Mar 7 23:13:06 2024 From: jlahoda at openjdk.org (Jan Lahoda) Date: Thu, 7 Mar 2024 23:13:06 GMT Subject: RFR: 8325362: Allow to create a simple in-memory input JavaFileObject In-Reply-To: <6KbXE6d6CHtDEoQ03C66d8eFAUyoUM_WhFjJYQiQkqk=.10b93b93-ab06-4b31-bb70-c82eda99a8db@github.com> References: <6KbXE6d6CHtDEoQ03C66d8eFAUyoUM_WhFjJYQiQkqk=.10b93b93-ab06-4b31-bb70-c82eda99a8db@github.com> Message-ID: On Thu, 7 Mar 2024 08:34:32 GMT, Jan Lahoda wrote: > There are many subtypes of `SimpleJavaFileObject` scattered through various codebases, majority of them looking like: > > > private static class JavaSource extends SimpleJavaFileObject { > > private String code; > > public JavaSource(String code) { > super(URI.create("myfo:/Test.java"), JavaFileObject.Kind.SOURCE); > this.code = code; > } > > @Override > public CharSequence getCharContent(boolean ignoreEncodingErrors) { > return code; > } > } > > > The proposal herein is a to add a factory method that would return an implementation of `SimpleJavaFileObject` based on the provided `URI` and source content. > > The CSR for this change is available for review here: > https://bugs.openjdk.org/browse/JDK-8327536 Thanks for the comments so far. I've tried to: - add a sample snippet - adjust the javadoc as suggest - convert existing tests to use the new method (those that I could find and update) ------------- PR Comment: https://git.openjdk.org/jdk/pull/18149#issuecomment-1984753425 From jjg at openjdk.org Thu Mar 7 23:32:23 2024 From: jjg at openjdk.org (Jonathan Gibbons) Date: Thu, 7 Mar 2024 23:32:23 GMT Subject: RFR: JDK-8298405: Implement JEP 467: Markdown Documentation Comments [v47] In-Reply-To: References: Message-ID: > Please review a patch to add support for Markdown syntax in documentation comments, as described in the associated JEP. > > Notable features: > > * support for `///` documentation comments in `JavaTokenizer` > * new module `jdk.internal.md` -- a private copy of the `commonmark-java` library > * updates to `DocCommentParser` to treat `///` comments as Markdown > * updates to the standard doclet to render Markdown comments in HTML Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: add test cases for links to anchors ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16388/files - new: https://git.openjdk.org/jdk/pull/16388/files/fc76e8c7..8dfd9e08 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16388&range=46 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16388&range=45-46 Stats: 60 lines in 1 file changed: 60 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/16388.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16388/head:pull/16388 PR: https://git.openjdk.org/jdk/pull/16388 From darcy at openjdk.org Fri Mar 8 03:02:54 2024 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 8 Mar 2024 03:02:54 GMT Subject: RFR: 8325362: Allow to create a simple in-memory input JavaFileObject [v2] In-Reply-To: References: <6KbXE6d6CHtDEoQ03C66d8eFAUyoUM_WhFjJYQiQkqk=.10b93b93-ab06-4b31-bb70-c82eda99a8db@github.com> Message-ID: On Thu, 7 Mar 2024 23:13:06 GMT, Jan Lahoda wrote: >> There are many subtypes of `SimpleJavaFileObject` scattered through various codebases, majority of them looking like: >> >> >> private static class JavaSource extends SimpleJavaFileObject { >> >> private String code; >> >> public JavaSource(String code) { >> super(URI.create("myfo:/Test.java"), JavaFileObject.Kind.SOURCE); >> this.code = code; >> } >> >> @Override >> public CharSequence getCharContent(boolean ignoreEncodingErrors) { >> return code; >> } >> } >> >> >> The proposal herein is a to add a factory method that would return an implementation of `SimpleJavaFileObject` based on the provided `URI` and source content. >> >> The CSR for this change is available for review here: >> https://bugs.openjdk.org/browse/JDK-8327536 > > Jan Lahoda has updated the pull request incrementally with six additional commits since the last revision: > > - Removing trailing whitespaces. > - Updating tests to use the new SimpleJavaFileObject.forSource > - Not using schema in the URI. > - Using URI.create instead of new URI in the sample. > - Reflecting review comments. > - Adding a sample code snippet. Good to see the change in use in the regression tests; I assume any copyright updates will be done before pushing. ------------- Marked as reviewed by darcy (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/18149#pullrequestreview-1923941820 From jpai at openjdk.org Fri Mar 8 04:06:53 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 8 Mar 2024 04:06:53 GMT Subject: RFR: 8325362: Allow to create a simple in-memory input JavaFileObject [v2] In-Reply-To: References: <6KbXE6d6CHtDEoQ03C66d8eFAUyoUM_WhFjJYQiQkqk=.10b93b93-ab06-4b31-bb70-c82eda99a8db@github.com> Message-ID: On Thu, 7 Mar 2024 23:13:06 GMT, Jan Lahoda wrote: >> There are many subtypes of `SimpleJavaFileObject` scattered through various codebases, majority of them looking like: >> >> >> private static class JavaSource extends SimpleJavaFileObject { >> >> private String code; >> >> public JavaSource(String code) { >> super(URI.create("myfo:/Test.java"), JavaFileObject.Kind.SOURCE); >> this.code = code; >> } >> >> @Override >> public CharSequence getCharContent(boolean ignoreEncodingErrors) { >> return code; >> } >> } >> >> >> The proposal herein is a to add a factory method that would return an implementation of `SimpleJavaFileObject` based on the provided `URI` and source content. >> >> The CSR for this change is available for review here: >> https://bugs.openjdk.org/browse/JDK-8327536 > > Jan Lahoda has updated the pull request incrementally with six additional commits since the last revision: > > - Removing trailing whitespaces. > - Updating tests to use the new SimpleJavaFileObject.forSource > - Not using schema in the URI. > - Using URI.create instead of new URI in the sample. > - Reflecting review comments. > - Adding a sample code snippet. Thank you Jan for the updates. The javadoc changes look good to me. ------------- PR Review: https://git.openjdk.org/jdk/pull/18149#pullrequestreview-1923986147 From jlahoda at openjdk.org Fri Mar 8 10:19:17 2024 From: jlahoda at openjdk.org (Jan Lahoda) Date: Fri, 8 Mar 2024 10:19:17 GMT Subject: RFR: 8325362: Allow to create a simple in-memory input JavaFileObject [v3] In-Reply-To: <6KbXE6d6CHtDEoQ03C66d8eFAUyoUM_WhFjJYQiQkqk=.10b93b93-ab06-4b31-bb70-c82eda99a8db@github.com> References: <6KbXE6d6CHtDEoQ03C66d8eFAUyoUM_WhFjJYQiQkqk=.10b93b93-ab06-4b31-bb70-c82eda99a8db@github.com> Message-ID: <_FwDFqhoDvhgTfVbgGgM79QPwekvljLpee0W2fKgwZ8=.ac82faa4-5551-4778-aab7-84573fa48de1@github.com> > There are many subtypes of `SimpleJavaFileObject` scattered through various codebases, majority of them looking like: > > > private static class JavaSource extends SimpleJavaFileObject { > > private String code; > > public JavaSource(String code) { > super(URI.create("myfo:/Test.java"), JavaFileObject.Kind.SOURCE); > this.code = code; > } > > @Override > public CharSequence getCharContent(boolean ignoreEncodingErrors) { > return code; > } > } > > > The proposal herein is a to add a factory method that would return an implementation of `SimpleJavaFileObject` based on the provided `URI` and source content. > > The CSR for this change is available for review here: > https://bugs.openjdk.org/browse/JDK-8327536 Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: Updating license headers. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/18149/files - new: https://git.openjdk.org/jdk/pull/18149/files/52416a1b..dba3bc9d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=18149&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18149&range=01-02 Stats: 20 lines in 20 files changed: 2 ins; 0 del; 18 mod Patch: https://git.openjdk.org/jdk/pull/18149.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18149/head:pull/18149 PR: https://git.openjdk.org/jdk/pull/18149 From abimpoudis at openjdk.org Fri Mar 8 11:19:17 2024 From: abimpoudis at openjdk.org (Aggelos Biboudis) Date: Fri, 8 Mar 2024 11:19:17 GMT Subject: RFR: 8327683: Crash with primitive type pattern and generic expression in instanceof Message-ID: When compiling the following code, javac results in `java.lang.AssertionError: T.intValue`: public static boolean wideningReferenceConversionUnboxing(T i) { return i instanceof int ii; } The translated code after `Lower`, results in a generated assignment `(int)i.intValue()`. The reason for this bug is that the variable `i` required to have the erased type, set. This PR addresses this issue in `TransPatterns`: public static boolean wideningReferenceConversionUnboxing(Integer i) { return (let int ii in (let /*synthetic*/ final T tmp4500$ = i in tmp4500$ != null && (let /*synthetic*/ final T tmp4500$ = i in tmp4500$ != null)) && (let ii = (int)i.intValue(); in true)); } We also observe a duplicated check in the generated code: `(let /*synthetic*/ final T tmp4500$ = i in tmp4500$ != null`. This PR also tidies up the relevant code transformation in `Lower`. ------------- Commit messages: - 8327683: Crash with primitive type pattern and generic expression in instanceof Changes: https://git.openjdk.org/jdk/pull/18168/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18168&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8327683 Stats: 241 lines in 5 files changed: 204 ins; 15 del; 22 mod Patch: https://git.openjdk.org/jdk/pull/18168.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18168/head:pull/18168 PR: https://git.openjdk.org/jdk/pull/18168 From jlaskey at openjdk.org Fri Mar 8 12:11:53 2024 From: jlaskey at openjdk.org (Jim Laskey) Date: Fri, 8 Mar 2024 12:11:53 GMT Subject: RFR: 8325362: Allow to create a simple in-memory input JavaFileObject [v3] In-Reply-To: <_FwDFqhoDvhgTfVbgGgM79QPwekvljLpee0W2fKgwZ8=.ac82faa4-5551-4778-aab7-84573fa48de1@github.com> References: <6KbXE6d6CHtDEoQ03C66d8eFAUyoUM_WhFjJYQiQkqk=.10b93b93-ab06-4b31-bb70-c82eda99a8db@github.com> <_FwDFqhoDvhgTfVbgGgM79QPwekvljLpee0W2fKgwZ8=.ac82faa4-5551-4778-aab7-84573fa48de1@github.com> Message-ID: On Fri, 8 Mar 2024 10:19:17 GMT, Jan Lahoda wrote: >> There are many subtypes of `SimpleJavaFileObject` scattered through various codebases, majority of them looking like: >> >> >> private static class JavaSource extends SimpleJavaFileObject { >> >> private String code; >> >> public JavaSource(String code) { >> super(URI.create("myfo:/Test.java"), JavaFileObject.Kind.SOURCE); >> this.code = code; >> } >> >> @Override >> public CharSequence getCharContent(boolean ignoreEncodingErrors) { >> return code; >> } >> } >> >> >> The proposal herein is a to add a factory method that would return an implementation of `SimpleJavaFileObject` based on the provided `URI` and source content. >> >> The CSR for this change is available for review here: >> https://bugs.openjdk.org/browse/JDK-8327536 > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Updating license headers. LGTM ------------- Marked as reviewed by jlaskey (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/18149#pullrequestreview-1924745292 From abimpoudis at openjdk.org Sun Mar 10 15:58:19 2024 From: abimpoudis at openjdk.org (Aggelos Biboudis) Date: Sun, 10 Mar 2024 15:58:19 GMT Subject: RFR: 8327683: Crash with primitive type pattern and generic expression in instanceof [v2] In-Reply-To: References: Message-ID: > When compiling the following code, javac results in `java.lang.AssertionError: T.intValue`: > > > public static boolean wideningReferenceConversionUnboxing(T i) { > return i instanceof int ii; > } > > > The translated code after `Lower`, results in a generated assignment `(int)i.intValue()`. The reason for this bug is that the variable `i` required to have the erased type, set. This PR addresses this issue in `TransPatterns`: > > > public static boolean wideningReferenceConversionUnboxing(Integer i) { > return (let int ii in > (let /*synthetic*/ final T tmp4500$ = i in tmp4500$ != null && (let /*synthetic*/ final T tmp4500$ = i in tmp4500$ != null)) && > (let ii = (int)i.intValue(); in true)); > } > > > We also observe a duplicated check in the generated code: `(let /*synthetic*/ final T tmp4500$ = i in tmp4500$ != null`. This PR also tidies up the relevant code transformation in `Lower`. Aggelos Biboudis has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge branch 'master' into fix-#8327683 - 8327683: Crash with primitive type pattern and generic expression in instanceof ------------- Changes: - all: https://git.openjdk.org/jdk/pull/18168/files - new: https://git.openjdk.org/jdk/pull/18168/files/aaf20903..d57b0456 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=18168&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18168&range=00-01 Stats: 7955 lines in 150 files changed: 3776 ins; 3694 del; 485 mod Patch: https://git.openjdk.org/jdk/pull/18168.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18168/head:pull/18168 PR: https://git.openjdk.org/jdk/pull/18168 From dholmes at openjdk.org Sun Mar 10 21:46:56 2024 From: dholmes at openjdk.org (David Holmes) Date: Sun, 10 Mar 2024 21:46:56 GMT Subject: RFR: 8323605: Java source launcher should not require `--source ...` to enable preview [v4] In-Reply-To: <18o5YIblHul4zgTjQ_zbQbORH-NPgvbiY0mTMhqYD4Y=.14d86d1c-4fb0-4e5c-8ec8-1430fb131bb5@github.com> References: <18o5YIblHul4zgTjQ_zbQbORH-NPgvbiY0mTMhqYD4Y=.14d86d1c-4fb0-4e5c-8ec8-1430fb131bb5@github.com> Message-ID: On Mon, 4 Mar 2024 08:18:25 GMT, Christian Stein wrote: >> Please review this PR targeting the source launcher that instead of throwing an error reading _"--enable-preview must be used with --source"_ adds the required compiler arguments on-the-fly. >> >> The add arguments are `--release` and `feature`, with `feature` being the release feature number of the current Java runtime as acquired by `Runtime.version().feature()`. > > Christian Stein has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Update `java`'s man page > - Merge branch 'refs/heads/master' into JDK-8323605-launch-with-source-by-default > - Remove now outdated workaround > > [skip ci] > - Update copyright dates > > [skip ci] > - 8323605: Java source launcher should not require `--source ...` to enable preview src/java.base/share/man/java.1 line 284: > 282: If \f[V]--enable-preview\f[R] is specified, the \f[V]--source N\f[R] > 283: arguments can be omitted. > 284: The Java Runtime of version \f[V]N\f[R] implies an implicit I think that should be `A Java runtime version ...` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17731#discussion_r1518990161 From dholmes at openjdk.org Sun Mar 10 21:53:56 2024 From: dholmes at openjdk.org (David Holmes) Date: Sun, 10 Mar 2024 21:53:56 GMT Subject: RFR: 8323605: Java source launcher should not require `--source ...` to enable preview [v4] In-Reply-To: References: <18o5YIblHul4zgTjQ_zbQbORH-NPgvbiY0mTMhqYD4Y=.14d86d1c-4fb0-4e5c-8ec8-1430fb131bb5@github.com> Message-ID: On Sun, 10 Mar 2024 21:44:03 GMT, David Holmes wrote: >> Christian Stein has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: >> >> - Update `java`'s man page >> - Merge branch 'refs/heads/master' into JDK-8323605-launch-with-source-by-default >> - Remove now outdated workaround >> >> [skip ci] >> - Update copyright dates >> >> [skip ci] >> - 8323605: Java source launcher should not require `--source ...` to enable preview > > src/java.base/share/man/java.1 line 284: > >> 282: If \f[V]--enable-preview\f[R] is specified, the \f[V]--source N\f[R] >> 283: arguments can be omitted. >> 284: The Java Runtime of version \f[V]N\f[R] implies an implicit > > I think that should be `A Java runtime version ...` Also `implies an implicit` is doubling up. I suggest the following complete sentence: If the Java runtime version is N, then `--release N` is implied when compiling source files. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17731#discussion_r1518991164 From abimpoudis at openjdk.org Mon Mar 11 16:42:27 2024 From: abimpoudis at openjdk.org (Aggelos Biboudis) Date: Mon, 11 Mar 2024 16:42:27 GMT Subject: RFR: 8326204: yield statements doesn't allow cast expressions with more than 1 type arguments Message-ID: A valid use of `yield` that includes a cast to a generic type with multiple parameters, was misdetected by `blockStatement` in parser. This PR addresses this issue. ------------- Commit messages: - 8326204: yield statements doesn't allow cast expressions with more than 1 type arguments Changes: https://git.openjdk.org/jdk/pull/18196/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18196&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8326204 Stats: 62 lines in 2 files changed: 61 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/18196.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18196/head:pull/18196 PR: https://git.openjdk.org/jdk/pull/18196 From jlahoda at openjdk.org Mon Mar 11 16:42:27 2024 From: jlahoda at openjdk.org (Jan Lahoda) Date: Mon, 11 Mar 2024 16:42:27 GMT Subject: RFR: 8326204: yield statements doesn't allow cast expressions with more than 1 type arguments In-Reply-To: References: Message-ID: On Mon, 11 Mar 2024 14:23:38 GMT, Aggelos Biboudis wrote: > A valid use of `yield` that includes a cast to a generic type with multiple parameters, was misdetected by `blockStatement` in parser. This PR addresses this issue. Looks good, with one suggestion for consideration. src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 2897: > 2895: int balance = 1; > 2896: boolean hasComma = false; > 2897: boolean hasTypeArgs = false; For consideration, may also balance out the `<`/`>`, to cover cases like this: private static int t(int i) { yield((Map) null, 2); } private static void yield(Map m, int j) { } Not critical, as this is error recovery anyway, so for consideration only. ------------- Marked as reviewed by jlahoda (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/18196#pullrequestreview-1928189455 PR Review Comment: https://git.openjdk.org/jdk/pull/18196#discussion_r1519935963 From aturbanov at openjdk.org Mon Mar 11 18:16:54 2024 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Mon, 11 Mar 2024 18:16:54 GMT Subject: RFR: 8325936: jshell - crash on 'new Object().""' In-Reply-To: References: Message-ID: On Thu, 15 Feb 2024 16:55:31 GMT, Hannes Greule wrote: > This fixes a crash in jshell when the target of a StringTemplate is not a processor. We only look up the `process` method if the type is actually a processor. The added test case fails without that fix. > > Please let me know what you think of this fix, and if there are things that should be changed. src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 4482: > 4480: Type interfaceType = types.asSuper(processorType, syms.processorType.tsym); > 4481: > 4482: if (interfaceType == null) { Suggestion: if (interfaceType == null) { ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17876#discussion_r1520210961 From jjg at openjdk.org Mon Mar 11 22:02:30 2024 From: jjg at openjdk.org (Jonathan Gibbons) Date: Mon, 11 Mar 2024 22:02:30 GMT Subject: RFR: JDK-8298405: Implement JEP 467: Markdown Documentation Comments [v48] In-Reply-To: References: Message-ID: > Please review a patch to add support for Markdown syntax in documentation comments, as described in the associated JEP. > > Notable features: > > * support for `///` documentation comments in `JavaTokenizer` > * new module `jdk.internal.md` -- a private copy of the `commonmark-java` library > * updates to `DocCommentParser` to treat `///` comments as Markdown > * updates to the standard doclet to render Markdown comments in HTML Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: improve first-sentence break in Markdown comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16388/files - new: https://git.openjdk.org/jdk/pull/16388/files/8dfd9e08..81279a74 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16388&range=47 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16388&range=46-47 Stats: 50 lines in 2 files changed: 45 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/16388.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16388/head:pull/16388 PR: https://git.openjdk.org/jdk/pull/16388 From jjg at openjdk.org Mon Mar 11 23:53:33 2024 From: jjg at openjdk.org (Jonathan Gibbons) Date: Mon, 11 Mar 2024 23:53:33 GMT Subject: RFR: JDK-8298405: Implement JEP 467: Markdown Documentation Comments [v49] In-Reply-To: References: Message-ID: > Please review a patch to add support for Markdown syntax in documentation comments, as described in the associated JEP. > > Notable features: > > * support for `///` documentation comments in `JavaTokenizer` > * new module `jdk.internal.md` -- a private copy of the `commonmark-java` library > * updates to `DocCommentParser` to treat `///` comments as Markdown > * updates to the standard doclet to render Markdown comments in HTML Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 68 commits: - Merge with upstream/master - improve first-sentence break in Markdown comments - add test cases for links to anchors - fix `textOf` method to accommodate Markdown content. - avoid relying on unspecified behavior `List.toString` - fix test after merge - Merge remote-tracking branch 'upstream/master' into 8298405.doclet-markdown-v3 - Revise `Markdown.update` to better handle container blocks. - Refactor most of TestMarkdown.java into separate tests, grouped by functionality - add support for (top-level) trailing code blocks add simple test case with tabs add TestMarkdownCodeBlocks.testTypical - ... and 58 more: https://git.openjdk.org/jdk/compare/586396cb...76eccbf4 ------------- Changes: https://git.openjdk.org/jdk/pull/16388/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16388&range=48 Stats: 23757 lines in 208 files changed: 23030 ins; 281 del; 446 mod Patch: https://git.openjdk.org/jdk/pull/16388.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16388/head:pull/16388 PR: https://git.openjdk.org/jdk/pull/16388 From abimpoudis at openjdk.org Tue Mar 12 14:11:32 2024 From: abimpoudis at openjdk.org (Aggelos Biboudis) Date: Tue, 12 Mar 2024 14:11:32 GMT Subject: RFR: 8327839: Crash with unboxing and widening primitive conversion in switch Message-ID: In cases where the compiler needs to unbox a `long`, `float`, `double` and then run the exactness check, we were getting a crash. While the selector value is always boxed, the type (which controls the execution flow) was not, because the `selectorType` was wrong. This PR addresses this bug. ------------- Commit messages: - 8327839: Crash with unboxing and widening primitive conversion in switch Changes: https://git.openjdk.org/jdk/pull/18236/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18236&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8327839 Stats: 111 lines in 5 files changed: 99 ins; 0 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/18236.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18236/head:pull/18236 PR: https://git.openjdk.org/jdk/pull/18236 From cstein at openjdk.org Tue Mar 12 15:59:26 2024 From: cstein at openjdk.org (Christian Stein) Date: Tue, 12 Mar 2024 15:59:26 GMT Subject: RFR: 8323605: Java source launcher should not require `--source ...` to enable preview [v5] In-Reply-To: References: Message-ID: <-QBM8H1Pd_m5jPlXkqjQ_82D1RR7riOPNVkqul-qZQk=.0714650d-4a22-4d80-ad92-100ad387b1ed@github.com> > Please review this PR targeting the source launcher that instead of throwing an error reading _"--enable-preview must be used with --source"_ adds the required compiler arguments on-the-fly. > > The add arguments are `--release` and `feature`, with `feature` being the release feature number of the current Java runtime as acquired by `Runtime.version().feature()`. Christian Stein has updated the pull request incrementally with one additional commit since the last revision: Update to suggested sentence ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17731/files - new: https://git.openjdk.org/jdk/pull/17731/files/bb8eac9a..a82e4fe3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17731&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17731&range=03-04 Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/17731.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17731/head:pull/17731 PR: https://git.openjdk.org/jdk/pull/17731 From cstein at openjdk.org Tue Mar 12 16:02:16 2024 From: cstein at openjdk.org (Christian Stein) Date: Tue, 12 Mar 2024 16:02:16 GMT Subject: RFR: 8323605: Java source launcher should not require `--source ...` to enable preview [v4] In-Reply-To: References: <18o5YIblHul4zgTjQ_zbQbORH-NPgvbiY0mTMhqYD4Y=.14d86d1c-4fb0-4e5c-8ec8-1430fb131bb5@github.com> Message-ID: On Sun, 10 Mar 2024 21:50:59 GMT, David Holmes wrote: >> src/java.base/share/man/java.1 line 284: >> >>> 282: If \f[V]--enable-preview\f[R] is specified, the \f[V]--source N\f[R] >>> 283: arguments can be omitted. >>> 284: The Java Runtime of version \f[V]N\f[R] implies an implicit >> >> I think that should be `A Java runtime version ...` > > Also `implies an implicit` is doubling up. I suggest the following complete sentence: > > If the Java runtime version is N, then `--release N` is implied when compiling source files. Done via https://github.com/openjdk/jdk/pull/17731/commits/a82e4fe3d05a411635bbce0a69e17218184e7ab6 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17731#discussion_r1521736000 From cstein at openjdk.org Tue Mar 12 16:06:24 2024 From: cstein at openjdk.org (Christian Stein) Date: Tue, 12 Mar 2024 16:06:24 GMT Subject: RFR: 8323605: Java source launcher should not require `--source ...` to enable preview [v6] In-Reply-To: References: Message-ID: > Please review this PR targeting the source launcher that instead of throwing an error reading _"--enable-preview must be used with --source"_ adds the required compiler arguments on-the-fly. > > The add arguments are `--release` and `feature`, with `feature` being the release feature number of the current Java runtime as acquired by `Runtime.version().feature()`. Christian Stein has updated the pull request incrementally with one additional commit since the last revision: Remove superfluous backticks ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17731/files - new: https://git.openjdk.org/jdk/pull/17731/files/a82e4fe3..dccb064e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17731&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17731&range=04-05 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/17731.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17731/head:pull/17731 PR: https://git.openjdk.org/jdk/pull/17731 From abimpoudis at openjdk.org Tue Mar 12 17:30:47 2024 From: abimpoudis at openjdk.org (Aggelos Biboudis) Date: Tue, 12 Mar 2024 17:30:47 GMT Subject: RFR: 8326204: yield statements doesn't allow cast expressions with more than 1 type arguments [v2] In-Reply-To: References: Message-ID: > A valid use of `yield` that includes a cast to a generic type with multiple parameters, was misdetected by `blockStatement` in parser. This PR addresses this issue. Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision: Address comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/18196/files - new: https://git.openjdk.org/jdk/pull/18196/files/25f6ffec..f688c1e3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=18196&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18196&range=00-01 Stats: 21 lines in 4 files changed: 16 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/18196.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18196/head:pull/18196 PR: https://git.openjdk.org/jdk/pull/18196 From dholmes at openjdk.org Wed Mar 13 06:40:19 2024 From: dholmes at openjdk.org (David Holmes) Date: Wed, 13 Mar 2024 06:40:19 GMT Subject: RFR: 8323605: Java source launcher should not require `--source ...` to enable preview [v6] In-Reply-To: References: Message-ID: On Tue, 12 Mar 2024 16:06:24 GMT, Christian Stein wrote: >> Please review this PR targeting the source launcher that instead of throwing an error reading _"--enable-preview must be used with --source"_ adds the required compiler arguments on-the-fly. >> >> The add arguments are `--release` and `feature`, with `feature` being the release feature number of the current Java runtime as acquired by `Runtime.version().feature()`. > > Christian Stein has updated the pull request incrementally with one additional commit since the last revision: > > Remove superfluous backticks manpage update is good. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17731#pullrequestreview-1933262272 From cstein at openjdk.org Wed Mar 13 06:48:24 2024 From: cstein at openjdk.org (Christian Stein) Date: Wed, 13 Mar 2024 06:48:24 GMT Subject: Integrated: 8323605: Java source launcher should not require `--source ...` to enable preview In-Reply-To: References: Message-ID: <-H_mhLBd9_vxYOM1SlD8GsaHqH2FMqMemp5EvkcRMog=.2f4717c4-75ce-4902-9199-4ee57687e74d@github.com> On Tue, 6 Feb 2024 12:01:04 GMT, Christian Stein wrote: > Please review this PR targeting the source launcher that instead of throwing an error reading _"--enable-preview must be used with --source"_ adds the required compiler arguments on-the-fly. > > The add arguments are `--release` and `feature`, with `feature` being the release feature number of the current Java runtime as acquired by `Runtime.version().feature()`. This pull request has now been integrated. Changeset: 3b18c5dc Author: Christian Stein URL: https://git.openjdk.org/jdk/commit/3b18c5dc5d5885fe5ebaabd9cd74f033a584e4ae Stats: 26 lines in 5 files changed: 7 ins; 11 del; 8 mod 8323605: Java source launcher should not require `--source ...` to enable preview Reviewed-by: mcimadamore, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/17731 From abimpoudis at openjdk.org Wed Mar 13 10:53:13 2024 From: abimpoudis at openjdk.org (Aggelos Biboudis) Date: Wed, 13 Mar 2024 10:53:13 GMT Subject: RFR: 8326204: yield statements doesn't allow cast expressions with more than 1 type arguments [v2] In-Reply-To: References: Message-ID: On Mon, 11 Mar 2024 15:38:34 GMT, Jan Lahoda wrote: >> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision: >> >> Address comments > > src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 2897: > >> 2895: int balance = 1; >> 2896: boolean hasComma = false; >> 2897: boolean hasTypeArgs = false; > > For consideration, may also balance out the `<`/`>`, to cover cases like this: > > private static int t(int i) { > yield((Map) null, 2); > } > > private static void yield(Map m, int j) { > > } > > > Not critical, as this is error recovery anyway, so for consideration only. Addressed. Thanks @lahodaj ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18196#discussion_r1522993223 From abimpoudis at openjdk.org Thu Mar 14 07:04:47 2024 From: abimpoudis at openjdk.org (Aggelos Biboudis) Date: Thu, 14 Mar 2024 07:04:47 GMT Subject: Integrated: 8326204: yield statements doesn't allow cast expressions with more than 1 type arguments In-Reply-To: References: Message-ID: On Mon, 11 Mar 2024 14:23:38 GMT, Aggelos Biboudis wrote: > A valid use of `yield` that includes a cast to a generic type with multiple parameters, was misdetected by `blockStatement` in parser. This PR addresses this issue. This pull request has now been integrated. Changeset: cff0747d Author: Aggelos Biboudis URL: https://git.openjdk.org/jdk/commit/cff0747d7f62efc3dafcd259ef2b15cd13bafbeb Stats: 78 lines in 4 files changed: 77 ins; 0 del; 1 mod 8326204: yield statements doesn't allow cast expressions with more than 1 type arguments Reviewed-by: jlahoda ------------- PR: https://git.openjdk.org/jdk/pull/18196 From mchung at openjdk.org Thu Mar 14 17:39:50 2024 From: mchung at openjdk.org (Mandy Chung) Date: Thu, 14 Mar 2024 17:39:50 GMT Subject: RFR: 8326979: (jdeps) improve the error message for FindException caused by InvalidModuleDescriptorException Message-ID: Trivial fix. Improve the error message to print the cause of the module resolution failure if present. ------------- Commit messages: - 8326979: (jdeps) improve the error message for FindException caused by InvalidModuleDescriptorException Changes: https://git.openjdk.org/jdk/pull/18308/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18308&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8326979 Stats: 89 lines in 2 files changed: 88 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/18308.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18308/head:pull/18308 PR: https://git.openjdk.org/jdk/pull/18308 From jpai at openjdk.org Fri Mar 15 01:29:37 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 15 Mar 2024 01:29:37 GMT Subject: RFR: 8326979: (jdeps) improve the error message for FindException caused by InvalidModuleDescriptorException In-Reply-To: References: Message-ID: <2aAHIoub3_KoC-XLtG-4TRhGgzb94aLiHMM2IHvSifM=.1f1e6684-b8a6-41a0-b97a-3e537b3c8578@github.com> On Thu, 14 Mar 2024 17:35:22 GMT, Mandy Chung wrote: > Trivial fix. Improve the error message to print the cause of the module resolution failure if present. Hello Mandy, this change to use the underlying cause of `ResolutionExcepion` and `FindException` when reporting the error message, appears OK to me. I didn't know if `ResolutionException` too wraps the actual cause underneath, so I looked around a few JBS issues where `ResolutionException` was reported as being thrown and it does appear that the actual cause lies underneath. So I think this change is fine. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/18308#pullrequestreview-1937969339 From alanb at openjdk.org Fri Mar 15 06:42:38 2024 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 15 Mar 2024 06:42:38 GMT Subject: RFR: 8326979: (jdeps) improve the error message for FindException caused by InvalidModuleDescriptorException In-Reply-To: References: Message-ID: On Thu, 14 Mar 2024 17:35:22 GMT, Mandy Chung wrote: > Trivial fix. Improve the error message to print the cause of the module resolution failure if present. Tests that depend on exception messages can be problematic but this one is easy to change if/when the exception message changes. ------------- Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/18308#pullrequestreview-1938210400 From jlahoda at openjdk.org Fri Mar 15 13:03:54 2024 From: jlahoda at openjdk.org (Jan Lahoda) Date: Fri, 15 Mar 2024 13:03:54 GMT Subject: RFR: 8327839: Crash with unboxing and widening primitive conversion in switch In-Reply-To: References: Message-ID: On Tue, 12 Mar 2024 14:06:11 GMT, Aggelos Biboudis wrote: > In cases where the compiler needs to unbox a `long`, `float`, `double` and then run the exactness check, we were getting a crash. While the selector value is always boxed, the type (which controls the execution flow) was not, because the `selectorType` was wrong. This PR addresses this bug. Looks reasonable to me. ------------- Marked as reviewed by jlahoda (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/18236#pullrequestreview-1938900922 From aturbanov at openjdk.org Sat Mar 16 22:18:23 2024 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Sat, 16 Mar 2024 22:18:23 GMT Subject: RFR: 8327839: Crash with unboxing and widening primitive conversion in switch In-Reply-To: References: Message-ID: On Tue, 12 Mar 2024 14:06:11 GMT, Aggelos Biboudis wrote: > In cases where the compiler needs to unbox a `long`, `float`, `double` and then run the exactness check, we were getting a crash. While the selector value is always boxed, the type (which controls the execution flow) was not, because the `selectorType` was wrong. This PR addresses this bug. test/langtools/tools/javac/patterns/PrimitivePatternsSwitch.java line 121: > 119: assertEquals(Float.MAX_VALUE, testUnboxingAndWideningFloat(Float.MAX_VALUE)); > 120: assertEquals(Float.MAX_VALUE, testUnboxingAndWideningFloatExplicitCast(Float.MAX_VALUE)); > 121: assertEquals(42f, testUnboxingAndWideningLong(42l)); Suggestion: assertEquals(42f, testUnboxingAndWideningLong(42L)); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18236#discussion_r1527165787 From jjg at openjdk.org Sat Mar 16 22:25:06 2024 From: jjg at openjdk.org (Jonathan Gibbons) Date: Sat, 16 Mar 2024 22:25:06 GMT Subject: RFR: JDK-8298405: Implement JEP 467: Markdown Documentation Comments [v50] In-Reply-To: References: Message-ID: <5iwOoEAgMLQAlSM2lel0c_hb0eV_rI0pRA1H4FTFpk0=.67fa5f21-25b3-417a-b9fc-ae31695708b7@github.com> > Please review a patch to add support for Markdown syntax in documentation comments, as described in the associated JEP. > > Notable features: > > * support for `///` documentation comments in `JavaTokenizer` > * new module `jdk.internal.md` -- a private copy of the `commonmark-java` library > * updates to `DocCommentParser` to treat `///` comments as Markdown > * updates to the standard doclet to render Markdown comments in HTML Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 69 commits: - Merge with upstream/master - Merge with upstream/master - improve first-sentence break in Markdown comments - add test cases for links to anchors - fix `textOf` method to accommodate Markdown content. - avoid relying on unspecified behavior `List.toString` - fix test after merge - Merge remote-tracking branch 'upstream/master' into 8298405.doclet-markdown-v3 - Revise `Markdown.update` to better handle container blocks. - Refactor most of TestMarkdown.java into separate tests, grouped by functionality - ... and 59 more: https://git.openjdk.org/jdk/compare/65a84c26...635af77d ------------- Changes: https://git.openjdk.org/jdk/pull/16388/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16388&range=49 Stats: 23526 lines in 208 files changed: 22955 ins; 228 del; 343 mod Patch: https://git.openjdk.org/jdk/pull/16388.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16388/head:pull/16388 PR: https://git.openjdk.org/jdk/pull/16388 From acobbs at openjdk.org Sun Mar 17 22:45:32 2024 From: acobbs at openjdk.org (Archie Cobbs) Date: Sun, 17 Mar 2024 22:45:32 GMT Subject: RFR: 8324736: Invalid end positions for EMPTY_STATEMENT [v2] In-Reply-To: References: <_SVXTU-6FrRb22P-dMVT4ohUBm_UUOzviExP75V57tU=.2665e11a-1f1f-49c2-98a6-4d0c69baacc3@github.com> Message-ID: On Sat, 24 Feb 2024 01:17:01 GMT, Vicente Romero wrote: >> Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: >> >> - Merge branch 'master' into JDK-8324736 >> - Fix bug where source positions got reversed. > > lgtm @vicente-romero-oracle any interest in sponsoring this so we can wrap it up? Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17595#issuecomment-2002642908 From abimpoudis at openjdk.org Mon Mar 18 08:53:29 2024 From: abimpoudis at openjdk.org (Aggelos Biboudis) Date: Mon, 18 Mar 2024 08:53:29 GMT Subject: RFR: 8327839: Crash with unboxing and widening primitive conversion in switch [v2] In-Reply-To: References: Message-ID: <2znGbxx7HVg1nNv4AURxwAs22uRivO_v35-uTHm1ceM=.b47fa1fa-92f5-4d10-832e-37f4e1a15659@github.com> > In cases where the compiler needs to unbox a `long`, `float`, `double` and then run the exactness check, we were getting a crash. While the selector value is always boxed, the type (which controls the execution flow) was not, because the `selectorType` was wrong. This PR addresses this bug. Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision: Update test/langtools/tools/javac/patterns/PrimitivePatternsSwitch.java Co-authored-by: Andrey Turbanov ------------- Changes: - all: https://git.openjdk.org/jdk/pull/18236/files - new: https://git.openjdk.org/jdk/pull/18236/files/ecf909d0..50275918 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=18236&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18236&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/18236.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18236/head:pull/18236 PR: https://git.openjdk.org/jdk/pull/18236 From cstein at openjdk.org Mon Mar 18 10:55:52 2024 From: cstein at openjdk.org (Christian Stein) Date: Mon, 18 Mar 2024 10:55:52 GMT Subject: RFR: JDK-8328339: Static import prevents source launcher from finding class with main method Message-ID: Please review this fix for finding the program class in case the first top-level type has no main method and the order of type compilation does not match the order in the source file - for example by a static import statement being present. Here's an excerpt from [JEP 458](https://openjdk.org/jeps/458#Launch-time-semantics-and-operation)'s "Launch-time semantics and operation" section describing the process: > 5. Determine the launch class of the initial .java file. If the first top level class in the initial file declares a standard main method (`public static void main(String[])` or other standard main entry points as defined in [JEP 463](https://openjdk.org/jeps/463#A-flexible-launch-protocol)), then that class is the launch class. Otherwise, if another top level class in the initial file declares a standard main method and has same name as the file, that class is the launch class. Otherwise, there is no launch class, and the launcher reports an error and stops. ------------- Commit messages: - JDK-8328339: Static import prevents source launcher from finding class with main method Changes: https://git.openjdk.org/jdk/pull/18345/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18345&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8328339 Stats: 27 lines in 2 files changed: 25 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/18345.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18345/head:pull/18345 PR: https://git.openjdk.org/jdk/pull/18345 From abimpoudis at openjdk.org Mon Mar 18 13:19:31 2024 From: abimpoudis at openjdk.org (Aggelos Biboudis) Date: Mon, 18 Mar 2024 13:19:31 GMT Subject: Integrated: 8327839: Crash with unboxing and widening primitive conversion in switch In-Reply-To: References: Message-ID: <6PEReV6E54AAZf2Qiiouqh89xGj3QhmgKyWla5rtChI=.ca66d96b-db04-4564-8fad-b4341c8405b3@github.com> On Tue, 12 Mar 2024 14:06:11 GMT, Aggelos Biboudis wrote: > In cases where the compiler needs to unbox a `long`, `float`, `double` and then run the exactness check, we were getting a crash. While the selector value is always boxed, the type (which controls the execution flow) was not, because the `selectorType` was wrong. This PR addresses this bug. This pull request has now been integrated. Changeset: fb390d20 Author: Aggelos Biboudis URL: https://git.openjdk.org/jdk/commit/fb390d202c8bbbbb87ba48fd01387feb35a1b768 Stats: 111 lines in 5 files changed: 99 ins; 0 del; 12 mod 8327839: Crash with unboxing and widening primitive conversion in switch Reviewed-by: jlahoda ------------- PR: https://git.openjdk.org/jdk/pull/18236 From jjg at openjdk.org Mon Mar 18 15:11:28 2024 From: jjg at openjdk.org (Jonathan Gibbons) Date: Mon, 18 Mar 2024 15:11:28 GMT Subject: RFR: 8297879: javadoc link to preview JEP 1000 has grouping character comma In-Reply-To: <1_igawz8T_HtBuu7XHnp5a7MdBKn1faVA5zBCr2T9bU=.dc2b11f7-84db-4db8-9752-9fd4eb4bd695@github.com> References: <1_igawz8T_HtBuu7XHnp5a7MdBKn1faVA5zBCr2T9bU=.dc2b11f7-84db-4db8-9752-9fd4eb4bd695@github.com> Message-ID: On Mon, 18 Mar 2024 14:53:44 GMT, Pavel Rappo wrote: > Please review this simple bugfix to properly construct links to preview JEPs. > > The most straightforward fix I could think of was to pass `String` rather than `int` (`Integer`) to a method, which eventually calls `java.text.MessageFormat.format(String, Object...)`. > > For the test, I decided to be ~lazy~ practical and piggyback on the existing infrastructure. The alternatives were: > > 1. slap `noreg-hard` on the JBS bug and skip testing > 2. create a sophisticated test that dynamically adds a constant into the `PreviewFeature.Feature` enum, annotates some class with `PreviewFeature` with that constant, and finally documents that class with `PreviewFeature` patched into `java.base` > > While (1) is insufficient, (2) seems overkill in this case. Marked as reviewed by jjg (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/18350#pullrequestreview-1943374124 From prappo at openjdk.org Mon Mar 18 15:11:29 2024 From: prappo at openjdk.org (Pavel Rappo) Date: Mon, 18 Mar 2024 15:11:29 GMT Subject: RFR: 8297879: javadoc link to preview JEP 1000 has grouping character comma In-Reply-To: <1_igawz8T_HtBuu7XHnp5a7MdBKn1faVA5zBCr2T9bU=.dc2b11f7-84db-4db8-9752-9fd4eb4bd695@github.com> References: <1_igawz8T_HtBuu7XHnp5a7MdBKn1faVA5zBCr2T9bU=.dc2b11f7-84db-4db8-9752-9fd4eb4bd695@github.com> Message-ID: On Mon, 18 Mar 2024 14:53:44 GMT, Pavel Rappo wrote: > Please review this simple bugfix to properly construct links to preview JEPs. > > The most straightforward fix I could think of was to pass `String` rather than `int` (`Integer`) to a method, which eventually calls `java.text.MessageFormat.format(String, Object...)`. > > For the test, I decided to be ~lazy~ practical and piggyback on the existing infrastructure. The alternatives were: > > 1. slap `noreg-hard` on the JBS bug and skip testing > 2. create a sophisticated test that dynamically adds a constant into the `PreviewFeature.Feature` enum, annotates some class with `PreviewFeature` with that constant, and finally documents that class with `PreviewFeature` patched into `java.base` > > While (1) is insufficient, (2) seems overkill in this case. Hm... it's surprising to see that the Skara bots consider that src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java belongs to core-libs, but not to compiler. Let me manually add it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18350#issuecomment-2004168270 From vromero at openjdk.org Mon Mar 18 16:28:27 2024 From: vromero at openjdk.org (Vicente Romero) Date: Mon, 18 Mar 2024 16:28:27 GMT Subject: RFR: 8297879: javadoc link to preview JEP 1000 has grouping character comma In-Reply-To: <1_igawz8T_HtBuu7XHnp5a7MdBKn1faVA5zBCr2T9bU=.dc2b11f7-84db-4db8-9752-9fd4eb4bd695@github.com> References: <1_igawz8T_HtBuu7XHnp5a7MdBKn1faVA5zBCr2T9bU=.dc2b11f7-84db-4db8-9752-9fd4eb4bd695@github.com> Message-ID: On Mon, 18 Mar 2024 14:53:44 GMT, Pavel Rappo wrote: > Please review this simple bugfix to properly construct links to preview JEPs. > > The most straightforward fix I could think of was to pass `String` rather than `int` (`Integer`) to a method, which eventually calls `java.text.MessageFormat.format(String, Object...)`. > > For the test, I decided to be ~lazy~ practical and piggyback on the existing infrastructure. The alternatives were: > > 1. slap `noreg-hard` on the JBS bug and skip testing > 2. create a sophisticated test that dynamically adds a constant into the `PreviewFeature.Feature` enum, annotates some class with `PreviewFeature` with that constant, and finally documents that class with `PreviewFeature` patched into `java.base` > > While (1) is insufficient, (2) seems overkill in this case. lgtm ------------- Marked as reviewed by vromero (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/18350#pullrequestreview-1943594610 From cstein at openjdk.org Mon Mar 18 17:12:38 2024 From: cstein at openjdk.org (Christian Stein) Date: Mon, 18 Mar 2024 17:12:38 GMT Subject: RFR: JDK-8328339: Static import prevents source launcher from finding class with main method [v2] In-Reply-To: References: Message-ID: > Please review this fix for finding the program class in case the first top-level type has no main method and the order of type compilation does not match the order in the source file - for example by a static import statement being present. > > Here's an excerpt from [JEP 458](https://openjdk.org/jeps/458#Launch-time-semantics-and-operation)'s "Launch-time semantics and operation" section describing the process: >> 5. Determine the launch class of the initial .java file. If the first top level class in the initial file declares a standard main method (`public static void main(String[])` or other standard main entry points as defined in [JEP 463](https://openjdk.org/jeps/463#A-flexible-launch-protocol)), then that class is the launch class. Otherwise, if another top level class in the initial file declares a standard main method and has same name as the file, that class is the launch class. Otherwise, there is no launch class, and the launcher reports an error and stops. Christian Stein has updated the pull request incrementally with one additional commit since the last revision: Ensure source-order of declared types in program source file Move computation of declared types into program descriptor factory. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/18345/files - new: https://git.openjdk.org/jdk/pull/18345/files/ead7fd7b..65fba8d6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=18345&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18345&range=00-01 Stats: 73 lines in 4 files changed: 24 ins; 31 del; 18 mod Patch: https://git.openjdk.org/jdk/pull/18345.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18345/head:pull/18345 PR: https://git.openjdk.org/jdk/pull/18345 From jlahoda at openjdk.org Mon Mar 18 17:43:30 2024 From: jlahoda at openjdk.org (Jan Lahoda) Date: Mon, 18 Mar 2024 17:43:30 GMT Subject: RFR: JDK-8328339: Static import prevents source launcher from finding class with main method [v2] In-Reply-To: References: Message-ID: On Mon, 18 Mar 2024 17:12:38 GMT, Christian Stein wrote: >> Please review this fix for finding the program class in case the first top-level type has no main method and the order of type compilation does not match the order in the source file - for example by a static import statement being present. >> >> Here's an excerpt from [JEP 458](https://openjdk.org/jeps/458#Launch-time-semantics-and-operation)'s "Launch-time semantics and operation" section describing the process: >>> 5. Determine the launch class of the initial .java file. If the first top level class in the initial file declares a standard main method (`public static void main(String[])` or other standard main entry points as defined in [JEP 463](https://openjdk.org/jeps/463#A-flexible-launch-protocol)), then that class is the launch class. Otherwise, if another top level class in the initial file declares a standard main method and has same name as the file, that class is the launch class. Otherwise, there is no launch class, and the launcher reports an error and stops. > > Christian Stein has updated the pull request incrementally with one additional commit since the last revision: > > Ensure source-order of declared types in program source file > > Move computation of declared types into program descriptor factory. Overall, looks good to me. Some suggestions for years in the headers + a potential suggestion to re-order gathering the declared types and package name, so that the qualified names can be computed in one step. src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/MemoryContext.java line 2: > 1: /* > 2: * Copyright (c) 2024, Oracle and/or its affiliates. All rights reserved. Suggestion: * Copyright (c) 2023, 2024, Oracle and/or its affiliates. All rights reserved. src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/ProgramDescriptor.java line 2: > 1: /* > 2: * Copyright (c) 2024, Oracle and/or its affiliates. All rights reserved. Suggestion: * Copyright (c) 2023, 2024, Oracle and/or its affiliates. All rights reserved. src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/ProgramDescriptor.java line 66: > 64: var task = compiler.getTask(null, standardFileManager, diagnostic -> {}, null, null, units); > 65: for (var tree : task.parse()) { > 66: for (var decl : tree.getTypeDecls()) { Not terribly important, but you could first compute the package name, and then compute the declared types. That would permit creating the fully qualified `declaredTypeNames` in one step, rather than putting the simple names into a List and then going through them again to qualify them. src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/SourceLauncher.java line 2: > 1: /* > 2: * Copyright (c) 2024, Oracle and/or its affiliates. All rights reserved. Suggestion: * Copyright (c) 2023, 2024, Oracle and/or its affiliates. All rights reserved. ------------- PR Review: https://git.openjdk.org/jdk/pull/18345#pullrequestreview-1943765732 PR Review Comment: https://git.openjdk.org/jdk/pull/18345#discussion_r1528988234 PR Review Comment: https://git.openjdk.org/jdk/pull/18345#discussion_r1528988646 PR Review Comment: https://git.openjdk.org/jdk/pull/18345#discussion_r1528995167 PR Review Comment: https://git.openjdk.org/jdk/pull/18345#discussion_r1528990277 From jjg at openjdk.org Mon Mar 18 18:44:53 2024 From: jjg at openjdk.org (Jonathan Gibbons) Date: Mon, 18 Mar 2024 18:44:53 GMT Subject: RFR: JDK-8298405: Implement JEP 467: Markdown Documentation Comments [v51] In-Reply-To: References: Message-ID: > Please review a patch to add support for Markdown syntax in documentation comments, as described in the associated JEP. > > Notable features: > > * support for `///` documentation comments in `JavaTokenizer` > * new module `jdk.internal.md` -- a private copy of the `commonmark-java` library > * updates to `DocCommentParser` to treat `///` comments as Markdown > * updates to the standard doclet to render Markdown comments in HTML Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 71 commits: - update man page - Merge remote-tracking branch 'upstream/master' into 8298405.doclet-markdown-v3 - Merge with upstream/master - Merge with upstream/master - improve first-sentence break in Markdown comments - add test cases for links to anchors - fix `textOf` method to accommodate Markdown content. - avoid relying on unspecified behavior `List.toString` - fix test after merge - Merge remote-tracking branch 'upstream/master' into 8298405.doclet-markdown-v3 - ... and 61 more: https://git.openjdk.org/jdk/compare/c901da48...03652d2f ------------- Changes: https://git.openjdk.org/jdk/pull/16388/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16388&range=50 Stats: 23609 lines in 209 files changed: 22986 ins; 254 del; 369 mod Patch: https://git.openjdk.org/jdk/pull/16388.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16388/head:pull/16388 PR: https://git.openjdk.org/jdk/pull/16388 From abimpoudis at openjdk.org Tue Mar 19 08:42:34 2024 From: abimpoudis at openjdk.org (Aggelos Biboudis) Date: Tue, 19 Mar 2024 08:42:34 GMT Subject: RFR: 8327683: Crash with primitive type pattern and generic expression in instanceof [v3] In-Reply-To: References: Message-ID: > When compiling the following code, javac results in `java.lang.AssertionError: T.intValue`: > > > public static boolean wideningReferenceConversionUnboxing(T i) { > return i instanceof int ii; > } > > > The translated code after `Lower`, results in a generated assignment `(int)i.intValue()`. The reason for this bug is that the variable `i` required to have the erased type, set. This PR addresses this issue in `TransPatterns`: > > > public static boolean wideningReferenceConversionUnboxing(Integer i) { > return (let int ii in > (let /*synthetic*/ final T tmp4500$ = i in tmp4500$ != null && (let /*synthetic*/ final T tmp4500$ = i in tmp4500$ != null)) && > (let ii = (int)i.intValue(); in true)); > } > > > We also observe a duplicated check in the generated code: `(let /*synthetic*/ final T tmp4500$ = i in tmp4500$ != null`. This PR also tidies up the relevant code transformation in `Lower`. Aggelos Biboudis has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Merge branch 'master' into fix-#8327683 - Merge branch 'master' into fix-#8327683 - 8327683: Crash with primitive type pattern and generic expression in instanceof ------------- Changes: - all: https://git.openjdk.org/jdk/pull/18168/files - new: https://git.openjdk.org/jdk/pull/18168/files/d57b0456..e53bec1d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=18168&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18168&range=01-02 Stats: 302490 lines in 632 files changed: 11358 ins; 8478 del; 282654 mod Patch: https://git.openjdk.org/jdk/pull/18168.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18168/head:pull/18168 PR: https://git.openjdk.org/jdk/pull/18168 From jlahoda at openjdk.org Tue Mar 19 09:38:26 2024 From: jlahoda at openjdk.org (Jan Lahoda) Date: Tue, 19 Mar 2024 09:38:26 GMT Subject: Integrated: 8325362: Allow to create a simple in-memory input JavaFileObject In-Reply-To: <6KbXE6d6CHtDEoQ03C66d8eFAUyoUM_WhFjJYQiQkqk=.10b93b93-ab06-4b31-bb70-c82eda99a8db@github.com> References: <6KbXE6d6CHtDEoQ03C66d8eFAUyoUM_WhFjJYQiQkqk=.10b93b93-ab06-4b31-bb70-c82eda99a8db@github.com> Message-ID: On Thu, 7 Mar 2024 08:34:32 GMT, Jan Lahoda wrote: > There are many subtypes of `SimpleJavaFileObject` scattered through various codebases, majority of them looking like: > > > private static class JavaSource extends SimpleJavaFileObject { > > private String code; > > public JavaSource(String code) { > super(URI.create("myfo:/Test.java"), JavaFileObject.Kind.SOURCE); > this.code = code; > } > > @Override > public CharSequence getCharContent(boolean ignoreEncodingErrors) { > return code; > } > } > > > The proposal herein is a to add a factory method that would return an implementation of `SimpleJavaFileObject` based on the provided `URI` and source content. > > The CSR for this change is available for review here: > https://bugs.openjdk.org/browse/JDK-8327536 This pull request has now been integrated. Changeset: 5b6b5144 Author: Jan Lahoda URL: https://git.openjdk.org/jdk/commit/5b6b514441fcbbaa210e2cad08ce2704fdf38191 Stats: 379 lines in 23 files changed: 183 ins; 111 del; 85 mod 8325362: Allow to create a simple in-memory input JavaFileObject Reviewed-by: jlaskey, darcy ------------- PR: https://git.openjdk.org/jdk/pull/18149 From weijun at openjdk.org Tue Mar 19 13:23:20 2024 From: weijun at openjdk.org (Weijun Wang) Date: Tue, 19 Mar 2024 13:23:20 GMT Subject: RFR: JDK-8328501 Incorrect @since tags for security java security interfaces In-Reply-To: References: Message-ID: On Tue, 19 Mar 2024 11:15:56 GMT, Nizar Benalla wrote: > The override of `getParams` in these interfaces was added in java 22 has an `@since 22`, but the method has been inherited to these interfaces for a long times, > As pointed out by my mentor Jan, > > > import javax.crypto.interfaces.DHPublicKey; > > public class DhkeyTest { > > public static void main(DHPublicKey key) { > System.err.println(key.getParams()); > } > > } > > > this compiles using JDK 8 without any compile-time errors. The @ since tag shouldn't be here > > > - the same goes for these other interfaces > > java.security.interfaces.DSAPublicKey > java.security.interfaces.XECPublicKey > java.security.interfaces.DSAPrivateKey > java.security.interfaces.ECPrivateKey > java.security.interfaces.XECPrivateKey > java.security.interfaces.EdECPrivateKey > java.security.interfaces.ECPublicKey > java.security.interfaces.EdECPublicKey > javax.crypto.interfaces.DHPrivateKey > javax.crypto.interfaces.DHPublicKey > > - these two should, have @ since 11 though > > java.security.interfaces.RSAPublicKey > java.security.interfaces.RSAPrivateKey I'd like to hear opinions from compiler experts. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18373#issuecomment-2007161883 From prappo at openjdk.org Tue Mar 19 15:25:26 2024 From: prappo at openjdk.org (Pavel Rappo) Date: Tue, 19 Mar 2024 15:25:26 GMT Subject: Integrated: 8297879: javadoc link to preview JEP 1000 has grouping character comma In-Reply-To: <1_igawz8T_HtBuu7XHnp5a7MdBKn1faVA5zBCr2T9bU=.dc2b11f7-84db-4db8-9752-9fd4eb4bd695@github.com> References: <1_igawz8T_HtBuu7XHnp5a7MdBKn1faVA5zBCr2T9bU=.dc2b11f7-84db-4db8-9752-9fd4eb4bd695@github.com> Message-ID: <7PArJXG1ZKRHbwf2SBnuB6z1YIOC9iYcMgHNX_MHmSI=.aa8998d0-08ec-44de-88e1-781df1a695ae@github.com> On Mon, 18 Mar 2024 14:53:44 GMT, Pavel Rappo wrote: > Please review this simple bugfix to properly construct links to preview JEPs. > > The most straightforward fix I could think of was to pass `String` rather than `int` (`Integer`) to a method, which eventually calls `java.text.MessageFormat.format(String, Object...)`. > > For the test, I decided to be ~lazy~ practical and piggyback on the existing infrastructure. The alternatives were: > > 1. slap `noreg-hard` on the JBS bug and skip testing > 2. create a sophisticated test that dynamically adds a constant into the `PreviewFeature.Feature` enum, annotates some class with `PreviewFeature` with that constant, and finally documents that class with `PreviewFeature` patched into `java.base` > > While (1) is insufficient, (2) seems overkill in this case. This pull request has now been integrated. Changeset: f140eb4c Author: Pavel Rappo URL: https://git.openjdk.org/jdk/commit/f140eb4c3a47e1479d62fe1eef16bbbea92892bc Stats: 5 lines in 3 files changed: 0 ins; 0 del; 5 mod 8297879: javadoc link to preview JEP 1000 has grouping character comma Reviewed-by: jjg, vromero ------------- PR: https://git.openjdk.org/jdk/pull/18350 From duke at openjdk.org Tue Mar 19 15:33:34 2024 From: duke at openjdk.org (Nizar Benalla) Date: Tue, 19 Mar 2024 15:33:34 GMT Subject: RFR: JDK-8328501 Incorrect @since tags for security java security interfaces [v2] In-Reply-To: References: Message-ID: > For context, I am writing tests to check for accurate use of `@since` tags in documentation comments in source code. > We're following these rules for now: > > if there's no `@since`: > > - for methods, look at the `@since` from the method from supertype this method overrides. If there's none from the overridden method, or if the `@since` in the enclosing class is newer that the one from the overridden method, use the `@since` from the enclosing element. Otherwise, use the `@since` from the overridden method. > - otherwise, use the `@since` from the enclosing element. > > The override of `getParams` in these interfaces was done in in JDK 22 and an `@since 22` was, but this method has been inherited to these interfaces for a long time. > > As pointed out by my mentor Jan, > > > import javax.crypto.interfaces.DHPublicKey; > > public class DhkeyTest { > > public static void main(DHPublicKey key) { > System.err.println(key.getParams()); > } > > } > > > this compiles using JDK 8 without any compile-time errors. The @ since tag shouldn't be here > > > - the same goes for these other interfaces > > java.security.interfaces.DSAPublicKey > java.security.interfaces.XECPublicKey > java.security.interfaces.DSAPrivateKey > java.security.interfaces.ECPrivateKey > java.security.interfaces.XECPrivateKey > java.security.interfaces.EdECPrivateKey > java.security.interfaces.ECPublicKey > java.security.interfaces.EdECPublicKey > javax.crypto.interfaces.DHPrivateKey > javax.crypto.interfaces.DHPublicKey > java.security.interfaces.RSAPublicKey > java.security.interfaces.RSAPrivateKey Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision: remove since tags ------------- Changes: - all: https://git.openjdk.org/jdk/pull/18373/files - new: https://git.openjdk.org/jdk/pull/18373/files/b5589e40..7ef8b4ee Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=18373&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18373&range=00-01 Stats: 2 lines in 2 files changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/18373.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18373/head:pull/18373 PR: https://git.openjdk.org/jdk/pull/18373 From cstein at openjdk.org Tue Mar 19 16:37:36 2024 From: cstein at openjdk.org (Christian Stein) Date: Tue, 19 Mar 2024 16:37:36 GMT Subject: RFR: JDK-8328339: Static import prevents source launcher from finding class with main method [v3] In-Reply-To: References: Message-ID: > Please review this fix for finding the program class in case the first top-level type has no main method and the order of type compilation does not match the order in the source file - for example by a static import statement being present. > > Here's an excerpt from [JEP 458](https://openjdk.org/jeps/458#Launch-time-semantics-and-operation)'s "Launch-time semantics and operation" section describing the process: >> 5. Determine the launch class of the initial .java file. If the first top level class in the initial file declares a standard main method (`public static void main(String[])` or other standard main entry points as defined in [JEP 463](https://openjdk.org/jeps/463#A-flexible-launch-protocol)), then that class is the launch class. Otherwise, if another top level class in the initial file declares a standard main method and has same name as the file, that class is the launch class. Otherwise, there is no launch class, and the launcher reports an error and stops. Christian Stein has updated the pull request incrementally with three additional commits since the last revision: - Update src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/SourceLauncher.java Co-authored-by: Jan Lahoda <51319204+lahodaj at users.noreply.github.com> - Update src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/ProgramDescriptor.java Co-authored-by: Jan Lahoda <51319204+lahodaj at users.noreply.github.com> - Update src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/MemoryContext.java Co-authored-by: Jan Lahoda <51319204+lahodaj at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.org/jdk/pull/18345/files - new: https://git.openjdk.org/jdk/pull/18345/files/65fba8d6..47b851ab Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=18345&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18345&range=01-02 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/18345.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18345/head:pull/18345 PR: https://git.openjdk.org/jdk/pull/18345 From cstein at openjdk.org Tue Mar 19 18:36:43 2024 From: cstein at openjdk.org (Christian Stein) Date: Tue, 19 Mar 2024 18:36:43 GMT Subject: RFR: JDK-8328339: Static import prevents source launcher from finding class with main method [v4] In-Reply-To: References: Message-ID: <_Ksqs4KcRiYEDbLqB3mN-SmQM2o3OyY_doJgIKE7QpM=.29ef03c7-d7b3-4fa8-8da2-8511b9a65a51@github.com> > Please review this fix for finding the program class in case the first top-level type has no main method and the order of type compilation does not match the order in the source file - for example by a static import statement being present. > > Here's an excerpt from [JEP 458](https://openjdk.org/jeps/458#Launch-time-semantics-and-operation)'s "Launch-time semantics and operation" section describing the process: >> 5. Determine the launch class of the initial .java file. If the first top level class in the initial file declares a standard main method (`public static void main(String[])` or other standard main entry points as defined in [JEP 463](https://openjdk.org/jeps/463#A-flexible-launch-protocol)), then that class is the launch class. Otherwise, if another top level class in the initial file declares a standard main method and has same name as the file, that class is the launch class. Otherwise, there is no launch class, and the launcher reports an error and stops. Christian Stein has updated the pull request incrementally with one additional commit since the last revision: Streamline program descriptor factory ------------- Changes: - all: https://git.openjdk.org/jdk/pull/18345/files - new: https://git.openjdk.org/jdk/pull/18345/files/47b851ab..62209989 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=18345&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18345&range=02-03 Stats: 23 lines in 2 files changed: 1 ins; 5 del; 17 mod Patch: https://git.openjdk.org/jdk/pull/18345.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18345/head:pull/18345 PR: https://git.openjdk.org/jdk/pull/18345 From hgreule at openjdk.org Tue Mar 19 18:48:26 2024 From: hgreule at openjdk.org (Hannes Greule) Date: Tue, 19 Mar 2024 18:48:26 GMT Subject: RFR: 8328536: javac - crash on unknown type referenced in yield statement Message-ID: Pasting e.g. I m(I i, int x) { return switch (x) { default -> i; }; } in jshell will cause a crash if `I` is not declared already. This comes down to javac not creating an error type for the value of the (implicit) yield from the switch. Javac will not crash but swallow the exception, and create a file containing the command line options. I first thought about just checking for null of the type here https://github.com/openjdk/jdk/blob/9ca4ae3d3b746f1d75036d189ff98f02b73b948f/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java#L1640 but after a closer look, the `checkIdInternal` method seems a better fit, as it also updates the type normally. ------------- Commit messages: - Fix jshell crash on unknown type in switch yield Changes: https://git.openjdk.org/jdk/pull/18383/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18383&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8328536 Stats: 12 lines in 2 files changed: 11 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/18383.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18383/head:pull/18383 PR: https://git.openjdk.org/jdk/pull/18383 From vromero at openjdk.org Wed Mar 20 17:10:23 2024 From: vromero at openjdk.org (Vicente Romero) Date: Wed, 20 Mar 2024 17:10:23 GMT Subject: RFR: 8327683: Crash with primitive type pattern and generic expression in instanceof [v3] In-Reply-To: References: Message-ID: On Tue, 19 Mar 2024 08:42:34 GMT, Aggelos Biboudis wrote: >> When compiling the following code, javac results in `java.lang.AssertionError: T.intValue`: >> >> >> public static boolean wideningReferenceConversionUnboxing(T i) { >> return i instanceof int ii; >> } >> >> >> The translated code after `Lower`, results in a generated assignment `(int)i.intValue()`. The reason for this bug is that the variable `i` required to have the erased type, set. This PR addresses this issue in `TransPatterns`: >> >> >> public static boolean wideningReferenceConversionUnboxing(Integer i) { >> return (let int ii in >> (let /*synthetic*/ final T tmp4500$ = i in tmp4500$ != null && (let /*synthetic*/ final T tmp4500$ = i in tmp4500$ != null)) && >> (let ii = (int)i.intValue(); in true)); >> } >> >> >> We also observe a duplicated check in the generated code: `(let /*synthetic*/ final T tmp4500$ = i in tmp4500$ != null`. This PR also tidies up the relevant code transformation in `Lower`. > > Aggelos Biboudis has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge branch 'master' into fix-#8327683 > - Merge branch 'master' into fix-#8327683 > - 8327683: Crash with primitive type pattern and generic expression in instanceof looks sensible ------------- Marked as reviewed by vromero (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/18168#pullrequestreview-1949546303 From acobbs at openjdk.org Thu Mar 21 02:20:49 2024 From: acobbs at openjdk.org (Archie Cobbs) Date: Thu, 21 Mar 2024 02:20:49 GMT Subject: RFR: 8328649: Disallow enclosing instances for local classes in constructor prologues Message-ID: A local class declared in a static context is not supposed to have an immediately enclosing instance (?15.9.2). That includes local classes declared in constructors prior to `super()` (during the "constructor prologue" in the new lingo). However, the compiler is allowing code like this to successfully compile: import java.util.concurrent.atomic.*; public class Test extends AtomicReference { public Test() { super(switch (0) { default -> { class Local { { Test.this.hashCode(); } } // this should fail yield null; } }); } } This patch fixes the "leak". ------------- Commit messages: - Remove obsolete test cases. - No enclosing instance for local classes in constructor prologues. Changes: https://git.openjdk.org/jdk/pull/18416/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18416&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8328649 Stats: 69 lines in 5 files changed: 36 ins; 29 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/18416.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18416/head:pull/18416 PR: https://git.openjdk.org/jdk/pull/18416 From liach at openjdk.org Thu Mar 21 02:51:18 2024 From: liach at openjdk.org (Chen Liang) Date: Thu, 21 Mar 2024 02:51:18 GMT Subject: RFR: 8328649: Disallow enclosing instances for local classes in constructor prologues In-Reply-To: References: Message-ID: On Thu, 21 Mar 2024 02:10:09 GMT, Archie Cobbs wrote: > A local class declared in a static context is not supposed to have an immediately enclosing instance (?15.9.2). That includes local classes declared in constructors prior to `super()` (during the "constructor prologue" in the new lingo). > > However, the compiler is allowing code like this to successfully compile: > > import java.util.concurrent.atomic.*; > public class Test extends AtomicReference { > > public Test() { > super(switch (0) { > default -> { > class Local { { Test.this.hashCode(); } } // this should fail > yield null; > } > }); > } > } > > This patch fixes the "leak". Thanks for this change! This unification of outer instance handling of inner and anonymous class declaration paves the way for Valhalla's value classes and makes things more straightforward. According to https://github.com/openjdk/jdk/pull/13656#issuecomment-1732340240 this change will affect the class file generated, such as for your given example. Should this patch get a CSR then? ------------- PR Comment: https://git.openjdk.org/jdk/pull/18416#issuecomment-2011091588 From abimpoudis at openjdk.org Thu Mar 21 08:05:25 2024 From: abimpoudis at openjdk.org (Aggelos Biboudis) Date: Thu, 21 Mar 2024 08:05:25 GMT Subject: Integrated: 8327683: Crash with primitive type pattern and generic expression in instanceof In-Reply-To: References: Message-ID: On Fri, 8 Mar 2024 11:14:21 GMT, Aggelos Biboudis wrote: > When compiling the following code, javac results in `java.lang.AssertionError: T.intValue`: > > > public static boolean wideningReferenceConversionUnboxing(T i) { > return i instanceof int ii; > } > > > The translated code after `Lower`, results in a generated assignment `(int)i.intValue()`. The reason for this bug is that the variable `i` required to have the erased type, set. This PR addresses this issue in `TransPatterns`: > > > public static boolean wideningReferenceConversionUnboxing(Integer i) { > return (let int ii in > (let /*synthetic*/ final T tmp4500$ = i in tmp4500$ != null && (let /*synthetic*/ final T tmp4500$ = i in tmp4500$ != null)) && > (let ii = (int)i.intValue(); in true)); > } > > > We also observe a duplicated check in the generated code: `(let /*synthetic*/ final T tmp4500$ = i in tmp4500$ != null`. This PR also tidies up the relevant code transformation in `Lower`. This pull request has now been integrated. Changeset: a5a2eca1 Author: Aggelos Biboudis URL: https://git.openjdk.org/jdk/commit/a5a2eca155bf5d9a1f01d0f3f21bd19dd0a7bd4d Stats: 241 lines in 5 files changed: 204 ins; 15 del; 22 mod 8327683: Crash with primitive type pattern and generic expression in instanceof Reviewed-by: vromero ------------- PR: https://git.openjdk.org/jdk/pull/18168 From cstein at openjdk.org Thu Mar 21 12:31:23 2024 From: cstein at openjdk.org (Christian Stein) Date: Thu, 21 Mar 2024 12:31:23 GMT Subject: RFR: JDK-8328339: Static import prevents source launcher from finding class with main method [v2] In-Reply-To: References: Message-ID: On Mon, 18 Mar 2024 17:40:15 GMT, Jan Lahoda wrote: >> Christian Stein has updated the pull request incrementally with one additional commit since the last revision: >> >> Ensure source-order of declared types in program source file >> >> Move computation of declared types into program descriptor factory. > > src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/ProgramDescriptor.java line 66: > >> 64: var task = compiler.getTask(null, standardFileManager, diagnostic -> {}, null, null, units); >> 65: for (var tree : task.parse()) { >> 66: for (var decl : tree.getTypeDecls()) { > > Not terribly important, but you could first compute the package name, and then compute the declared types. That would permit creating the fully qualified `declaredTypeNames` in one step, rather than putting the simple names into a List and then going through them again to qualify them. Refactored as suggested. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18345#discussion_r1533813680 From acobbs at openjdk.org Thu Mar 21 14:32:24 2024 From: acobbs at openjdk.org (Archie Cobbs) Date: Thu, 21 Mar 2024 14:32:24 GMT Subject: RFR: 8328649: Disallow enclosing instances for local classes in constructor prologues In-Reply-To: References: Message-ID: On Thu, 21 Mar 2024 02:48:47 GMT, Chen Liang wrote: > According to https://github.com/openjdk/jdk/pull/13656#issuecomment-1732340240 this change will affect the class file generated, such as for your given example. Should this patch get a CSR then? Well, this change only affects generated classfiles in the sense that it will be no longer possible to generate certain classfiles because compilation will fail instead :) But regardless I think a CSR is probably warranted so I'll add one. Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18416#issuecomment-2012450686 From jlahoda at openjdk.org Thu Mar 21 16:58:24 2024 From: jlahoda at openjdk.org (Jan Lahoda) Date: Thu, 21 Mar 2024 16:58:24 GMT Subject: RFR: JDK-8328339: Static import prevents source launcher from finding class with main method [v4] In-Reply-To: <_Ksqs4KcRiYEDbLqB3mN-SmQM2o3OyY_doJgIKE7QpM=.29ef03c7-d7b3-4fa8-8da2-8511b9a65a51@github.com> References: <_Ksqs4KcRiYEDbLqB3mN-SmQM2o3OyY_doJgIKE7QpM=.29ef03c7-d7b3-4fa8-8da2-8511b9a65a51@github.com> Message-ID: On Tue, 19 Mar 2024 18:36:43 GMT, Christian Stein wrote: >> Please review this fix for finding the program class in case the first top-level type has no main method and the order of type compilation does not match the order in the source file - for example by a static import statement being present. >> >> Here's an excerpt from [JEP 458](https://openjdk.org/jeps/458#Launch-time-semantics-and-operation)'s "Launch-time semantics and operation" section describing the process: >>> 5. Determine the launch class of the initial .java file. If the first top level class in the initial file declares a standard main method (`public static void main(String[])` or other standard main entry points as defined in [JEP 463](https://openjdk.org/jeps/463#A-flexible-launch-protocol)), then that class is the launch class. Otherwise, if another top level class in the initial file declares a standard main method and has same name as the file, that class is the launch class. Otherwise, there is no launch class, and the launcher reports an error and stops. > > Christian Stein has updated the pull request incrementally with one additional commit since the last revision: > > Streamline program descriptor factory Looks sensible. ------------- Marked as reviewed by jlahoda (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/18345#pullrequestreview-1952825965 From vromero at openjdk.org Thu Mar 21 21:52:27 2024 From: vromero at openjdk.org (Vicente Romero) Date: Thu, 21 Mar 2024 21:52:27 GMT Subject: RFR: 8328649: Disallow enclosing instances for local classes in constructor prologues In-Reply-To: References: Message-ID: <7o_xOUPuX7rOv_8PmACGB1QOZgNf5S7L1pTlIVmgC4Q=.05a44a0f-d9cb-440b-b89e-7a9a3fecf349@github.com> On Thu, 21 Mar 2024 02:10:09 GMT, Archie Cobbs wrote: > A local class declared in a static context is not supposed to have an immediately enclosing instance (?15.9.2). That includes local classes declared in constructors prior to `super()` (during the "constructor prologue" in the new lingo). > > However, the compiler is allowing code like this to successfully compile: > > import java.util.concurrent.atomic.*; > public class Test extends AtomicReference { > > public Test() { > super(switch (0) { > default -> { > class Local { { Test.this.hashCode(); } } // this should fail > yield null; > } > }); > } > } > > This patch fixes the "leak". looks good to me ------------- Marked as reviewed by vromero (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/18416#pullrequestreview-1953493763 From jjg at openjdk.org Thu Mar 21 22:02:41 2024 From: jjg at openjdk.org (Jonathan Gibbons) Date: Thu, 21 Mar 2024 22:02:41 GMT Subject: RFR: JDK-8298405: Implement JEP 467: Markdown Documentation Comments [v52] In-Reply-To: References: Message-ID: > Please review a patch to add support for Markdown syntax in documentation comments, as described in the associated JEP. > > Notable features: > > * support for `///` documentation comments in `JavaTokenizer` > * new module `jdk.internal.md` -- a private copy of the `commonmark-java` library > * updates to `DocCommentParser` to treat `///` comments as Markdown > * updates to the standard doclet to render Markdown comments in HTML Jonathan Gibbons has updated the pull request incrementally with three additional commits since the last revision: - Merge pull request #3 from lahodaj/fix-positions-replacement Fixing positions when transforming javadoc text with replacement characters. - Merge branch '8298405.doclet-markdown-v3' into fix-positions-replacement - Fixing positions when transforming javadoc text with replacement characters. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16388/files - new: https://git.openjdk.org/jdk/pull/16388/files/03652d2f..477fb155 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16388&range=51 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16388&range=50-51 Stats: 38 lines in 2 files changed: 26 ins; 0 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/16388.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16388/head:pull/16388 PR: https://git.openjdk.org/jdk/pull/16388 From jjg at openjdk.org Thu Mar 21 22:22:47 2024 From: jjg at openjdk.org (Jonathan Gibbons) Date: Thu, 21 Mar 2024 22:22:47 GMT Subject: RFR: JDK-8298405: Implement JEP 467: Markdown Documentation Comments [v53] In-Reply-To: References: Message-ID: <879IOXARfX5wvr3xTdwX5kChGG4v3yFNfRLZZXs0t3c=.776ba5e1-fcb8-43aa-b90c-94c2173dc15a@github.com> > Please review a patch to add support for Markdown syntax in documentation comments, as described in the associated JEP. > > Notable features: > > * support for `///` documentation comments in `JavaTokenizer` > * new module `jdk.internal.md` -- a private copy of the `commonmark-java` library > * updates to `DocCommentParser` to treat `///` comments as Markdown > * updates to the standard doclet to render Markdown comments in HTML Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 76 commits: - Merge branch '8298405.doclet-markdown-v3' of https://github.com/jonathan-gibbons/jdk into 8298405.doclet-markdown-v3 - Merge pull request #3 from lahodaj/fix-positions-replacement Fixing positions when transforming javadoc text with replacement characters. - Merge branch '8298405.doclet-markdown-v3' into fix-positions-replacement - Fixing positions when transforming javadoc text with replacement characters. - Merge remote-tracking branch 'upstream/master' into 8298405.doclet-markdown-v3 - update man page - Merge remote-tracking branch 'upstream/master' into 8298405.doclet-markdown-v3 - Merge with upstream/master - Merge with upstream/master - improve first-sentence break in Markdown comments - ... and 66 more: https://git.openjdk.org/jdk/compare/3f2e849c...a8ea1c72 ------------- Changes: https://git.openjdk.org/jdk/pull/16388/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16388&range=52 Stats: 23635 lines in 209 files changed: 23012 ins; 254 del; 369 mod Patch: https://git.openjdk.org/jdk/pull/16388.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16388/head:pull/16388 PR: https://git.openjdk.org/jdk/pull/16388 From acobbs at openjdk.org Thu Mar 21 22:57:29 2024 From: acobbs at openjdk.org (Archie Cobbs) Date: Thu, 21 Mar 2024 22:57:29 GMT Subject: Integrated: 8324736: Invalid end positions for EMPTY_STATEMENT In-Reply-To: References: Message-ID: On Fri, 26 Jan 2024 18:33:21 GMT, Archie Cobbs wrote: > In the fix for [JDK-8305671](https://bugs.openjdk.org/browse/JDK-8305671), an `EMPTY_STATEMENT` representing a lone semicolon was being created with the wrong source code position. The bug was that the starting position needed to be captured prior to advancing to the next token, not after. This pull request has now been integrated. Changeset: 46809b39 Author: Archie Cobbs Committer: Vicente Romero URL: https://git.openjdk.org/jdk/commit/46809b396ca76210f7939c8edf5a8263c29d3ddb Stats: 87 lines in 2 files changed: 86 ins; 0 del; 1 mod 8324736: Invalid end positions for EMPTY_STATEMENT Reviewed-by: vromero ------------- PR: https://git.openjdk.org/jdk/pull/17595 From cstein at openjdk.org Fri Mar 22 05:32:27 2024 From: cstein at openjdk.org (Christian Stein) Date: Fri, 22 Mar 2024 05:32:27 GMT Subject: Integrated: JDK-8328339: Static import prevents source launcher from finding class with main method In-Reply-To: References: Message-ID: On Mon, 18 Mar 2024 09:49:19 GMT, Christian Stein wrote: > Please review this fix for finding the program class in case the first top-level type has no main method and the order of type compilation does not match the order in the source file - for example by a static import statement being present. > > Here's an excerpt from [JEP 458](https://openjdk.org/jeps/458#Launch-time-semantics-and-operation)'s "Launch-time semantics and operation" section describing the process: >> 5. Determine the launch class of the initial .java file. If the first top level class in the initial file declares a standard main method (`public static void main(String[])` or other standard main entry points as defined in [JEP 463](https://openjdk.org/jeps/463#A-flexible-launch-protocol)), then that class is the launch class. Otherwise, if another top level class in the initial file declares a standard main method and has same name as the file, that class is the launch class. Otherwise, there is no launch class, and the launcher reports an error and stops. > > Tested tier1-tier3: ? This pull request has now been integrated. Changeset: 9bc741d0 Author: Christian Stein URL: https://git.openjdk.org/jdk/commit/9bc741d04f0c2e731f67ac21144812a55d0ea03d Stats: 97 lines in 4 files changed: 44 ins; 30 del; 23 mod 8328339: Static import prevents source launcher from finding class with main method Reviewed-by: jlahoda ------------- PR: https://git.openjdk.org/jdk/pull/18345 From acobbs at openjdk.org Fri Mar 22 18:36:54 2024 From: acobbs at openjdk.org (Archie Cobbs) Date: Fri, 22 Mar 2024 18:36:54 GMT Subject: RFR: 8325805: Compiler Implementation for Flexible Constructor Bodies (Second Preview) Message-ID: This patch changes the compiler to allow constructors to make assignments to fields prior to the `super()` invocation, i.e., in the pre-construction context. This is part of the work associated with [JDK-8325803 - Flexible Constructor Bodies (Second Preview)](https://bugs.openjdk.org/browse/JDK-8325803). This patch is based the relevant bits from @vicente-romero-oracle's commit [1b99b5cf](https://github.com/openjdk/valhalla/commit/1b99b5cfd9a5d484b9e7bdfc284daad9ad6535bf) to the valhalla repo. ------------- Commit messages: - Fix cut & paste of bug ID and summary. - Avoid possible unwanted side effects from method Symbol.flags(). - Add a few more test cases. - Fix bug where early assignments in lambda's were being allowed. - Add some more allowed assignment test cases. - Add test case for early assignment within a lambda. - Add comment. - Fix early ref logic by handling assign vs. reference separately. - Add some more test cases and modify the logic a bit. - Consolidate new logic into isAllowedEarlyReference() method. - ... and 4 more: https://git.openjdk.org/jdk/compare/d32ce657...4d2d3e83 Changes: https://git.openjdk.org/jdk/pull/18088/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18088&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8325805 Stats: 418 lines in 11 files changed: 375 ins; 37 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/18088.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18088/head:pull/18088 PR: https://git.openjdk.org/jdk/pull/18088 From vromero at openjdk.org Fri Mar 22 18:36:54 2024 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 22 Mar 2024 18:36:54 GMT Subject: RFR: 8325805: Compiler Implementation for Flexible Constructor Bodies (Second Preview) In-Reply-To: References: Message-ID: On Fri, 1 Mar 2024 17:51:11 GMT, Archie Cobbs wrote: > This patch changes the compiler to allow constructors to make assignments to fields prior to the `super()` invocation, i.e., in the pre-construction context. This is part of the work associated with [JDK-8325803 - Flexible Constructor Bodies (Second Preview)](https://bugs.openjdk.org/browse/JDK-8325803). > > This patch is based the relevant bits from @vicente-romero-oracle's commit [1b99b5cf](https://github.com/openjdk/valhalla/commit/1b99b5cfd9a5d484b9e7bdfc284daad9ad6535bf) to the valhalla repo. this looks good, will do another iteration, but I like it src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java line 3850: > 3848: // Check assumptions > 3849: Assert.check(env.info.ctorPrologue); > 3850: Assert.check((v.flags() & STATIC) == 0); nit: I would prefer here to directly read the `flags_field` field instead of invoking `Symbol::flags` as the later can provoke symbol completions. Probably not a big deal here but just to be on the safe side test/langtools/tools/javac/DefiniteAssignment/DA_DUConstructors.java line 3: > 1: /* > 2: * @test /nodynamiccopyright/ > 3: * @bug 8324873 just paperwork-ish, I'm not sure we should refer to a valhalla bug and keep the valhalla summary below. I get why you are doing it but I guess this current fix will be pushed before valhalla. So I would just use this current bug ID and summary and once we do a merge of this test in the valhalla repo we can add more information to it ------------- PR Review: https://git.openjdk.org/jdk/pull/18088#pullrequestreview-1955466746 PR Review Comment: https://git.openjdk.org/jdk/pull/18088#discussion_r1535713758 PR Review Comment: https://git.openjdk.org/jdk/pull/18088#discussion_r1535999652 From vromero at openjdk.org Fri Mar 22 18:36:54 2024 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 22 Mar 2024 18:36:54 GMT Subject: RFR: 8325805: Compiler Implementation for Flexible Constructor Bodies (Second Preview) In-Reply-To: References: Message-ID: On Fri, 22 Mar 2024 18:26:27 GMT, Archie Cobbs wrote: > Thanks for looking it over. When you think it's ready for prime time let me know and I'll convert it from draft. I would go for it, yep that way more people can chime in ------------- PR Comment: https://git.openjdk.org/jdk/pull/18088#issuecomment-2015678828 From acobbs at openjdk.org Fri Mar 22 18:36:54 2024 From: acobbs at openjdk.org (Archie Cobbs) Date: Fri, 22 Mar 2024 18:36:54 GMT Subject: RFR: 8325805: Compiler Implementation for Flexible Constructor Bodies (Second Preview) In-Reply-To: References: Message-ID: On Fri, 1 Mar 2024 17:51:11 GMT, Archie Cobbs wrote: > This patch changes the compiler to allow constructors to make assignments to fields prior to the `super()` invocation, i.e., in the pre-construction context. This is part of the work associated with [JDK-8325803 - Flexible Constructor Bodies (Second Preview)](https://bugs.openjdk.org/browse/JDK-8325803). > > This patch is based the relevant bits from @vicente-romero-oracle's commit [1b99b5cf](https://github.com/openjdk/valhalla/commit/1b99b5cfd9a5d484b9e7bdfc284daad9ad6535bf) to the valhalla repo. Thanks for looking it over. When you think it's ready for prime time let me know and I'll convert it from draft. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18088#issuecomment-2015675135 From acobbs at openjdk.org Fri Mar 22 18:36:54 2024 From: acobbs at openjdk.org (Archie Cobbs) Date: Fri, 22 Mar 2024 18:36:54 GMT Subject: RFR: 8325805: Compiler Implementation for Flexible Constructor Bodies (Second Preview) In-Reply-To: References: Message-ID: On Fri, 22 Mar 2024 14:48:35 GMT, Vicente Romero wrote: >> This patch changes the compiler to allow constructors to make assignments to fields prior to the `super()` invocation, i.e., in the pre-construction context. This is part of the work associated with [JDK-8325803 - Flexible Constructor Bodies (Second Preview)](https://bugs.openjdk.org/browse/JDK-8325803). >> >> This patch is based the relevant bits from @vicente-romero-oracle's commit [1b99b5cf](https://github.com/openjdk/valhalla/commit/1b99b5cfd9a5d484b9e7bdfc284daad9ad6535bf) to the valhalla repo. > > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java line 3850: > >> 3848: // Check assumptions >> 3849: Assert.check(env.info.ctorPrologue); >> 3850: Assert.check((v.flags() & STATIC) == 0); > > nit: I would prefer here to directly read the `flags_field` field instead of invoking `Symbol::flags` as the later can provoke symbol completions. Probably not a big deal here but just to be on the safe side Thanks - I didn't realize there could be side effects, and it's especially appropriate to avoid them because this is just an assertion statement. Fixed in 34aa494680f. > test/langtools/tools/javac/DefiniteAssignment/DA_DUConstructors.java line 3: > >> 1: /* >> 2: * @test /nodynamiccopyright/ >> 3: * @bug 8324873 > > just paperwork-ish, I'm not sure we should refer to a valhalla bug and keep the valhalla summary below. I get why you are doing it but I guess this current fix will be pushed before valhalla. So I would just use this current bug ID and summary and once we do a merge of this test in the valhalla repo we can add more information to it No I completely agree - two different repo's. Cut & paste glitch. Fixed in 4d2d3e83c42. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18088#discussion_r1535722543 PR Review Comment: https://git.openjdk.org/jdk/pull/18088#discussion_r1536017601 From liach at openjdk.org Fri Mar 22 18:36:54 2024 From: liach at openjdk.org (Chen Liang) Date: Fri, 22 Mar 2024 18:36:54 GMT Subject: RFR: 8325805: Compiler Implementation for Flexible Constructor Bodies (Second Preview) In-Reply-To: References: Message-ID: On Fri, 1 Mar 2024 17:51:11 GMT, Archie Cobbs wrote: > This patch changes the compiler to allow constructors to make assignments to fields prior to the `super()` invocation, i.e., in the pre-construction context. This is part of the work associated with [JDK-8325803 - Flexible Constructor Bodies (Second Preview)](https://bugs.openjdk.org/browse/JDK-8325803). > > This patch is based the relevant bits from @vicente-romero-oracle's commit [1b99b5cf](https://github.com/openjdk/valhalla/commit/1b99b5cfd9a5d484b9e7bdfc284daad9ad6535bf) to the valhalla repo. test/langtools/tools/javac/DefiniteAssignment/DA_DUConstructors.java line 1: > 1: /* Missing copyright header ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18088#discussion_r1510330459 From gli at openjdk.org Fri Mar 22 18:36:54 2024 From: gli at openjdk.org (Guoxiong Li) Date: Fri, 22 Mar 2024 18:36:54 GMT Subject: RFR: 8325805: Compiler Implementation for Flexible Constructor Bodies (Second Preview) In-Reply-To: References: Message-ID: <97ha6X_tGSnSRkBkXfY3YXa15y4gP4d018x60_9Tr0U=.745eed37-e298-4ea4-8c8f-1e2c8c398c4f@github.com> On Sun, 3 Mar 2024 16:51:40 GMT, Chen Liang wrote: >> This patch changes the compiler to allow constructors to make assignments to fields prior to the `super()` invocation, i.e., in the pre-construction context. This is part of the work associated with [JDK-8325803 - Flexible Constructor Bodies (Second Preview)](https://bugs.openjdk.org/browse/JDK-8325803). >> >> This patch is based the relevant bits from @vicente-romero-oracle's commit [1b99b5cf](https://github.com/openjdk/valhalla/commit/1b99b5cfd9a5d484b9e7bdfc284daad9ad6535bf) to the valhalla repo. > > test/langtools/tools/javac/DefiniteAssignment/DA_DUConstructors.java line 1: > >> 1: /* > > Missing copyright header Please notice the test annotation `@test /nodynamiccopyright/`, it means this file doesn't have a copyright. When the copyright is changed (add or delete lines) in the future, the line number of the compilation result will change, which cause the file `*.out` (`DA_DUConstructors.out` here) need to be adjusted. The `/nodynamiccopyright/` can avoid such unnecessary adjustment. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18088#discussion_r1510529472 From liach at openjdk.org Fri Mar 22 18:36:54 2024 From: liach at openjdk.org (Chen Liang) Date: Fri, 22 Mar 2024 18:36:54 GMT Subject: RFR: 8325805: Compiler Implementation for Flexible Constructor Bodies (Second Preview) In-Reply-To: <97ha6X_tGSnSRkBkXfY3YXa15y4gP4d018x60_9Tr0U=.745eed37-e298-4ea4-8c8f-1e2c8c398c4f@github.com> References: <97ha6X_tGSnSRkBkXfY3YXa15y4gP4d018x60_9Tr0U=.745eed37-e298-4ea4-8c8f-1e2c8c398c4f@github.com> Message-ID: <01kjuZRp4bWkbSPnVH19mdHuUB8VkRn8QTrXs8ehcfc=.0a9b4cf2-fc67-4c6e-8d82-c6f80628497e@github.com> On Mon, 4 Mar 2024 02:45:09 GMT, Guoxiong Li wrote: >> test/langtools/tools/javac/DefiniteAssignment/DA_DUConstructors.java line 1: >> >>> 1: /* >> >> Missing copyright header > > Please notice the test annotation `@test /nodynamiccopyright/`, it means this file doesn't have a copyright. When the copyright is changed (add or delete lines) in the future, the line number of the compilation result will change, which cause the file `*.out` (`DA_DUConstructors.out` here) need to be adjusted. The `/nodynamiccopyright/` can avoid such unnecessary adjustment. Is there a default copyright for such a file without a copyright header? I would assume it's simply copyright Oracle Corporation, all rights reserved? Also please bear with my comment, I know you feel impatient but I've never seen this tag before. The usage of `/nodynamiccopyright/` seems to be only in javac for preservation of hardcoded line number purposes so I was ignorant about it, as I mostly worked with other parts of the JDK. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18088#discussion_r1510532278 From gli at openjdk.org Fri Mar 22 18:36:54 2024 From: gli at openjdk.org (Guoxiong Li) Date: Fri, 22 Mar 2024 18:36:54 GMT Subject: RFR: 8325805: Compiler Implementation for Flexible Constructor Bodies (Second Preview) In-Reply-To: <01kjuZRp4bWkbSPnVH19mdHuUB8VkRn8QTrXs8ehcfc=.0a9b4cf2-fc67-4c6e-8d82-c6f80628497e@github.com> References: <97ha6X_tGSnSRkBkXfY3YXa15y4gP4d018x60_9Tr0U=.745eed37-e298-4ea4-8c8f-1e2c8c398c4f@github.com> <01kjuZRp4bWkbSPnVH19mdHuUB8VkRn8QTrXs8ehcfc=.0a9b4cf2-fc67-4c6e-8d82-c6f80628497e@github.com> Message-ID: On Mon, 4 Mar 2024 02:51:35 GMT, Chen Liang wrote: > Also please bear with my comment, I know you feel impatient but I've never seen this tag before. The usage of `/nodynamiccopyright/` seems to be only in javac for preservation of hardcoded line number purposes so I was ignorant about it, as I mostly worked with other parts of the JDK. Take it easy. I didn't feel impatient. Nobody can know everything. It is just a point that you don't know. Now you know it during reviewing. So, don't worry about making mistakes and keeping on reviewing, then you can learn more. > Is there a default copyright for such a file without a copyright header? I would assume it's simply copyright Oracle Corporation, all rights reserved? Now, it is my run not to know. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18088#discussion_r1510556663 From acobbs at openjdk.org Fri Mar 22 18:36:55 2024 From: acobbs at openjdk.org (Archie Cobbs) Date: Fri, 22 Mar 2024 18:36:55 GMT Subject: RFR: 8325805: Compiler Implementation for Flexible Constructor Bodies (Second Preview) In-Reply-To: References: <97ha6X_tGSnSRkBkXfY3YXa15y4gP4d018x60_9Tr0U=.745eed37-e298-4ea4-8c8f-1e2c8c398c4f@github.com> <01kjuZRp4bWkbSPnVH19mdHuUB8VkRn8QTrXs8ehcfc=.0a9b4cf2-fc67-4c6e-8d82-c6f80628497e@github.com> Message-ID: On Mon, 4 Mar 2024 03:42:29 GMT, Guoxiong Li wrote: >> Is there a default copyright for such a file without a copyright header? I would assume it's simply copyright Oracle Corporation, all rights reserved? >> >> Also please bear with my comment, I know you feel impatient but I've never seen this tag before. The usage of `/nodynamiccopyright/` seems to be only in javac for preservation of hardcoded line number purposes so I was ignorant about it, as I mostly worked with other parts of the JDK. > >> Also please bear with my comment, I know you feel impatient but I've never seen this tag before. The usage of `/nodynamiccopyright/` seems to be only in javac for preservation of hardcoded line number purposes so I was ignorant about it, as I mostly worked with other parts of the JDK. > > Take it easy. I didn't feel impatient. Nobody can know everything. It is just a point that you don't know. Now you know it during reviewing. So, don't worry about making mistakes and keeping on reviewing, then you can learn more. > >> Is there a default copyright for such a file without a copyright header? I would assume it's simply copyright Oracle Corporation, all rights reserved? > > Now, it is my run not to know. For reference, here's where this is discussed in the developer's guide: https://openjdk.org/groups/compiler/tests.html See section 10 "Golden file tests". ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18088#discussion_r1511285106 From vromero at openjdk.org Fri Mar 22 20:25:22 2024 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 22 Mar 2024 20:25:22 GMT Subject: RFR: 8325805: Compiler Implementation for Flexible Constructor Bodies (Second Preview) In-Reply-To: References: Message-ID: <5E1Avi0X0BspHSAmMcQD6uzmSpfYcStHvDkgb792dgU=.604b4010-6a0b-4cad-aaaa-054fb42a5e7a@github.com> On Fri, 1 Mar 2024 17:51:11 GMT, Archie Cobbs wrote: > This patch changes the compiler to allow constructors to make assignments to fields prior to the `super()` invocation, i.e., in the pre-construction context. This is part of the work associated with [JDK-8325803 - Flexible Constructor Bodies (Second Preview)](https://bugs.openjdk.org/browse/JDK-8325803). > > This patch is based the relevant bits from @vicente-romero-oracle's commit [1b99b5cf](https://github.com/openjdk/valhalla/commit/1b99b5cfd9a5d484b9e7bdfc284daad9ad6535bf) to the valhalla repo. I already need this code in valhalla, I guess I will be despicably plagiarizing your code :) ------------- PR Comment: https://git.openjdk.org/jdk/pull/18088#issuecomment-2015849459 From acobbs at openjdk.org Fri Mar 22 20:35:22 2024 From: acobbs at openjdk.org (Archie Cobbs) Date: Fri, 22 Mar 2024 20:35:22 GMT Subject: RFR: 8325805: Compiler Implementation for Flexible Constructor Bodies (Second Preview) In-Reply-To: References: Message-ID: On Fri, 1 Mar 2024 17:51:11 GMT, Archie Cobbs wrote: > This patch changes the compiler to allow constructors to make assignments to fields prior to the `super()` invocation, i.e., in the pre-construction context. This is part of the work associated with [JDK-8325803 - Flexible Constructor Bodies (Second Preview)](https://bugs.openjdk.org/browse/JDK-8325803). > > This patch is based the relevant bits from @vicente-romero-oracle's commit [1b99b5cf](https://github.com/openjdk/valhalla/commit/1b99b5cfd9a5d484b9e7bdfc284daad9ad6535bf) to the valhalla repo. Ha, that's only fair... I'm very much a cut & paste enthusiast myself :) ------------- PR Comment: https://git.openjdk.org/jdk/pull/18088#issuecomment-2015864721 From jlahoda at openjdk.org Mon Mar 25 20:06:33 2024 From: jlahoda at openjdk.org (Jan Lahoda) Date: Mon, 25 Mar 2024 20:06:33 GMT Subject: RFR: 8325168: JShell should support Markdown comments Message-ID: This is an attempt to add Markdown support in documentation comments to JShell. It works by converting the Markdown text to HTML during the process of resolving `{@inheritDoc}` tags. ------------- Depends on: https://git.openjdk.org/jdk/pull/16388 Commit messages: - Cleanup. - Preventing a NPE. - Fixing test. - Merge branch '8298405.doclet-markdown-v3' into JDK-8298405 - Cleanup. - Merge branch '8298405.doclet-markdown-v3' into JDK-8298405 - Cleanup. - Merge branch '8298405.doclet-markdown-v3' into JDK-8298405 - Removing ToHTMLMarkdownTransformer, as suggested - Adding forgotten class. - ... and 3 more: https://git.openjdk.org/jdk/compare/a8ea1c72...0ba0fffd Changes: https://git.openjdk.org/jdk/pull/17686/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17686&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8325168 Stats: 1825 lines in 8 files changed: 977 ins; 842 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/17686.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17686/head:pull/17686 PR: https://git.openjdk.org/jdk/pull/17686 From jjg at openjdk.org Mon Mar 25 20:06:33 2024 From: jjg at openjdk.org (Jonathan Gibbons) Date: Mon, 25 Mar 2024 20:06:33 GMT Subject: RFR: 8325168: JShell should support Markdown comments In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 14:02:28 GMT, Jan Lahoda wrote: > This is an attempt to add Markdown support in documentation comments to JShell. > > It works by converting the Markdown text to HTML during the process of resolving `{@inheritDoc}` tags. Changes requested by jjg (Reviewer). Compared to the previous PR, which was reasonably simple and quite elegant, this one seems unduly complicated and somewhat invasive. It is also using the transformer mechanism in a way that is not as intended. The `jdk.internal.md` module is intended to be for JDK support for Markdown. As such, it has an imported copy of `commonmark-java` and now the new transformer support, which is just intended to be used to support any JDK extensions to Markdown, such as the new support for reference links for program elements. (There are suggestions for other future features in the JEP.) As such, I would expect all JDK clients to use the existing "standard" transformer, and to not substitute their own. Ideally, the "standard" transformer would be used by default, but I wanted to avoid an unconditional dependency from `jdk.compiler` to `jdk.internal.md` -- so hence the use of the service provider mechanism. (I guess I could update `jdk.compiler` to use `requires static` to establish a compile-time dependency on the `jdk.internal.md` module, and then try and install the standard transformer, which would always be available if we put a hard dependency in modules like `jdk.javadoc` and `jdk.jshell`.) Your previous PR was pretty good (although I accept we did not get as far as a full review and approval.) The recent changes the overall Markdown work were made with that PR in mind. As such, the intention was that only two fairly small changes would be required. 1. Change the means to detect Markdown comments, from looking for `/**md` to using the new `CommentKind` support in `DocTrees`. 2. Install the 'standard' transformer, to enable the JDK extensions to Markdown With those two changes, you can use the previous technique to parse and render a Markdown doc comment as before. src/jdk.compiler/share/classes/jdk/internal/shellsupport/doc/JavadocHelper.java line 95: > 93: import com.sun.tools.javac.util.DefinedBy.Api; > 94: import com.sun.tools.javac.util.Pair; > 95: import java.util.ServiceLoader; out of order; suggest moving to be with other `java.*` imports src/jdk.compiler/share/classes/jdk/internal/shellsupport/doc/JavadocHelper.java line 261: > 259: @Override > 260: public Void scan(Iterable nodes, Void p) { > 261: return super.scan(nodes, p); // Generated from nbfs://nbhost/SystemFileSystem/Templates/Classes/Code/OverriddenMethodBody I'm not sure what to do with that comment. ------------- PR Review: https://git.openjdk.org/jdk/pull/17686#pullrequestreview-1860164867 PR Comment: https://git.openjdk.org/jdk/pull/17686#issuecomment-1927843621 PR Review Comment: https://git.openjdk.org/jdk/pull/17686#discussion_r1476580909 PR Review Comment: https://git.openjdk.org/jdk/pull/17686#discussion_r1476583652 From jlahoda at openjdk.org Mon Mar 25 20:06:33 2024 From: jlahoda at openjdk.org (Jan Lahoda) Date: Mon, 25 Mar 2024 20:06:33 GMT Subject: RFR: 8325168: JShell should support Markdown comments In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 14:02:28 GMT, Jan Lahoda wrote: > This is an attempt to add Markdown support in documentation comments to JShell. > > It works by converting the Markdown text to HTML during the process of resolving `{@inheritDoc}` tags. Thanks for the comments! I've dropped the `ToHTML` transformer, and made the transformations easier. Sadly, the standard transformer seems to break raw text tree positions, so it is not currently possible to properly replace the Markdown text with the Javadoc text when the transformer is installed. Please see: https://github.com/openjdk/jdk/pull/16388#discussion_r1479306878 for more details. Once that is solved, it should be possible to merge the newest changes in the Markdown branch. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17686#issuecomment-1928909938 From duke at openjdk.org Mon Mar 25 22:51:48 2024 From: duke at openjdk.org (Nizar Benalla) Date: Mon, 25 Mar 2024 22:51:48 GMT Subject: RFR: JDK-8328501 Incorrect `@since` tags for security java security interfaces [v3] In-Reply-To: References: Message-ID: > For context, I am writing tests to check for accurate use of `@since` tags in documentation comments in source code. > We're following these rules for now: > > ### Rule 1: Introduction of New Elements > > - If an element is new in JDK N, with no equivalent in JDK N-1, it must include `@since N`. > - Exception: Member elements (fields, methods, nested classes) may omit `@since` if their version matches the value specified for the enclosing class or interface. > > ### Rule 2: Existing Elements in Subsequent JDK Versions > > - If an element exists in JDK N, with an equivalent in JDK N-1, it should not include `@since N`. > > ### Rule 3: Handling Missing `@since` Tags in methods if there is no `@since` > > - When inspecting methods, prioritize the `@since` annotation of the supertype's overridden method. > - If unavailable or if the enclosing class's `@since` is newer, use the enclosing element's `@since`. > > I.e. if A extends B, and we add a method to B in JDK N, and add an override of the method to A in JDK M (M > N), we will use N as the effective `@since` for the method. > Here's an illustration using Markdown and Java code: > > The override of `getParams` in these interfaces was done in in JDK 22 and an `@since 22` was, but this method has been inherited to these interfaces for a long time. > > As pointed out by my mentor Jan, > > > import javax.crypto.interfaces.DHPublicKey; > > public class DhkeyTest { > > public static void main(DHPublicKey key) { > System.err.println(key.getParams()); > } > > } > > > this compiles using JDK 8 without any compile-time errors. The @ since tag shouldn't be here > > > - the same goes for these other interfaces > > java.security.interfaces.DSAPublicKey > java.security.interfaces.XECPublicKey > java.security.interfaces.DSAPrivateKey > java.security.interfaces.ECPrivateKey > java.security.interfaces.XECPrivateKey > java.security.interfaces.EdECPrivateKey > java.security.interfaces.ECPublicKey > java.security.interfaces.EdECPublicKey > javax.crypto.interfaces.DHPrivateKey > javax.crypto.interfaces.DHPublicKey > java.security.interfaces.RSAPublicKey > java.security.interfaces.RSAPrivateKey Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision: Update copyright year to 2024 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/18373/files - new: https://git.openjdk.org/jdk/pull/18373/files/7ef8b4ee..b04a75e5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=18373&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18373&range=01-02 Stats: 12 lines in 12 files changed: 0 ins; 0 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/18373.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18373/head:pull/18373 PR: https://git.openjdk.org/jdk/pull/18373 From mullan at openjdk.org Tue Mar 26 17:00:27 2024 From: mullan at openjdk.org (Sean Mullan) Date: Tue, 26 Mar 2024 17:00:27 GMT Subject: RFR: JDK-8328501 Incorrect `@since` tags for security java security interfaces [v3] In-Reply-To: References: Message-ID: On Mon, 25 Mar 2024 22:51:48 GMT, Nizar Benalla wrote: >> For context, I am writing tests to check for accurate use of `@since` tags in documentation comments in source code. >> We're following these rules for now: >> >> ### Rule 1: Introduction of New Elements >> >> - If an element is new in JDK N, with no equivalent in JDK N-1, it must include `@since N`. >> - Exception: Member elements (fields, methods, nested classes) may omit `@since` if their version matches the value specified for the enclosing class or interface. >> >> ### Rule 2: Existing Elements in Subsequent JDK Versions >> >> - If an element exists in JDK N, with an equivalent in JDK N-1, it should not include `@since N`. >> >> ### Rule 3: Handling Missing `@since` Tags in methods if there is no `@since` >> >> - When inspecting methods, prioritize the `@since` annotation of the supertype's overridden method. >> - If unavailable or if the enclosing class's `@since` is newer, use the enclosing element's `@since`. >> >> I.e. if A extends B, and we add a method to B in JDK N, and add an override of the method to A in JDK M (M > N), we will use N as the effective `@since` for the method. >> Here's an illustration using Markdown and Java code: >> >> The override of `getParams` in these interfaces was done in in JDK 22 and an `@since 22` was, but this method has been inherited to these interfaces for a long time. >> >> As pointed out by my mentor Jan, >> >> >> import javax.crypto.interfaces.DHPublicKey; >> >> public class DhkeyTest { >> >> public static void main(DHPublicKey key) { >> System.err.println(key.getParams()); >> } >> >> } >> >> >> this compiles using JDK 8 without any compile-time errors. The @ since tag shouldn't be here >> >> >> - the same goes for these other interfaces >> >> java.security.interfaces.DSAPublicKey >> java.security.interfaces.XECPublicKey >> java.security.interfaces.DSAPrivateKey >> java.security.interfaces.ECPrivateKey >> java.security.interfaces.XECPrivateKey >> java.security.interfaces.EdECPrivateKey >> java.security.interfaces.ECPublicKey >> java.security.interfaces.EdECPublicKey >> javax.crypto.interfaces.DHPrivateKey >> javax.crypto.interfaces.DHPublicKey >> java.security.interfaces.RSAPublicKey >> java.security.interfaces.RSAPrivateKey > > Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright year to 2024 Looks good. Please add a `noreg-doc` label to the bug. ------------- Marked as reviewed by mullan (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/18373#pullrequestreview-1961142238 From duke at openjdk.org Tue Mar 26 17:06:22 2024 From: duke at openjdk.org (Nizar Benalla) Date: Tue, 26 Mar 2024 17:06:22 GMT Subject: RFR: JDK-8328501 Incorrect `@since` tags for security java security interfaces [v3] In-Reply-To: References: Message-ID: On Mon, 25 Mar 2024 22:51:48 GMT, Nizar Benalla wrote: >> For context, I am writing tests to check for accurate use of `@since` tags in documentation comments in source code. >> We're following these rules for now: >> >> ### Rule 1: Introduction of New Elements >> >> - If an element is new in JDK N, with no equivalent in JDK N-1, it must include `@since N`. >> - Exception: Member elements (fields, methods, nested classes) may omit `@since` if their version matches the value specified for the enclosing class or interface. >> >> ### Rule 2: Existing Elements in Subsequent JDK Versions >> >> - If an element exists in JDK N, with an equivalent in JDK N-1, it should not include `@since N`. >> >> ### Rule 3: Handling Missing `@since` Tags in methods if there is no `@since` >> >> - When inspecting methods, prioritize the `@since` annotation of the supertype's overridden method. >> - If unavailable or if the enclosing class's `@since` is newer, use the enclosing element's `@since`. >> >> I.e. if A extends B, and we add a method to B in JDK N, and add an override of the method to A in JDK M (M > N), we will use N as the effective `@since` for the method. >> Here's an illustration using Markdown and Java code: >> >> The override of `getParams` in these interfaces was done in in JDK 22 and an `@since 22` was, but this method has been inherited to these interfaces for a long time. >> >> As pointed out by my mentor Jan, >> >> >> import javax.crypto.interfaces.DHPublicKey; >> >> public class DhkeyTest { >> >> public static void main(DHPublicKey key) { >> System.err.println(key.getParams()); >> } >> >> } >> >> >> this compiles using JDK 8 without any compile-time errors. The @ since tag shouldn't be here >> >> >> - the same goes for these other interfaces >> >> java.security.interfaces.DSAPublicKey >> java.security.interfaces.XECPublicKey >> java.security.interfaces.DSAPrivateKey >> java.security.interfaces.ECPrivateKey >> java.security.interfaces.XECPrivateKey >> java.security.interfaces.EdECPrivateKey >> java.security.interfaces.ECPublicKey >> java.security.interfaces.EdECPublicKey >> javax.crypto.interfaces.DHPrivateKey >> javax.crypto.interfaces.DHPublicKey >> java.security.interfaces.RSAPublicKey >> java.security.interfaces.RSAPrivateKey > > Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright year to 2024 Mistake comment ------------- PR Comment: https://git.openjdk.org/jdk/pull/18373#issuecomment-2020995518 From duke at openjdk.org Tue Mar 26 17:12:22 2024 From: duke at openjdk.org (Nizar Benalla) Date: Tue, 26 Mar 2024 17:12:22 GMT Subject: RFR: JDK-8328501 Incorrect `@since` tags for security java security interfaces [v3] In-Reply-To: References: Message-ID: On Mon, 25 Mar 2024 22:51:48 GMT, Nizar Benalla wrote: >> For context, I am writing tests to check for accurate use of `@since` tags in documentation comments in source code. >> We're following these rules for now: >> >> ### Rule 1: Introduction of New Elements >> >> - If an element is new in JDK N, with no equivalent in JDK N-1, it must include `@since N`. >> - Exception: Member elements (fields, methods, nested classes) may omit `@since` if their version matches the value specified for the enclosing class or interface. >> >> ### Rule 2: Existing Elements in Subsequent JDK Versions >> >> - If an element exists in JDK N, with an equivalent in JDK N-1, it should not include `@since N`. >> >> ### Rule 3: Handling Missing `@since` Tags in methods if there is no `@since` >> >> - When inspecting methods, prioritize the `@since` annotation of the supertype's overridden method. >> - If unavailable or if the enclosing class's `@since` is newer, use the enclosing element's `@since`. >> >> I.e. if A extends B, and we add a method to B in JDK N, and add an override of the method to A in JDK M (M > N), we will use N as the effective `@since` for the method. >> Here's an illustration using Markdown and Java code: >> >> The override of `getParams` in these interfaces was done in in JDK 22 and an `@since 22` was, but this method has been inherited to these interfaces for a long time. >> >> As pointed out by my mentor Jan, >> >> >> import javax.crypto.interfaces.DHPublicKey; >> >> public class DhkeyTest { >> >> public static void main(DHPublicKey key) { >> System.err.println(key.getParams()); >> } >> >> } >> >> >> this compiles using JDK 8 without any compile-time errors. The @ since tag shouldn't be here >> >> >> - the same goes for these other interfaces >> >> java.security.interfaces.DSAPublicKey >> java.security.interfaces.XECPublicKey >> java.security.interfaces.DSAPrivateKey >> java.security.interfaces.ECPrivateKey >> java.security.interfaces.XECPrivateKey >> java.security.interfaces.EdECPrivateKey >> java.security.interfaces.ECPublicKey >> java.security.interfaces.EdECPublicKey >> javax.crypto.interfaces.DHPrivateKey >> javax.crypto.interfaces.DHPublicKey >> java.security.interfaces.RSAPublicKey >> java.security.interfaces.RSAPrivateKey > > Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright year to 2024 Done, will also add it to the 2 similar bugs that are left - I will integrate the changes tomorrow ------------- PR Comment: https://git.openjdk.org/jdk/pull/18373#issuecomment-2021011637 From abimpoudis at openjdk.org Tue Mar 26 18:10:34 2024 From: abimpoudis at openjdk.org (Aggelos Biboudis) Date: Tue, 26 Mar 2024 18:10:34 GMT Subject: RFR: 8329115: Crash involving return from inner switch Message-ID: <51EqoP3SWkAr6rg_zot9rAxc3a8STGQYx5liY8Dcl_0=.249fbb6c-6830-442d-a03e-346696ae96a6@github.com> When a `return` is used erroneously in a `switch`, attribution should continue for the `tree.expr` of a return node if exists. int test() { return switch (new R1()) { case R1() -> { return switch (new R2()) { // crashes, instead it should just be the error: attempt to return out of a switch expression case R2() -> 1; }; } }; } ------------- Commit messages: - 8329115: Crash involving return from inner switch Changes: https://git.openjdk.org/jdk/pull/18494/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18494&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8329115 Stats: 26 lines in 3 files changed: 26 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/18494.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18494/head:pull/18494 PR: https://git.openjdk.org/jdk/pull/18494 From jlahoda at openjdk.org Wed Mar 27 09:05:31 2024 From: jlahoda at openjdk.org (Jan Lahoda) Date: Wed, 27 Mar 2024 09:05:31 GMT Subject: RFR: 8329115: Crash involving return from inner switch In-Reply-To: <51EqoP3SWkAr6rg_zot9rAxc3a8STGQYx5liY8Dcl_0=.249fbb6c-6830-442d-a03e-346696ae96a6@github.com> References: <51EqoP3SWkAr6rg_zot9rAxc3a8STGQYx5liY8Dcl_0=.249fbb6c-6830-442d-a03e-346696ae96a6@github.com> Message-ID: On Tue, 26 Mar 2024 18:05:36 GMT, Aggelos Biboudis wrote: > When a `return` is used erroneously in a `switch`, attribution should continue for the `tree.expr` of a return node if exists. > > > int test() { > return switch (new R1()) { > case R1() -> { > return switch (new R2()) { // crashes, instead it should just be the error: attempt to return out of a switch expression > case R2() -> 1; > }; > } > }; > } Looks good to me, thanks! ------------- Marked as reviewed by jlahoda (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/18494#pullrequestreview-1962690780 From abimpoudis at openjdk.org Wed Mar 27 09:41:30 2024 From: abimpoudis at openjdk.org (Aggelos Biboudis) Date: Wed, 27 Mar 2024 09:41:30 GMT Subject: Integrated: 8329115: Crash involving return from inner switch In-Reply-To: <51EqoP3SWkAr6rg_zot9rAxc3a8STGQYx5liY8Dcl_0=.249fbb6c-6830-442d-a03e-346696ae96a6@github.com> References: <51EqoP3SWkAr6rg_zot9rAxc3a8STGQYx5liY8Dcl_0=.249fbb6c-6830-442d-a03e-346696ae96a6@github.com> Message-ID: On Tue, 26 Mar 2024 18:05:36 GMT, Aggelos Biboudis wrote: > When a `return` is used erroneously in a `switch`, attribution should continue for the `tree.expr` of a return node if exists. > > > int test() { > return switch (new R1()) { > case R1() -> { > return switch (new R2()) { // crashes, instead it should just be the error: attempt to return out of a switch expression > case R2() -> 1; > }; > } > }; > } This pull request has now been integrated. Changeset: 4dfcc6df Author: Aggelos Biboudis URL: https://git.openjdk.org/jdk/commit/4dfcc6df173d91b9b0b73d1ac3008e7cbb283871 Stats: 26 lines in 3 files changed: 26 ins; 0 del; 0 mod 8329115: Crash involving return from inner switch Reviewed-by: jlahoda ------------- PR: https://git.openjdk.org/jdk/pull/18494 From jlahoda at openjdk.org Wed Mar 27 15:47:35 2024 From: jlahoda at openjdk.org (Jan Lahoda) Date: Wed, 27 Mar 2024 15:47:35 GMT Subject: RFR: 8324651: Compiler Implementation for Derived Record Creation (Preview) Message-ID: This is a patch for javac, that adds the Derived Record Creation expressions. The current draft specification for the feature is: https://cr.openjdk.org/~gbierman/jep468/jep468-20240326/specs/derived-record-creation-jls.html The current CSR is here: https://bugs.openjdk.org/browse/JDK-8328637 The patch is mostly straightforward, with two notable changes: - there is a new `ElementKind.COMPONENT_LOCAL_VARIABLE`, as the specification introduces this term, and it seems consistent with `ElementKind.BINDING_VARIABLE` that was introduced some time ago. - there are a bit broader changes in `Flow`, to facilitate the introduction of variables without an explicit declaration for definite assignment and effectively final computation. ------------- Commit messages: - Removing whitespace - Cleanup. - Cleanup, bugfixes. - Adding tests. - Adding examples. - More correct handling of exceptions in derived record creation expression; optimizing the resulting bytecode. - Javadoc cleanup. - Merge branch 'master' into wthexp - Adding missing file. - Cleanup. - ... and 11 more: https://git.openjdk.org/jdk/compare/0c1b254b...a61682ff Changes: https://git.openjdk.org/jdk/pull/18509/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18509&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8324651 Stats: 1551 lines in 41 files changed: 1481 ins; 20 del; 50 mod Patch: https://git.openjdk.org/jdk/pull/18509.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18509/head:pull/18509 PR: https://git.openjdk.org/jdk/pull/18509 From jjg at openjdk.org Wed Mar 27 17:41:10 2024 From: jjg at openjdk.org (Jonathan Gibbons) Date: Wed, 27 Mar 2024 17:41:10 GMT Subject: RFR: JDK-8298405: Implement JEP 467: Markdown Documentation Comments [v54] In-Reply-To: References: Message-ID: > Please review a patch to add support for Markdown syntax in documentation comments, as described in the associated JEP. > > Notable features: > > * support for `///` documentation comments in `JavaTokenizer` > * new module `jdk.internal.md` -- a private copy of the `commonmark-java` library > * updates to `DocCommentParser` to treat `///` comments as Markdown > * updates to the standard doclet to render Markdown comments in HTML Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: add support for `--disable-line-doc-comments` ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16388/files - new: https://git.openjdk.org/jdk/pull/16388/files/a8ea1c72..37646287 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16388&range=53 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16388&range=52-53 Stats: 134 lines in 9 files changed: 132 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/16388.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16388/head:pull/16388 PR: https://git.openjdk.org/jdk/pull/16388 From jjg at openjdk.org Wed Mar 27 22:08:57 2024 From: jjg at openjdk.org (Jonathan Gibbons) Date: Wed, 27 Mar 2024 22:08:57 GMT Subject: RFR: JDK-8303689: javac -Xlint could/should report on "dangling" doc comments Message-ID: Please review the updates to support a proposed new `-Xlint:dangling-doc-comments` option. The work can be thought of as in 3 parts: 1. An update to the `javac` internal class `DeferredLintHandler` so that it is possible to specify the appropriately configured `Lint` object when it is time to consider whether to generate the diagnostic or not. 2. Updates to the `javac` front end to record "dangling docs comments" found near the beginning of a declaration, and to report them using an instance of `DeferredLintHandler`. This allows the warnings to be enabled or disabled using the standard mechanisms for `-Xlint` and `@SuppressWarnings`. The procedure for handling dangling doc comments is described in this comment in `JavacParser`. * Dangling documentation comments are handled as follows. * 1. {@code Scanner} adds all doc comments to a queue of * recent doc comments. The queue is flushed whenever * it is known that the recent doc comments should be * ignored and should not cause any warnings. * 2. The primary documentation comment is the one obtained * from the first token of any declaration. * (using {@code token.getDocComment()}. * 3. At the end of the "signature" of the declaration * (that is, before any initialization or body for the * declaration) any other "recent" comments are saved * in a map using the primary comment as a key, * using this method, {@code saveDanglingComments}. * 4. When the tree node for the declaration is finally * available, and the primary comment, if any, * is "attached", (in {@link #attach}) any related * dangling comments are also attached to the tree node * by registering them using the {@link #deferredLintHandler}. * 5. (Later) Warnings may be genereated for the dangling * comments, subject to the {@code -Xlint} and * {@code @SuppressWarnings}. 3. Updates to the make files to disable the warnings in modules for which the warning is generated. This is often because of the confusing use of `/**` to create box or other standout comments. ------------- Commit messages: - JDK-8303689: javac -Xlint could/should report on "dangling" doc comments Changes: https://git.openjdk.org/jdk/pull/18527/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18527&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8303689 Stats: 477 lines in 60 files changed: 368 ins; 5 del; 104 mod Patch: https://git.openjdk.org/jdk/pull/18527.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18527/head:pull/18527 PR: https://git.openjdk.org/jdk/pull/18527 From prappo at openjdk.org Wed Mar 27 22:44:31 2024 From: prappo at openjdk.org (Pavel Rappo) Date: Wed, 27 Mar 2024 22:44:31 GMT Subject: RFR: JDK-8303689: javac -Xlint could/should report on "dangling" doc comments In-Reply-To: References: Message-ID: <7vkdZb7QDt106_k7_i7PrYzCYuEwTT-P2l4VxDOrNQk=.e98a3d16-8be0-4194-acd5-94eff555adce@github.com> On Wed, 27 Mar 2024 22:04:30 GMT, Jonathan Gibbons wrote: > Please review the updates to support a proposed new `-Xlint:dangling-doc-comments` option. > > The work can be thought of as in 3 parts: > > 1. An update to the `javac` internal class `DeferredLintHandler` so that it is possible to specify the appropriately configured `Lint` object when it is time to consider whether to generate the diagnostic or not. > > 2. Updates to the `javac` front end to record "dangling docs comments" found near the beginning of a declaration, and to report them using an instance of `DeferredLintHandler`. This allows the warnings to be enabled or disabled using the standard mechanisms for `-Xlint` and `@SuppressWarnings`. The procedure for handling dangling doc comments is described in this comment in `JavacParser`. > > * Dangling documentation comments are handled as follows. > * 1. {@code Scanner} adds all doc comments to a queue of > * recent doc comments. The queue is flushed whenever > * it is known that the recent doc comments should be > * ignored and should not cause any warnings. > * 2. The primary documentation comment is the one obtained > * from the first token of any declaration. > * (using {@code token.getDocComment()}. > * 3. At the end of the "signature" of the declaration > * (that is, before any initialization or body for the > * declaration) any other "recent" comments are saved > * in a map using the primary comment as a key, > * using this method, {@code saveDanglingComments}. > * 4. When the tree node for the declaration is finally > * available, and the primary comment, if any, > * is "attached", (in {@link #attach}) any related > * dangling comments are also attached to the tree node > * by registering them using the {@link #deferredLintHandler}. > * 5. (Later) Warnings may be genereated for the dangling > * comments, subject to the {@code -Xlint} and > * {@code @SuppressWarnings}. > > > 3. Updates to the make files to disable the warnings in modules for which the > warning is generated. This is often because of the confusing use of `/**` to > create box or other standout comments. Would this be the first lint -- not doclint -- warning related to comments, let alone doc comments? ------------- PR Comment: https://git.openjdk.org/jdk/pull/18527#issuecomment-2024106466 From liach at openjdk.org Wed Mar 27 22:52:32 2024 From: liach at openjdk.org (Chen Liang) Date: Wed, 27 Mar 2024 22:52:32 GMT Subject: RFR: 8328536: javac - crash on unknown type referenced in yield statement In-Reply-To: References: Message-ID: On Tue, 19 Mar 2024 17:49:32 GMT, Hannes Greule wrote: > Pasting e.g. > > I m(I i, int x) { > return switch (x) { > default -> i; > }; > } > > in jshell will cause a crash if `I` is not declared already. This comes down to javac not creating an error type for the value of the (implicit) yield from the switch. > > Javac will not crash but swallow the exception, and create a file containing the command line options. > > I first thought about just checking for null of the type here https://github.com/openjdk/jdk/blob/9ca4ae3d3b746f1d75036d189ff98f02b73b948f/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java#L1640 but after a closer look, the `checkIdInternal` method seems a better fit, as it also updates the type normally. test/langtools/jdk/jshell/ToolSimpleTest.java line 1: > 1: /* You should add the bug id in the test header. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18383#discussion_r1542127628 From prappo at openjdk.org Wed Mar 27 22:55:32 2024 From: prappo at openjdk.org (Pavel Rappo) Date: Wed, 27 Mar 2024 22:55:32 GMT Subject: RFR: JDK-8303689: javac -Xlint could/should report on "dangling" doc comments In-Reply-To: References: Message-ID: On Wed, 27 Mar 2024 22:04:30 GMT, Jonathan Gibbons wrote: > Please review the updates to support a proposed new `-Xlint:dangling-doc-comments` option. > > The work can be thought of as in 3 parts: > > 1. An update to the `javac` internal class `DeferredLintHandler` so that it is possible to specify the appropriately configured `Lint` object when it is time to consider whether to generate the diagnostic or not. > > 2. Updates to the `javac` front end to record "dangling docs comments" found near the beginning of a declaration, and to report them using an instance of `DeferredLintHandler`. This allows the warnings to be enabled or disabled using the standard mechanisms for `-Xlint` and `@SuppressWarnings`. The procedure for handling dangling doc comments is described in this comment in `JavacParser`. > > * Dangling documentation comments are handled as follows. > * 1. {@code Scanner} adds all doc comments to a queue of > * recent doc comments. The queue is flushed whenever > * it is known that the recent doc comments should be > * ignored and should not cause any warnings. > * 2. The primary documentation comment is the one obtained > * from the first token of any declaration. > * (using {@code token.getDocComment()}. > * 3. At the end of the "signature" of the declaration > * (that is, before any initialization or body for the > * declaration) any other "recent" comments are saved > * in a map using the primary comment as a key, > * using this method, {@code saveDanglingComments}. > * 4. When the tree node for the declaration is finally > * available, and the primary comment, if any, > * is "attached", (in {@link #attach}) any related > * dangling comments are also attached to the tree node > * by registering them using the {@link #deferredLintHandler}. > * 5. (Later) Warnings may be genereated for the dangling > * comments, subject to the {@code -Xlint} and > * {@code @SuppressWarnings}. > > > 3. Updates to the make files to disable the warnings in modules for which the > warning is generated. This is often because of the confusing use of `/**` to > create box or other standout comments. Javadoc changes look trivially good. I only note that the javadoc man page diff contains some unrelated changes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18527#issuecomment-2024116236 From prappo at openjdk.org Wed Mar 27 22:59:34 2024 From: prappo at openjdk.org (Pavel Rappo) Date: Wed, 27 Mar 2024 22:59:34 GMT Subject: RFR: JDK-8303689: javac -Xlint could/should report on "dangling" doc comments In-Reply-To: References: Message-ID: On Wed, 27 Mar 2024 22:04:30 GMT, Jonathan Gibbons wrote: > Please review the updates to support a proposed new `-Xlint:dangling-doc-comments` option. > > The work can be thought of as in 3 parts: > > 1. An update to the `javac` internal class `DeferredLintHandler` so that it is possible to specify the appropriately configured `Lint` object when it is time to consider whether to generate the diagnostic or not. > > 2. Updates to the `javac` front end to record "dangling docs comments" found near the beginning of a declaration, and to report them using an instance of `DeferredLintHandler`. This allows the warnings to be enabled or disabled using the standard mechanisms for `-Xlint` and `@SuppressWarnings`. The procedure for handling dangling doc comments is described in this comment in `JavacParser`. > > * Dangling documentation comments are handled as follows. > * 1. {@code Scanner} adds all doc comments to a queue of > * recent doc comments. The queue is flushed whenever > * it is known that the recent doc comments should be > * ignored and should not cause any warnings. > * 2. The primary documentation comment is the one obtained > * from the first token of any declaration. > * (using {@code token.getDocComment()}. > * 3. At the end of the "signature" of the declaration > * (that is, before any initialization or body for the > * declaration) any other "recent" comments are saved > * in a map using the primary comment as a key, > * using this method, {@code saveDanglingComments}. > * 4. When the tree node for the declaration is finally > * available, and the primary comment, if any, > * is "attached", (in {@link #attach}) any related > * dangling comments are also attached to the tree node > * by registering them using the {@link #deferredLintHandler}. > * 5. (Later) Warnings may be genereated for the dangling > * comments, subject to the {@code -Xlint} and > * {@code @SuppressWarnings}. > > > 3. Updates to the make files to disable the warnings in modules for which the > warning is generated. This is often because of the confusing use of `/**` to > create box or other standout comments. src/jdk.javadoc/share/man/javadoc.1 line 111: > 109: source code with the \f[V]javac\f[R] option \f[V]-Xlint\f[R], or more > 110: specifically, \f[V]-Xlint:dangling-doc-comments\f[R]. > 111: Within a source file, you may use suppress any warnings generated by Typo? Suggestion: Within a source file, you may suppress any warnings generated by ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18527#discussion_r1542131487 From jjg at openjdk.org Wed Mar 27 23:47:32 2024 From: jjg at openjdk.org (Jonathan Gibbons) Date: Wed, 27 Mar 2024 23:47:32 GMT Subject: RFR: JDK-8303689: javac -Xlint could/should report on "dangling" doc comments In-Reply-To: <7vkdZb7QDt106_k7_i7PrYzCYuEwTT-P2l4VxDOrNQk=.e98a3d16-8be0-4194-acd5-94eff555adce@github.com> References: <7vkdZb7QDt106_k7_i7PrYzCYuEwTT-P2l4VxDOrNQk=.e98a3d16-8be0-4194-acd5-94eff555adce@github.com> Message-ID: On Wed, 27 Mar 2024 22:41:33 GMT, Pavel Rappo wrote: > Would this be the first lint -- not doclint -- warning related to comments, let alone doc comments? No. `-Xlint:dep-ann` correlates `@Deprecated` annotations with `@deprecated` tags in doc comments. > src/jdk.javadoc/share/man/javadoc.1 line 111: > >> 109: source code with the \f[V]javac\f[R] option \f[V]-Xlint\f[R], or more >> 110: specifically, \f[V]-Xlint:dangling-doc-comments\f[R]. >> 111: Within a source file, you may use suppress any warnings generated by > > Typo? > Suggestion: > > Within a source file, you may suppress any warnings generated by Thanks; I'll check the underlying original. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18527#issuecomment-2024162355 PR Review Comment: https://git.openjdk.org/jdk/pull/18527#discussion_r1542157047 From hgreule at openjdk.org Thu Mar 28 08:37:00 2024 From: hgreule at openjdk.org (Hannes Greule) Date: Thu, 28 Mar 2024 08:37:00 GMT Subject: RFR: 8328536: javac - crash on unknown type referenced in yield statement [v2] In-Reply-To: References: Message-ID: > Pasting e.g. > > I m(I i, int x) { > return switch (x) { > default -> i; > }; > } > > in jshell will cause a crash if `I` is not declared already. This comes down to javac not creating an error type for the value of the (implicit) yield from the switch. > > Javac will not crash but swallow the exception, and create a file containing the command line options. > > I first thought about just checking for null of the type here https://github.com/openjdk/jdk/blob/9ca4ae3d3b746f1d75036d189ff98f02b73b948f/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java#L1640 but after a closer look, the `checkIdInternal` method seems a better fit, as it also updates the type normally. Hannes Greule has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Merge branch 'refs/heads/master' into fix/switch-yield-unknown-type-crash - add bug id - Fix jshell crash on unknown type in switch yield ------------- Changes: - all: https://git.openjdk.org/jdk/pull/18383/files - new: https://git.openjdk.org/jdk/pull/18383/files/ed7dc8fe..846ac70c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=18383&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18383&range=00-01 Stats: 65016 lines in 2504 files changed: 13779 ins; 8799 del; 42438 mod Patch: https://git.openjdk.org/jdk/pull/18383.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18383/head:pull/18383 PR: https://git.openjdk.org/jdk/pull/18383 From abimpoudis at openjdk.org Thu Mar 28 11:31:34 2024 From: abimpoudis at openjdk.org (Aggelos Biboudis) Date: Thu, 28 Mar 2024 11:31:34 GMT Subject: RFR: 8324651: Compiler Implementation for Derived Record Creation (Preview) In-Reply-To: References: Message-ID: On Wed, 27 Mar 2024 10:24:51 GMT, Jan Lahoda wrote: > This is a patch for javac, that adds the Derived Record Creation expressions. The current draft specification for the feature is: > https://cr.openjdk.org/~gbierman/jep468/jep468-20240326/specs/derived-record-creation-jls.html > > The current CSR is here: > https://bugs.openjdk.org/browse/JDK-8328637 > > The patch is mostly straightforward, with two notable changes: > - there is a new `ElementKind.COMPONENT_LOCAL_VARIABLE`, as the specification introduces this term, and it seems consistent with `ElementKind.BINDING_VARIABLE` that was introduced some time ago. > - there are a bit broader changes in `Flow`, to facilitate the introduction of variables without an explicit declaration for definite assignment and effectively final computation. src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 2228: > 2226: * index into the vars array. > 2227: */ > 2228: void newVar(JCTree pos,VarSymbol sym) { This is used only twice. One from `void newVar(JCVariableDecl varDecl)` which is very intuitive and one with `newVar(null, component);` which I understand. But, is there any reason to create a `var` in the future with something else than `null` (unrelated to `sym`?). Maybe the comment needs to be updated to document what should be the relation (if any) between `pos` and `sym`. src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 3259: > 3257: startPos = tree.pos().getStartPosition(); > 3258: > 3259: if (vars == null) Curly braces here? src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java line 3607: > 3605: public void visitLambda(JCLambda that) { visitTree(that); } > 3606: public void visitParens(JCParens that) { visitTree(that); } > 3607: public void visitReconstruction(JCDerivedInstance that) { visitTree(that); } Maybe `visitDerivedInstance` to be in sync with the `JCDerivedInstance` world? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18509#discussion_r1542712222 PR Review Comment: https://git.openjdk.org/jdk/pull/18509#discussion_r1542713984 PR Review Comment: https://git.openjdk.org/jdk/pull/18509#discussion_r1542746919 From jlahoda at openjdk.org Thu Mar 28 13:24:48 2024 From: jlahoda at openjdk.org (Jan Lahoda) Date: Thu, 28 Mar 2024 13:24:48 GMT Subject: RFR: 8324651: Compiler Implementation for Derived Record Creation (Preview) [v2] In-Reply-To: References: Message-ID: > This is a patch for javac, that adds the Derived Record Creation expressions. The current draft specification for the feature is: > https://cr.openjdk.org/~gbierman/jep468/jep468-20240326/specs/derived-record-creation-jls.html > > The current CSR is here: > https://bugs.openjdk.org/browse/JDK-8328637 > > The patch is mostly straightforward, with two notable changes: > - there is a new `ElementKind.COMPONENT_LOCAL_VARIABLE`, as the specification introduces this term, and it seems consistent with `ElementKind.BINDING_VARIABLE` that was introduced some time ago. > - there are a bit broader changes in `Flow`, to facilitate the introduction of variables without an explicit declaration for definite assignment and effectively final computation. Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: Fixing support for derived record creation expression in JShell. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/18509/files - new: https://git.openjdk.org/jdk/pull/18509/files/a61682ff..e1a61833 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=18509&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18509&range=00-01 Stats: 61 lines in 11 files changed: 57 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/18509.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18509/head:pull/18509 PR: https://git.openjdk.org/jdk/pull/18509 From jlahoda at openjdk.org Thu Mar 28 13:45:58 2024 From: jlahoda at openjdk.org (Jan Lahoda) Date: Thu, 28 Mar 2024 13:45:58 GMT Subject: RFR: 8324651: Compiler Implementation for Derived Record Creation (Preview) [v3] In-Reply-To: References: Message-ID: > This is a patch for javac, that adds the Derived Record Creation expressions. The current draft specification for the feature is: > https://cr.openjdk.org/~gbierman/jep468/jep468-20240326/specs/derived-record-creation-jls.html > > The current CSR is here: > https://bugs.openjdk.org/browse/JDK-8328637 > > The patch is mostly straightforward, with two notable changes: > - there is a new `ElementKind.COMPONENT_LOCAL_VARIABLE`, as the specification introduces this term, and it seems consistent with `ElementKind.BINDING_VARIABLE` that was introduced some time ago. > - there are a bit broader changes in `Flow`, to facilitate the introduction of variables without an explicit declaration for definite assignment and effectively final computation. Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: Renaming visitReconstruction to visitDerivedInstance as suggested. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/18509/files - new: https://git.openjdk.org/jdk/pull/18509/files/e1a61833..73752b90 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=18509&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18509&range=01-02 Stats: 15 lines in 10 files changed: 0 ins; 0 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/18509.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18509/head:pull/18509 PR: https://git.openjdk.org/jdk/pull/18509 From jlahoda at openjdk.org Thu Mar 28 13:45:59 2024 From: jlahoda at openjdk.org (Jan Lahoda) Date: Thu, 28 Mar 2024 13:45:59 GMT Subject: RFR: 8324651: Compiler Implementation for Derived Record Creation (Preview) [v3] In-Reply-To: References: Message-ID: On Thu, 28 Mar 2024 11:00:42 GMT, Aggelos Biboudis wrote: >> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: >> >> Renaming visitReconstruction to visitDerivedInstance as suggested. > > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 2228: > >> 2226: * index into the vars array. >> 2227: */ >> 2228: void newVar(JCTree pos,VarSymbol sym) { > > This is used only twice. One from `void newVar(JCVariableDecl varDecl)` which is very intuitive and one with `newVar(null, component);` which I understand. But, is there any reason to create a `var` in the future with something else than `null` (unrelated to `sym`?). Maybe the comment needs to be updated to document what should be the relation (if any) between `pos` and `sym`. Oops, that's actually an oversight - there should be a pos specified in all cases. Should be fixed now. > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 3259: > >> 3257: startPos = tree.pos().getStartPosition(); >> 3258: >> 3259: if (vars == null) > > Curly braces here? This is a copy of the similar code for `vardecls`. I was thinking if I could unify the codepaths, but does not seem to be so simple, so I created a duplicate. So, it might be better to keep the code the same/similar as it was before, to minimize disruptions. > src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java line 3607: > >> 3605: public void visitLambda(JCLambda that) { visitTree(that); } >> 3606: public void visitParens(JCParens that) { visitTree(that); } >> 3607: public void visitReconstruction(JCDerivedInstance that) { visitTree(that); } > > Maybe `visitDerivedInstance` to be in sync with the `JCDerivedInstance` world? Done. Thanks! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18509#discussion_r1543004274 PR Review Comment: https://git.openjdk.org/jdk/pull/18509#discussion_r1543006459 PR Review Comment: https://git.openjdk.org/jdk/pull/18509#discussion_r1543006600 From jlahoda at openjdk.org Thu Mar 28 14:01:07 2024 From: jlahoda at openjdk.org (Jan Lahoda) Date: Thu, 28 Mar 2024 14:01:07 GMT Subject: RFR: 8324651: Compiler Implementation for Derived Record Creation (Preview) [v4] In-Reply-To: References: Message-ID: > This is a patch for javac, that adds the Derived Record Creation expressions. The current draft specification for the feature is: > https://cr.openjdk.org/~gbierman/jep468/jep468-20240326/specs/derived-record-creation-jls.html > > The current CSR is here: > https://bugs.openjdk.org/browse/JDK-8328637 > > The patch is mostly straightforward, with two notable changes: > - there is a new `ElementKind.COMPONENT_LOCAL_VARIABLE`, as the specification introduces this term, and it seems consistent with `ElementKind.BINDING_VARIABLE` that was introduced some time ago. > - there are a bit broader changes in `Flow`, to facilitate the introduction of variables without an explicit declaration for definite assignment and effectively final computation. Jan Lahoda has updated the pull request incrementally with two additional commits since the last revision: - Adding tests. - The var declaration can be any JCTree. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/18509/files - new: https://git.openjdk.org/jdk/pull/18509/files/73752b90..7b706eeb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=18509&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18509&range=02-03 Stats: 170 lines in 3 files changed: 169 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/18509.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18509/head:pull/18509 PR: https://git.openjdk.org/jdk/pull/18509 From jlahoda at openjdk.org Thu Mar 28 14:08:44 2024 From: jlahoda at openjdk.org (Jan Lahoda) Date: Thu, 28 Mar 2024 14:08:44 GMT Subject: RFR: 8324651: Compiler Implementation for Derived Record Creation (Preview) [v5] In-Reply-To: References: Message-ID: > This is a patch for javac, that adds the Derived Record Creation expressions. The current draft specification for the feature is: > https://cr.openjdk.org/~gbierman/jep468/jep468-20240326/specs/derived-record-creation-jls.html > > The current CSR is here: > https://bugs.openjdk.org/browse/JDK-8328637 > > The patch is mostly straightforward, with two notable changes: > - there is a new `ElementKind.COMPONENT_LOCAL_VARIABLE`, as the specification introduces this term, and it seems consistent with `ElementKind.BINDING_VARIABLE` that was introduced some time ago. > - there are a bit broader changes in `Flow`, to facilitate the introduction of variables without an explicit declaration for definite assignment and effectively final computation. Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: Fixing tests. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/18509/files - new: https://git.openjdk.org/jdk/pull/18509/files/7b706eeb..f89501ee Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=18509&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18509&range=03-04 Stats: 79 lines in 4 files changed: 0 ins; 46 del; 33 mod Patch: https://git.openjdk.org/jdk/pull/18509.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18509/head:pull/18509 PR: https://git.openjdk.org/jdk/pull/18509 From jjg at openjdk.org Thu Mar 28 17:51:48 2024 From: jjg at openjdk.org (Jonathan Gibbons) Date: Thu, 28 Mar 2024 17:51:48 GMT Subject: RFR: JDK-8298405: Implement JEP 467: Markdown Documentation Comments [v43] In-Reply-To: References: Message-ID: On Thu, 29 Feb 2024 11:39:41 GMT, Hannes Walln?fer wrote: >> Setext headings only come in "level 1" and "level 2" flavors. >> And, at the time the renderer sees the AST, the difference between ATX and setext headings is erased. They're just "headings". >> >> I also think it is better to have a simple rule than an "adaptive" rule. If you start doing a more complex rule, you have to consider the effect on subheadings as well. > > I suspected it was about the limited range of Setext headings. Yesterday my proposal was intentionally vague, but thinking about this again I think we should actually do the simplest and least intrusive thing possible: > > // minLevel is 4 for members, 2 for page-level elements, 1 for doc files > "h" + Math.max(heading.getLevel(), minLevel); > > This arguably generates the correct heading for most simple use cases. What it doesn't do is to translate whole hierarchies of headings, but I would argue that few people people need this and those who do should figure out the rules and use the correct ATX headings. Generally, I disagree with the policy here. In particular, this suggestion "squashes"/"merges" heading levels at the more significant end of the range (i.e. h1, h2) and not at the least significant end of the range (i.e. h5, h6). And, while we do specify the required heading levels in "traditional" doc comments, that seems less than optimal. (I note in times past we had to _modify_ the headings in doc comments as a result of the policy). Given all that, it seems better/simpler to specify that an author should start the headings in any comment at level 1 and have the tool adjust the level as needed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1543389787 From vromero at openjdk.org Fri Mar 29 01:22:45 2024 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 29 Mar 2024 01:22:45 GMT Subject: RFR: 8325217: MethodSymbol.getModifiers() returns SEALED for restricted methods Message-ID: Please review this simple fix, basically javadoc is showing the `sealed` modifier for methods annotated with the `jdk.internal.javac.Restricted` annotation. This is because the `SEALED` and `RESTRICTED` flags share the same bit. The proposed solution is to drop the `RESTRICTED` flag at MethodSymbol::getModifiers before converting the flags to modifiers, TIA, Vicente ------------- Commit messages: - 8325217: MethodSymbol.getModifiers() returns SEALED for restricted methods Changes: https://git.openjdk.org/jdk/pull/18543/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18543&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8325217 Stats: 10 lines in 2 files changed: 1 ins; 2 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/18543.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18543/head:pull/18543 PR: https://git.openjdk.org/jdk/pull/18543 From vromero at openjdk.org Fri Mar 29 03:07:32 2024 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 29 Mar 2024 03:07:32 GMT Subject: RFR: JDK-8303689: javac -Xlint could/should report on "dangling" doc comments In-Reply-To: References: Message-ID: On Wed, 27 Mar 2024 22:04:30 GMT, Jonathan Gibbons wrote: > Please review the updates to support a proposed new `-Xlint:dangling-doc-comments` option. > > The work can be thought of as in 3 parts: > > 1. An update to the `javac` internal class `DeferredLintHandler` so that it is possible to specify the appropriately configured `Lint` object when it is time to consider whether to generate the diagnostic or not. > > 2. Updates to the `javac` front end to record "dangling docs comments" found near the beginning of a declaration, and to report them using an instance of `DeferredLintHandler`. This allows the warnings to be enabled or disabled using the standard mechanisms for `-Xlint` and `@SuppressWarnings`. The procedure for handling dangling doc comments is described in this comment in `JavacParser`. > > * Dangling documentation comments are handled as follows. > * 1. {@code Scanner} adds all doc comments to a queue of > * recent doc comments. The queue is flushed whenever > * it is known that the recent doc comments should be > * ignored and should not cause any warnings. > * 2. The primary documentation comment is the one obtained > * from the first token of any declaration. > * (using {@code token.getDocComment()}. > * 3. At the end of the "signature" of the declaration > * (that is, before any initialization or body for the > * declaration) any other "recent" comments are saved > * in a map using the primary comment as a key, > * using this method, {@code saveDanglingComments}. > * 4. When the tree node for the declaration is finally > * available, and the primary comment, if any, > * is "attached", (in {@link #attach}) any related > * dangling comments are also attached to the tree node > * by registering them using the {@link #deferredLintHandler}. > * 5. (Later) Warnings may be genereated for the dangling > * comments, subject to the {@code -Xlint} and > * {@code @SuppressWarnings}. > > > 3. Updates to the make files to disable the warnings in modules for which the > warning is generated. This is often because of the confusing use of `/**` to > create box or other standout comments. lgtm ------------- Marked as reviewed by vromero (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/18527#pullrequestreview-1967750057