suppress deprecation warnings over a narrow scope

[scabug]

Sometimes I'm forced to use a deprecated method. I need to filter these case by case, so that the warnings remain useful generally. I do appreciate these warnings and act on them when I can, but if my build output becomes overrun with warnings I can do nothing about, I will eventually just ignore them all.

I've open this but to clarify #1781

[scabug]

Imported From: https://issues.scala-lang.org/browse/SI-7934?orig=1
Reporter: Topher (topher.the.geek)
See #1781

[scabug]

@retronym said (edited on Oct 25, 2013 3:02:15 PM UTC):
One thing you can exploit is that deprecation warnings are not issued within deprecated methods/classes. So you can coral your usages of deprecated APIs behind a facade:

scala> @deprecated("", "") def foo = 0
foo: Int

scala> object Test { @deprecated("", "") class Coral { def fooForwarder = foo }; object Coral extends Coral }
defined object Test

scala> Test.Coral.fooForwarder
res1: Int = 0

[scabug]

@retronym said:
Marking as out-of-scope given this workaround.

[scabug]

Topher (topher.the.geek) said:
Sweet, the workaround helps. Thank you. I'll be using it, for now. However it's just begging me to file a bug "Hey, I can use a deprecated object without a warning being issued!" So now I think: a) that should be fixed, and b) this bug should be reopened.

[scabug]

@retronym said (edited on Oct 25, 2013 3:28:22 PM UTC):
The class is deprecated, not the object that extends it. Why didn't I get a deprecation warning when I extended it? Companions may circumvent deprecations.

[scabug]

Thayne (thayne) said:
I agree with Topher. This shouldn't be closed because there is a workaround that uses another bug.

[scabug]

Ben Hutchison (ben_hutchison) said:
+1. please reopen. The workaround isn't effective, just moves the problem to the next layer. If you have to call an deprecated API, you don't want deprecation noise in the compile output forever more.

[scabug]

Pedro Larroy said:
+1 please reopen

[scabug]

Devin Ben-Hur (dbenhur) said:
+1 Reopen. This is a terrible workaround.

[scabug]

Thayne (thayne) said (edited on Jun 26, 2015 6:32:23 PM UTC):
As has been pointed out, the workaround depends on behavior that I at least would consider a bug, and may be fixed at a later time. And without finer control it means that for code that has to use deprecated API's I can either use -Xfatal-warnings or -deprecation, but not both.

+1 reopening.

[scabug]

Thayne (thayne) said:
Also pull request 4544 hasn't been merged in yet, and the silencer plugin only allows you to silence all warnings, not just deprecation warnings.

[scabug]

Jonathan Word (Argoday) said:
+1 to reopen

This is a ridiculous workaround ... that behavior should be a bug .. and as far as I can tell doesn't work anymore (yay - bug fixed)

[scabug]

Nicolas F Rouquette (NicolasRouquette) said:
+1 Jason's trick is indeed clever; however, it is rather cumbersome for corralling calls to deprecated interface, class or constructor methods from a third-party library because one has to write different Scala code to call such deprecated methods so that we can compile with -deprecation and -Xfatal-warnings

[scabug]

Tomer Gabel (holograph) said:
If anyone still cares, the workaround doesn't appear to work with Scala 2.10... I'm out of ideas at this point, guess I'll have to selectively elide -Xfatal-warnings. This is actually a pretty stupid problem to have.

[scabug]

Tomer Gabel (holograph) said:
That isn't consistent with what I'm experiencing, even the first line gives a deprecation error:

> ++2.10.3
[info] Setting version to 2.10.3
[info] Reapplying settings...
[info] Set current project to root (in build file:/Users/tomerga/dev/accord/)
> show console::scalacOptions
[info] List(-language:reflectiveCalls, -feature, -deprecation, -unchecked, -Xfatal-warnings)
[success] Total time: 0 s, completed Jul 17, 2016 11:50:31 AM
> console
[info] Starting scala interpreter...
[info]
Welcome to Scala version 2.10.3 (Java HotSpot(TM) 64-Bit Server VM, Java 1.8.0_60).
Type in expressions to have them evaluated.
Type :help for more information.

scala> @deprecated("", "") def foo = 0
<console>:5: error: method foo is deprecated:
  lazy val $result = `foo`

[scabug]

Tomer Gabel (holograph) said:
Your comment is neither helpful nor pleasant. This isn't a shell/REPL issue, this is a Scala issue (unless you're implying that SBT isn't representative)?

If you want to see this in action, the Accord codebase has a branch that cross-compiles between 2.10.3 and 2.11.1 that showcases this issue.

[scabug]

@SethTisue said:
"guess I'll have to selectively elide -Xfatal-warnings" — yeah, I would (rather sadly) suggest making a subproject in sbt where -Xfatal-warnings is not used, and putting forwarders there. It's still a kludge, but you might decide you prefer build kludges to code kludges.

This is definitely a real problem; I'm sorry we weren't able to prioritize it for Scala 2.12.0.

As an aside, cross-compiling across major Scala versions can get pretty painful, for a variety of reasons. If you want cross-compiling and -Xfatal-warnings, I would expect trouble in many areas.

Tomer: Mr. Marki is known for his sometimes cryptic sense of humor, which can result in occasional misunderstandings (or simple incomprehension). I promise you he's helpful, pleasant, and a gentleman.

[scabug]

@SethTisue said:
Krzysztof Pado sketched a potential fix approach in https://groups.google.com/forum/#!topic/scala-internals/LsycMcEkXiA

[omervk]

Bumping this, hopefully out of oblivion. This requires me to give up -Xfatal-warnings, which is not a Good Thing To Do.

[pshirshov]

I would propose to implement fine-granular warning settings.

So, for each kind of a warning we should be able choose one of 3 possible alert levels, {IGNORE | WARN | FAIL}.

The only problem is how to identify warnings - there is no identifier parameter available in compiler logging method (c.warning(...), etc).

Actually we may implement two solutions (both of them may co-exist):

1. Add a "identifier" parameter into compiler to all the compiler logging methods. So we may provide identifiers like c.warning(123456, "message"), c.error(4567, "message")
2. Add missing parameters with a macro as a hash(file:line:character).

At the end we would be able to do smth like scalac -Y:warning:SC-XXXX:ignore -Y:warning:SC-XXXX:fail

This should be relatively easy to implement and it should significantly improve our experience.

Related topic: https://contributors.scala-lang.org/t/fine-granular-warnings-silencing/

[vn971]

@omervk The "silencer" plugin works for this I must say, specifically the (dangerous) part of it that disables warnings based on a pattern: https://github.com/ghik/silencer#global-regex-based-suppression

[aisven]

I just have the same problems. I am using -Xfatal-warnings and I have a library in which I have to deprecate a function, but I do not want to delete the unit tests for that function.

[lrytz]

I'm looking at scala/scala-dev#333 currently, too late for 2.13.1, but hopefully we'll get something for 2.13.2.

https://github.com/ghik/silencer was mentioned before, I can recommend you to give it a try.

[ashawley]

@sourcekick One workaround for tests that may or may not work for you, is to disable fatal warnings (or deprecations) in sbt.

scalacOptions in Test ~= (_ filterNot (_ == "-Xfatal-warnings"))

[SethTisue]

:squirrel: scala/scala#8373