8350514: Refactor MandatoryWarningHandler to support dynamic verbosity #23730
+35
−46
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR is a sub-task split off from JDK-8224228, which seeks to add
@SuppressWarnings
support for lexical features.The
MandatoryWarningHandler
is used by thepreview
,deprecation
,removal
, andunchecked
mandatory warnings. The constructor takes a booleanverbose
flag which is documented to "Specify whether or not detailed messages about individual instances should be given, or whether an aggregate message should be generated at the end of the compilation."The problem is that this flag doesn't really make sense for warnings that are suppressible via
@SuppressWarnings
: for such warnings, what we actually want to do is trigger the aggregate message at the end of compilation if and only if there were any warnings that were not suppressed by@SuppressWarnings
but were suppressed because the corresponding lint category was not enabled, either because it wasn't enabled by default, or due to an explicit-Xlint:-foo
flag.Currently, we get that same net result, because
preview
is not suppressible via@SuppressWarnings
, and for the other three categories there is logic around the calls toMandatoryWarningHandler.report()
to ensure the right thing happens.It would be simpler and more straightforward for the users of
MandatoryWarningHandler
to just pass along the currently applicableLint
instance and letMandatoryWarningHandler
keep track of whether to generate the aggregate message at the end of the compilation.Progress
Issue
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/23730/head:pull/23730
$ git checkout pull/23730
Update a local copy of the PR:
$ git checkout pull/23730
$ git pull https://git.openjdk.org/jdk.git pull/23730/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 23730
View PR using the GUI difftool:
$ git pr show -t 23730
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/23730.diff
Using Webrev
Link to Webrev Comment