GitLab

I've put mkSOName in HscTypes for now; I'm not sure what the best place
for it is.

This required various build system changes to get the build to go
through.

In the inplace shell wrappers, we set LD_LIBRARY_PATH to allow programs
to find their libraries. In the future, we might change the inplace tree
to be the same shape as an installed tree instead. However, this would
mean changing the way we do installation, as currently we use cabal's
installation methods to install the libraries, but that only works if
the libraries are under libraries/foo/dist-install/build/..., rather
than in inplace/lib/...

All the work was done by Dan Winograd-Cort.

The main thing is that arrow comamnds now have their own
data type HsCmd (defined in HsExpr).  Previously it was
punned with the HsExpr type, which was jolly confusing,
and made it hard to do anything arrow-specific.

To make this work, we now parameterise
  * MatchGroup
  * Match
  * GRHSs, GRHS
  * StmtLR and friends
over the "body", that is the kind of thing they
enclose.  This "body" parameter can be instantiated to
either LHsExpr or LHsCmd respectively.

Everything else is really a knock-on effect; there should
be no change (yet!) in behaviour.  But it should be a sounder
basis for fixing bugs.

* Get rid of the lookupInInerts stage

* Re-introduce the flat-cache for flattening type-family equations
  See Note [Type family equations] in TcSMonad. My previous clever attempt
  with organising the work list proved too fragile.

  There's a (static) flag -fno-flat-cache to switch if off,
  so you can try with and without

* Improve the -ddump-cs-trace output

* The usual round of refactoring

This makes it easier to ensure that we get consistent consistency
checking, e.g. that
    -f1 -f2
will do the same checks as
    -f2 -f1

I think that some of the checks were bogus before, but hopefully
all are correct now.

It's still the case that
    -dynamic -static
will leave -fPIC enabled, but it's tricky to avoid that, and we already
have similar situations where for example
    -XRankNTypes -XNoRankNTypes
will leave ExplicitForAll enabled.

We used to add the options when the way was enabled, but this caused
problems with the static/dynamic choice, as once the 'dynamic' options
had been added it wasn't easy to remove them. We therefore didn't allow
-static on the commandline if we'd already seen -static, which kludged
around the issue.

But apart from being unsatisfactory in the first place, this is a
problem if we want to allow -dynamic being on by default, as there
wouldn't be any way to turn it off.

So now we add C/CPP/linker flags required by the 'way's when flags
are requested, rather than during flag parsing.

The current fix is relatively dumb as far as where to add HpLim
checks: it will always perform a check unless we know that we're
returning from a closure or we are doing a non let-no-escape case
analysis.  The performance impact on the nofib suite looks like this:

            Min          +5.7%     -0.0%     -6.5%     -6.4%    -50.0%
            Max          +6.3%     +5.8%     +5.0%     +5.5%     +0.8%
 Geometric Mean          +6.2%     +0.1%     +0.5%     +0.5%     -0.8%

Overall, the executable bloat is the biggest problem, so we keep the old
omit-yields optimization on by default. Remember that if you need an
interruptibility guarantee, you need to recompile all of your libraries
with -fno-omit-yields.

A better fix would involve only inserting the yields necessary to break
loops; this is left as future work.
Signed-off-by: Edward Z. Yang <ezyang@mit.edu>

This is a hopefully temporary measure until the new SRT design is
implemeented.

* Make Any into a type family (which it should always have been)
  This is to support the future introduction of eta rules for
  product types (see email on ghc-users title "PolyKind issue"
  early Sept 2012)

* Add the *internal* data type support for
    (a) closed type families [so that you can't give
        type instance for 'Any']
    (b) injective type families [because Any is really
        injective]
  This amounts to two boolean flags on the SynFamilyTyCon
  constructor of TyCon.SynTyConRhs.

There is some knock-on effect, but all of a routine nature.

It remains to offer source syntax for either closed or
injective families.

This single commit combines a lot of work done by
Thijs Alkemade <thijsalkemade@gmail.com>, plus a slew
of subsequent refactoring by Simon PJ.

The basic idea is
* Add a new expression form "_", a hole, standing for a not-yet-written expression
* Give a useful error message that
   (a) gives the type of the hole
   (b) gives the types of some enclosing value bindings that
       mention the hole

Driven by this goal I did a LOT of refactoring in TcErrors, which in turn
allows us to report enclosing value bindings for other errors, not just
holes.  (Thijs rightly did not attempt this!)

The major data type change is a new form of constraint
  data Ct = ...
    	  | CHoleCan {
    	      cc_ev       :: CtEvidence,
    	      cc_hole_ty  :: TcTauType,
    	      cc_depth    :: SubGoalDepth }

I'm still in two minds about whether this is the best plan. Another
possibility would be to have a predicate type for holes, somthing like
   class Hole a where
     holeValue :: a

It works the way it is, but there are some annoying special cases for
CHoleCan (just grep for "CHoleCan").

This frees wORD_SIZE up to be moved out of HaskellConstants

We now also generate nice wrappers for the platformConstants
methods. For now it's all commented out as the definitions
conflict with those in Constants.

We now generate a platformConstants file that we can read at runtime.

I've switched to passing DynFlags rather than Platform, as (a) it's
simpler to not have to extract targetPlatform in so many places, and
(b) it may be useful to have DynFlags around in future.

We need to make the SRT label external and unique when splitting,
because it is shared amongst all the functions in the module.  Also
some SRT-related cleanup.

It's now just 'dopt Opt_Ticky'