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. > I think there are two potential issues here: > > 1. a SW includes a warning not handled by javac (but handled by another > compiler, or IDE). Is the suppression then marked as redundant when compiling > with javac? > > 2. a SW category `Foo` includes N warnings in javac, but N + M warnings in > some other compiler/IDE. Say that none of the N javac warnings is detected -- > we will then proceed to claim this SW has redundant suppressions. But in some > other IDE/compiler this might not actually be the case. > > > Now, (1) is simpler to handle than (2) -- after all, we know which warnings > javac can handle and which it cannot -- so we might only restrict redundant > suppressions to the very categories handled by javac. Which, I think, it's > what > [e16ef3b](https://github.com/openjdk/jdk/commit/e16ef3bce55444e6c85fe788b248ba2f1bfe0e4c) > does. > > There's no such logic for (2) though. So, in a way, this PR assumes that SW > category definition is sort of fixed, and that other tools follow the same > classification as what's done in javac. I'm not 100% sure this is always the > case, but perhaps this is an area that @stephan-herrmann could help us assess? I'm glad you asked. The following quote from JLS has been on my mind many times ๐ > 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 tokens recognized by ecj are **documented** in https://help.eclipse.org/latest/index.jsp?topic=%2Forg.eclipse.jdt.doc.user%2Ftasks%2Ftask-suppress_warnings.htm&cp%3D1_3_8_2 As you can see, some categories are the same as with javac, there are categories unknown to javac and vice versa. Aside: _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, like in "module Warn about module system related issues.". I am sure the same holds also in the opposite direction. I'd be happy to clarify where I can, if asked._ When ecj encounters a `@SW` token which it doesn't know of, it reports: `Unsupported @SuppressWarnings("foo")`. Ecj has "always" (since 2008) reported `Unnecessary @SuppressWarnings("x")` (for known category "x"). But we never implemented suppression for this particular warning (except for the silence-all `@SuppressWarnings("all")`). Actually, some years ago we stumbled on a N + M kind problem even within ecj: 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). In these cases we already have the problem (2). We ended up with a clumsy (info) warning: "At least one of the problems in category 'x' is not analysed due to a compiler option being ignored". IOW, the set of detected warnings doesn't only depend on the compiler used, but also on the compiler *configuration*. Aside: _the topic of compiler configuration is complicated by the fact, that we have different granularity: in the IDE you have very fine grained control over problem categories and sub-categories, whereas the set of `@SW` tokens is kind of coarse grained. Finally, CLI options are somewhere in the middle of the former two._ As for coordination between compilers I don't think we will ever have the exact same set of analyses / warnings. To some degree a little competition to detect the most useful set of problems may actually be healthy for the community ๐ . Short of full equivalence we might, however, try to provide our compilers with a little knowledge about other compilers: * list of categories known to other compiler * list of categories where other compiler may detect more problems I might even remember some user asking for ways to make the list of known tokens configurable in the compiler preferences. I know that **many** users would be very happy if we found a solution for wrong reports of unnecessary suppression. This isn't even considering other flavors of the SuppressWarnings annotation itself. That's it from the top of my head. Feel free to ask if anything is unclear. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25167#issuecomment-4290572993
