Reconsidering -Wall and -Wcompat

Boespflug, Mathieu m at
Mon Feb 15 10:33:09 UTC 2016

Hi Ben,

could we enlarge the options a bit? I feel that we're in a false
dichotomy currently. I think the issue isn't so much what warnings you
see from the compiler with common settings, so much as "what warnings
will cause my build to fail?". i.e. the issue isn't what's in -Wall,
it's what goes in -Werror...

If we don't include -Wcompat in -Wall, then I suspect Ben is quite
right that many will ignore / not be aware of -Wcompat hence rendering
the 3 release policy rather moot (it's much less useful if developers
don't /know/ they're incompatible until the last minute). If we do
include it then packages with -Wall -Werror will fail far too early:
i.e. way before the compat change actually happens, 3 compiler
releases down the line. So may I suggest the following:

* include -Wcompat and -Wall, but make it "magic" so that -Wcompat
never causes a build to fail even when users set -Wall -Werror.

This should address the concerns I've been hearing by folks at large
companies who say that at their company a warning is equivalent to an
error, because they always compile with -Wall -Werror. Otherwise
warnings just accumulate, hence no one pays attention to them, hence
warnings become useless.

As an aside: I believe -Wall should do what it says on the tin: enable
all warnings. When GHC comes up with new warnings, we should pretty
much never hesitate to add them to the -Wall set. At Tweag I/O we've
had one instance of a serious bug that shipped into production and
several days worth of wasted effort, because a constraint maintaining
a key invariant was mistakenly unused. -fwarn-redundant-constraints
would of caught this bug very early and saved us all the trouble (a
test would have worked too, but as it happens a test did exist but had
a bug too).

Mathieu Boespflug
Founder at

On 14 February 2016 at 17:12, Ben Gamari <ben at> wrote:
> tl;dr. GHC has a new set of warnings, -Wcompat, intended to give users
>        advance notice of coming library changes. We want to know whether
>        you think this set should be included in -Wall. See the Wiki [4]
>        and voice your opinion via the linked poll.
> Hello everyone,
> GHC 8.0.1 will include a new warning group, -Wcompat, which arose out of
> the MonadFail proposal discussion [1] late last year. This warning set
> is intended to provide a means of informing users of coming changes in
> GHC's core libraries.
> We would like to solicit the community's feedback on whether this new
> flag set should be implied by -Wall.
> This proposal is motivated by concern expressed by some that -Wcompat
> would see little usage unless it is placed in one of the warning sets
> typically used during development. One such set is -Wall, which enables
> a generous fraction of GHC's warning collectionand is is intended [2]
> for use during development.
> Unfortunately, despite the (albeit only recently stated) intent of
> flag, -Wall is widely used outside of development [3], often with the
> expectation that the result be warning-clean across multiple GHC
> versions. While we hope that -Wall will see less use in this context in
> the future, given its current role we wouldn't want to add options to it
> that would cause undue burden for users.
> So, we are asking for your opinion: should -Wcompat be implied by -Wall?
> You can find a more thorough description of the precise proposal on the
> GHC Wiki [4]. It would be very much appreciated if you could take a few
> minutes familiarize yourself with the options and provide your thoughts
> via this quick poll,
> Feel free to discuss the issue further in this thread.
> Thank you for sharing,
> - Ben
> [1]
> [2]
> [3] In a rather unscientific study, nearly half of packages on Hackage
>     include it in ghc-options,
>         $ tar -xf ~/.cabal/packages/00-INDEX.tar
>         $ (for pkg in $(ls); do ls $pkg/*/*.cabal | sort -r | head -n1; done) | xargs grep -L '\-Wall' | wc -l
>         4352
>         $ ls | wc -l
>         9347
> [4]
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at

More information about the ghc-devs mailing list