Pattern/expression ambiguity resolution

This patch removes 'EWildPat', 'EAsPat', 'EViewPat', and 'ELazyPat'
from 'HsExpr' by using the ambiguity resolution system introduced
earlier for the command/expression ambiguity.

Problem: there are places in the grammar where we do not know whether we
are parsing an expression or a pattern, for example:

	do { Con a b <- x } -- 'Con a b' is a pattern
	do { Con a b }      -- 'Con a b' is an expression

Until we encounter binding syntax (<-) we don't know whether to parse
'Con a b' as an expression or a pattern.

The old solution was to parse as HsExpr always, and rejig later:

	checkPattern :: LHsExpr GhcPs -> P (LPat GhcPs)

This meant polluting 'HsExpr' with pattern-related constructors. In
other words, limitations of the parser were affecting the AST, and all
other code (the renamer, the typechecker) had to deal with these extra
constructors.

We fix this abstraction leak by parsing into an overloaded
representation:

	class DisambECP b where ...
	newtype ECP = ECP { runECP_PV :: forall b. DisambECP b => PV (Located b) }

See Note [Ambiguous syntactic categories] for details.

Now the intricacies of parsing have no effect on the hsSyn AST when it
comes to the expression/pattern ambiguity.

1 files changed, 3 insertions, 0 deletions

diff --git a/testsuite/tests/parser/should_fail/patFail002.hs b/testsuite/tests/parser/should_fail/patFail002.hs
new file mode 100644
index 0000000000..b6be3c4482
--- /dev/null
+++ b/testsuite/tests/parser/should_fail/patFail002.hs
@@ -0,0 +1,3 @@
+module PatFail002 where
+
+f (let a = x in a) = _