[ghc-steering-committee] #571: -Wsevere, Shepherd: Adam (rec: accept)
Adam Gundry
adam at well-typed.com
Thu Oct 5 06:56:22 UTC 2023
On 04/10/2023 22:04, Simon Marlow wrote:
> My concrete suggestion is we EITHER
>
> * Enable -Werror=severe in future GHC20xx versions only, or
> * Enable it by default and in future GHC20xx versions, but not in
> GHC2021, Haskell2010, or Haskell98
Sorry, I don't quite understand the difference between these options.
What does it mean to enable -Werror=severe by default but not in
GHC2021, given that GHC2021 is the (current) default?
Cheers,
Adam
> On Wed, 4 Oct 2023 at 09:28, Simon Peyton Jones
> <simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com>> wrote:
>
> I must say that I am strongly influenced by the fact that
>
> * Matt Parsons
> * Andrew Lelechenko (bodigrim)
>
> are both not just in favour, but *strongly *in favour. They must
> think of the case as compelling, because they are both usually very
> careful about unnecessary breakage.
>
> if we make -Werror=severe the default, then any new warning
> added to -Wsevere is a new breaking change, and we would have to
> judge it to be compelling enough by GR2
>
>
> Yes indeed. But that's not a bug -- it's a feature.
>
> To be clear I have no strongly held opinion myself. Perhaps we
> should canvas opinion among people using Haskell in production? We
> did so with CLC but we could do so publicly.
>
> Simon
>
> On Wed, 4 Oct 2023 at 09:18, Simon Marlow <marlowsd at gmail.com
> <mailto:marlowsd at gmail.com>> wrote:
>
> I don't think this breaking change (namely making -Werror=severe
> the default) meets the bar for "compelling reason" according to
> GR2 of our proposed policy, so I'm voting against. It's
> certainly not a bug or a security hole. Maybe you could argue
> that it's a design flaw in the language, but I'm not all that
> convinced. It's an unforced breaking change in my opinion. If we
> add "makes it more difficult to shoot yourself in the foot" a
> compelling enough reason to break GR1 then I think we've
> weakened it significantly.
>
> Here's another problem: if we make -Werror=severe the default,
> then any new warning added to -Wsevere is a new breaking change,
> and we would have to judge it to be compelling enough by GR2. If
> we don't make -Werror=severe the default, then we're not
> restricted in what we can add to -Wsevere. Probably -Wsevere
> would end up being more useful as a result.
>
> Cheers
> Simon
>
>
> On Tue, 3 Oct 2023 at 11:00, Simon Peyton Jones
> <simon.peytonjones at gmail.com
> <mailto:simon.peytonjones at gmail.com>> wrote:
>
> 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 <mailto: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 <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
> <https://github.com/ghc-proposals/ghc-proposals/pull/571>
> > Rendered:
> >
> https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-severe-warnings.rst <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/pull/571>
> >>
> >>
> https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-severe-warnings.rst <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 <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
More information about the ghc-steering-committee
mailing list