Warnings, -Wall, and versioning policy

Wed Jan 13 18:17:46 UTC 2016

On Wed, Jan 13, 2016 at 7:43 AM, Simon Peyton Jones
<simonpj at microsoft.com> wrote:

> An implication is that GHC is free to introduce new warnings X into -Wall.   Indeed doing so would be good, because the warning X might later move into the default set.  Indeed for such warnings, adding a "PS: this warning will become the default in GHC 9.2" might be a useful way to signal the upcoming change.  Then you can use -Wall and look for any "PS" indicators.

Yep. In general I think we don't know how _much_ noise a warning will
create until it makes it into the wild, so just as with other new
features its good to give them a bit of a "dry run" before deciding
that they come "by default."

> You don’t give a rationale for (2) but I think you intend that if someone wants to add -Wno-X when GHC introduces X in 9.0, you don't want GHC 8.6 to fall over.  Worth articulating the rationale.

Yes, that's exactly the rationale. It doesn't help us short term, but
longer term it should let users fiddle with warning flags more freely.

I think the general issue with three releases is not whether or not
GHC introduces warnings and at what pace, but that certain _types_ of
warnings (in particular redundancies, be they constraints, imports,
etc) will fire on entirely desirable code due to certain migration
paths. Most of the tricks we developed for backwards-compatible
migrations essentially depend on certain redundancies in code for a
period. Those can't be removed without hurting backwards-compatibility
of code, but their presence also induces warnings.

So as a whole "warning freeness" and "backwards compatible migrations"
become increasingly at odds with one another.

A full refactor of our warning sets would probably help in this
regard, so that the default advice could be "good code is -Wlint clean
but not necessarily -Wpedantic clean". Or even "is clean under
-Wpedantic -Wno-redundancies".

--Gershom

>
> | -----Original Message-----
> | From: Glasgow-haskell-users [mailto:glasgow-haskell-users-
> | bounces at haskell.org] On Behalf Of Gershom B
> | Sent: 13 January 2016 02:20
> | To: GHC users <glasgow-haskell-users at haskell.org>; ghc-devs at haskell.org;
> | Edward Kmett <ekmett at gmail.com>; Herbert Valerio Riedel <hvr at gnu.org>; Simon
> | Marlow <marlowsd at gmail.com>
> | Subject: Re: Warnings, -Wall, and versioning policy
> |
> | Hi Simon. I think you raise important issues here, although I believe you’re
> | mistaken in one regard. Hackage rejects -Werror but I don’t think it rejects
> | -Wall.
> |
> |  What I’d suggest is perhaps the following.
> |
> | 1) The libraries committee put forward -Wall cleanliness as an _aspirational
> | goal_ rather than a final product, noting that the actual cleanliness might
> | be with regards to `-Wall -Wno-foo -Wno-bar``.
> |
> | 2) GHC _change its code_ so that `ghc -Wno-wat` yields a _warning_ rather
> | than an _error_ on `-W` followed by an unrecognized string.
> |
> | 3) No warning flags be introduced into the _default_ set without at least a
> | few releases in some other set such as `-Wall`.
> |
> | We may also want to try to maintain a “best practices” example cabal file
> | that shows how one can build with additional warnings under a “dev” flag, and
> | with fewer warnings otherwise — so that the noise inflicted on package devs
> | under their builds doesn’t get inflicted on all end users, and even perhaps
> | with different warning flags per ghc version flag.
> |
> | I think this will respect the concerns of people that like to use `-Wall`,
> | want to have relatively warning clean code, and want to have some degree of
> | backwards compatibility (which is not an unreasonable combination in my
> | opinion).
> |
> | Some related
> | discussion: https://ghc.haskell.org/trac/ghc/ticket/11370 and https://ghc.has
> | kell.org/trac/ghc/wiki/Design/Warnings
> |
> | Cheers,
> | Gershom
> |
> |
> | On January 12, 2016 at 11:18:57 AM, Simon Marlow (marlowsd at gmail.com) wrote:
> | > Hi folks,
> | >
> | > We haven't described what guarantees GHC provides with respect to -Wall
> | > behaviour across versions, and as a result there are some differing
> | > expectations around this. It came up in this weeks' GHC meeting, so we
> | > thought it would be a good idea to state the policy explicitly. Here it is:
> | >
> | > We guarantee that code that compiles with no warnings with -Wall
> | > ("Wall-clean") and a particular GHC version, on a particular
> | > platform, will be Wall-clean with future minor releases of the same
> | > major GHC version on the same platform.
> | >
> | > (we plan to put this text in the User's Guide for future releases)
> | >
> | > There are no other guarantees. In particular:
> | > - In a new major release, GHC may introduce new warnings into -Wall,
> | > and/or change the meaning of existing warnings such that they trigger
> | > (or not) under different conditions.
> | > - GHC may generate different warnings on different platforms. (examples
> | > of this are -fwarn-overflowed-literals and
> | > -fwarn-unsupported-calling-conventions)
> | >
> | > Some rationale:
> | > - We consider any change to the language that GHC accepts to be a
> | > potentially code-breaking change, and subject to careful scrutiny. To
> | > extend this to warnings would be a *lot* of work, and would make it
> | > really difficult to introduce new warnings and improve the existing ones.
> | > - Warnings can be based on analyses that can change in accuracy over
> | > time. The -fwarn-unused-imports warning has changed a lot in what it
> | > rejects, for example.
> | > - We often introduce new warnings that naturally belong in -Wall. If
> | > -Wall was required to be a fixed point, we would have to start
> | > introducing new flags, and versioning, etc. and even keep the old
> | > implementation of warnings when they change. It would get really messy.
> | >
> | > There are some consequences to this. -Wall -Werror is useful for
> | > keeping your code warning-clean when developing, but shipping code with
> | > these options turned on in the build system is asking for trouble when
> | > building your code with different GHC versions and platforms. Keep
> | > those options for development only. Hackage already rejects packages
> | > that include -Wall for this reason.
> | >
> | > One reason we're raising this now is that it causes problems for the
> | > 3-release policy
> | >
> | (https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fprime.haske
> | ll.org%2fwiki%2fLibraries%2f3-Release-
> | Policy&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c5d13dce17e0b47a80263
> | 08d31bc02832%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=KzdY%2bG8jP8ofztNpN
> | khKGyB5PVW1XUWbw2lCQqdSNmc%3d) which
> | > requires that it be possible to write code that is Wall-clean with 3
> | > major releases of GHC. GHC itself doesn't guarantee this, so it might
> | > be hard for the core libraries committee to provide this guarantee. I
> | > suggest this requirement be dropped from the policy.
> | >
> | > Cheers,
> | > Simon
> | > _______________________________________________
> | > Glasgow-haskell-users mailing list
> | > Glasgow-haskell-users at haskell.org
> | >
> | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell.
> | org%2fcgi-bin%2fmailman%2flistinfo%2fglasgow-haskell-
> | users&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c5d13dce17e0b47a802630
> | 8d31bc02832%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=f395AsIaHpKb8S9z4CAo
> | qfGhiDxa5tzQUo8Sm5%2bgKPQ%3d
> | >
> |
> | _______________________________________________
> | Glasgow-haskell-users mailing list
> | Glasgow-haskell-users at haskell.org
> | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell.
> | org%2fcgi-bin%2fmailman%2flistinfo%2fglasgow-haskell-
> | users%0a&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c5d13dce17e0b47a802
> | 6308d31bc02832%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=6snGzNQuPSFVsZ2SY
> | fAxdSvo%2fjCOXvlq6cwzQM0L6iY%3d