Custom warning suppression

Elliot Cameron eacameron at gmail.com
Wed Sep 7 18:36:59 UTC 2016


I would love this. Especially if we then added "partial" warnings to the
many Prelude/base functions that fit this description.

On Wed, Sep 7, 2016 at 11:09 AM, Richard Eisenberg <rae at cs.brynmawr.edu>
wrote:

> Seems reasonable and useful to me. Is this a good use of the process here?
> https://github.com/ghc-proposals/ghc-proposals
>
> On Sep 7, 2016, at 10: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
>
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160907/9e16f6b1/attachment-0001.html>


More information about the ghc-devs mailing list