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

Suppress/grandfather existing warnings #3163

Open
nakulj opened this issue Apr 29, 2022 · 4 comments
Open

Suppress/grandfather existing warnings #3163

nakulj opened this issue Apr 29, 2022 · 4 comments

Comments

@nakulj
Copy link

nakulj commented Apr 29, 2022

Adding errorprone to a new codebase is currently quite tedious as it complains about all the existing issues.
In an ideal world, this means that we should go back and fix all of them, but this is usually infeasible :)

It would be nice if we could use Refaster to just automatically add suppression decorations to existing issues.

@cushon
Copy link
Collaborator

cushon commented May 13, 2024

One variation on this (which is similar to a workflow we use at Google) is to emit the diagnostics, and then have a separate tool that can add @SuppressWarnings for a collection of diagnostics. #3766 could be helpful for that, although only the the path and line number is needed for a particular diagnostic, which is fairly straightforward to scrape from the text of the build log.

@nakulj
Copy link
Author

nakulj commented May 13, 2024

Hmm, I agree that line numbers would be fairly easy to scrape out. But is the start of the offending line always the best place for a suppression annotation? (Genuinely asking, I would think no but I’m unsure)

@cushon
Copy link
Collaborator

cushon commented May 13, 2024

The annotation is only valid on declarations of variables, methods, and classes. The separate tool we use parses the file and then looks at the syntax tree to find the closes valid location for a particular line.

@nakulj
Copy link
Author

nakulj commented May 13, 2024

Ooh, would love to see that in the open if Google is amenable to it!

Alternatively… errorprone could read CSV of filenames/linenumbers/error types to ignore. That would be more brittle, but I think in this case that would actually be a good thing— anyone who touches the file would be forced to at least consider improving it.

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

No branches or pull requests

2 participants