I’m developing a plugin for the Scala compiler. My plugin adds semantics to constructs that the compiler currently warns about. I’m using the 2.10 compiler (yes, bleeding edge) and it warns about pure expressions “in statement position.” In particular when I do
class Example {
“Hello”
}
The naked string literal has no obvious effect and causes the compiler to produce a warning. In my case the plugin notices this construct and does extra special bonus things with it. What I’m looking for is a way to suppress the warning to reduce noise in my test suite (not to mention for plugin users).
I could probably come up with some other way to signal information to the plugin that would be better than this but for the moment I’d rather focus on other more fundamental issues. A quick way to turn off the warning for now would be great. Is there such a way?
Peter
Let me be very explicit about my motivation: the reason I want to *suppress* some warnings is that I *like* warnings and I want to hear them clearly. So I do not cede the "warning high ground" to the "no suppressing warnings" camp, any more than I think spammers love email more than the rest of us. Too much information is at least as great a threat to efficient compiler/human communication as is too little; greater for sure, in fact, because the quiet side is bounded by zero and the noisy side is unbounded.
Two nice examples of false positives from -unchecked:
Erasure allows to check that ss.isInstanceOf[Iterable[_]], but since Iterable is covariant, that implies ss.isInstanceOf[Iterable[Any]], hence the warning is bogus. I don't know the bug report for this.
[warn] case ArrayApply(x: Exp[Array[T]], i: Exp[Int]) =>
Note that this definition is not accepted, but I have no clue why. Not even this:def f[A](a: A): a.type = ???def f[A](a: A)(b: a.type) = ???is accepted - why? Do dependent method types not support singleton types?
We were just talking about this in another thread. Singleton is bounded by AnyRef. Jason suggested we make it universal, in which case the above would work. Failing that, this.scala> def f[A <: AnyRef](a: A): a.type = ???f: [A <: AnyRef](a: A)a.type
Anyway, trying to use & does not work:
scala> def f[T <: AnyRef](x: Exp[T]) = x match { case (y: ArrayApply[t]) & ArrayApply(x, i) => x }<console>:11: error: constructor cannot be instantiated to expected type;found : ArrayApply[T]required: <unapply-selector>.typedef f[T <: AnyRef](x: Exp[T]) = x match { case (y: ArrayApply[t]) & ArrayApply(x, i) => x }
Two nice examples of false positives from -unchecked:
I ran into this one yesterday. The warning isn't emitted in 2.10,
which is a bit of a shame, as it was a proxy for a seemingly absent type error.
Agreed; I was being whimsical.
The "scrutinee is incompatible with pattern type" error is only issued
if the scrutinee is a final type (final + invariant) [1].
On the same code but a different warning topic, it looks like there's
a missing unreachability warning here: as long as Seq <: List, the
second branch should be unreachable, shouldn't it?
And since I expect it will be your followup question, null is considered for unreachability but not for exhaustiveness checking. These are the reasonable behaviors, especially since "unreachable code" used to fail the compile (and I think it still should.)
scala> (new B) match {case A() => true}<console>:11: error: constructor cannot be instantiated to expected type;found : Arequired: B(new B) match {case A() => true}^
Note that no warning arises; Paul simply explained why the behavior is correct.On Sat, Jul 28, 2012 at 4:36 PM, Nils Kilden-Pedersen <nil...@gmail.com> wrote:
> On Sat, Jul 28, 2012 at 9:23 AM, Paul Phillips <pa...@improving.org> wrote:
>>
>>
>>
>> On Sat, Jul 28, 2012 at 7:20 AM, Paolo Giarrusso
>> <pgiar...@mathematik.uni-marburg.de> wrote:
>>>
>>> On the same code but a different warning topic, it looks like there's
>>> a missing unreachability warning here: as long as Seq <: List, the
>>> second branch should be unreachable, shouldn't it?
>>
>>
>> Nope, not a bug. There's a single value the first case doesn't cover.
>> Starts with "n" and ends with "ull..."
>>
>
> Shouldn't that only trigger with Xcheck-null enabled?