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
