GitLab

We might want to put the values initSysTools finds in their own type,
rather than having them flattened into DynFlags

so we no longer need to use defaultDynFlags there

isWindowsHost is True iff mingw32_HOST_OS is defined.

This disappeared when we stopped being "fptools" and became just "ghc"

One of the conditions we were checking was
    t2 `eqPatLType` t2
rather than
    t1 `eqPatLType` t2

When we deal with a family-instance declaration (TcTyClsDecls.tcFamInstDecl)
we must check the TyCon for validity; for example, that a newtype has exactly
one field.  That is done all-at-once for normal declarations, and had been
forgotten altogether for families.

I also refactored the interface to tcFamInstDecl1 slightly.


A slightly separate matter: if there's an error in family instances
(e.g. overlap) we get a confusing error message cascade if we attempt to
deal with 'deriving' clauses too; this patch bales out earlier in that case.


Another slightly separate matter: standalone deriving for family 
instances can legitimately have more specific types, just like normal
data decls. For example
   
   data instance F [a] = ...
   deriving instance (Eq a, Eq b) => Eq (F [(a,b)])

So tcLookupFamInstExact can a bit more forgiving than it was.
 

Sorry -- my 'validate' didn't work right and I missed a trick.
This patch must accompany

 * Fix Trac #2045: use big-tuple machiney for implication constraints