Conflicts:
	compiler/typecheck/TcDeriv.lhs
	compiler/typecheck/TcGenGenerics.lhs

The driving change is this:

* The canonical CFunEqCan constraints now have the form
       [G] F xis ~ fsk
       [W] F xis ~ fmv
  where fsk is a flatten-skolem, and fmv is a flatten-meta-variable
  Think of them as the name of the type-function application

See Note [The flattening story] in TcFlatten.  A flatten-meta-variable
is distinguishable by its MetaInfo of FlatMetaTv

This in turn led to an enormous cascade of other changes, which simplify
and modularise the constraint solver.  In particular:

* Basic data types
    * I got rid of inert_solved_funeqs altogether. It serves no useful
      role that inert_flat_cache does not solve.

    * I added wl_implics to the WorkList, as a convenient place to
      accumulate newly-emitted implications; see Note [Residual
      implications] in TcSMonad.

    * I eliminated tcs_ty_binds altogether. These were the bindings
      for unification variables that we have now solved by
      unification.  We kept them in a finite map and did the
      side-effecting unification later.  But in cannonicalisation we
      had to look up in the side-effected mutable tyvars anyway, so
      nothing was being gained.

      Our original idea was that the solver would be pure, and would
      be a no-op if you discarded its results, but this was already
      not-true for implications since we update their evidence
      bindings in an imperative way.  So rather than the uneasy
      compromise, it's now clearly imperative!

* I split out the flatten/unflatten code into a new module, TcFlatten

* I simplified and articulated explicitly the (rather hazy) invariants
  for the inert substitution inert_eqs.  See Note [eqCanRewrite] and
  See Note [Applying the inert substitution] in TcFlatten

* Unflattening is now done (by TcFlatten.unflatten) after solveFlats,
  before solving nested implications.  This turned out to simplify a
  lot of code. Previously, unflattening was done as part of zonking, at
  the very very end.

    * Eager unflattening allowed me to remove the unpleasant ic_fsks
      field of an Implication (hurrah)

    * Eager unflattening made the TcSimplify.floatEqualities function
      much simpler (just float equalities looking like a ~ ty, where a
      is an untouchable meta-tyvar).

    * Likewise the idea of "pushing wanteds in as givens" could be
      completely eliminated.

* I radically simplified the code that determines when there are
  'given' equalities, and hence whether we can float 'wanted' equalies
  out.  See TcSMonad.getNoGivenEqs, and Note [When does an implication
  have given equalities?].

  This allowed me to get rid of the unpleasant inert_no_eqs flag in InertCans.

* As part of this given-equality stuff, I fixed Trac #9211. See Note
  [Let-bound skolems] in TcSMonad

* Orientation of tyvar/tyvar equalities (a ~ b) was partly done during
  canonicalisation, but then repeated in the spontaneous-solve stage
  (trySpontaneousSolveTwoWay). Now it is done exclusively during
  canonicalisation, which keeps all the code in one place.  See
  Note [Canonical orientation for tyvar/tyvar equality constraints]
  in TcCanonical

This is a deliberate choice, to simplify code, invariants, and I think
performance in typical cases.  The "loopy givens" case is situations like

   [G]  a ~ TF (a, Int)

where TF is a type function with TF (a,b) = (TF a, TF b).

See Note [An alternative story for the inert substitution] in TcFlatten.

There were two unrelated functions, and the `-ddump-rule-firings` output
was coming in a non-deterministic order as a result. So now there is just
one function.

We were falling into an infinite loop when doing the ambiguity
check on a class method, even though we had previously detected
a superclass cycle.  There was code to deal with this, but it
wasn't right.

mjo authored 10 years ago and Herbert Valerio Riedel committed 10 years ago

hvr made some suggestions in D352 and D371, this fixes them in the
already-applied patch for Data/Bool.hs as well for consistency.

Reviewed By: austin, hvr

Differential Revision: https://phabricator.haskell.org/D379

The internal Unicode definitions were updated via
d4fd1680

[skip ci]

This gets rid of `-fno-warn-unused-binds` by turning the E* types into
constructor-less data types (as they're used as phantom-types only)

Moreover, this modules uses `AutoDeriveTypeable` so we can drop all those
redundant `deriving (Typeable)` lines as well

Reviewed By: austin, ekmett

Differential Revision: https://phabricator.haskell.org/D385

This pulls in a change to have the new "Examples" sections being in
`base` collapsed by default.

mjo authored 10 years ago and Herbert Valerio Riedel committed 10 years ago

This adds doctest examples for every function and data type in `Data.Char`.

Reviewed By: austin, hvr

Differential Revision: https://phabricator.haskell.org/D371

This just simplifies the error message in cases where there are no useful
equalities in the context

that binds a variable mentioned in the wanted

There is really no point in reporting ones further out; they can't be useful

With the new constraint solver, we don't guarantee to fully-normalise
all constraints (if doing so is not necessary to solve them). So we
may end up with an inferred type like
      f :: [F Int] -> Bool
which could be simplifed to
      f :: [Char] -> Bool
if there is a suitable family instance declaration.  This patch
does this normalisation, in TcBinds.mkExport

Previously we could get constraints in which the untouchables-level did not
strictly increase, which is one of the main invariants!

This patch also simplifies and modularises the tricky case of generalising
an inferred let-binding

Previously the univerally-quantified variables of the DFun were also (bizarrely)
used as the lexically-scoped variables of the instance declaration.  So, for example,
the DFun's type could not be alpha-renamed.  This was an odd restriction, which has
bitten me several times.

This patch does the Right Thing, by adding an ib_tyvars field to the
InstBindings record, which captures the lexically scoped variables.
Easy, robust, nice.  (I think this record probably didn't exist originally,
hence the hack.)

This makes newClsInst (was mkInstance) look more like newFamInst, and simplifies
the plumbing of the overlap flag, and ensures that freshening (required by
the InstEnv stuff) happens in one place.

On the way I also tided up the rather ragged family of tcInstSkolTyVars and
friends.  The result at least has more uniform naming.

This change is just for naming uniformity with the existing downgradeRole

This function previously would expand *data* families even when it was asked
for a *Nominal* coercion.  This patch fixes it, and adds comments.

This is a straight refactoring that puts the generation of unfolding
info in one place, which is a lot tidier

The simplified function is tcSuperClasses;
no need for an implication constraint here

I forget all the details, but I spent some time trying to
understand the current setup, and tried to simplify it a bit