GitLab

It's now in the nofib repo.

Now configure looks for it as an installed program instead.

I'm less convinced this is a good idea now.  But it does avoid
rebuilding most of stage1 when you pull and reconfigure.  Better
solutions welcome.

we also have $1_$2_CONFIGURE_OPTS, which is used.

This fixes build problems of the form
  ghc-cabal: Version mismatch between ghc and ghc-pkg

A long-standing improvement to the error message for kinds. Now instead of
    Expected kind `* -> *', but `Int' has kind `*'
we get
    The first argument of `T' should have kind `* -> *',
    but `Int' has kind `*'

Ha!

Record updates are amazingly hard to typecheck right.  This is one place
where GHC's policy of typechecking the original source is much harder than
desugaring and typechecking that!

Anyway, the bug here is that to compute the 'fixed' type variables I was
only looking at one constructor rather than all the relevant_cons

Test is typecheck/should_compile/T3219, which GHC 6.10 barfs on (with Lint).

When using shared libs we should link each lib against its deps. This allows
the dynamic linker to chase dependencies and means we do not have to specify
all indirect dependencies (as we must do for static libs).

As is already the case for ghc -fPIC. This is needed because ghc -dynamic
means to generate code that is capable of being linked to Haskell shared
libs and for C code the equivalent is -fPIC. Normally C code does not need
-fPIC merely to link to shared libs however Haskell shared libs do not
follow common conventions. In particular the static data cannot be
referenced statically because it cannot be copied by the static linker.
The linker cannot copy them because we do not specify a .size for the
_closure entries (in the .data section) though in principle we could.

Following a suggestion of Claus Reinke, this patch improves the error
messages involving type functions.  Here's the relevant note from TcTyFuns.

Note [Non-injective type functions]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
It's very confusing to get a message like
     Couldn't match expected type `Depend s'
            against inferred type `Depend s1'
so pp_open_tc adds:
       NB: `Depend' is a (non-injective) type function

Currently we add this independently for each argument, so we also get
     Couldn't match expected type `a'
            against inferred type `Dual (Dual a)'
       NB: `Dual' is a (non-injective) type function
which is arguably redundant.  But on the other hand, it's probably
a good idea for the programmer to know the error involves type functions
so I've left it in for now.  The obvious alternative is to only add
this NB in the case of matching (T ...) ~ (T ...).