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

Simon Peyton Jones simon.peytonjones at gmail.com
Mon Nov 21 13:42:12 UTC 2022


>
> 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).
>

I'm still a bit baffled by the "x-" bit.  It just seems like extra noise.

Or is there an (entirely implicit) suggestion that eventually we might want
"y-"  and "z-" prefixes, for some y and z?

Simon

On Mon, 21 Nov 2022 at 12:55, Richard Eisenberg <lists at richarde.dev> wrote:

> 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
>
> _______________________________________________
> 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/20221121/5de4cb30/attachment.html>


More information about the ghc-steering-committee mailing list