-
Notifications
You must be signed in to change notification settings - Fork 749
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
Option to mark warnings as errors #424
Comments
This sounds like a good idea to me. We've also received requests for a flag to enable all checks as warnings (even if they're errors by default) in order to collect the full list of diagnostics for a codebase. I imagine the implementation of the two flags would be very similar. |
@cushon wasn't this implemented the other way around meaning that you can downgrade errors to warnings but not the other way around? |
Is it implemented? |
@emartynov Not yet, sadly. :( I think @cushon mistakenly closed this issue when he implemented the option to convert all errors to warnings, rather than an option for converting all warnings to errors. |
Thanks! Would be nice to re-open it :) |
Indeed! :) But alas I'm not a Googler, so I don't have permissions to reopen this issue. @cushon WDYT? |
Agreed this should be re-opened, but I'm curious about the downsides of |
We have one warning about using deprecated API and it will break the build now. I don't know if I would want to mix deprecation and error-prone warnings. But probably, any warning should be caught and fixed as soon as possible. |
Can you use |
I'd love an option to mark error prone warnings as errors so that even warnings won't get ignored.
While it is possible to do the following:
it does not really suffice since all warnings are then marked as errors. Another option would be for every error prone rule to increase the severity though this will get impossible to maintain.
Maybe it could be something as simple as
-Xep:WarningsAsErrors
.The text was updated successfully, but these errors were encountered: