Allow WARNING pragmas to be controlled with custom flags
Motivation
I’m reorganizing some modules in my library, and want to add WARNING
pragmas to encourage users to import the new things. However, there are cases where importing the old things is still the right choice, and so users there will want to disable the warnings.
However, control of WARNING
pragmas is kind of all-or-nothing (even if scoped to a file), so I’d like it if users could disable warnings from my package specifically, or even better, disable specific named categories of warnings.
Proposal
To that end, I suggest allowing WARNING
pragmas to take the name of a flag to control them from the CLI. Notionally, that might be something like:
{-# WARNING "you likely meant to import X instead" "import-advice" #-}
which could then be controlled with
-Wimport-advice
-Wno-import-advice
in addition to the existing -Wwarnings-deprecations
, -Werror
, etc.
I would expect that this should also work with the symbol-specific syntax:
{-# WARNING foo, foo' "you likely meant to call bar instead" "call-advice" #-}
Considerations
I would expect custom warnings to be enabled any time -Wwarnings-deprecations
is, e.g. by default.
This specific plan would allow you to piggy-back on existing warning flags like -Wdodgy-imports
. I can’t think of any reasons why you would want to, but it does have the benefit that omitting a flag name would have the same semantics as specifying warnings-deprecations
.
On the other hand, it also means that warnings provided in code can collide with GHC’s own warnings; further, it’s probably not possible to know a priori which flags to parse. For that reason, one might instead want to control these warnings via an option such as -Wcustom=import-advice
/-Wno-custom=import-advice
, perhaps with -Wno-custom
(sans value) meaning the same thing as -Wno-warnings-deprecations
.
For similar reasons, one might want to further scope these with package names, altho that would mean that factoring modules between packages could change warning names, which would be inconvenient for end users.
I think the same things should also apply to DEPRECATED
pragmas, in that one might want to control specific deprecations by originating package as well as use site, without turning them off altogether.