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. > The ability to use "suppression" itself as a category seems to be an handy > escape hatch. That said, for folks enabling "suppression" in their > compilation units, this _could_ mean some adjustments to the code base before > they can fully take advantage of this. Not saying this is a blocker. Agreed. The most important thing is that the design is sound (and I stand by the statement that it is). However it's a fair second-order question to then ask: "Is this going to mean adding a bunch of tedious new `@SuppressWarnings("suppression")` annotations to my code?" A few thoughts on that question... [ Aside: I admit I was suprised after `"this-escape"` was added how many warnings appeared in my code. But in my mind, that's OK - passing `-Xlint:all` with no exceptions is supposed to be a high standard. ] First of all, if you are only using one compiler, then zero `@SuppressWarnings("suppression")` annotations should be needed. Instead, eliminate the unnecessary suppressions that are being identified for you and enjoy your new, cleaner code base :) Otherwise, you will only need `@SuppressWarnings("suppression")` in cases where the two compilers warn differently about the same code. This is not a scenario I have a lot of experience with, but at least we can make the following observation: you will not need to add any more `"suppression"`'s suppressions than you have already added `"serial"` (or whatever) suppressions. So the magnitude of the change is linear in the magnitude of the changes you've already had to do to deal with those original warnings. Moreover, you would only have to do this for warnings where the compilers behave differently with respect to `"suppression"`. For those cases where the compilers behave the same, your code just gets cleaner because the fix is to remove the `"serial"` (or whatever) suppression that was unnecessary in the first place. Finally, if all else fails, there is `-Xlint:-suppression` as a last resort - as there is with any other category. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25167#issuecomment-4290692069
