AMP (#8004) almost finished, review would be nice

[David Luposchainsky]

Hey ghc-devs,

I finished #8004. The patch introduces a new compiler flag,
"-fwarn-amp", that is on by default. The changes are pretty local,
affecting TcRnDriver.lhs, PrelNames.lhs and DynFlags.hs, and you can
view it here:

https://github.com/quchen/ghc/compare/amp_warnings?expand=1

(Note that that's my very dirts personal branch, It needs some squashing
to make the actual patch out of this; also note that it includes
coloured warning output so I could debug better. Other than that it's
the real thing though.)

If you have the time I'd like someone who knows his way around GHC to
take a look at it so I don't break stuff unexpectedly :-)


A couple of issues remain:

1. Validation does not work due to the warnings issued. Since "sh
validate" uses -Werror, an AMP warning will stop the compilation before
tests can even be run. Unfortunately, the build system seems to use the
variables 'GhcStage1HcOpts' in the build process of phase 1, which is of
course done with the current (7.6.3 or whatever is installed) compiler.
When adding "-fno-warn-amp" to that variable phase 1 won't build because
the parameter is unknown to the old compiler. Is there some sort of
-"ignore next parameter if unknown" hack, or is there a smart solution?

2. Temporarily removing the -Werror constraint from validate-settings.mk
(or by using custom-settings.mk) makes the validation build go through.
However, the testsuite defines a couple of violating modules, therefore
there is unexpected STDERR output, hence a handful of tests fail. Should
a fix for this be included in the AMP patch, or be done as a separate
instance?

3. Similarly, GHC defines around 50 offending modules, creating warnings
in the standard build process. Again, should this be included, or can we
push that to after the feature freeze and regard it as bugfixing?

Greetings,
David/quchen