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

[jonathan-gibbons]

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.

---

Progress

• Change must be properly reviewed (1 review required, with at least 1 Reviewer)
• Change requires CSR request JDK-8329137 to be approved
• Change must not contain extraneous whitespace
• Commit message must refer to an issue

Issues

• JDK-8303689: javac -Xlint could/should report on "dangling" doc comments (Enhancement - P4)
• JDK-8329137: javac -Xlint could/should report on "dangling" doc comments (CSR)

Reviewers

• Vicente Romero (@vicente-romero-oracle - Reviewer) ⚠️ Review applies to 39689a52
• Magnus Ihse Bursie (@magicus - Reviewer) ⚠️ Review applies to 3d6f1f95
• Phil Race (@prrace - Reviewer)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/18527/head:pull/18527
$ git checkout pull/18527

Update a local copy of the PR:
$ git checkout pull/18527
$ git pull https://git.openjdk.org/jdk.git pull/18527/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 18527

View PR using the GUI difftool:
$ git pr show -t 18527

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/18527.diff

Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back jjg! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk]

@jonathan-gibbons This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

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

Reviewed-by: vromero, ihse, prr

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 15 new commits pushed to the master branch:

• f3bb3e2: 8331153: JFR: Improve logging of jdk/jfr/api/consumer/filestream/TestOrdered.java
• 07facd0: 8330734: JFR: Re-engineer mirror class mechanism
• 0bf516f: 8330624: Inconsistent use of semicolon in the code snippet of java.io.Serializable javadoc
• d13e533: 8321014: RISC-V: C2 VectorLoadShuffle
• 8bbd725: 8331187: Optimize MethodTypeDesc and ClassDesc.ofDescriptor for primitive types
• 5e2ced4: 8327247: C2 uses up to 2GB of RAM to compile complex string concat in extreme cases
• 2b7176a: 8330625: Compilation memory statistic: prevent tearing of the final report
• e4ed7ce: 8331063: Some HttpClient tests don't report leaks
• cfd19f0: 8329850: [AIX] Allow loading of different members of same shared library archive
• ffd850f: 8309881: Qualified name of a type element depends on its origin (source vs class)
• ... and 5 more: https://git.openjdk.org/jdk/compare/1c238d43e81acf516297f26660059d0bab5b5b8a...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

[openjdk]

@jonathan-gibbons The following labels will be automatically applied to this pull request:

• build
• client
• compiler
• core-libs
• hotspot-jfr
• javadoc
• kulla
• serviceability

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing lists. If you would like to change these labels, use the /label pull request command.

[mlbridge]

Webrevs

• 09: Full - Incremental (48e8b0a2)
• 08: Full - Incremental (39689a52)
• 07: Full (16a265a2)
• 06: Full (1f576798)
• 05: Full (02efe566)
• 04: Full - Incremental (8ad8b818)
• 03: Full - Incremental (f3670e7a)
• 02: Full - Incremental (3f745431)
• 01: Full - Incremental (56d6dcac)
• 00: Full (3d6f1f95)

[pavelrappo]

Would this be the first lint -- not doclint -- warning related to comments, let alone doc comments?

[pavelrappo]

Javadoc changes look trivially good. I only note that the javadoc man page diff contains some unrelated changes.

[pavelrappo]

Typo?

Suggested change

	Within a source file, you may use suppress any warnings generated by
	Within a source file, you may suppress any warnings generated by

[jonathan-gibbons]

Thanks; I'll check/fix the underlying original.

[jonathan-gibbons]

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.

[vicente-romero-oracle]

lgtm

[magicus]

The build changes look okay.

Do you have any plan of going through all the Java modules and fixing the issues, or opening JBS issues to have them fixed? Or will these lint warnings remain disabled for the foreseeable future?

[jonathan-gibbons]

@magicus

The build changes look okay.

Do you have any plan of going through all the Java modules and fixing the issues, or opening JBS issues to have them fixed? Or will these lint warnings remain disabled for the foreseeable future?

The plan is to create an umbrella bug to clean up the individual modules. There is interest to clean up java.base, to keep that one free of any warnings, and I can see that the langtools modules will get cleaned up as well. It will be up to other component teams to decide if and when to clean up other parts of the system. Once this work has been integrated, it is relatively easy to enable the warnings for a module and to fix the ensuing issues. Since any changes "only" involve comments, it should be reasonably easy to fix them, unlike some pervasive other warnings, like this-escape.

[openjdk]

@jonathan-gibbons this pull request can not be integrated into master due to one or more merge conflicts. To resolve these merge conflicts and update this pull request you can run the following commands in the local repository for your personal fork:

git checkout 8303689.dangling-comments
git fetch https://git.openjdk.org/jdk.git master
git merge FETCH_HEAD
# resolve conflicts and follow the instructions given by git merge
git commit -m "Merge master"
git push

[vicente-romero-oracle]

looks good

[jonathan-gibbons]

/integrate

[openjdk]

Going to push as commit a920af2.
Since your change was applied there have been 15 commits pushed to the master branch:

• f3bb3e2: 8331153: JFR: Improve logging of jdk/jfr/api/consumer/filestream/TestOrdered.java
• 07facd0: 8330734: JFR: Re-engineer mirror class mechanism
• 0bf516f: 8330624: Inconsistent use of semicolon in the code snippet of java.io.Serializable javadoc
• d13e533: 8321014: RISC-V: C2 VectorLoadShuffle
• 8bbd725: 8331187: Optimize MethodTypeDesc and ClassDesc.ofDescriptor for primitive types
• 5e2ced4: 8327247: C2 uses up to 2GB of RAM to compile complex string concat in extreme cases
• 2b7176a: 8330625: Compilation memory statistic: prevent tearing of the final report
• e4ed7ce: 8331063: Some HttpClient tests don't report leaks
• cfd19f0: 8329850: [AIX] Allow loading of different members of same shared library archive
• ffd850f: 8309881: Qualified name of a type element depends on its origin (source vs class)
• ... and 5 more: https://git.openjdk.org/jdk/compare/1c238d43e81acf516297f26660059d0bab5b5b8a...master

Your commit was automatically rebased without conflicts.

[openjdk]

@jonathan-gibbons Pushed as commit a920af2.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.