Treat out-of-scope variables as holes
authorSimon Peyton Jones <simonpj@microsoft.com>
Wed, 24 Jun 2015 22:27:59 +0000 (23:27 +0100)
committerSimon Peyton Jones <simonpj@microsoft.com>
Fri, 26 Jun 2015 07:33:10 +0000 (08:33 +0100)
commitfb7b6922573af76a954d939c85e6af7c39a19896
treeb0604fd3ca0d94d74758c5767e048f9027fe8754
parent95fc6d5940582c8a42cd8f65b7e21b6e6370ea83
Treat out-of-scope variables as holes

This patch implements the idea in Trac #10569.

* An out-of-scope variable is treated as a typed expression
  hole.

* That is, we don't report it in the type checker, not the
  renamer, and we when we do report it, we give its type.

* Moreover, we can defer the error to runtime with
  -fdefer-typed-holes

In implementation terms:

* The renamer turns an unbound variable into a HsUnboundVar

* The type checker emits a Hole constraint for a
  HsUnboundVar, and turns it back into a HsVar

It was a bit painful to implement because a whole raft of
error messages change slightly.  But there was absolutely
nothing hard in principle.

Holes are reported with a bunch of possibly-useful context,
notably the "relevant bindings".  I found that this was
distracting clutter in the very common case of a mis-typed
variable that is only accidentally not in scope, so I've
arranged to print the context information only for true holes,
that is ones starting with an underscore.

Unbound data constructors use in patterns, like
  f (D x) = x
are still reportd by the renamer, and abort compilation
before type checking.
13 files changed:
compiler/deSugar/Coverage.hs
compiler/deSugar/DsExpr.hs
compiler/hsSyn/HsExpr.hs
compiler/rename/RnEnv.hs
compiler/rename/RnExpr.hs
compiler/typecheck/TcErrors.hs
compiler/typecheck/TcExpr.hs
compiler/typecheck/TcRnTypes.hs
compiler/typecheck/TcRules.hs
compiler/typecheck/TcSMonad.hs
compiler/typecheck/TcSimplify.hs
compiler/typecheck/TcType.hs
docs/users_guide/glasgow_exts.xml