Proposal: Warnings for unnecessary warning suppression

[Maurizio Cimadamore]

>
> OTOH a deeper refactoring would replace the LintCategory enum with 
> something more complicated in a tree-like hierarchy.
>
> Are there any concrete design thoughts on this yet?
We have no concrete design on this yet. But this is influenced by making 
Lint more pluggable. E.g. perhaps the families will be reflected in some 
sealed hierarchy that will be part of the JDK, something that programs 
can reason about.
> Dumb question: would adding a new compiler "step" be (roughly 
> speaking) as straightforward as adding CompileState.WARN and 
> doingsomething like this?
>
> - generate(desugar(flow(attribute(x))));
> + generate(desugar(warn(flow(attribute(x)))));
>
> As for consolidating all of the warning logic, I like that idea and 
> the potential ability to make warnings more pluggable. The refactoring 
> would be tedious but straightforward, at least for those warnings that 
> simply inspect the information already being gatheredby the compiler.

I believe having a new step consolidating the various logic is a good 
way to approach this. I suspect that, when doing this exercise, we will 
find commonalities between the various Linters, and maybe some abstract 
class, with some entry point will be the start of a more pluggable way 
to think about these problems (maybe this API will initially be 
javac-only, but when mature enough we can re-consider).

We should also look at what others have done in this space - most 
notably ErrorProne.

>
>
> Should I create issues for the following? Let me know your thoughts:
>
>   * Minor lint refactoring cleanups
>   * Add a new warn() compiler step after flow analysis
>       o ThisEscapeAnalyzer is a charter member
>   * Refactor to move lint warnings into the warn() step (umbrella)
>       o Add issues over time under this umbrella for migrating
>         existing warnings
>       o Depends on: Add new warn() step
>   * Umbrella issue for the @SuppressWarnings cleanup
>       o Existing cleanup issues go under here
>   * Suppression warnings (this proposal)
>       o Depends on: Add new warn() step
>       o Depends on: Umbrella issue for the @SuppressWarnings cleanup
>       o Depends on: Minor lint refactoring cleanups
>
Yep. Not sure whether this proposal depends on the @SuppressWarnings 
cleanup: in principle you could also add the analysis and disable it 
when building the JDK, and let the various components to be updated at 
their pace.

Maurizio

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20241111/c97eeec6/attachment.htm>