Track visibility in TypeEqOrigin
authorRichard Eisenberg <rae@cs.brynmawr.edu>
Tue, 18 Jul 2017 18:30:40 +0000 (14:30 -0400)
committerRichard Eisenberg <rae@cs.brynmawr.edu>
Thu, 27 Jul 2017 11:49:06 +0000 (07:49 -0400)
commitfb752133f45f01b27240d7cc6bce2063a015e51b
tree50cf27e290589b665a4bc182485437cf2a601b7d
parentc2417b87ff59c92fbfa8eceeff2a0d6152b11a47
Track visibility in TypeEqOrigin

A type equality error can arise from a mismatch between
*invisible* arguments just as easily as from visible arguments.
But we should really prefer printing out errors from visible
arguments over invisible ones. Suppose we have a mismatch between
`Proxy Int` and `Proxy Maybe`. Would you rather get an error
between `Int` and `Maybe`? Or between `*` and `* -> *`? I thought
so, too.

There is a fair amount of plumbing with this one, but I think
it's worth it.

This commit introduces a performance regression in test
perf/compiler/T5631. The cause of the regression is not the
new visibility stuff, directly: it's due to a change from
zipWithM to zipWith3M in TcUnify. To my surprise, zipWithM
is nicely optimized (it fuses away), but zipWith3M is not.
There are other examples of functions that could be made faster,
so I've posted a separate ticket, #14037, to track these
improvements. For now, I've accepted the small (6.6%) regression.
12 files changed:
compiler/typecheck/Inst.hs
compiler/typecheck/TcCanonical.hs
compiler/typecheck/TcErrors.hs
compiler/typecheck/TcHsType.hs
compiler/typecheck/TcRnTypes.hs
compiler/typecheck/TcType.hs
compiler/typecheck/TcUnify.hs
testsuite/tests/perf/compiler/all.T
testsuite/tests/polykinds/KindVType.stderr
testsuite/tests/typecheck/should_fail/T12373.stderr
testsuite/tests/typecheck/should_fail/T13530.stderr
testsuite/tests/typecheck/should_fail/T8603.stderr