suppress unchecked warnings globally #1781
Comments
|
Imported From: https://issues.scala-lang.org/browse/SI-1781?orig=1 |
|
@odersky said: |
|
@stepancheg said: |
|
@dragos said: |
|
@paulp said: |
|
@adriaanm said: |
|
@paulp said: |
|
@adriaanm said (edited on Jul 4, 2012 9:25:22 AM UTC): So, I agree we should not emit warnings that cannot be fixed nor turned off in the first place, I don't think we should provide a way to turn off all unchecked warnings. So, yes, the right/hard approach shouldn't be a 'won't fix', but I don't even know who to assign this to right now. |
|
@paulp said: Here's the sanity test of everyone's position: why isn't -unchecked on by default? It sure as hell should be. There is no more frequently answered question than "why doesn't this match work", and the transcript almost always shows that nice ignorable "there were unchecked warnings." But to do that we have to make it easy for people to suppress them, because there is still no other way in some cases, and certainly there's no comparably aesthetic way in others. To be burying all of the unchecked warnings because we don't want people to bury some of them is the epitome of "we had to destroy the village in order to save it." |
|
Chris Fuller (cfuller) said: Some of us have the discipline to respect warnings for what they are and address them from code wherever possible. The reality is that this is not always possible. Projects generally have to consume external code either in the form of an API that they integrate with or third-party libraries that they consume, and where these break the rules (such as by marking a class as deprecated without providing a replacement yet or exposing raw types), your own code is forced to break them as well to interact with them. Not offering any way to acknowledge the situation and suppress it from the output seriously harms the signal-to-noise ratio, with the result that developers are eventually forced to ignore all warnings completely for their own sanity, because they have no way to distinguish warnings that are new and should be fixed immediately from those that are known and cannot currently be addressed. |
|
Bas van den Broek (basvandenbroek) said: |
|
@som-snytt said: scala> @deprecated("","") def f = 8
f: Int
scala> f
<console>:9: warning: method f is deprecated:
f
^
scala> object A {
| def a = {
| @deprecated("","") def _f = f
| _f
| }}
defined object A
scala> A.a
res1: Int = 8I've forgotten now whether that was a feature or a bug. I think a feature, because local defs are not API and therefore cannot be deprecated, so invoking them cannot warn. However, marking them deprecated says the call stack is polluted with deprecations thereafter, but you know what you're doing. It's the This came up again, in the context of wanting -Xfatal-warnings for only some warnings, or conversely, -Xfatal-warnings but with certain unavoidable warnings suppressed. |
|
Topher (topher.the.geek) said: For clarity, I've opened a new bug for that focused need: #7934. I'd suggest closing this bug as "Won't fix." That's a fine response to the request "suppress unchecked warnings globally." As for everyone who voted for this bug because they wanted "suppress deprecation warnings over a limited scope," I encourage you to head over to the new bug and vote for it. |
Currently, Scala supports suppressing unchecked warning only for single expression:
However, some classes (test cases, for example) tend to have many places where unchecked warnings arise. There should be a way to disable unchecked warnings for the whole class, like this:
or disable unchecked warnings for the whole compiler run:
The text was updated successfully, but these errors were encountered: