GitLab

See comments for details.

In particular, in mkExport we must quantify over the kind
variables mentioned in the kinds of the free type variables

Now these are always added by the run<blah> functions in SysTools, so
we never miss any out.  Several cleanups resulted.

As far as I can tell the bug should be harmless, apart from the
failing assertion.  Since the ticket reported crashes, there might be
problems elsewhere that aren't triggered by this test case.

A buglet that exposed an opportunity for some welcome refactoring
and simplification.  Main changes

* TcMType.zonkQuantifiedTyVars is replaced by quantifyTyVars, which
  does a bit more zonking (so that its clients do not need to)

* TcHsType.kindGeneralise becomes a bit simpler, and hands off
  to quantifyTyVars

* A bit of simplification of the hacky code in TcTyClsDcls.tcConDecl,
  where we figure out how to generalise the data constructor's type

* Improve the error message from badExistential when a constructor
  has an existential type, by printing the offending type

* Some consequential simplification in simplifyInfer.

If we're building the dynamic way too, then hasCafRefs needs to check
whether the dynamic way would use a dynamic name.

Fixes #7592.

Affects i386 only. Some gcc's generate code containing __i686, and then
define that symbol to 1, which causes compilation to fail. We undef
the symbol to work around it.

We were trying to look up the mkInteger Id before we'd compiled
the Integer modules. I'm not sure why this never showed up with
integer-gmp; possibly we just always got lucky with the build
order.

We were accepting
    module ExportCommaComma (id, reverse,,) where
where only 1 trailing comma should be permitted.

It was removed in 9e4e2c24.

It's no longer used by Data.Unique, so there's no need to have it
in rts any more.

We need different paths in the wrapper, as teh installed tree is a
different shape to the build tree.

Pattern bindings are jolly tricky to typecheck, especially if there are
also type signatures involved.  Trac #7268 pointed out that I'd got it
wrong; this fixes it.  See Note [Typing patterns in pattern bindings] in TcPat.

This was really just an oversight from long ago.

This fixes Trac #7888, where the user wanted to use 'undefined' in a
context that needed ((forall a. a->a) -> Int).  We allow OpenKind
unification variables to be instantiate with polytypes (or unboxed
types), hence the change.

'error' has always been like this; this change simply extends
the special treatment to 'undefined'.  It's still magical;
you can't define your own wrapper for 'error' and get the
same behaviour.  Really just a convenience hack.

When specialising a top-level recursive group, if none of the binders
are exported then we can start specialising based on the later calls to
the functions.
This is instead of creating specialisations based on the RHS of the
bindings.
The main benefit of this is that only specialisations that will actually
be used are created. This saves quite a bit of memory when compiling
stream-fusion and ForceSpecConstr sort of code.

Nofib has an average allocation and runtime of -0.7%, maximum 2%.
There are a few with significant decreases in allocation (10 - 20%)
but, interestingly, those ones seem to have similar runtimes.
One of these does have a significantly reduced total elapsed time
though: -38%.

On average the nofib compilation times are the same, but they do vary
with s.d. of -4 to 4%.
I think this is acceptable because of the fairly major code blowup fixes
this has for fusion-style code.
(In one example, a SpecConstr was previously producing 122,000 term size,
now only produces 28,000 with the same object code)

When GHCi makes temporary DLLs, those also need to be linked against
the right RTS, or we won't be able to load them.

This is particularly important as without it validate fails, as it
tries to pass RTS options to haddock, and with the default RTS config
those options aren't permitted.

Now that we can build the GHC package the dyn way, there's no need
to exclude them.

On Windows, we need to prepend "lib" to Haskell DLLs.
(maybe we should be naming the DLLs without the prefix instead? But this
works for now).