Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[draft] initial implementation of emitting warnings for unneeded suppressions #4828

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

msridhar
Copy link
Contributor

@msridhar msridhar commented Feb 18, 2025

See #886. This change requires various cleanups, better naming, documentation, etc., and it doesn't handle all cases, but I wanted to post it to get feedback on whether this approach seems reasonable or needs to be reworked in some way.

For the most part this PR piggybacks on the extant tracking of which suppressions are active and when checkers are being suppressed. If a warning would be emitted by a checker and there is an active suppression of that warning, the suppression is marked as "used." Then, in Scanner, warnings are emitted for unused suppressions when restoring the old suppression information. Custom suppression annotations are not yet handled. Also we don't yet report the warning on the proper @SuppressWarnings annotation directly and support auto-fixing.

The main complication is that checkers may discover and use suppression information in ways that are hard to automatically detect. E.g., see this logic in UngroupedOverloads; NullAway also has such custom logic. If these uses of suppression annotations are not detected, it will lead to suppressions falsely being reported as unused. To avoid that, for now checkers need to opt in to supporting unused warning suppression checking. I opted in JdkObsolete as an example, as it does not seem to have any non-standard checking of suppressions. If this approach makes sense, maybe we can find a way to automatically opt in more checkers in the future (or just do so by hand). I also added an API to enable checkers to expose their custom uses of suppressions, and made some initial use of it in this WIP NullAway change.

If this approach looks reasonable / acceptable I'll clean up the changes and make them ready for a proper review. FYI @cushon @cpovirk

@msridhar msridhar force-pushed the warn-on-unneeded-suppressions branch 4 times, most recently from 8d72751 to 5d5f2e2 Compare February 26, 2025 04:33
@msridhar msridhar force-pushed the warn-on-unneeded-suppressions branch 3 times, most recently from 742faef to 5911eb6 Compare February 27, 2025 19:53
@msridhar msridhar force-pushed the warn-on-unneeded-suppressions branch from 5911eb6 to c87f5b2 Compare March 5, 2025 19:59
@msridhar
Copy link
Contributor Author

msridhar commented Mar 5, 2025

@cushon was curious if you had any thoughts on this approach and whether it's acceptable. Happy to do more cleanup if you feel it's needed before you can take a quick-ish look. And I do intend to implement proper support for auto-fix before requesting a proper review.

@msridhar msridhar force-pushed the warn-on-unneeded-suppressions branch 2 times, most recently from 2722d36 to c7d1740 Compare March 10, 2025 16:07
@msridhar msridhar force-pushed the warn-on-unneeded-suppressions branch from c7d1740 to c164b86 Compare March 13, 2025 18:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant