59

I was wondering if scala had an equivalent to java's @SuppressWarnings that can be applied to a function or whatever to ignore any deprecation warnings[1] that function emits?

1: Relevant warning in my case is: method stop in class Thread is deprecated: see corresponding Javadoc for more information. I am aware of the problems with stop however there are still some cases where due to legacy code we have to use it.

Aaron Novstrup
  • 20,967
  • 7
  • 70
  • 108
BenjaminJackman
  • 1,439
  • 1
  • 10
  • 18
  • Good question! In my case, I compile with -Xmigration because it is useful when testing code found on Internet, and I get " – PhiLho Jul 20 '11 at 15:02

4 Answers4

30

No, and an enhancement request [1] for such a feature was closed as wontfix.

I agree it would be useful. I expect that the Scala core team aren't against the idea, but they have finite resources and many higher priorities.

update: this feature was eventually implemented in scala 2.13.2 release on 2020-04-22, see this answer

[1] https://issues.scala-lang.org/browse/SI-1781

dtech
  • 13,741
  • 11
  • 48
  • 73
retronym
  • 54,768
  • 12
  • 155
  • 168
  • 4
    That request was for an `@unchecked` annotation. The OP is concerned with deprecation warnings rather than unsafe cast warnings. – Aaron Novstrup Aug 17 '10 at 20:31
  • 1
    You're right. A comment on the ticket did suggest @SuppressWarnings("unchecked") http://lampsvn.epfl.ch/trac/scala/ticket/1781#comment:3 – retronym Aug 17 '10 at 21:08
  • 8
    A pity. Not being able to distinguish between good and bad warnings makes them pretty much useless in a big project's build report. – Jürgen Strobel Jan 09 '14 at 13:20
  • 1
    Ahem. There is no such thing as a "good" warning. A warning is a problem that doesn't kill you right now, but might kill you tomorrow. Just becasue Java is such a broken language, we got the very bad habit to ignore warnings. – Ichthyo Jan 17 '14 at 21:01
  • 40
    @Ichthyo What you say is nice in theory, but not true in practice. Warnings are here to give mere hints, and they are often *false positives*, even in Scala (otherwise they would be errors!). In case of a false positive, it would be better to add a comment as to why it is so, and disable it. Otherwise it pollutes the project report and make less visible the *genuine warnings* that may reveal *a real threat* to the safety of the program! – Lionel Parreaux Jul 25 '14 at 15:18
  • 13
    @Ichthyo I'm sorry if I offended you; wasn't my intention. I'm not sure what you mean by "obviously lacking the experience of a huge and long standing code base drowned in warnings". I did work on such projects (granted, not in Scala; it was C++). Removing those warnings (whether caused by real problems or not) was indeed a priority. I guess every project and associated policy is different anyway. My point was that in some contexts, it can be justified to hide particular warnings at particular place, to keep everything else simple and coherent – Lionel Parreaux Jul 26 '14 at 00:54
  • 2
    Though closed, it eventually got implemented, in time for Scala 2.13.2. – Daniel C. Sobral Apr 15 '20 at 23:23
  • I amended the answer for scala 2.13.2 since it's the first google result and accepted answer @DanielC.Sobral – dtech Aug 07 '20 at 10:17
27

EDIT: You should use @nowarn


There is a simple compiler plugin for this: silencer (a bit shameless plug)

ghik
  • 10,706
  • 1
  • 37
  • 50
18

Scala 2.13.2 provides @nowarn annotation developed on the basis of ghik's silencer, for example

import scala.annotation.nowarn
def t = { 0: @nowarn; 1 }

raises no warnings, whilst

def t = { 0; 1 }

gives

warning: a pure expression does nothing in statement position; multiline expressions might require enclosing parentheses
  def t = { 0; 1 }
            ^
Mario Galic
  • 47,285
  • 6
  • 56
  • 98
  • @DanielC.Sobral Seems it was [renamed](https://github.com/scala/scala/pull/8373#issuecomment-595211382) from `silent` to `nowarn` [here](https://github.com/scala/scala/commit/0dce86940af26ca838df5aa7cf8b9490cacc5947). – Mario Galic Apr 15 '20 at 23:54
  • Full usage it available in `scalac -Wconf:help` – dtech Aug 07 '20 at 10:18
-2

Here is how to suppress all warnings in sbt:

import sbt._
import Keys._
import KeyRanks.DTask
import xsbti.{Reporter, Problem, Position, Severity}

private lazy val compilerReporter = TaskKey[xsbti.Reporter](
  "compilerReporter",
  "Experimental hook to listen (or send) compilation failure messages.",
  DTask
)

val ignoreWarnings = Seq(
  compilerReporter in (Compile, compile) :=
    new xsbti.Reporter {
      private val buffer = collection.mutable.ArrayBuffer.empty[Problem]
      def reset(): Unit = buffer.clear()
      def hasErrors: Boolean = buffer.exists(_.severity == Severity.Error)
      def hasWarnings: Boolean = buffer.exists(_.severity == Severity.Warn)
      def printSummary(): Unit = {

        print("\033c")
        if (problems.nonEmpty) {
          problems.foreach{ p =>
            println("=====================================================")
            println(p.position)
            println(p.message)
            println()
            println()
          }
        }
      }
      def problems: Array[Problem] = buffer.toArray

      def log(problem: Problem): Unit = {
        if (problem.severity == Severity.Error) {
          buffer.append(problem)
        }
      }
      def log(pos: Position, msg: String, sev: Severity): Unit = {
        log(new Problem {
          def category: String = "foo"
          def severity: Severity = sev
          def message: String = msg
          def position: Position = pos
        })
      }
      def comment(pos: xsbti.Position, msg: String): Unit = ()
    }
)
Guillaume Massé
  • 8,004
  • 8
  • 44
  • 57