Joachim Breitner writes:

[Deliberately restricting my reply to one mailing list. Cross-posting is usually not required.]

Hi,

Am Sonntag, den 14.02.2016, 19:51 +0100 schrieb Sven Panne:

...

As stated on the Wiki, stuff in -Wcompat will often be non- actionable,

you omitted the important “if backwards compatibility is desired;”. The sometimes complicated hoops that you will have to jump through to gain 3-release-backward-compatibility are not something I expect every developer to follow, and for most others, “adjust early to API changes” will more likely be the sensible thing to do. Those might want to leave -Wcompat in their builds.

Couldn't have said it better myself. Ubiquitous usage of -Wall isn't a problem; it's when users begin to assume that the behavior of -Wall (which nominally includes *all* warnings supported by GHC) will remain stable across releases that the trouble begins. Cheers, - Ben

On 2016-02-15 at 04:47:56 +0100, Richard Eisenberg wrote:

On Feb 14, 2016, at 1:51 PM, Sven Panne wrote:

...

IMHO, the distinction between "during development" and "outside of it" is purely hypothetical.

I find this comment quite interesting, as I see quite a large difference between these.* For example, I use -Werror during development, but not outside it. For me, "during development" is when the author can see the output from the compiler. "Outside of it" is when the author is not looking at the output.

When I'm developing, I want to see lots and lots of warnings.

When I'm building something I downloaded from Hackage, I generally don't care.

So I wonder if there's a way for the tooling to distinguish between development builds and non-dev builds.

You may be interested in the upcoming `cabal.project`-file feature which besides allowing to specify which .cabal files your multi-package project is made up of (and tells cabal where your project-root is), allows to set additional `ghc-options`, specify whether tests/benchmarks are to be enabled, or request specific cabal flag settings (basically most things you can set via the CLI as well), or even which GHC compiler executable to use (rather than picking up whatever's in PATH). This can be specified for all packages in the project or on per-package granularity. `cabal.project` files have only an effect when you're triggering cabal invocations from within a source-tree, i.e. when you're in the "during development" mode. So that would be a good place to specify your development-mode GHC warning-flag configuration and other development-centric configurations.

I know cabal better than stack, so I'll use that as my example. When I say `cabal configure --enable-tests; cabal build`, it means I want more information about how well this package works. Perhaps with --enable-tests, -Wall -Wcompat -Werror should be enabled by default. If I just say `cabal install`, I probably don't care so much about how well the package is working and can leave off the extra diagnostics.

On 2016-02-15 at 11:33:09 +0100, Boespflug, Mathieu wrote: [...]

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

Tbh, I don't like the "magic" part at all. In fact, I currently rely on `-Wcompat -Werror` triggering an error in my builds. To address the concern more generally is what https://ghc.haskell.org/trac/ghc/ticket/11219 aims to, but without any magic. Then you'd say -Wall -Werror -Wno-error=compat if -Wcompat implied by -Wall. But we ran out of time for GHC 8.0, so #11219 will have to wait till GHC 8.2.

"Boespflug, Mathieu" 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