We now first collect the option instructions (from the commandline,
from pragmas in source files, etc), and then later flatten them into
the list of enabled options. This will enable us to use different
standards (H98, H2010, etc) as a base upon which to apply the
instructions, when we don't know what the base will be when we start
collecting instructions.

This phase originally invoked the llvm-as tool that turns a textual
llvm assembly file into a bit code file for the rest of llvm to deal
with. Now the llvm opt tool can do this itself, so we don't need to
use llvm-as anymore.

and add a comment to explain why it was wrong.  This fixes the dyn
test failures that sprang up recently.

This was done as part of an honours thesis at UNSW, the paper describing the
work and results can be found at:

http://www.cse.unsw.edu.au/~pls/thesis/davidt-thesis.pdf

A Homepage for the backend can be found at:

http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/Backends/LLVM

Quick summary of performance is that for the 'nofib' benchmark suite, runtimes
are within 5% slower than the NCG and generally better than the C code
generator.  For some code though, such as the DPH projects benchmark, the LLVM
code generator outperforms the NCG and C code generator by about a 25%
reduction in run times.

We now have a DeprecatedFullText constructor, so we can override the
"-#include is deprecated: " part of the warning.

If the command line contains any Haskell source files, then we behave
as if --make had been given.

The meaning of the -c flag has changed (back): -c now selects one-shot
compilation, but stops before linking.  However, to retain backwards
compatibility, -c is still allowed with --make, and means the same as
--make -no-link.  The -no-link flag has been un-deprecated.

-fno-code is now allowed with --make (#3783); the fact that it was
disabled before was largely accidental, it seems.  We also had some
regressions in this area: it seems that -fno-code was causing a .hc
file to be emitted in certain cases.  I've tidied up the code, there
was no need for -fno-code to be a "mode" flag, as far as I can tell.

-fno-code does not emit interface files, nor does it do recompilation
checking, as suggested in #3783.  This would make Haddock emit
interface files, for example, and I'm fairly sure we don't want to do
that.  Compiling with -fno-code is pretty quick anyway, perhaps we can
get away without recompilation checking.

You can now link with
    -with-rtsopts="-H128m -K1m"

If RTS options are disabled then:
* The ghc_rts_opts C code variable is processed as normal
* The GHCRTS environment variable is ignored and, if it is defined, a
  warning is emitted
* The +RTS flag gives an error and terminates the program

If enabled, these accept more layout, but give warnings

The new flag -msse2 enables code generation for SSE2 on x86.  It
results in substantially faster floating-point performance; the main
reason for doing this was that our x87 code generation is appallingly
bad, and since we plan to drop -fvia-C soon, we need a way to generate
half-decent floating-point code.

The catch is that SSE2 is only available on CPUs that support it (P4+,
AMD K8+).  We'll have to think hard about whether we should enable it
by default for the libraries we ship.  In the meantime, at least
-msse2 should be an acceptable replacement for "-fvia-C
-optc-ffast-math -fexcess-precision".

SSE2 also has the advantage of performing all operations at the
correct precision, so floating-point results are consistent with other
platforms.

I also tweaked the x87 code generation a bit while I was here, now
it's slighlty less bad than before.

This patch moves a lot of code around, but has zero functionality change.
The idea is that the types

    CoreToDo
    SimplifierSwitch	
    SimplifierMode
    FloatOutSwitches

and 

    the main core-to-core pipeline construction

belong in simplCore/, and *not* in DynFlags.

This patch collects a small raft of related changes

* Arrange that during 
     (a) rule matching and 
     (b) uses of exprIsConApp_maybe
  we "look through" unfoldings only if they are active
  in the phase. Doing this for (a) required a bit of 
  extra plumbing in the rule matching code, but I think
  it's worth it.

  One wrinkle is that even if inlining is off (in the 'gentle'
  phase of simplification) during rule matching we want to
  "look through" things with inlinings.  
   See SimplUtils.activeUnfInRule.

  This fixes a long-standing bug, where things that were
  supposed to be (say) NOINLINE, could still be poked into
  via exprIsConApp_maybe. 

* In the above cases, also check for (non-rule) loop breakers; 
  we never look through these.  This fixes a bug that could make
  the simplifier diverge (and did for Roman).  
  Test = simplCore/should_compile/dfun-loop

* Try harder not to choose a DFun as a loop breaker. This is 
  just a small adjustment in the OccurAnal scoring function

* In the scoring function in OccurAnal, look at the InlineRule
  unfolding (if there is one) not the actual RHS, beause the
  former is what'll be inlined.  

* Make the application of any function to dictionary arguments
  CONLIKE.  Thus (f d1 d2) is CONLIKE.  
  Encapsulated in CoreUtils.isExpandableApp
  Reason: see Note [Expandable overloadings] in CoreUtils

* Make case expressions seem slightly smaller in CoreUnfold.
  This reverses an unexpected consequences of charging for
  alternatives.

Refactorings
~~~~~~~~~~~~
* Signficantly refactor the data type for Unfolding (again). 
  The result is much nicer.  

* Add type synonym BasicTypes.CompilerPhase = Int
  and use it

Many of the files touched by this patch are simply knock-on
consequences of these two refactorings.

Caution: Largely untested

I finally got tired of the #ifdef OLD_STRICTNESS stuff.  I had been
keeping it around in the hope of doing old-to-new comparisions, but
have failed to do so for many years, so I don't think it's going to
happen.  This patch deletes the clutter.

The -fexpose-all-unfoldings flag arranges to put unfoldings for *everything*
in the interface file.  Of course,  this makes the file a lot bigger, but
it also makes it complete, and that's great for supercompilation; or indeed
any whole-program work.

Consequences:
  * Interface files need to record loop-breaker-hood.  (Previously,
    loop breakers were never exposed, so that info wasn't necessary.)
    Hence a small interface file format change. 

  * When inlining, must check loop-breaker-hood. (Previously, loop
    breakers didn't have an unfolding at all, so no need to check.)

  * Ditto in exprIsConApp_maybe.  Roman actually tripped this bug, 
    because a DFun, which had an unfolding, was also a loop breaker

  * TidyPgm.tidyIdInfo must be careful to preserve loop-breaker-hood

So Id.idUnfolding checks for loop-breaker-hood and returns NoUnfolding
if so. When you want the unfolding regardless of loop-breaker-hood, 
use Id.realIdUnfolding.

I have not documented the flag yet, because it's experimental.  Nor
have I tested it thoroughly.  But with the flag off (the normal case)
everything should work.

This ensures that messages coming out with -dshow-passes 
also come out with -dverbose-core2core

This change helps to break the mutual recursion generated by
an instance declaration.

See Note [Gentle mode] in SimplUtils

By default INLINE functions only inline when they
are given enough arguments, so the flag isn't needed

To get ticky profiling you still have to compile with -ticky (for
those modules that you want to profile), but you can link with either
-debug or -ticky.

GHC has had an experimental implementation of impredicative
polymorphism for a year or two now (flag -XImpredicativeTypes). 
But

  a) The implementation is ridiculously complicated, and the complexity
     is pervasive (in the type checker) rather than localized.
     I'm very unhappy about this, especially as we add more stuff to
     the type checker for type families.

  b) The specification (type system) is well-defined [1], but is also pretty
     complicated, and it's just too hard to predict which programs will
     typecheck and which will not.

So it's time for a re-think.  I propose to deprecate it in 6.12, and
remove it altogether in 6.14.  We may by then have something else to
put in its place.  (There is no lack of candidates [2,3,4]!)

[1] http://research.microsoft.com/en-us/um/people/simonpj/papers/boxy/
[2] http://research.microsoft.com/en-us/um/people/crusso/qml/
[3] http://research.microsoft.com/en-us/um/people/daan/pubs.html
[4] http://gallium.inria.fr/~remy/mlf/

With -fstrictness-before=n, GHC runs an additional strictness analysis pass
before simplifier phase n.

The change is this (see Trac #2798).  Instead of writing

  mdo { a <- getChar
      ; b <- f c
      ; c <- g b
      ; putChar c
      ; return b }

you would write

  do { a <- getChar
     ; rec { b <- f c
           ; c <- g b }
     ; putChar c
     ; return b }

That is, 
  * 'mdo' is eliminated 
  * 'rec' is added, which groups a bunch of statements
    into a single recursive statement

This 'rec' thing is already present for the arrow notation, so it  
makes the two more uniform.  Moreover, 'rec' lets you say more
precisely where the recursion is (if you want to), whereas 'mdo' just
says "there's recursion here somewhere".  Lastly, all this works with
rebindable syntax (which mdo does not).

Currently 'mdo' is enabled by -XRecursiveDo.  So we now deprecate this
flag, with another flag -XDoRec to enable the 'rec' keyword.

Implementation notes:
  * Some changes in Lexer.x
  * All uses of RecStmt now use record syntax

I'm still not really happy with the "rec_ids" and "later_ids" in the
RecStmt constructor, but I don't dare change it without consulting Ross
about the consequences for arrow syntax.

It turned out that we lacked flags to switch off these two passes,
so I added them.

This implements the Haskell Prime proposal
  http://hackage.haskell.org/trac/haskell-prime/wiki/ExplicitForall

Flag is -XExplicitForAll

Implied by Opt_RankNTypes, Opt_Rank2Types, Opt_ScopedTypeVariables, 
           Opt_LiberalTypeSynonyms, Opt_ExistentialQuantification, 
           Opt_PolymorphicComponents 

- We have -m32 as machine-dependent option for gcc for a 32 bit build
- Like on OpenBSD, SL requires -fno-stack-protector to avoid triggering the
  stack smashing checks inserted by gcc by default on this platform.

A few changes bundled together here:

 - Add -package-id flag, like -package but takes an
   InstalledPackageId as an argument (mainly for Cabal)
   (docs to follow)

 - Fix the shadowing behaviour: if we end up with
   two packages with the same name/version that came from
   different package databases, then one will shadow the
   other.  This may mean we have to disable other packages
   that depended on the now-shadowed package.  Lots of
   refactoring to ensure that we can get reasonable diagnostics when
   this happens

<command line>: cannot satisfy -package shadowdep: 
    shadowdep-1-XXX is unusable due to missing or recursive dependencies:
      shadow-1-XXX
    (use -v for more information)