Is it possible to consider deprecation warnings not fatal when -Xfatal-warnings is on?

[Eax Melanhovich]

Hello.

We are building our project with -Xfatal-warnings
and -deprecation:false flags. Scala version is 2.11.6. It would be nice
to see deprecation warnings, but in this case project would not compile
because of -Xfatal-warnings flag. It's doubtful we will fix deprecation
warnings in near future but we would like to be aware of them.

Is it possible to consider deprecation warnings not fatal somehow? A
solution was found in Google:

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

... but it seems that there is no -Yinline-warnings flag in
Scala anymore.

--
Best regards,
Eax Melanhovich
http://eax.me/

[Eax Melanhovich]

Well, I said something stupid about -Yinline-warnings - sorry for
that :)

Actually my question is if it possible to solve a task using only
scalac flags, without putting any additional code to build.scala.

[Som Snytt]

Not really. Not yet.

Providing a custom "reporter" is supposed to be supported at some point. (It's just a var, so it could be done in code.)

It looks like the "API" would be for your reporter to override hasWarnings to account for deprecations detected by a custom warning method. (You'd count deprecations by checking the message strings.)

It seems to me that this use case is an argument for pushing your deprecation checking out to a separate tool, like Abide or some other checker.

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

[Roman Janusz]

Here's my attempt for general annotation-based warning suppression:

https://github.com/ghik/silencer

[Som Snytt]

I just coded up an option so you can say -Xreporter MyReporter. Maybe they'll take it, so your Reporter would be easier to set up. I wonder if then a macro could just inspect enclosing contexts looking for an annotation to suppress?

That makes this work for the limited use case:

class MyReporter(ss: Settings) extends ConsoleReporter(ss) {
  var deprecationCount = 0
  override def warning(pos: Position, msg: String): Unit = {
    if (msg contains "is deprecated") deprecationCount += 1
    super.warning(pos, msg)
  }
  override def hasWarnings: Boolean = count(WARNING) - deprecationCount > 0
}

Maybe it has to override reset or something, too.

My other idea was a macro to generate the "deprecated module" trick around deprecated call sites. That would be true hackery, of course. And doesn't address this use case of wanting to see the deprecation warnings but not count toward the fatal warnings budget.

[Roman Janusz]

The problem with warning suppression is that they can be emitted by pre-typer compiler phases where macros have not yet been expanded and type information is not available. My plugin addresses this by implementing a reporter which defers these warnings and emits them only after typer phase is done. This is also needed because the plugin looks around for annotations, which need to be typechecked. This approach generally seems to work as long as there isn't any piece of code that wants to inspect emitted warnings before typechecking is done (e.g. some macro).

Also, another annoying thing with annotation-based approach is that we have no full position information (range positions), so we need to "approximate" them somehow based on offset positions.

[Som Snytt]

Yes, that's interesting. A message is emitted at a position, but it doesn't tell you who was the emitter and what tree they were looking at. ("Run again with -Xprint:typer.")

The ticket https://issues.scala-lang.org/browse/SI-9350 is just a quickie. What if I'm writing errors to my code quality database? I mean my coder quality db. I need a dispose or finish method, which would also be a hook for ConsoleReporter to printSummary.