Skip to content

suppress deprecation warnings over a narrow scope #7934

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

Closed
scabug opened this issue Oct 25, 2013 · 25 comments
Closed

suppress deprecation warnings over a narrow scope #7934

scabug opened this issue Oct 25, 2013 · 25 comments
Assignees
Milestone

Comments

@scabug
Copy link

scabug commented Oct 25, 2013

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
Copy link
Author

scabug commented Oct 25, 2013

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

@scabug
Copy link
Author

scabug commented Oct 25, 2013

@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
Copy link
Author

scabug commented Oct 25, 2013

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

@scabug
Copy link
Author

scabug commented Oct 25, 2013

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
Copy link
Author

scabug commented Oct 25, 2013

@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
Copy link
Author

scabug commented Dec 6, 2014

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

@scabug
Copy link
Author

scabug commented May 17, 2015

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
Copy link
Author

scabug commented May 22, 2015

Pedro Larroy said:
+1 please reopen

@scabug
Copy link
Author

scabug commented Jun 26, 2015

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

@scabug
Copy link
Author

scabug commented Jun 26, 2015

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
Copy link
Author

scabug commented Jun 26, 2015

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
Copy link
Author

scabug commented Aug 13, 2015

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
Copy link
Author

scabug commented Sep 22, 2015

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
Copy link
Author

scabug commented Jul 13, 2016

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
Copy link
Author

scabug commented Jul 17, 2016

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
Copy link
Author

scabug commented Aug 3, 2016

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
Copy link
Author

scabug commented Aug 3, 2016

@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
Copy link
Author

scabug commented Aug 3, 2016

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

@omervk
Copy link

omervk commented Jul 30, 2017

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

@pshirshov
Copy link

pshirshov commented Oct 6, 2018

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
Copy link

vn971 commented Feb 13, 2019

@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
Copy link

aisven commented Aug 16, 2019

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
Copy link
Member

lrytz commented Aug 16, 2019

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
Copy link
Member

@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 SethTisue modified the milestones: Backlog, 2.13.2 Mar 9, 2020
@SethTisue
Copy link
Member

:squirrel: scala/scala#8373

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

No branches or pull requests

9 participants