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

Tue Sep 19 19:59:41 UTC 2023

See discussion on the CLC issue
https://github.com/haskell/core-libraries-committee/issues/207#issuecomment-1726091889

Some are positively keen on making severe warnings into errors by default,
just the opposite of our current discussion!

Simon

On Tue, 19 Sept 2023 at 17:21, Arnaud Spiwack <arnaud.spiwack at tweag.io>
wrote:

> Is the general consensus on this thread that defaults should never change,
> even if better defaults are discovered?
>
> On Tue, 19 Sept 2023 at 17:13, Chris Dornan <chris at chrisdornan.com> wrote:
>
>> My opposition is entirely grounded in the change of default behaviour;
>> otherwise i am in favour.
>>
>> On Tue, 19 Sep 2023 at 15:31, Simon Marlow <marlowsd at gmail.com> wrote:
>>
>>> On Tue, 19 Sept 2023 at 15:26, Simon Peyton Jones <
>>> simon.peytonjones at gmail.com> wrote:
>>>
>>>> I think that the motivation for this proposal is to make it harder to
>>>> shoot yourself in the foot.
>>>>
>>>> Maybe implementing this "severe" *category*, but not changing its *default
>>>> *to error, would get us some of the way there?  Then "best-practice
>>>> guidance" could be "use -Werror=severe", and job done.  That's a bit easier
>>>> to say than saying "use -Werrror=missing-methods -Werror= ..." etc.
>>>>
>>>
>>> Absolutely! I'm only objecting to changing the default. Adding the
>>> "severe" category by itself is useful, I agree.
>>>
>>> Cheers
>>> Simon
>>>
>>>
>>>>
>>>> Simon
>>>>
>>>> On Tue, 19 Sept 2023 at 14:35, Chris Dornan <chris at chrisdornan.com>
>>>> wrote:
>>>>
>>>>> Like Simon M I habitually develop with -Wall -Werror, and like Moritz
>>>>> I think we really need to be very careful about deliberately breaking
>>>>> packages.
>>>>>
>>>>> For sure, if we were starting anew I would be be sympathetic to
>>>>> treating them as errors, but, for me, that isn't a good enough reason to
>>>>> make this breaking change.
>>>>>
>>>>> For this reason I vote against this proposal.
>>>>>
>>>>> Chris
>>>>>
>>>>> On 19 Sep 2023, at 14:20, Simon Marlow <marlowsd at gmail.com> wrote:
>>>>>
>>>>> 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
>>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>>>
>>>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
>
>
> --
> Arnaud Spiwack
> Director, Research at https://moduscreate.com and https://tweag.io.
> _______________________________________________
> 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/30c7e476/attachment.html>