Warnings, -Wall, and versioning policy

[Gershom B]

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 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://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 at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>