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.haskell.org/trac/ghc/wiki/Design/Warnings Cheers, Gershom On January 12, 2016 at 11:18:57 AM, Simon Marlow (marlowsd@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://prime.haskell.org/wiki/Libraries/3-Release-Policy) 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@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users