Dynamic GHC is now working in-place, but pathologically slow due
to the DLL split.

(GHC assumes that all intra-package calls are in the same DLL, but that
isn't true when we split the GHC package into 2 DLLs. That means that
GHC's startup time is around 22 seconds, as it is doing run-time
linking).

Also, ghci isn't actually working yet:

$ inplace/bin/ghc-stage2 --interactive
GHCi, version 7.7.20130512: http://www.haskell.org/ghc/  :? for help
Loading package ghc-prim ... <command line>: can't load .so/.DLL for:
HSghc-prim-0.3.1.0.dll (addDLL: could not load DLL)
ghc-stage2.exe: HSghc-prim-0.3.1.0: The specified module could not be
found.

Not just base, integer-gmp and ghc-prim.

On Windows, we need to keep the DLL called libffi-6.dll (rather than
libffi.dll) or Windows can't find it.

This is a rather ugly hack to fix dynamically linked GHC on Windows.

If GHC is linked with -threaded, then it links against libHSrts_thr.
But if base is linked against libHSrts, then both end up getting
loaded, and things go wrong. We therefore link the libraries that
link against the RTS with the same RTS flags that we link GHC with.

They used to be treated as being in an exnternal package, which went
wrong on Windows (it tried to call them via an imp wrapper, rather
than calling them directly).

parcs authored 11 years ago and jpm@cs.ox.ac.uk committed 11 years ago

New external top-level names were being created but the name cache
wasn't being populated, leading to #7878.

Signed-off-by: Jose Pedro Magalhaes <jpm@cs.ox.ac.uk>

People are probably more likely to notice some useful variables
if they're located closer to the top (like V=0 and stage=2.)

Signed-off-by: Austin Seipp <aseipp@pobox.com>

This is a bad bug, if a rare one.
See Note [Work-free values only in environment].

Thanks to Amos Robinson for finding it.

Previously we looked for fundeps, and if any fired we
didn't try to solve the constraint.  But that's wrong
(see Note [Weird fundeps]).  Now I solve first and only
if that fails try fundeps.  Code is neater too.

Fixes Trac #7875

We simply weren't quantifying kind variables at the points we
were claiming.  In paritcular, in
     forall (a:k). blah
we quantify the 'k' around the 'forall a', provided k isn't
already in scope

See Note [Eliminate flat-skols].  IT wasn't exactly wrong before
the the error messages are deeply strange.

The pretty-printer uses isPredTy to decide whether to use "=>" or "->",
and typeKind crashes on ill-kinded types. But it's really unhelpful for
the pretty-printer to crash on an ill-kinded type, because then you can't
see it!

Fixes Trac #7872

This includes selector, ap, and constructor thunks. They are still
guarded by the -ticky-dyn-thk flag.

(This is 024df664 with a small bug fix.)

The flag shows no real impact on nofib benchmarks and GHC itself,
which is expected given the small number of strict but not already
unpacked fields in the source of these programs. However, the flag
allows us to omit most of the UNPACK pragmas that are so common in
source code today.

Previously, for
  f :: [Bool]
  f = map not

we'd get a helpful message
    Probable cause: ‛map’ is applied to too few arguments

but not for
  f :: [Bool]
  f = map

which seems a bit stupid.

We were saying
     The function `f' is applied to one argument,
     but its type `[a] -> b' has only one
which is obviously bogus.

This fix suppresses the explanation in cases where it may not
be the *right* explanation.

In particular,
   (forall a. Num a => ...)
always has kind *, becuase the "=>" really is a function.

It turned out that this was at the bottom of the crash in Trac #7778,
which is now fixed

sed on OS X doesn't handle \+

Based on a patch from Peter Trommler

It was marked as "backwards compatibility" in 2006, so I think
can be removed now. It allowed using old field names when looking
at fields with ghc-pkg.

It used to just ignore the --simple-output flag

Patch from Peter Trommler

explicitly link against any dependent library

properly (see #7819)

On iOS, binaries are really static libraries, so we don't want to use
flags like -lm when linking them.

Based on a patch from PHO, in trac #7813.

We were previously declaring StgRun as a private symbol (in
rts/StgRun.h), but were actually defining it as a public one (in
rts/StgCRun.c). This caused a linkage problem with old binutils. See:
http://www.haskell.org/pipermail/ghc-devs/2013-April/000932.html

Patch from pgj; part of #7819.