Re: Compiler plugin for warning suppression

Maybe it could use a mechanism like that for language feature imports?

On Wed, Apr 15, 2015, 3:44 PM Som Snytt <[email protected]> wrote:

> I think there was a conceptual difference between a scoped
> SuppressWarning("unchecked") and a more selective filter on the reporter.
>
> But I haven't seen what that difference might look like, and how you
> express what to suppress.
>
> There's probably an argument to be made that suppression should not be
> block-scoped, but more selective, and the "filter language" should require
> a fine-grained selection.
>
> The impetus is to avoid inadvertent suppression.
>
>
> On Wed, Apr 15, 2015 at 12:19 PM, Haoyi Li <[email protected]> wrote:
>
>> We should definitely push for this to be a thing.
>>
>> Ironically, adding a way to suppress fatal warnings lets you make your
>> compiler *more strict*, since the standard for making warnings fatal
>> changes from
>>
>> "zero false positives"
>>
>> to
>>
>> "n false positives, where n is small enough it wouldn't be too annoying
>> to add explanations for each one"
>>
>> At work we have all sorts of fatal warnings turned on in our
>> python/coffee codebases and we wouldn't have been able to turn any of them
>> on if not for a way to suppress the handful of cases where the weird code
>> was justified
>>
>> On Wed, Apr 15, 2015 at 11:56 AM, Roman Janusz <[email protected]>
>> wrote:
>>
>>> I'm really happy to see that Scala is open for that feature. From
>>> various discussions I kind of deduced that warning suppression is
>>> considered bad and that's why it isn't there.
>>> I will try to dig a bit into the compiler and see what I can do, but it
>>> seems to me that native implementation would have to be done differently
>>> than what's currently in the plugin.
>>>
>>> W dniu środa, 15 kwietnia 2015 00:24:43 UTC+2 użytkownik Adriaan Moors
>>> napisał:
>>>>
>>>> Awesome -- I'm really glad you picked this up!
>>>>
>>>> We're actually in favor of making reporting configurable (that "won't
>>>> fix" ticket is a bit overloaded). I actually refactored quite a bit of
>>>> code <http://11bfa25e37> to enable this a while ago, but didn't get
>>>> around to implementing the user-facing part.
>>>>
>>>> If you're willing to do the work, I'd be happy to merge this plugin
>>>> into the standard 2.11.x compiler (albeit under a -Xreporter switch).
>>>> Ideally, we should SIP a reporting configuration mechanism for 2.12.
>>>>
>>>> thank you!
>>>> adriaan
>>>>
>>>> On Tue, Apr 14, 2015 at 2:46 PM, Roman Janusz <[email protected]>
>>>> wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> Recently, inspired by the Towards a Safer Scala
>>>>> <http://confreaks.tv/videos/pnws2014-towards-a-safer-scala> talk from
>>>>> this year's ScalaDays, I wanted to try out the set of scalac options
>>>>> recommended by the speaker:
>>>>>
>>>>> scalacOptions ++= Seq(
>>>>>   "-Xlint",
>>>>>   "-Xdeprecation",
>>>>>   "-Xfatal-warnings"
>>>>> )
>>>>>
>>>>> Unfortunately, almost immediately I ran into a show-stopper: Scala has
>>>>> no warning suppression similar to Java's @SuppressWarnings. I googled
>>>>> around and unpleasantly found out that requests for this feature have been
>>>>> rejected. See for example SI-1781
>>>>> <https://issues.scala-lang.org/browse/SI-1781>.
>>>>>
>>>>> But I realized that writing a compiler plugin which could fill that
>>>>> gap would not be that hard.
>>>>>
>>>>> So here it is:
>>>>>
>>>>> *silencer <https://github.com/ghik/silencer>*It would be nice to have
>>>>> some feedback from you, Scala users, to see if there is any interest in
>>>>> maintaining such plugin. The current proof-of-concept implementation is
>>>>> really simple and small, but uses internal scalac API, so I guess there's
>>>>> no guarantee that it won't break with some new Scala version. That is also
>>>>> why I think some community support would help a lot.
>>>>>
>>>>> Cheers,
>>>>> Roman
>>>>>
>>>>> --
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "scala-language" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>>> an email to [email protected].
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>
>>>>
>>>>  --
>>> You received this message because you are subscribed to the Google
>>> Groups "scala-language" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to [email protected].
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>  --
>> You received this message because you are subscribed to the Google Groups
>> "scala-language" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [email protected].
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>  --
> You received this message because you are subscribed to the Google Groups
> "scala-language" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "scala-language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.