Warnings, -Wall, and versioning policy

Wed Jan 13 21:42:11 UTC 2016

OK.  When this thread comes to a conclusion, can someone write it down; update the 3-release policy; and say what changes you want in GHC?

Thanks

Simon

| -----Original Message-----
| From: Gershom B [mailto:gershomb at gmail.com]
| Sent: 13 January 2016 18:18
| To: Simon Peyton Jones <simonpj at microsoft.com>
| Cc: 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
| 
| 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
| > |
| https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fkell.org%2ft
| rac%2fghc%2fwiki%2fDesign%2fWarnings&data=01%7c01%7csimonpj%40064d.mgd.micros
| oft.com%7c9de7c65d89a84408f00808d31c45e258%7c72f988bf86f141af91ab2d7cd011db47
| %7c1&sdata=BE9pq5knT%2fWTxOfrtEYefqDC2qMEQP%2b9fbcgvs%2f2qr0%3d | 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