which (finally) fills out the functionality of polymorphic kinds.
It also fixes numerous bugs.

Main changes are:

Renaming stuff
~~~~~~~~~~~~~~
* New type in HsTypes:
     data HsBndrSig sig = HsBSig sig [Name]
  which is used for type signatures in patterns, and kind signatures
  in types.  So when you say
       f (x :: [a]) = x ++ x
  or
       data T (f :: k -> *) (x :: *) = MkT (f x)
  the signatures in both cases are a HsBndrSig.

* The [Name] in HsBndrSig records the variables bound by the
  pattern, that is 'a' in the first example, 'k' in the second,
  and nothing in the third.  The renamer initialises the field.

* As a result I was able to get rid of
     RnHsSyn.extractHsTyNames :: LHsType Name -> NameSet
  and its friends altogether.  Deleted the entire module!
  This led to some knock-on refactoring; in particular the
  type renamer now returns the free variables just like the
  term renamer.

Kind-checking types: mainly TcHsType
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
A major change is that instead of kind-checking types in two
passes, we now do one. Under the old scheme, the first pass did
kind-checking and (hackily) annotated the HsType with the
inferred kinds; and the second pass desugared the HsType to a
Type.  But now that we have kind variables inside types, the
first pass (TcHsType.tc_hs_type) can go straight to Type, and
zonking will squeeze out any kind unification variables later.

This is much nicer, but it was much more fiddly than I had expected.

The nastiest corner is this: it's very important that tc_hs_type
uses lazy constructors to build the returned type. See
Note [Zonking inside the knot] in TcHsType.

Type-checking type and class declarations: mainly TcTyClsDecls
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I did tons of refactoring in TcTyClsDecls.  Simpler and nicer now.

Typechecking bindings: mainly TcBinds
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I rejigged (yet again) the handling of type signatures in TcBinds.
It's a bit simpler now.  The main change is that tcTySigs goes
right through to a TcSigInfo in one step; previously it was split
into two, part here and part later.

Unsafe coercions
~~~~~~~~~~~~~~~~
Usually equality coercions have exactly the same kind on both
sides.  But we do allow an *unsafe* coercion between Int# and Bool,
say, used in
    case error Bool "flah" of { True -> 3#; False -> 0# }
-->
    (error Bool "flah") |> unsafeCoerce Bool Int#

So what is the instantiation of (~#) here?
   unsafeCoerce Bool Int# :: (~#) ??? Bool Int#
I'm using OpenKind here for now, but it's un-satisfying that
the lhs and rhs of the ~ don't have precisely the same kind.

More minor
~~~~~~~~~~
* HsDecl.TySynonym has its free variables attached, which makes
  the cycle computation in TcTyDecls.mkSynEdges easier.

* Fixed a nasty reversed-comparison bug in FamInstEnv:
  @@ -490,7 +490,7 @@ lookup_fam_inst_env' match_fun one_sided ie fam tys
     n_tys = length tys
     extra_tys = drop arity tys
     (match_tys, add_extra_tys)
-       | arity > n_tys = (take arity tys, \res_tys -> res_tys ++ extra_tys)
+       | arity < n_tys = (take arity tys, \res_tys -> res_tys ++ extra_tys)
        | otherwise     = (tys,            \res_tys -> res_tys)

We were keeping around the Task struct (216 bytes) for every worker we
ever created, even though we only keep a maximum of 6 workers per
Capability.  These Task structs accumulate and cause a space leak in
programs that do lots of safe FFI calls; this patch frees the Task
struct as soon as a worker exits.

One reason we were keeping the Task structs around is because we print
out per-Task timing stats in +RTS -s, but that isn't terribly useful.
What is sometimes useful is knowing how *many* Tasks there were.  So
now I'm printing a single-line summary, this is for the program in

  TASKS: 2001 (1 bound, 31 peak workers (2000 total), using -N1)

So although we created 2k tasks overall, there were only 31 workers
active at any one time (which is exactly what we expect: the program
makes 30 safe FFI calls concurrently).

This also gives an indication of how many capabilities were being
used, which is handy if you use +RTS -N without an explicit number.

e.g.

[3 of 5] Compiling C                (C.hs, C.o)
[4 of 5] Compiling D                (D.hs, D.o) [C changed]
[5 of 5] Compiling E                (E.hs, E.o) [D changed]

The main motivation for this is so that we can give the user a clue
when something is being recompiled because the flags changed:

[1 of 1] Compiling Test2            ( Test2.hs, Test2.o ) [flags changed]

The reasoning is that GHC will only skip recompilation if it has found
a valid up-to-date object file and .hi file, so there is no need to
also check that these flags have not changed, and indeed there are
valid reasons to want to change them.

GHCi now maintains two DynFlags: one that applies to whole modules
loaded with :load, and one that applies to things typed at the prompt
(expressions, statements, declarations, commands).

  The :set command modifies both DynFlags.  This is for backwards
  compatibility: users won't notice any difference.

  The :seti command applies only to the interactive DynFlags.

Additionally, I made a few changes to ":set" (with no arguments):

  * Now it only prints out options that differ from the defaults,
    rather than the whole list.

  * There is a new variant, ":set -a" to print out all options (the
    old behaviour).

  * It also prints out language options.

e.g.

Prelude> :set
options currently set: none.
base language is: Haskell2010
with the following modifiers:
  -XNoDatatypeContexts
  -XNondecreasingIndentation
GHCi-specific dynamic flag settings:
other dynamic, non-language, flag settings:
  -fimplicit-import-qualified
warning settings:

":seti" (with no arguments) does the same as ":set", but for the
interactive options.  It also has the "-a" option.

The interactive DynFlags are kept in the InteractiveContext, and
copied into the HscEnv at the appropriate points (all in HscMain).

There are some new GHC API operations:

-- | Set the 'DynFlags' used to evaluate interactive expressions.
setInteractiveDynFlags :: GhcMonad m => DynFlags -> m ()

-- | Get the 'DynFlags' used to evaluate interactive expressions.
getInteractiveDynFlags :: GhcMonad m => m DynFlags

-- | Sets the program 'DynFlags'.
setProgramDynFlags :: GhcMonad m => DynFlags -> m [PackageId]

-- | Returns the program 'DynFlags'.
getProgramDynFlags :: GhcMonad m => m DynFlags

Note I have not completed the whole of the plan outlined in #3217 yet:
when in the context of a loaded module we don't take the interactive
DynFlags from that module.  That needs some more refactoring and
thinking about, because we'll need to save and restore the original
interactive DynFlags.

This solves the immediate problem that people are having with the new
flag checking in 7.4.1, because now it is possible to set language
options in ~/.ghci that do not affect loaded modules and thereby cause
recompilation.

And make the docs a bit more concrete.

tibbe authored Feb 16, 2012 and Simon Marlow committed Feb 27, 2012

This command calls git-new-workdir (a separate script in git's contrib
directory) on all repos.  Useful to create multiple build trees, without
cloning the repos.

Usage:
  sync-all new-workdir <new_workdir> [<branch>]

aljee@hyper.cx authored Feb 22, 2012 and Simon Marlow committed Feb 27, 2012

createDirectoryHierarchy consisted of an existence test followed by
createDirectory, which failed if that directory was creted just after
the test. createDirectoryifMissing does not have this problem.