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

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 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@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 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/0...

...

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@joachim-breitner.de http://www.joachim-breitner.de/

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee