GitLab

This bug led to Trac #4816, which is hereby fixed

See Note [Enumeration types] in TyCon, and comments in Trac #4528

The bytecode generator was being too eager.
Fixes Trac #4528, or rather, a near variant.

This satisfies Trac #3877.  Documentation is changed too.
I'm not sure if this should go in 7.0.2.

When we have TypeSynonymInstances without FlexibleInstances we should still
insist on a H98-style instance head, after looking through the synonym.

This patch also make FlexibleInstances imply TypeSynonymInstances.  Anything
else is a bit awkward, and not very useful.

I will add more comments, but I want to commit this tonight,
so the overnight builds get it.

Fixes an accidental glitch in T1835

This patch finally deals with the super-delicate question of
superclases in possibly-recursive dictionaries.  The key idea
is the DFun Superclass Invariant (see TcInstDcls):

     In the body of a DFun, every superclass argument to the
     returned dictionary is
       either   * one of the arguments of the DFun,
       or       * constant, bound at top level

To establish the invariant, we add new "silent" superclass
argument(s) to each dfun, so that the dfun does not do superclass
selection internally.  There's a bit of hoo-ha to make sure that
we don't print those silent arguments in error messages; a knock
on effect was a change in interface-file format.

A second change is that instead of the complex and fragile
"self dictionary binding" in TcInstDcls and TcClassDcl,
using the same mechanism for existential pattern bindings.
See Note [Subtle interaction of recursion and overlap] in TcInstDcls
and Note [Binding when looking up instances] in InstEnv.

Main notes are here:

  * Note [Silent Superclass Arguments] in TcInstDcls,
    including the DFun Superclass Invariant

Main code changes are:

  * The code for MkId.mkDictFunId and mkDictFunTy

  * DFunUnfoldings get a little more complicated;
    their arguments are a new type DFunArg (in CoreSyn)

  * No "self" argument in tcInstanceMethod
  * No special tcSimplifySuperClasss
  * No "dependents" argument to EvDFunApp

IMPORTANT
   It turns out that it's quite tricky to generate the right
   DFunUnfolding for a specialised dfun, when you use SPECIALISE
   INSTANCE.  For now I've just commented it out (in DsBinds) but
   that'll lose some optimisation, and I need to get back to
   this.

Also, same thing now applies for adding superclasses.

Moreover canonicalisation now is "clever", i.e. it never canonicalizes a class 
constraint if it can already discharge it from some other inert or previously
encountered constraints. See Note [Avoiding the superclass explosion]

This works around a segfault we get when trying to load libiconv.a on
some platforms.

They should use the GHC from the build tree, not the bootstrapping compiler.

  
The renamer wasn't attaching the right used-variables to a
TransformStmt constructor.

The real modification is in RnExpr; the rest is just
pretty-printing and white space.

See Note [Case elimination: lifted case].
Thanks to Roman for identifying this case.

If GHC's command line options are bad then the options parser uses the
pretty printer before the -dppr-cols flag has been read.

 -dsuppress-all
 -dsuppress-type-applications
 -dsuppress-idinfo