Re: RFR: 8338525: Leading and trailing code blocks by indentation

2024-09-12 Thread Pavel Rappo
On Wed, 11 Sep 2024 22:36:02 GMT, Jonathan Gibbons wrote: > Please review these changes to correct the handling of leading and trailing > indented code blocks in a doc comment. > > There are two separate issues here: one for leading indented code blocks and > one for trailing indented code blo

Re: RFR: 8322036: Improve help output from the javadoc tool [v4]

2024-08-27 Thread Pavel Rappo
On Mon, 26 Aug 2024 12:01:42 GMT, Nizar Benalla wrote: >> Could I please get a review for this small clenup? I updated the `--help` >> command output to match that of `man javadoc`. >> >> I also noticed that `--help-extended` was renamed to `--help-extra` at some >> point but doc-comment was

Re: RFR: 8322036: Improve help output from the javadoc tool [v3]

2024-08-26 Thread Pavel Rappo
On Mon, 26 Aug 2024 11:15:53 GMT, Nizar Benalla wrote: > I can change it back. By the way I only see it used in the codebase once > [here](https://github.com/openjdk/jdk/blob/20d8f58c92009a46dfb91b951e7d87b4cb8e8b41/src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/Start.java#L254) > wher

Re: RFR: 8322036: Improve help output from the javadoc tool [v3]

2024-08-26 Thread Pavel Rappo
On Thu, 22 Aug 2024 18:11:16 GMT, Nizar Benalla wrote: >> Could I please get a review for this small clenup? I updated the `--help` >> command output to match that of `man javadoc`. >> >> I also noticed that `--help-extended` was renamed to `--help-extra` at some >> point but doc-comment was

Re: RFR: 8322036: Improve help output from the javadoc tool

2024-08-26 Thread Pavel Rappo
On Tue, 20 Aug 2024 14:46:07 GMT, Jonathan Gibbons wrote: > > Outside this PR diff, do we need to lowercase this ["Standard > > Doclet"](https://github.com/openjdk/jdk/blob/d0a265039a36292d87b249af0e8977982e5acc7b/src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/

Re: RFR: 8322036: Improve help output from the javadoc tool [v3]

2024-08-26 Thread Pavel Rappo
On Thu, 22 Aug 2024 18:08:11 GMT, Nizar Benalla wrote: >> They should not be removed/deleted. They could be replaced with single >> quotes `'` but IIRC they sometimes? have to be doubled in properties files. > > Fixed in > [e24bbd8](https://github.com/openjdk/jdk/pull/20618/commits/e24bbd8d6c1f

Re: RFR: 8322036: Improve help output from the javadoc tool

2024-08-20 Thread Pavel Rappo
On Fri, 16 Aug 2024 15:03:58 GMT, Nizar Benalla wrote: > Could I please get a review for this small clenup? I updated the `--help` > command output to match that of `man javadoc`. > > I also noticed that `--help-extended` was renamed to `--help-extra` at some > point but doc-comment was not c

Re: RFR: 8301991: Convert l10n properties resource bundles to UTF-8 native [v2]

2024-08-20 Thread Pavel Rappo
On Wed, 13 Sep 2023 17:38:28 GMT, Justin Lu wrote: >> JDK .properties files still use ISO-8859-1 encoding with escape sequences. >> It would improve readability to see the native characters instead of escape >> sequences (especially for the L10n process). The majority of files changed >> are l

Re: RFR: 8322036: Improve help output from the javadoc tool

2024-08-19 Thread Pavel Rappo
On Fri, 16 Aug 2024 15:03:58 GMT, Nizar Benalla wrote: > Could I please get a review for this small clenup? I updated the `--help` > command output to match that of `man javadoc`. > > I also noticed that `--help-extended` was renamed to `--help-extra` at some > point but doc-comment was not c

Re: [jdk23] RFR: 8337054: JDK 23 RDP2 L10n resource files update [v3]

2024-07-31 Thread Pavel Rappo
On Wed, 31 Jul 2024 11:02:06 GMT, Damon Nguyen wrote: >> Localization update for JDK23 RDP2 >> >> Please view for enhanced diffs on affected files: >> https://cr.openjdk.org/~dnguyen/output/ > > Damon Nguyen has updated the pull request incrementally with one additional > commit since the last

Integrated: 8299080: Wrong default value of snippet lang attribute

2024-07-17 Thread Pavel Rappo
On Mon, 1 Jul 2024 13:33:28 GMT, Pavel Rappo wrote: > Please review this bugfix to the way the language of a snippet is determined > and processed. > > The language of a snippet affects the form of snippet markup and enables > external syntax highlighting, such as that provi

Re: RFR: 8299080: Wrong default value of snippet lang attribute [v3]

2024-07-16 Thread Pavel Rappo
of a snippet is determined and processed > as follows: > > 1. If the `lang` attribute is present, then its value is the language; if > that value is empty, then the language is undefined > 2. Otherwise, >1. If the snippet is inline, then the language is `java` >

Re: [jdk23] RFR: 8336259: Wrong link to stylesheet.css in JavaDoc API documentation

2024-07-15 Thread Pavel Rappo
On Fri, 12 Jul 2024 23:38:31 GMT, Chen Liang wrote: > Please review the backport of #20145 onto jdk23, fixing 2 unnecessary and > erroneous links in the doc files. Marked as reviewed by prappo (Reviewer). - PR Review: https://git.openjdk.org/jdk/pull/20166#pullrequestreview-217806

Re: [jdk23] RFR: 8325369: @sealedGraph: Bad link to image for tag on nested classes

2024-07-15 Thread Pavel Rappo
On Thu, 11 Jul 2024 16:19:49 GMT, Chen Liang wrote: > Please review this build-only change that fixes the link to the SVG sealed > graph by the `@sealedGraph` javadoc taglet. This affects JDK 23 ea > documentation (as shown in #20122) and thus is backported. Marked as reviewed by prappo (Revie

Re: RFR: 8299080: Wrong default value of snippet lang attribute [v2]

2024-07-15 Thread Pavel Rappo
of a snippet is determined and processed > as follows: > > 1. If the `lang` attribute is present, then its value is the language; if > that value is empty, then the language is undefined > 2. Otherwise, >1. If the snippet is inline, then the language is `java` >2. O

Re: RFR: 8299080: Wrong default value of snippet lang attribute [v2]

2024-07-15 Thread Pavel Rappo
On Tue, 9 Jul 2024 21:13:45 GMT, Jonathan Gibbons wrote: >> General comment: while the dust on `Path.getExtension` is still settling, as >> a matter of policy, we should try and stay compatible with that. In >> particular, a filename like `.gitignore` is a hidden filename with no >> extension,

Re: [jdk23] RFR: 8318106: Generated HTML for snippet does not always contain an id

2024-07-13 Thread Pavel Rappo
On Fri, 12 Jul 2024 23:43:28 GMT, Chen Liang wrote: > improves the accessibility of snippets Accessibility is a loaded word in context of HTML. Just to clarify, this PR has nothing to do with a11y. - Marked as reviewed by prappo (Reviewer). PR Review: https://git.openjdk.org/jdk/

Integrated: 8318106: Generated HTML for snippet does not always contain an id

2024-07-12 Thread Pavel Rappo
On Thu, 11 Jul 2024 14:07:39 GMT, Pavel Rappo wrote: > Please review this jdk24 bug, which we intend to backport to jdk23 before > RDP2, which is a week away. This is a simple fix, but it disturbs multiple > tests. > > Here's a tip for reviewing. Sometimes a snippet id in

Re: [jdk23] RFR: 8336036: Synthetic documentation for a record's equals is incorrect for floating-point types

2024-07-11 Thread Pavel Rappo
On Thu, 11 Jul 2024 21:10:43 GMT, Chen Liang wrote: > Please review this backport of #20129 to JDK 23, fixing the documentation > Javadoc generates for the default object method implementations in user > records about the comparison behavior for `float` and `double` values. Marked as reviewed

Re: RFR: 8336036: Record equals Javadoc is incorrect for floating-point types

2024-07-11 Thread Pavel Rappo
On Wed, 10 Jul 2024 23:24:43 GMT, Chen Liang wrote: > Fixes to Javadoc's default documentation on record classes, that all > primitives are compared as if with their wrapper classes' `compare` method by > default. Looks good. - Marked as reviewed by prappo (Reviewer). PR Review:

Re: RFR: 8318106: Generated HTML for snippet does not always contain an id [v2]

2024-07-11 Thread Pavel Rappo
On Thu, 11 Jul 2024 14:43:08 GMT, Chen Liang wrote: >> Pavel Rappo has refreshed the contents of this pull request, and previous >> commits have been removed. The incremental views will show differences >> compared to the previous content of the PR. The pull request co

Re: RFR: 8318106: Generated HTML for snippet does not always contain an id [v2]

2024-07-11 Thread Pavel Rappo
and "Method Details" sections. Otherwise, it will only appear in "Method > Details". Appearances are numbered starting from 1 and increment by 1 from > top ("Method Summary") to bottom ("Method Details"). Pavel Rappo has refreshed the contents of

RFR: 8318106: Generated HTML for snippet does not always contain an id

2024-07-11 Thread Pavel Rappo
Please review this jdk24 bug, which we intend to backport to jdk23 before RDP2, which is a week away. This is a simple fix, but it disturbs multiple tests. Here's a tip for reviewing. Sometimes a snippet id in a test ends up with `()1`, other times with `()2`. This is because the same snippet ma

Re: RFR: 8299080: Wrong default value of snippet lang attribute

2024-07-01 Thread Pavel Rappo
On Mon, 1 Jul 2024 16:20:56 GMT, Hannes Wallnöfer wrote: > I think Chen's point was that it should not be `null`, to which I agree, > although it is probably a corner case. If so, my bad for misreading it. For such corner cases authors should specify `lang` attribute. - PR Review

Re: RFR: 8299080: Wrong default value of snippet lang attribute

2024-07-01 Thread Pavel Rappo
On Mon, 1 Jul 2024 14:03:52 GMT, Chen Liang wrote: >> Please review this bugfix to the way the language of a snippet is determined >> and processed. >> >> The language of a snippet affects the form of snippet markup and enables >> external syntax highlighting, such as that provided by prism.js

RFR: 8299080: Wrong default value of snippet lang attribute

2024-07-01 Thread Pavel Rappo
Please review this bugfix to the way the language of a snippet is determined and processed. The language of a snippet affects the form of snippet markup and enables external syntax highlighting, such as that provided by prism.js. The language of a snippet is [[determined](https://docs.oracle.c

Re: [jdk23] RFR: 8334332: TestIOException.java fails if run by root

2024-06-18 Thread Pavel Rappo
> The commit being backported was authored by SendaoYan on 18 Jun 2024 and was > reviewed by Pavel Rappo. > > Only change test testcase, no risk. > > Thanks! Marked as reviewed by prappo (Reviewer). - PR Review: https://git.openjdk.org/jdk/pull/19765#pullrequestreview-2125224767

Re: RFR: 8334332: TestIOException.java fails if run by root [v4]

2024-06-18 Thread Pavel Rappo
On Tue, 18 Jun 2024 07:43:23 GMT, SendaoYan wrote: >> Hi all, >> Test >> `test/langtools/jdk/javadoc/doclet/testIOException/TestIOException.java` run >> fails with root user privileged. I think it's necessary to skip this >> testcase when user is root. >> Why run the jtreg test by root use

Re: RFR: 8334332: TestIOException.java fails if run by root [v4]

2024-06-18 Thread Pavel Rappo
On Tue, 18 Jun 2024 07:43:23 GMT, SendaoYan wrote: >> Hi all, >> Test >> `test/langtools/jdk/javadoc/doclet/testIOException/TestIOException.java` run >> fails with root user privileged. I think it's necessary to skip this >> testcase when user is root. >> Why run the jtreg test by root use

Re: RFR: 8334332: TestIOException.java fails if run by root [v2]

2024-06-18 Thread Pavel Rappo
On Tue, 18 Jun 2024 01:26:33 GMT, SendaoYan wrote: > Does the `throw new Error(f + ": " + message);` should be replaced to `throw > new SkippedException(f + ": " + message);`, to avoid report failure if a > directory cannot be made read-only. Yes, it does! That's the whole point. Ironically, I

Re: RFR: 8334332: TestIOException.java fails if run by root [v2]

2024-06-17 Thread Pavel Rappo
On Sat, 15 Jun 2024 09:54:38 GMT, SendaoYan wrote: >> Hi all, >> Test >> `test/langtools/jdk/javadoc/doclet/testIOException/TestIOException.java` run >> fails with root user privileged. I think it's necessary to skip this >> testcase when user is root. >> Why run the jtreg test by root use

Re: RFR: 8334332: Run TestIOException.java with root user fails [v2]

2024-06-17 Thread Pavel Rappo
On Sat, 15 Jun 2024 09:54:38 GMT, SendaoYan wrote: >> Hi all, >> Test >> `test/langtools/jdk/javadoc/doclet/testIOException/TestIOException.java` run >> fails with root user privileged. I think it's necessary to skip this >> testcase when user is root. >> Why run the jtreg test by root use

Re: RFR: 8322708: Global HTML attributes are not allowed [v3]

2024-06-14 Thread Pavel Rappo
On Fri, 14 Jun 2024 12:15:45 GMT, Nizar Benalla wrote: >> Can I please get a review for this change, that aims to add support for >> Global HTML tags. >> Here is the >> [link](https://cr.openjdk.org/~nbenalla/javadocGlobalPR/pkg1/package-summary.html) >> to the generated docs. >> Thanks in adv

Re: RFR: 8322708: Global HTML attributes are not allowed [v3]

2024-06-14 Thread Pavel Rappo
On Wed, 12 Jun 2024 09:03:38 GMT, Hannes Wallnöfer wrote: >> Wouldn't the easiest solution be to add a boolean `global`/`isGlobal` field >> and getter to `Attr`? >> >> That would give use some more opportunities to simplify the code: We could >> get rid of the `GLOBAL_ATTRS` map here *and* avo

Re: RFR: 8322708: Global HTML attributes are not allowed [v3]

2024-06-14 Thread Pavel Rappo
On Tue, 11 Jun 2024 23:49:15 GMT, Jonathan Gibbons wrote: >> As @jonathan-gibbons likes to point out, javadoc is not an HTML validation >> tool. So I think, it's okay to leave the code simple. Maybe this would be >> even simpler? >> >> data-[a-z][-a-z0-9]* > > I admit to being "lazy" when

Re: RFR: 8322708: Global HTML attributes are not allowed [v3]

2024-06-14 Thread Pavel Rappo
On Tue, 11 Jun 2024 14:42:48 GMT, Nizar Benalla wrote: >> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Checker.java line >> 695: >> >>> 693: // custom "data-*" attributes are also accepted >>> 694: var attrName=name.toString(); >>> 695: if (!att

Re: RFR: 8322708: Global HTML attributes are not allowed [v2]

2024-06-11 Thread Pavel Rappo
On Tue, 11 Jun 2024 13:35:31 GMT, Chen Liang wrote: >> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/HtmlTag.java line >> 556: >> >>> 554: } >>> 555: >>> 556: private final EnumSet GLOBAL_ATTRS = EnumSet.of( >> >> I get it, you cannot make it static because it's used in a

Re: RFR: 8322708: Global HTML attributes are not allowed [v2]

2024-06-11 Thread Pavel Rappo
On Tue, 11 Jun 2024 13:24:48 GMT, Nizar Benalla wrote: >> Can I please get a review for this change, that aims to add support for >> Global HTML tags. >> Here is the >> [link](https://cr.openjdk.org/~nbenalla/javadocGlobalAttrs/pkg1/package-summary.html) >> to the generated docs. >> Thanks in

Re: RFR: 8322708: Global HTML attributes are not allowed

2024-06-11 Thread Pavel Rappo
On Tue, 11 Jun 2024 11:37:27 GMT, Nizar Benalla wrote: > Can I please get a review for this change, that aims to add support for > Global HTML tags. > Here is the > [link](https://cr.openjdk.org/~nbenalla/javadocGlobalAttrs/pkg1/package-summary.html) > to the generated docs. > Thanks in advanc

Re: RFR: 8322708: Global HTML attributes are not allowed

2024-06-11 Thread Pavel Rappo
On Tue, 11 Jun 2024 11:51:05 GMT, Chen Liang wrote: >> Can I please get a review for this change, that aims to add support for >> Global HTML tags. >> Here is the >> [link](https://cr.openjdk.org/~nbenalla/javadocGlobalAttrs/pkg1/package-summary.html) >> to the generated docs. >> Thanks in adv

Re: RFR: 8333827: JDK 23 RDP1 L10n resource files update [v2]

2024-06-11 Thread Pavel Rappo
On Mon, 10 Jun 2024 21:58:29 GMT, Damon Nguyen wrote: >> This issue is responsible for updating the translations of all the >> localize(able) resources in the JDK. Primarily, the changes between JDK 22 >> RDP 1 and the integration of the JDK 23 RDP 1 L10n drop will be translated. >> >> The tra

Re: RFR: 8331947: Preview creates checkbox for JEP-less preview feature [v4]

2024-06-05 Thread Pavel Rappo
On Fri, 31 May 2024 10:01:17 GMT, Hannes Wallnöfer wrote: >> Please review a simple patch to exclude preview visitor classes meant to >> support future preview features from the Preview API page. >> >> The test adds an sample element annotated with the new >> `PreviewFeature.Feature.LANGUAGE_

Re: RFR: 8331579: Reference to primitive type fails without error or warning

2024-05-31 Thread Pavel Rappo
On Fri, 31 May 2024 10:19:52 GMT, Pavel Rappo wrote: > Consider adding a case of a primitive array, which while relates to > primitives is also an object. Oh, sorry, I see you did it in a separate test. I don't know why I didn't notice it. Sigh. - PR Revie

Re: RFR: 8331579: Reference to primitive type fails without error or warning

2024-05-31 Thread Pavel Rappo
On Tue, 28 May 2024 12:28:53 GMT, Hannes Wallnöfer wrote: > Please review a simple fix to make DocLint report an error when linking to > non-declared types in `{@link}` or `@see` tags. This has been implemented > when the Standard Doclet is running without DocLint in > [JDK-8284030](https://bu

Re: RFR: 8331579: Reference to primitive type fails without error or warning

2024-05-31 Thread Pavel Rappo
On Tue, 28 May 2024 12:28:53 GMT, Hannes Wallnöfer wrote: > Please review a simple fix to make DocLint report an error when linking to > non-declared types in `{@link}` or `@see` tags. This has been implemented > when the Standard Doclet is running without DocLint in > [JDK-8284030](https://bu

Re: RFR: 8332039: Cannot invoke "com.sun.source.util.DocTreePath.getTreePath()" because "path" is null

2024-05-31 Thread Pavel Rappo
On Thu, 30 May 2024 18:43:28 GMT, Pavel Rappo wrote: >> Please review a patch to fix a NPE thrown when a `@since` tag inherited by a >> nested class contains a nested inline tag. The solution is to make >> `CommentHelper.getDocTreePath(DocTree)` able to handle block tag

Re: RFR: 8332039: Cannot invoke "com.sun.source.util.DocTreePath.getTreePath()" because "path" is null

2024-05-30 Thread Pavel Rappo
On Thu, 23 May 2024 10:39:52 GMT, Hannes Wallnöfer wrote: > Please review a patch to fix a NPE thrown when a `@since` tag inherited by a > nested class contains a nested inline tag. The solution is to make > `CommentHelper.getDocTreePath(DocTree)` able to handle block tags inherited > by neste

Re: RFR: 8332545: Fix handling of HTML5 entities in Markdown comments

2024-05-20 Thread Pavel Rappo
On Mon, 20 May 2024 20:17:10 GMT, Jonathan Gibbons wrote: > Please review a small fix to address a crash when handling HTML5 entities in > a Markdown doc comment. > > The path for the `entities.txt` (originally `entities.properties`) was not > correctly imported when importing the latest versi

Re: RFR: 8298405: Implement JEP 467: Markdown Documentation Comments [v69]

2024-05-16 Thread Pavel Rappo
On Thu, 16 May 2024 14:53:17 GMT, Chen Liang wrote: > My rationale for a potential preview is that we changed > `-Xlint:dangling-doc-comments` as `///` is now dangling doc comment. Is this > considered a Java programming language change? There were some community > comments objecting the use o

Re: RFR: 8298405: Implement JEP 467: Markdown Documentation Comments [v69]

2024-05-16 Thread Pavel Rappo
On Wed, 15 May 2024 21:04:36 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 `j

Re: RFR: 8298405: Implement JEP 467: Markdown Documentation Comments [v69]

2024-05-16 Thread Pavel Rappo
On Thu, 16 May 2024 13:05:39 GMT, Chen Liang wrote: > A meta question about the JEP: Why don't Javadoc features (like snippets and > markdown comments) don't go through preview, while Compiler features mostly > do? Is there any bar for previews? Jon could probably reply more substantially, but

Re: RFR: 8298405: Implement JEP 467: Markdown Documentation Comments [v69]

2024-05-16 Thread Pavel Rappo
On Wed, 15 May 2024 21:04:36 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 `j

Re: RFR: 8332239: Improve CSS for block tags

2024-05-16 Thread Pavel Rappo
On Thu, 16 May 2024 10:56:26 GMT, Hannes Wallnöfer wrote: > Please review a change to improve the layout of definition lists used to > display block tags: > > - Add indentation to the `` elements used for block tag details > - Set the margin of lists within block tag details so they do not ap

Re: RFR: 8298405: Implement JEP 467: Markdown Documentation Comments [v67]

2024-05-15 Thread Pavel Rappo
On Tue, 7 May 2024 17:31: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 `jd

Withdrawn: 8330205: Initial troff manpage generation for JDK 24

2024-05-14 Thread Pavel Rappo
On Tue, 7 May 2024 11:53:19 GMT, Pavel Rappo wrote: > Please review this mechanical change to man pages. This PR should be > integrated after https://github.com/openjdk/jdk/pull/18787. This pull request has been closed without being integrated. - PR: https://git.openjdk.o

Re: RFR: 8330205: Initial troff manpage generation for JDK 24

2024-05-14 Thread Pavel Rappo
On Tue, 7 May 2024 11:53:19 GMT, Pavel Rappo wrote: > Please review this mechanical change to man pages. This PR should be > integrated after https://github.com/openjdk/jdk/pull/18787. Withdrawing this, as a different approach is required. - PR Comment: https://git.openj

Re: RFR: 8330205: Initial troff manpage generation for JDK 24

2024-05-13 Thread Pavel Rappo
On Thu, 9 May 2024 08:18:41 GMT, David Holmes wrote: >> Please review this mechanical change to man pages. This PR should be >> integrated after https://github.com/openjdk/jdk/pull/18787. > > src/java.base/share/man/java.1 line 3856: > >> 3854: .SH REMOVED JAVA OPTIONS >> 3855: .PP >> 3856: The

Re: RFR: 8330205: Initial troff manpage generation for JDK 24

2024-05-07 Thread Pavel Rappo
On Tue, 7 May 2024 11:53:19 GMT, Pavel Rappo wrote: > Please review this mechanical change to man pages. This PR should be > integrated after https://github.com/openjdk/jdk/pull/18787. Thanks for reviewing it Joe, I'm now delegating integration of this PR to @JesperIRL, you, or

Re: RFR: 8330205: Initial troff manpage generation for JDK 24

2024-05-07 Thread Pavel Rappo
On Tue, 7 May 2024 11:53:19 GMT, Pavel Rappo wrote: > Please review this mechanical change to man pages. This PR should be > integrated after https://github.com/openjdk/jdk/pull/18787. This PR is standalone as opposed to dependent because the https://github.com/openjdk/jdk/pull

RFR: 8330205: Initial troff manpage generation for JDK 24

2024-05-07 Thread Pavel Rappo
Please review this mechanical change to man pages. This PR should be integrated after https://github.com/openjdk/jdk/pull/18787. - Commit messages: - Initial commit Changes: https://git.openjdk.org/jdk/pull/19119/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19119&range=

Re: RFR: 8296175: Output warning if generated docs contain diagnostic markers

2024-04-26 Thread Pavel Rappo
On Fri, 26 Apr 2024 15:14:04 GMT, Hannes Wallnöfer wrote: > Please review a change to print a terminal message if the documentation > generated by `HtmlDoclet` contains any diagnostic marker elements for invalid > input. The message is printed after the documentation has been generated and > b

Re: RFR: 8324342: Doclet should default @since for a nested class to that of its enclosing class [v2]

2024-04-18 Thread Pavel Rappo
On Thu, 18 Apr 2024 18:43:13 GMT, Jonathan Gibbons wrote: >> Please review changes to the support for `since`, `author`, and `version` >> tags, such that if there are no such tags on a nested class, the doclet will >> look for any such tags in enclosing classes. > > Jonathan Gibbons has updated

Re: RFR: 8330063: Upgrade jQuery to 3.7.1

2024-04-17 Thread Pavel Rappo
On Fri, 12 Apr 2024 11:11:47 GMT, Hannes Wallnöfer wrote: > Please review a change to update jQuery from version 3.6.1 to 3.7.1 in > JavaDoc. The jQuery compressed and uncompressed files were obtained from > https://jquery.com/download/. Changes were tested against javadoc tests as > well as m

Re: RFR: 8330063: Upgrade jQuery to 3.7.1

2024-04-17 Thread Pavel Rappo
On Fri, 12 Apr 2024 11:11:47 GMT, Hannes Wallnöfer wrote: > Please review a change to update jQuery from version 3.6.1 to 3.7.1 in > JavaDoc. The jQuery compressed and uncompressed files were obtained from > https://jquery.com/download/. Changes were tested against javadoc tests as > well as m

Re: RFR: 8324342: Doclet should default @since for a nested class to that of its enclosing class

2024-04-16 Thread Pavel Rappo
On Tue, 16 Apr 2024 18:29:02 GMT, Jonathan Gibbons wrote: >> src/jdk.javadoc/share/man/javadoc.1 line 1: >> >>> 1: .\" Copyright (c) 1994, 2024, Oracle and/or its affiliates. All rights >>> reserved. >> >> This diff to the man page seems to contain some unrelated changes. If this >> is intent

Re: RFR: JDK-8298405: Implement JEP 467: Markdown Documentation Comments [v55]

2024-04-09 Thread Pavel Rappo
On Mon, 8 Apr 2024 21:12:42 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 `jd

Re: RFR: JDK-8324342: doclet should default @since for a nested class to that of its enclosing class

2024-04-08 Thread Pavel Rappo
On Wed, 20 Mar 2024 19:04:04 GMT, Jonathan Gibbons wrote: > Please review changes to the support for `since`, `author`, and `version` > tags, such that if there are no such tags on a nested class, the doclet will > look for any such tags in enclosing classes. This looks like the right thing to

Re: RFR: 8325088: Overloads that differ in type parameters may be lost [v6]

2024-04-08 Thread Pavel Rappo
uivalent signatures in a class". Which means that for > any two constructors or methods the erasure of their signatures must differ, > or else it won't compile. > > The change is pretty straightforward, except for some test fallout that > required attention. > > [JLS

Integrated: 8325088: Overloads that differ in type parameters may be lost

2024-04-08 Thread Pavel Rappo
On Wed, 27 Mar 2024 17:19:35 GMT, Pavel Rappo wrote: > Creating a link to a constructor or a method or comparing constructors or > methods __does not__ factor in type parameters. When constructors or methods > are overloaded and differ only in type parameters -- a situation which is

Re: RFR: 8325088: Overloads that differ in type parameters may be lost [v5]

2024-04-05 Thread Pavel Rappo
On Fri, 5 Apr 2024 19:58:27 GMT, Jonathan Gibbons wrote: > > Does this make sense? > > While I am dubious about 3-tuples, your explanation makes enough sense that I > accept your reply. Thanks for the explanation. Yet another alternative notation, should we come up with one in the future. Whi

Re: RFR: 8325088: Overloads that differ in type parameters may be lost [v5]

2024-04-05 Thread Pavel Rappo
On Fri, 5 Apr 2024 17:52:25 GMT, Jonathan Gibbons wrote: > Approved, with two optional suggestions. Both could be considered style > suggestions. > > ## 1 > (Minor) While I like the new multi-valued return for > `forMember(ExecutableElement executable)` I'm slightly surprised at the use > of

Re: RFR: 8325088: Overloads that differ in type parameters may be lost [v4]

2024-04-05 Thread Pavel Rappo
On Thu, 4 Apr 2024 21:21:58 GMT, Pavel Rappo wrote: >> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ConstructorWriter.java >> line 200: >> >>> 198: content.add(heading); >>> 199: return HtmlTree.SECTIO

Re: RFR: 8325088: Overloads that differ in type parameters may be lost [v5]

2024-04-05 Thread Pavel Rappo
uivalent signatures in a class". Which means that for > any two constructors or methods the erasure of their signatures must differ, > or else it won't compile. > > The change is pretty straightforward, except for some test fallout that > required attention. > >

Re: RFR: JDK-8329717 Missing `@since` tags in elements in DocumentationTool and Taglet [v2]

2024-04-05 Thread Pavel Rappo
On Fri, 5 Apr 2024 12:01:52 GMT, Nizar Benalla wrote: >> src/jdk.javadoc/share/classes/jdk/javadoc/doclet/Taglet.java line 99: >> >>> 97: * @implSpec This implementation returns the inverse >>> 98: * result to {@code isInlineTag}. >>> 99: * @since 15 >> >> Might as well insert a

Re: RFR: JDK-8329717 Missing `@since` tags in elements in DocumentationTool and Taglet [v2]

2024-04-05 Thread Pavel Rappo
On Fri, 5 Apr 2024 12:02:41 GMT, Nizar Benalla wrote: >> In this PR I added an `@since` tag to SNIPPET_PATH and isBlockTag() as they >> were added in later versions >> >> - SNIPPET_PATH was added in JDK 18 >> [here](https://github.com/openjdk/jdk/commit/0fc47e99d20a1ee886df878f1302769bdd913aab

Re: RFR: JDK-8329717 Missing `@since` tags in elements in DocumentationTool and Taglet

2024-04-05 Thread Pavel Rappo
On Fri, 5 Apr 2024 00:02:00 GMT, Nizar Benalla wrote: > In this PR I added an `@since` tag to SNIPPET_PATH and isBlockTag() as they > were added in later versions > > - SNIPPET_PATH was added in JDK 18 > [here](https://github.com/openjdk/jdk/commit/0fc47e99d20a1ee886df878f1302769bdd913aab#diff

Re: RFR: 8325088: Overloads that differ in type parameters may be lost [v4]

2024-04-04 Thread Pavel Rappo
On Thu, 4 Apr 2024 21:31:03 GMT, Jonathan Gibbons wrote: >> True, type parameters are not an issue for annotation interface methods, >> which [are not allowed to have any parameters][], type or otherwise. >> However, the code that prints annotations for method signatures does not >> know that

Re: RFR: 8325088: Overloads that differ in type parameters may be lost [v4]

2024-04-04 Thread Pavel Rappo
On Thu, 4 Apr 2024 18:52:42 GMT, Jonathan Gibbons wrote: >> Pavel Rappo has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Respond to feedback > > src/jdk.javadoc/share/classes/jdk/javadoc

Re: RFR: 8325088: Overloads that differ in type parameters may be lost [v3]

2024-04-04 Thread Pavel Rappo
On Thu, 4 Apr 2024 13:53:57 GMT, Chen Liang wrote: >> The answer to your latter question is no. The id that will be assigned to >> that public method do depend on whether the private overload positioned >> before it is documented. You cannot do much about it with the current design >> of `Visi

Re: RFR: 8325088: Overloads that differ in type parameters may be lost [v3]

2024-04-04 Thread Pavel Rappo
On Wed, 3 Apr 2024 23:29:44 GMT, Chen Liang wrote: >> Pavel Rappo 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 11 addi

Re: RFR: 8325088: Overloads that differ in type parameters may be lost [v4]

2024-04-04 Thread Pavel Rappo
uivalent signatures in a class". Which means that for > any two constructors or methods the erasure of their signatures must differ, > or else it won't compile. > > The change is pretty straightforward, except for some test fallout that > required attention. > &

Re: RFR: 8325088: Overloads that differ in type parameters may be lost [v3]

2024-04-04 Thread Pavel Rappo
On Wed, 3 Apr 2024 23:19:29 GMT, Chen Liang wrote: >> Pavel Rappo 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 11 addi

Re: RFR: 8325088: Overloads that differ in type parameters may be lost [v3]

2024-04-04 Thread Pavel Rappo
On Wed, 3 Apr 2024 23:15:43 GMT, Chen Liang wrote: >> Pavel Rappo 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 11 addi

Re: RFR: 8325088: Overloads that differ in type parameters may be lost [v3]

2024-04-03 Thread Pavel Rappo
On Wed, 3 Apr 2024 18:14:39 GMT, Pavel Rappo wrote: >> Creating a link to a constructor or a method or comparing constructors or >> methods __does not__ factor in type parameters. When constructors or methods >> are overloaded and differ only in type parameters -- a

Re: RFR: 8325088: Overloads that differ in type parameters may be lost [v3]

2024-04-03 Thread Pavel Rappo
uivalent signatures in a class". Which means that for > any two constructors or methods the erasure of their signatures must differ, > or else it won't compile. > > The change is pretty straightforward, except for some test fallout that > required attention. > > [JLS

Re: RFR: 8325088: Overloads that differ in type parameters may be lost [v2]

2024-04-03 Thread Pavel Rappo
uivalent signatures in a class". Which means that for > any two constructors or methods the erasure of their signatures must differ, > or else it won't compile. > > The change is pretty straightforward, except for some test fallout that > required attention. > > [JLS

Re: RFR: 8325088: Overloads that differ in type parameters may be lost

2024-03-28 Thread Pavel Rappo
On Wed, 27 Mar 2024 21:56:48 GMT, Chen Liang wrote: >> Creating a link to a constructor or a method or comparing constructors or >> methods __does not__ factor in type parameters. When constructors or methods >> are overloaded and differ only in type parameters -- a situation which is >> absen

Re: RFR: 8325088: Overloads that differ in type parameters may be lost

2024-03-28 Thread Pavel Rappo
On Thu, 28 Mar 2024 17:03:46 GMT, Jonathan Gibbons wrote: > Some of us are in the privileged position of being at the bottom of the > software stack, and so we rarely if ever need to create documentation to > other libraries. That paragraph of mine (that you are likely replying to) was about t

Re: RFR: 8325088: Overloads that differ in type parameters may be lost

2024-03-28 Thread Pavel Rappo
On Wed, 27 Mar 2024 17:19:35 GMT, Pavel Rappo wrote: > Creating a link to a constructor or a method or comparing constructors or > methods __does not__ factor in type parameters. When constructors or methods > are overloaded and differ only in type parameters -- a situation which is

Re: RFR: JDK-8303689: javac -Xlint could/should report on "dangling" doc comments

2024-03-27 Thread Pavel Rappo
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

Re: RFR: JDK-8303689: javac -Xlint could/should report on "dangling" doc comments

2024-03-27 Thread Pavel Rappo
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

Re: RFR: JDK-8303689: javac -Xlint could/should report on "dangling" doc comments

2024-03-27 Thread Pavel Rappo
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

Re: RFR: 8325088: Overloads that differ in type parameters may be lost

2024-03-27 Thread Pavel Rappo
On Wed, 27 Mar 2024 17:19:35 GMT, Pavel Rappo wrote: > Creating a link to a constructor or a method or comparing constructors or > methods __does not__ factor in type parameters. When constructors or methods > are overloaded and differ only in type parameters -- a situation which is

RFR: 8325088: Overloads that differ in type parameters may be lost

2024-03-27 Thread Pavel Rappo
Creating a link to a constructor or a method or comparing constructors or methods __does not__ factor in type parameters. When constructors or methods are overloaded and differ only in type parameters -- a situation which is absent in JDK API, but present elsewhere -- that causes significant def

Integrated: 8297879: javadoc link to preview JEP 1000 has grouping character comma

2024-03-19 Thread Pavel Rappo
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 even

Re: RFR: 8297879: javadoc link to preview JEP 1000 has grouping character comma

2024-03-18 Thread Pavel Rappo
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 even

RFR: 8297879: javadoc link to preview JEP 1000 has grouping character comma

2024-03-18 Thread Pavel Rappo
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 ~

Re: RFR: 8327824: Type annotation placed on incorrect array nesting levels [v2]

2024-03-13 Thread Pavel Rappo
On Tue, 12 Mar 2024 22:06:35 GMT, Chen Liang wrote: >> Please review this patch that fixes placement of type annotations on array >> types in Javadoc output. This oversight seems to have existed since JDK 8 >> but was never noticed or reported. > > Chen Liang has updated the pull request with a

Re: RFR: JDK-8325874: Improve checkbox-based interface in summary pages

2024-03-13 Thread Pavel Rappo
On Wed, 13 Mar 2024 14:30:01 GMT, Hannes Wallnöfer wrote: > > if you check "all" and then uncheck something else, then "all" will remain > > selected. That is a confusing state. > > I agree, but I think the behavior of the checkbox is as it should be, and > it's the label that is slightly misl

Re: RFR: JDK-8325874: Improve checkbox-based interface in summary pages

2024-03-13 Thread Pavel Rappo
On Mon, 11 Mar 2024 13:37:54 GMT, Hannes Wallnöfer wrote: > Please review a change to improve the user experience and implementation for > the checkbox-based interface to selectively display content on API summary > pages: > > - Add a checkbox to toggle (select/unselect) all checkboxes in the

  1   2   3   4   5   >