Re: [ghc-steering-committee] #571: -Wsevere, Shepherd: Adam (rec: accept)

For those not aware, Hackage right now rejects packages with `-Wall -Werror` in their ghc-options because warnings change between GHC versions so this tends to lead to unnecessary breakage. I think that's a good policy, even though I use `-Wall -Werror` everywhere when developing. Interestingly, this proposal creates exactly the same kind of risk, by making some existing warnings errors by default and introducing the possibility that the set of warnings treated this way might change in the future. Admittedly it's a smaller risk than `-Wall -Werror`, but it's still a risk for developers. Also note that `ghc -XHaskell2010` will reject some legal Haskell2010 programs, unless you also say `-Wwarn=severe`. We are normally careful to document the ways in which GHC deviates from the language definition in the user guide. I can see the motivation, but I have to vote against here. I don't think we should change the set of programs accepted by the compiler unless absolutely necessary. If it's legal code today, it should be accepted by future versions of the compiler unless we have a really good reason to change that. Cheers Simon On Tue, 19 Sept 2023 at 08:53, Moritz Angermann wrote:

Just to clarify: I am not against change, or evolution. I'm actually looking forward to progress. What I am against ist sudden breakage. As such, if there _is_ breakage (clc stackage is a subset), we have to assume there will be breakage in production codebases, most of which are likely not public.

Can't we have `-Wcompat` enable `-Werror=missing-methods`, and `-Werror=missing-fields` (I guess that's the same as `-Werror=sever`?) Advertise this prominently in the release notes for GHC 9.10? And then enable this fully in GHC 9.14? Though I guess the flag we want is really `-Wcompat-error`, or we rather change the notion of -Wcompat to also promote warnings to errors early? In any case either the current documentation for -Wcompat would need to be adjusted, or we'd need something that signals new errors.

Ideally I'd like to see something like a warning for `missing-methods`, with an additional note that this will become an error in GHC X.Y, and that one can opt into this behaviour by enabling -Wcompat.

My test for support is generally: can I take existing code unmodified, swap out the compiler, and it will still compile? That way I can report back regressions, bugs, ... early on during alphas, betas, and release candidates. Right now I can't. I usually have to wait for x.y.4+. That also means the feedback for anyone working on GHC is terrible. You won't hear about bugs until late in the release cycle where the master branch has moved forward by a lot. At the same time it's painful for integrators who end up having to backport and patch old branches. https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-status already states anything but 9.4 and 9.6 won't see any further releases. Our current production compiler is 8.10, we could not switch to 9.2 due to performance regressions. And finally have almost everything compiling with 9.6, but are far from having any form of performance profile feedback on 9.6 yet.

Again, I'm not against breakage per-se. I'm against sudden breakage. Managed evolution or however we want to call it, is something I'd absolutely support!

Best, Moritz

On Tue, 19 Sept 2023 at 15:15, Adam Gundry wrote:

...

On 18/09/2023 20:28, Richard Eisenberg wrote:

...

Bottom line for me: I think we should implement and then experiment. Given the potentially delicate nature of this, I might even advocate

for

...

implementing this in a release branch, so that as much of Hackage as possible actually has a hope of compiling. Then test to see where the breakage occurs. If were happy with the result, rebase the implementation on master. But I don't want us to get into a state where we accept, implement, observe moderate breakage, and then blast ahead because the committee approved the idea.

The breakage concern is worth thinking about, I agree, but fortunately in this instance we don't need to wait for an implementation to run an experiment. The change can be relatively effectively simulated by compiling with -Werror=missing-methods -Werror=missing-fields, and indeed Oleg has done so already for clc-stackage as he reports here:

https://github.com/ghc-proposals/ghc-proposals/issues/544#issue-1410125536

https://github.com/ghc-proposals/ghc-proposals/issues/544#issuecomment-12799...

Out of nearly 3000 packages, he found 22 were broken by -Werror=missing-methods and 9 by -Werror=missing-fields.

Adam

-- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/

Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee