Configurable and suppressable warnings #333
Broken Windows Theory: clean codebases that keep warnings under control encourage to keep the codebase clean.
This proposal has two goals: make warnings globally configurable using compiler flags, and allow suppressing warnings locally.
What we have today
Considerations for new functionality
Global Configuration: allow users to configure what is reported as error, warning, info, or not at all.
Managing many errors/warnings
Links, Discussions, WIPs
Better warning & error messages (considered out of scope / separate proposal)
Rough Syntax Proposal
Syntax needs to be clarified and probably made less ambiguous, so far i only thought about categories, filters and severities.
Note: this only configures how warnings are emitted.
First matching rule wins
Relation to existing functionality
The text was updated successfully, but these errors were encountered:
This would be useful for tools like scalafix. In particular, it would be useful to have the ability override the severity level per message kind, despite presence of -Xfatal-warnings. It would also be useful to have unique identifiers attached to each reported message (cc/ scalameta/scalameta#924)
The other thing that is sorely lacking currently is a general escape hatch mechanism usable per-use-site, e.g.
I think having
Agree. Wartremover uses @SuppressWarnings rather than comments, but only because it has to implement that itself. scalastyle uses comments, as you say, and it's very fragile/dangerous. It would be amazing if there was a single annotation where you could specify the particular warnings to silence, and it was respected by scalac, scalafix linters, wartremover, ...