GitLab

(cherry picked from commit 59b4e6d0)

The constraints for Functor don't line up 1-1 with the arguments
(they are fetched out from sub-terms of the type), but the surrounding
code was mistakenly assuming they were in 1-1 association.

(cherry picked from commit 13a330e8)

Conflicts:
	compiler/typecheck/TcDeriv.lhs

eir@cis.upenn.edu authored Mar 13, 2014 and thoughtpolice committed Mar 17, 2014

(cherry picked from commit 8ee6162e)

Conflicts:
	testsuite/tests/deriving/should_compile/all.T

This matches GCC's choice of Unicode quotation marks (i.e. U+2018 and U+2019)
and therefore looks more familiar on the console. This addresses #2507

.
Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org>
(cherry picked from commit 018676c7)

eir@cis.upenn.edu authored Feb 09, 2014 and thoughtpolice committed Feb 17, 2014

(cherry picked from commit 9e0c1ae5)

(unfortunately, not to the better, these might need some more
massaging.)

following
  a) suppressing kind foralls and arguments
  b) better fundep error messages

(this is related to #3647)

Many of the files modified are just wibbles to output, because now
tycons have roles attached to them, which are produced in the debugging
dumps.

As apparently there is already a test named T5863,
I named this one T5863a.

This patch makes the Data.Typeable.Typeable class work with arguments of any
kind. In particular, this removes the Typeable1..7 class hierarchy, greatly
simplyfing the whole Typeable story. Also added is the AutoDeriveTypeable
language extension, which will automatically derive Typeable for all types and
classes declared in that module. Since there is now no good reason to give
handwritten instances of the Typeable class, those are ignored (for backwards
compatibility), and a warning is emitted.

The old, kind-* Typeable class is now called OldTypeable, and lives in the
Data.OldTypeable module. It is deprecated, and should be removed in some future
version of GHC.

Notably
 * Showing relevant bindings
 * Not suggesting add instance (Num T); see Trac #7222

...in response to Trac #5858