Newcomer help (Trac #12056)

Ben Gamari ben at
Wed May 17 19:11:16 UTC 2017

Sean Gillespie <sean at> writes:

> Howdy,
Hi Sean,

> I started looking at Trac #12056 (,
> but I'm a bit stuck.

Thanks for looking into this!
> Indeed, if I run the following command, I get no warnings
>     ghc Main.hs -Wfoo -w -Wunrecognised-warning-flags -Wbar
> But if I also specify -Wdeprecated-flags, I get warnings again
>     ghc Main.hs -Wfoo -w -Wunrecognised-warning-flags -Wdeprecated-flags -Wbar 
>     on the commandline: warning: unrecognised warning flag: -Wfoo 
>     on the commandline: warning: unrecognised warning flag: -Wbar
> Then I found this little function in compiler/main/HscTypes
>     handleFlagWarnings :: DynFlags -> [Located String] -> IO ()
>     handleFlagWarnings dflags warns
>      = when (wopt Opt_WarnDeprecatedFlags dflags) $ do
>             -- It would be nicer if warns :: [Located MsgDoc], but that
>             -- has circular import problems.
>           let bag = listToBag [ mkPlainWarnMsg dflags loc (text warn)
>                               | L loc warn <- warns ]
>           printOrThrowWarnings dflags bag
> So I updated it accept Opt_WarnDeprecatedFlags and Opt_WarnUnrecognisedWarningsFlags.
> Complete patch here:
> Unfortunately when I did that, -Wno-deprecated-flags no longer had an effect so long
> as -Wunrecognised-warnings-flags
>     ./inplace/bin/ghc-stage2 -Wunrecognised-warning-flags -Wno-deprecated-flags -XOverlappingInstances
>     on the commandline: warning:
>         -XOverlappingInstances is deprecated: instead use per-instance pragmas OVERLAPPING/OVERLAPPABLE/OVERLAPS
> And now that is where I'm stuck; I can't seem to find a place where I can distinguish
> between the different warning types. Even WarnReason is set to NoReason because of
> the usage of mkPlainWarnMsg.
Sorry for the late response; this ended up being quite a rabbit-hole. In
general I see relatively few really good solutions here.  Ideally we
would make the warnings produced by the DynFlags parser proper MsgDocs,
as the comment in handleFlagWarnings suggests. However, the comment
isn't quite accurate: the reason for not using MsgDoc here isn't just
import loops; you also need to have DynFlags in order to construct a
MsgDoc (see the smart constructors in ErrUtils). This requirement is
something we might be able to hack around in the case of flag errors by
simply using some "generic" DynFlags, but I'm not sure that the payoff
of doing so is all that great.

It seems to me like we should rather stick with the current approach of
not using MsgDoc. Instead, we should augment the warnings returned from
the DynFlags parser with enough information so we can filter them out
later if necessary. This might either be by including a WarnReason with
each Located String, or possibly returning Opt_WarnDeprecatedFlags and
Opt_WarnUnrecognizedWarningsFlags warnings in separate lists.
I tend to think the former would be cleaner.

I hope this helps.


- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <>

More information about the ghc-devs mailing list