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

[Simon Peyton Jones]

Here's my summary:

   - There is strong (universal, even) support for the `severe` category.
   - There is pretty strong support for making severe warnings into errors
   at some point.  As Matt puts it "this is not a question of GHC breaking
   things, but rather *revealing* and providing early-diagnosis for *already
   broken* things".
   - But I think we are moving towards a policy of giving users time to
   adapt via a deprecation cycle, whenever that is feasible.  And it is
   feasible here.

So my suggestion would be:

   - When implemented, make `-Wwarn=severe` the default, but add to each
   severe warning a deprecation-style message saying that it'll become an
   error in the next iteration.
   - In the next released, make `-Werror=severe` the default.
   - Don't complicate matters by involving GHC2024.  That is another
   conversation, and even if we wanted to include `-Werorr=severe` in GHC2024,
   we would *still* want a deprecation cycle!

Would that be acceptable?

Simon

On Fri, 29 Sept 2023 at 19:41, Adam Gundry <adam at well-typed.com> wrote:

> Dear Committee,
>
> It seems we are somewhat split on the -Wsevere proposal, even assuming
> it is introduced with a deprecation period (changing the warning text
> and adding the group in advance). There is consensus that adding the
> group by itself is fine, and potentially enabling -Werror=severe under
> GHC2024, but enabling it by default for existing code is more
> controversial.
>
> Ultimately this is a judgement call about the value of the proposal
> versus the breakage it causes. I remain of the view that it is
> worthwhile. This is not merely about more aggressively enforcing best
> practice. Rather, it eliminates the risk of the following:
>
> * Suppose package A defines a type class, package B depends on package
> A, and package C depends on package B.
>
> * Now package A extends the type class definition with a new method and
> default methods. Everything still compiles; package B now issues a
> -Wmissing-methods warning (but is not actively maintained, and the
> author of package C is unlikely to look at warnings in all their
> dependencies).
>
> * Users of package C have to try to debug an infinite loop.
>
> Given that this change avoids a significant issue, affected code has
> been issuing warnings for many years, and impacted users can very easily
> set -Wwarn=severe either at the package level or the project level, I
> think is worth accepting the backwards compatibility cost and the fact
> that some Haskell2010 code will no longer be accepted by default.
>
> Matt Parsons puts it well in the CLC thread, which is pretty clearly in
> favour of this proposal overall
> (
> https://github.com/haskell/core-libraries-committee/issues/207#issuecomment-1726091889
> ):
>
>  > I think GHC should strive to make fewer breaking changes, and make
> those changes as easy-to-adopt as possible. But this is not a question
> of GHC breaking things, but rather revealing and providing
> early-diagnosis for already broken things.
>
> Further opinions are welcome, of course.
>
> Adam
>
>
> On 14/09/2023 09:32, Adam Gundry wrote:
> > Dear Committee,
> >
> > Joachim, along with Oleg Grenrus, proposes to change -Wmissing-methods
> > and -Wmissing-fields warnings into errors by default (retaining the
> > option to downgrade them). I recommend we accept the proposal.
> >
> > Proposal: https://github.com/ghc-proposals/ghc-proposals/pull/571
> > Rendered:
> >
> https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-severe-warnings.rst
> >
> > This is primarily motivated by the fact that when classes have default
> > methods, missing methods can lead to runtime loops, which are generally
> > difficult to debug. Since in practice not all users pay attention to
> > warnings that do not inhibit compilation, it makes sense to identify a
> > class of warnings that are sufficiently serious to require explicit
> > action from the user to silence them.
> >
> > Since these warnings are currently not errors by default, library
> > authors experimentally assessing the impact of changes may be lead to
> > assume that introducing new methods/fields does not lead to breakage
> > (because downstream code will still compile). The proposal thus makes it
> > more obvious that adding a new method or field is a breaking change.
> >
> > The proposal deliberately causes builds to fail by default for some
> > libraries that currently emit warnings. Oleg has kindly performed impact
> > assessments to identify such libraries, and the breakage of a few
> > packages seems worth the cost.
> >
> > It is easy to restore the warnings to their previous classification by
> > passing an option at build time, e.g. using -Wno-error=missing-methods.
> > Users can set such an option in cabal.project or stack.yaml to work
> > around breakage that is not promptly fixed by the library author.
> >
> > This change does mean that GHC with -XHaskell98/2010 will by default
> > reject some programs that are explicitly permitted by the Haskell98/2010
> > specification. I recommend we document this infelicity, but accept it,
> > as much of the benefit of the proposal is that it applies by default.
> >
> > The proposal establishes the precedent that some warnings may be treated
> > as errors by default, and introduces a warning group -Wsevere to
> > classify them. This seems conceptually useful and gives us the option to
> > extend the -Wsevere set in the future (e.g. as a final stage of
> > deprecation before a feature is removed).
> >
> > Thoughts?
> >
> > Adam
> >
> >
> > On 11/09/2023 20:25, Joachim Breitner wrote:
> >> Dear Committee,
> >>
> >> based on suggestions by Oleg Grenrus, I wrote a proposal to introduce a
> >> warning group -Wsevere for on-by-defaults, error-by-default warnings,
> >> and initially fill it with missing-methods and missing-fields.
> >>
> >>
> >> https://github.com/ghc-proposals/ghc-proposals/pull/571
> >>
> >>
> https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-severe-warnings.rst
> >>
> >> I’d like to nominate Adam as the shepherd, who already reviewed it a
> >> bit on Github.
> >>
> >> Please guide us to a conclusion as outlined in
> >> https://github.com/ghc-proposals/ghc-proposals#committee-process
> >>
> >>
> >> Cheers,
> >> Joachim
>
>
> --
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20231003/84ccf7aa/attachment.html>