GitLab

If these modules use UniqFM then we get a stack overflow when compiling
modules that use fundeps. I haven't tracked down the actual cause.

Fixes the ghcpkg01 test.

Previously, cheapEqExpr would always return False if it encountered a cast.
This was bad for two reasons. Firstly, CSE (which uses cheapEqExpr to compare
expressions) never eliminated expressions which contained casts and secondly,
it was inconsistent with exprIsBig. This patch fixes this.

With constructor unpacking, it's possible for constructors and record
selectors to have non-trivial code, which should be optimised before
being fed to the code generator.  Example:

  data Foo = Foo { get :: {-# UNPACK #-} !Int }

Then we do not want to get this:
  T2070.get =
    \ (tpl_B1 :: T2070.Foo) ->
    case tpl_B1 of tpl1_B2 { T2070.Foo rb_B4 ->
        let {
          ipv_B3 [Just S] :: GHC.Base.Int
          [Str: DmdType m]
          ipv_B3 = GHC.Base.I# rb_B4
        } in  ipv_B3 }

If this goes through to codegen, we'll generate bad code.  Admittedly,
this only matters when the selector is used in a curried way (e.g
map get xs), but nevertheless it's silly.

This patch injects the implicit bindings in SimplCore, before the
simplifier runs.  That slows the simplifier a little, because it has
to look at some extra bindings; but it's probably a slight effect.
If it turns out to matter I suppose we can always inject them later,
e.g. just before the final simplification.

An unexpected (to me) consequence is that we get some specialisation rules
for class-method selectors.  E.g. we get a rule
	RULE  (==) Int dInt = eqInt
There's no harm in this, but not much benefit either, because the 
same result will happen when we inline (==) and dInt, but it's perhaps
more direct.

This is a second attempt to fix #1537: to make the static typechecking
of do-notation behave just like the desugared version of the same thing.
This should allow parameterised monads to work properly (see Oleg's comment
in the above ticket).

We can probably merge to 6.8.3 if it goes smoothly.

Incidentally, the resulting setup suffers from greater type ambiguity
if (>>=) has a very general type.  So test rebindable6 no longer works
(at least not without more type signatures), and rebindable5 requires
extra functional dependencies.  But they are weird tests.

Perhaps in the past '.align 2' meant align to 4 bytes, but nowadays it
means align to 2 bytes.  The compacting collector requires info tables
to be aligned to 4 bytes, because it stores tag bits in the low 2
bits.

This only affects -fvia-C - the native code generator was already
emitting the correct alignment.  The incorrect alignment might well
have been adversely affecting performance with -fvia-C on Windows.

- This image is in the public domain, cf 
  http://en.wikipedia.org/wiki/Image:Greek_lc_lamda_thin.svg

- Also moving all MacOS-specific Makefile components into 
  distrib/MacOS/Makefile

- GHC as a Mac framework
- I tried to make a package where the user could choose whether to install
  in /Library/Frameworks or ~/Library/Frameworks (to allow installation for
  non-admins).  However, that doesn't work well without including the whole
  distribution twice as the decision as to whether the admin password needs
  to be entered is made at packaging time (not at install time).

This means that an unregisterised build on a platform not directly
supported by GHC can now have full FFI support using libffi.

Also in this commit:

 - use PrimRep rather than CgRep to describe FFI args in the byte
   code generator.  No functional changes, but PrimRep is more correct.

 - change TyCon.sizeofPrimRep to primRepSizeW, which is more useful

This patch caused at least the following test failures:
   1744(normal)
   ghci028(ghci)
   unicode001(normal)
and additionally made the stage3 build fail.  

A little more validation please!

I didn't find the exact cause of the failure yet, but it appears that
the Lexer is miscompiled in some strange way.  If any of {Encoding,
StringBuffer, or Lexer} are compiled without -O, the problem goes
away.