Compiler plugin for warning suppression

[Roman Janusz]

Hello,

Recently, inspired by the Towards a Safer Scala talk from this year's ScalaDays, I wanted to try out the set of scalac options recommended by the speaker:

scalacOptions ++= Seq(
  "-Xlint",
  "-Xdeprecation",  
  "-Xfatal-warnings"
)

Unfortunately, almost immediately I ran into a show-stopper: Scala has no warning suppression similar to Java's @SuppressWarnings. I googled around and unpleasantly found out that requests for this feature have been rejected. See for example SI-1781.

But I realized that writing a compiler plugin which could fill that gap would not be that hard.

So here it is: silencer

It would be nice to have some feedback from you, Scala users, to see if there is any interest in maintaining such plugin. The current proof-of-concept implementation is really simple and small, but uses internal scalac API, so I guess there's no guarantee that it won't break with some new Scala version. That is also why I think some community support would help a lot.

Cheers,
Roman

[Adriaan Moors]

Awesome -- I'm really glad you picked this up! 

We're actually in favor of making reporting configurable (that "won't fix" ticket is a bit overloaded). I actually refactored quite a bit of code to enable this a while ago, but didn't get around to implementing the user-facing part.

If you're willing to do the work, I'd be happy to merge this plugin into the standard 2.11.x compiler (albeit under a -Xreporter switch). Ideally, we should SIP a reporting configuration mechanism for 2.12.

thank you!

adriaan

--
You received this message because you are subscribed to the Google Groups "scala-language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-languag...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Adriaan Moors]

Sorry, copy/paste mistake in my link. The PR I meant to point to: https://github.com/scala/scala/pull/3820

[Sébastien Doeraene]

Hi,

Oh yes please!

Sébastien

[Eugene Burmako]

Some questions:

1) treeRangePos says "approximate". Is it possible to make it non-approximate?

2) Will this work with Scala IDE? Iirc it only runs up until typer and then stops compilation.

3) In general, what about extensibility? If an AnalyzerPlugin and/or MacroPlugin plugin wants to check whether there are warnings reported, how does it do that?

4) What do you think of per-file and per-project suppressions? 

[Roman Janusz]

1) treeRangePos simply computes range position based on all positions "seen" in the tree. This could potentially not catch some warnings issued for positions of trees which are already not present after typer. This should be easily fixable, though.
2) You're right, it probably doesn't work in presentation compiler. It would be nice to be able to declare that a PluginComponent which runs just after typer could be also invoked by the presentation compiler.
3) I assume you are referring to the fact that the plugin delays reporting of warnings until the typer phase is done. This is because it needs fully typechecked tree so that it can properly detect the @silent annotations. I was aware that this could potentially break something, but it seemed strange to me that some compiler code would rely on warnings like that. I did a quick search for hasWarnings in the compiler code and did not find anything. Anyway, this is one thing that I definitely wanted to ask here about, so thank you for bringing this up. I didn't know that AnalyzerPlugin and MacroPlugin exist.

The solution to both 2) and 3) would be to move the annotation detection before the typer, but I'm not sure how to do it at a phase where my annotations are not yet typechecked. I could do some hairy stuff like trying to resolve imports to @silent manually, but this is always going to be limited and incorrect in general case (although it would still be useful to me).

4) You mean to add a possibility to suppress warnings e.g. by using some magic import which would suppress warnings in entire file? Seems a little out of scope of what I needed and it can't be done with annotations, so currently I'd prefer to leave it as it is, i.e. fully annotation-based.

[Roman Janusz]

I'm really happy to see that Scala is open for that feature. From various discussions I kind of deduced that warning suppression is considered bad and that's why it isn't there.
I will try to dig a bit into the compiler and see what I can do, but it seems to me that native implementation would have to be done differently than what's currently in the plugin.

[Haoyi Li]

We should definitely push for this to be a thing. 

Ironically, adding a way to suppress fatal warnings lets you make your compiler more strict, since the standard for making warnings fatal changes from 

"zero false positives" 

to 

"n false positives, where n is small enough it wouldn't be too annoying to add explanations for each one" 

At work we have all sorts of fatal warnings turned on in our python/coffee codebases and we wouldn't have been able to turn any of them on if not for a way to suppress the handful of cases where the weird code was justified

[Som Snytt]

I think there was a conceptual difference between a scoped SuppressWarning("unchecked") and a more selective filter on the reporter.

But I haven't seen what that difference might look like, and how you express what to suppress.

There's probably an argument to be made that suppression should not be block-scoped, but more selective, and the "filter language" should require a fine-grained selection.

The impetus is to avoid inadvertent suppression.

[Naftoli Gugenheim]

Maybe it could use a mechanism like that for language feature imports?

[Som Snytt]

Related filtering ticket when looking for diverging implicits:

https://issues.scala-lang.org/browse/SI-8467

I realize the movie "Divergent" already explores this issue, but I haven't seen it. There are, likely, a cluster of filtering use cases with, possibly, a uniform solution.

I'd also like to see an option to collapse the indentation under -Ytyper-debug. Snippets of the output usual pertain to a small range, so it would be handy to cut/paste it without the extra-wide margin.

[Jon Pretty]

On Wed, 15 Apr 2015 at 21:00 Naftoli Gugenheim <nafto...@gmail.com> wrote:

Maybe it could use a mechanism like that for language feature imports?

+1

This would have the benefit of being able to scope the warning suppression to a package, file, class, method, or whatever, and would also make the determination of whether a warning is an error (or not) part of the source code.

This probably won't be possible with pre-typer warnings, though. I'm not sure what proportion of warnings are pre-typer, but it's not many.

Cheers,

Jon