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

Configurable error reporting #333

Open
adriaanm opened this Issue Mar 8, 2017 · 6 comments

Comments

Projects
None yet
6 participants
@adriaanm
Member

adriaanm commented Mar 8, 2017

For example, allow user to specify which warnings become errors, which ones are suppressed. Maybe deprecations of more than two major versions ago are errors, while more recent ones are just counted.

First stepping stone at: scala/scala#4544

@SethTisue

This comment has been minimized.

Show comment
Hide comment
@SethTisue

SethTisue Jun 6, 2017

Member

perhaps the right context to tackle this would be in association with backporting the structured-errors stuff form Dotty

Member

SethTisue commented Jun 6, 2017

perhaps the right context to tackle this would be in association with backporting the structured-errors stuff form Dotty

@olafurpg

This comment has been minimized.

Show comment
Hide comment
@olafurpg

olafurpg Jun 7, 2017

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)

olafurpg commented Jun 7, 2017

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)

@ShaneDelmore

This comment has been minimized.

Show comment
Hide comment
@ShaneDelmore

ShaneDelmore Jun 7, 2017

Unique identifiers would be appreciated for scala-clippy as well. Currently we are using regexes to try to determine the message type.

ShaneDelmore commented Jun 7, 2017

Unique identifiers would be appreciated for scala-clippy as well. Currently we are using regexes to try to determine the message type.

@pmpfr

This comment has been minimized.

Show comment
Hide comment
@pmpfr

pmpfr Nov 15, 2017

The other thing that is sorely lacking currently is a general escape hatch mechanism usable per-use-site, e.g. @SuppressWarnings(Seq(CompilerWarning.MissingInterpolator)). Currently people often have to globally disable useful warning because of a tiny number of false positives.

pmpfr commented Nov 15, 2017

The other thing that is sorely lacking currently is a general escape hatch mechanism usable per-use-site, e.g. @SuppressWarnings(Seq(CompilerWarning.MissingInterpolator)). Currently people often have to globally disable useful warning because of a tiny number of false positives.

@jvican

This comment has been minimized.

Show comment
Hide comment
@jvican

jvican Nov 16, 2017

Member

I think having @warnoff or @supressWarnings in the standard library would be very useful. Currently, linters are forced to use comments because if they used their own annotation that would add a runtime dependency on downstream users. This approach would be much extensible and elegant and could enable other tools to reuse them.

Member

jvican commented Nov 16, 2017

I think having @warnoff or @supressWarnings in the standard library would be very useful. Currently, linters are forced to use comments because if they used their own annotation that would add a runtime dependency on downstream users. This approach would be much extensible and elegant and could enable other tools to reuse them.

@pmpfr

This comment has been minimized.

Show comment
Hide comment
@pmpfr

pmpfr Nov 16, 2017

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, ...

pmpfr commented Nov 16, 2017

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, ...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment