[ghc-steering-committee] #451: WARNING pragma with category, Recommendation: accept

[Richard Eisenberg]

I'm strongly in favor of this proposal, and I think that would remain true regardless of the shed colors.

But to share some color preferences: I think the x- should be in the warning pragma, as currently written on GitHub. I also think we will soon want to be able to put the warnings into various bins (e.g. Wcompat, which seems very very useful for library writers for the same reasons it's useful for GHC itself). But there's nothing stopping us from expanding this syntax later, e.g. {-# WARNING [x-furble at compat] ... #-} or some such, and maybe it's better to gain experience before overengineering.

Richard

> On Nov 16, 2022, at 2:16 PM, Joachim Breitner <mail at joachim-breitner.de> wrote:
> 
> Dear all,
> 
> Adam has submitted “WARNING pragmas with categories” for committee
> consideration:
> https://github.com/ghc-proposals/ghc-proposals/pull/541
> https://github.com/adamgundry/ghc-proposals/blob/warning-pragmas/proposals/0000-warning-pragmas-with-categories.rst
> 
> I’m shepherding that one myself.
> 
> WARNING pragmas can come with categories now:
>   {-# WARNING [partial] head "This is a partial function, …" #-}
> 
> so that one can sensible group them and allow the user to silence the
> warning (-Wno-x-partial) or make them errors (-Werror-x-partial), just
> like with the built-in warning categories.
> 
> No language pragma is required (presumably since we are already in a
> GHC-specific pragma).
> 
> These custom warnings categories need to be prefixed with `x-` on the
> command line to keep them separate from the built-in warnings. This is
> a decision where I am inviting the committee to bikeshed:
> * Do we really need a separator, or is it ok for library-defined 
>  warnings to join a built-in category?
> * Should it be used in syntax as well (WARNING [x-partial]) for easier 
>  predictability and later extension to other prefixes (see below)?
> 
> All these custom warning categories are part of the severity group
> -Wdefault (on by default, not errors). I expect we eventually want to
> give the programmer control over the severity (off by default, error by
> default, part of -Wcompat, etc…), but it’s not immediately clear what
> to do here, so we can add it latter (another optional field in the
> pragma, a separate pragma, a naming convention like xe-foo, or
> something else).
> Please complain if you think this needs to be addressed here.
> 
> Cheers,
> Joachim
> 
> 
> -- 
> Joachim Breitner
>  mail at joachim-breitner.de
>  http://www.joachim-breitner.de/
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee