Do type-class defaulting even if there are insoluble constraints
authorSimon Peyton Jones <simonpj@microsoft.com>
Thu, 24 Apr 2014 23:04:45 +0000 (00:04 +0100)
committerSimon Peyton Jones <simonpj@microsoft.com>
Mon, 28 Apr 2014 09:59:51 +0000 (10:59 +0100)
commitba2e20149e2addaccf5ce3122d3a6e93da696a0a
tree14d2eb5a30ccb5f98be00caae683393e98d19979
parent0960a37868e6d08857e86465c8ca346b29b1c813
Do type-class defaulting even if there are insoluble constraints

The argument in Trac #9033 is very compelling: we should not report 20
errors, fix one, and have the other 19 disappear.  They were spurious
in the first place.

The fix was easy; do type-class defaulting uncondionally, rather than
only if there are no insoluble constraints.

See Note [When to do type-class defaulting] in TcSimplify.

Error messages generally improve, especially tc211 which actually
had an example of precisely this phenomenon.
13 files changed:
compiler/typecheck/TcSimplify.lhs
testsuite/tests/indexed-types/should_fail/T5934.stderr
testsuite/tests/typecheck/should_compile/tc211.stderr
testsuite/tests/typecheck/should_fail/T8603.stderr
testsuite/tests/typecheck/should_fail/T9033.hs [new file with mode: 0644]
testsuite/tests/typecheck/should_fail/T9033.stderr [new file with mode: 0644]
testsuite/tests/typecheck/should_fail/all.T
testsuite/tests/typecheck/should_fail/mc24.stderr
testsuite/tests/typecheck/should_fail/tcfail004.stderr
testsuite/tests/typecheck/should_fail/tcfail005.stderr
testsuite/tests/typecheck/should_fail/tcfail140.stderr
testsuite/tests/typecheck/should_fail/tcfail189.stderr
testsuite/tests/typecheck/should_fail/tcfail206.stderr