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

Joachim Breitner mail at joachim-breitner.de
Wed Nov 16 19:16:29 UTC 2022


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/



More information about the ghc-steering-committee mailing list