Proposal: Warnings for unnecessary warning suppression

[Maurizio Cimadamore]

Hi Archie,
my 0.02$ below:

On 07/05/2025 19:26, Archie Cobbs wrote:
> I'd like to restart this discussion of JDK-8344159 
> <https://bugs.openjdk.org/browse/JDK-8344159>  - "Add lint warnings 
> for unnecessary warning suppression"
>
> Note, this is likely not destined for JDK 25. I'm bringing it up now 
> simply because some refactoring that arose from the previous 
> discussion back in November (which is here 
> <https://mail.openjdk.org/pipermail/compiler-dev/2024-November/028573.html>) 
> is now mostly done.
>
> I think a fair summary of the current state is: Having the compiler 
> emit warnings for unnecessary warning suppression is considered a 
> useful idea in principle, but it's unclear what is the best way to 
> configure/enable that functionality in the compiler.
>
> In particular, there are subtle corner cases that could be problematic 
> if these warnings were enabled by -Xlint:all, especially for -Werror 
> builds.

IMHO, this is a problem present with the addition of every new lint 
warning. It's not specific to this one. Of course, some new lint warning 
operate on brand new language features, so the potential to compromise 
existing compilaton units is low. But I'd expect that warnings such as 
"serial" would have ran into similar corner cases (e.g. previously ok 
code started to report new warnings, and to fail with Werror).

So I think this seems ok, and not enough to cause a tweak to the 
treatment of lint:all.

I'll add here that a more robust fix for Werror issues is to enable 
developers to be more specific in the warnings they'd like to promote to 
errors (as discussed in the past). I'll CC Kevin who has always been a 
fan of this feature ;-)

>
> Also complicating things, there are two different ways to suppress 
> warnings, @SuppressWarnings("foo") and -Xlint:-foo and for similar 
> "corner case" reasons they need to be configurable separately.

IMHO, the main value of this new lint warning is to detect the use of 
`@SuppressWarnings` that are redundant. Sure there's the command-line 
flavor as well, but that renders any source code analysis dependent on 
the flags passed to javac. In other words, detecting redundant 
`@SuppressWarnings` has a more "timeless" nature that does not apply to 
detecting redundant command-line suppressions. The former tells you 
something about _your code_, in a way that is independent from which 
flags you use to compile it. Which is why I think we should only worry 
about that.

Maurizio

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20250509/50a53bc3/attachment-0001.htm>