Reconsidering -Wall and -Wcompat

[Ben Gamari]

"Boespflug, Mathieu" <m at tweag.io> writes:

> 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...

I can certainly see this point. As pointed out by Herbert, this is best
provided by #11219 which unfortunately didn't make the 8.0 release.

> 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.

I am sympathetic to this argument. For better or for worse, however,
there seems to be precedent for excluding some warnings in -Wall. Clang,
for instance, uses -Weverything for "give me everything". Up until this
point we have followed this model (although don't have a -Weverything);
for instance, we disable -Wimplicit-prelude in -Wall since it is
inappropriate for most users.

I'm not sure whether we should break with this tradition as users are
quite used to invoking their compiler with `-Wall` during development.
Throwing warnings about implicit Prelude imports at them would be
surprising to say the least.

> When GHC comes up with new warnings, we should pretty
> much never hesitate to add them to the -Wall set.

I agree. This is why Simon wrote an explicit declaration that -Wall is
not stable to the list a few weeks ago. We really don't want to worry
about breaking builds of (potentially broken) user code when adding
warnings.

Cheers,

- Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160215/0e0852e9/attachment.sig>