Make out-of-scope errors more prominent
authorSimon Peyton Jones <simonpj@microsoft.com>
Fri, 27 Apr 2018 15:15:25 +0000 (16:15 +0100)
committerSimon Peyton Jones <simonpj@microsoft.com>
Fri, 27 Apr 2018 16:19:05 +0000 (17:19 +0100)
commit08003e7f4abafb0c9fe084e4670122ce67cf45dd
treef3071aa28b7122ff2e0525d66a7bae6877199ac0
parent0c01224bb95b3c0d6730ededaf04c9ab0892e297
Make out-of-scope errors more prominent

Generally, when the type checker reports an error, more serious
ones suppress less serious ones.

A "variable out of scope" error is arguably the most serious of all,
so this patch moves it to the front of the list instead of the end.

This patch also fixes Trac #14149, which had
-fdefer-out-of-scope-variables, but also had a solid type error.
As things stood, the type error was not reported at all, and
compilation "succeeded" with error code 0.  Yikes.

Note that

- "Hole errors" (including out of scope) are never suppressed.
  (maybeReportHoleError vs maybeReportError in TcErorrs)
  They can just get drowned by the noise.

- But with the new orientation, out of scope errors will suppress
  type errors.  That would be easy to change.
compiler/typecheck/TcErrors.hs
testsuite/tests/typecheck/should_compile/T14149.stderr
testsuite/tests/typecheck/should_compile/all.T
testsuite/tests/typecheck/should_fail/T12406.stderr