Sean Gillespie writes:

Howdy,

Hi Sean,

I started looking at Trac #12056 (https://ghc.haskell.org/trac/ghc/ticket/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: https://phabricator.haskell.org/D3581

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. Cheers, - Ben