Custom warning suppression

Richard Eisenberg rae at
Wed Sep 7 15:09:02 UTC 2016

Seems reasonable and useful to me. Is this a good use of the process here?

> On Sep 7, 2016, at 10:39 AM, David Feuer <david.feuer at> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the ghc-devs mailing list