Custom warning suppression

Michael Sloan mgsloan at gmail.com
Sat Sep 24 00:31:21 UTC 2016


Interesting ideas!

What if #1 was implemented as a new declaration type that is allowed
in where clauses?

f x = SomeConstant where { unused x }

For #2, I would love to have a general system for declaring new types
of warnings that come with a way to dispatch the specific warning.
So, picking some random new names for these:

{-# NEW_VALUE_WARNING partial "This function is partial, and so should
be used with care" #-}

{-# VALUE_WARNING partial unsafePerformIO #-}   -- Additional detail
text is optional!!

Lots of potential for bike shedding, a variety of choices in the
tradeoff between complexity and boilerplate.

On Wed, Sep 7, 2016 at 7:39 AM, David Feuer <david.feuer at gmail.com> wrote:
> Currently, the only way to suppress custom warnings and deprecations is with
> -fno-warn-warnings-deprecations, which is a rather large hammer. I see two
> ways we can improve this, and I propose that we should do both.
>
> 1. Per-binding suppression
>
> Add -fno-warn-binding, -fno-deprecate-binding, -fwarn-binding options, and
> -fdeprecate-binding options. These would take the (optionally qualified)
> name of a binding and control warnings tied to it. So if you invoked
> -fno-warn-binding "sillyFunction", then GHC would not warn you about the
> silliness of anything named sillyFunction. -fno-warn-binding
> "Data.Silly.sillyFunction" would limit the suppression to the silly function
> in Data.Silly. -fno-deprecate-binding would refrain from emitting
> deprecation warnings for the binding in question. -fno-deprecate-binding
> would presumably imply no-warn-binding, since someone who doesn't care that
> a function is going to be removed probably also doesn't care what else is
> wrong with it.
>
> 2. Named warning classes
>
> I'd like to add an optional "warning class" to the WARNING pragma, preceding
> the warning description. This would be a short string indicating what sort
> of warning is involved. This would be totally free-form, but the
> documentation would suggest a few conventional options such as "partial" and
> "slow". Then whole warning classes could be controlled with -fno-warn-class
> and -first-class.
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>


More information about the ghc-devs mailing list