Warnings, -Wall, and versioning policy

[Simon Marlow]

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