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

[Arnaud Spiwack]

I'm in favour.

For the bikeshedding question, the mathematician in me believes that using
`WARNING [partial]` is more canonical. Except that there is the
`deprectations` category which is suppressed with `-Wno-deprecations` (the
proposal solves this in saying that `-Wno-deprecations` is actually an
alias for `-Wno-x-deprecations`, why not). Pragmatically, though, the more
I think about it, the more I'm favouring enforcing that the warning author
write `WARNING [x-partial]` (it is also permitted to write `[deprecations]`
without an x, which would avoid introducing `x-deprecations` gratuitously).
The explicitness here, I think, helps. The warning category would _always_
be called `x-partial`. It's easier to process, easier to google. The cost
is tiny.

As to the other question: we probably shouldn't permit warnings to join
other warning categories: they are documented in the user guide, and having
one of these warnings trigger for another reason can be potentially quite
confusing. Not every category anyway. Maybe we will find some that can be
sensibly extended. Forcing `WARNING [x-partial]` allows us to whitelist
categories that can be extended with custom warnings.

I don't think that the other alternatives in the proposal need to be
addressed at this point (if anything, I think they are better addressed
when we have more information on how people actually use these new
categories, instead of just guessing what the pain points will be).

/Arnaud

On Wed, 16 Nov 2022 at 20:16, 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20221117/2b4f52fa/attachment-0001.html>