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

[Simon Marlow]

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 <moritz.angermann at gmail.com>
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 <adam at well-typed.com> 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-1279948737
>>
>> 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 at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20230919/e59f5ed9/attachment.html>