On Sun, 19 Apr 2026 21:22:55 GMT, Archie Cobbs <[email protected]> wrote:
>> This PR adds a new compiler warning for `@SuppressWarnings` annotations that >> don't actually suppress any warnings. >> >> Summary of code changes: >> >> * Add new warning and associated lint category `"suppression"` >> * Update `LintMapper` to keep track of which `@SuppressWarnings` >> suppressions have been validated ¹ >> * Update `Log.warning()` so it validates any current suppression of the >> warning's lint category in effect. >> * Add a new `validate` parameter to `Lint.isEnabled()` and >> `Lint.isSuppressed()` that specifies whether to also validate any current >> suppression. >> * Add `Lint.isActive()` to check whether a category is enabled _or_ >> suppression of the category is being tracked - in other words, whether the >> warning calculation needs to be performed. Used for non-trivial warning >> calculations. >> * Add `-Xlint:-suppression` flags to `*.gmk` build files so the build >> doesn't break >> >> ¹ The suppression of a lint category is "validated" as soon as it suppresses >> some warning in that category >> >> --------- >> - [x] I confirm that I make this contribution in accordance with the >> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). > > Archie Cobbs has updated the pull request incrementally with one additional > commit since the last revision: > > Add test to verfiy compiler ignores unknown categories per review > suggestion. > Compiler vendors are encouraged to document the strings they support for > @SuppressWarnings, and to cooperate to ensure that the same strings are > recognized across multiple compilers. The `javac` list is [here](https://docs.oracle.com/en/java/javase/25/docs/specs/man/javac.html#option-Xlint-custom). Somewhat obscured but not completely :) > In the past I had looked at some of javac's categories, but just from the > help text I was unable to infer what exactly was analyzed These days the lint category is specified in the same place as the text of the warning (i.e., in the [properties file](https://github.com/openjdk/jdk/blob/97ccabb28e7ae81765a84b98ad418e0b7b87a505/src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties#L1958-L1961)). Look for comments like `lint: module` above each entry. > When ecj encounters a `@SW` token which it doesn't know of, it reports: > `Unsupported @SuppressWarnings("foo")`. Hmm, depending on how you read it, that could be considered a violation of §9.6.4.5: _A Java compiler must ignore any such string that it does not recognize._ > Many warnings aren't even computed if the corresponding option is disabled. > So we face situations where ecj knows about absence of N but might have > report M, but M is not analyzed (option disabled). FWIW this implementation avoids that scenario, by calculating warnings in a blob of code if the warning is enabled OR if the warnings is suppressible and unnecessary suppression detection is enabled. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25167#issuecomment-4290763468
