Fail fast on pattern synonyms
We were recovering too eagerly from errors in pattern-synonym type inference, leading to a cascade of confusing follow up errors (Trac #15685, #15692). The underlying issue is that a pattern synonym should have a closed, fixed type, with no unification variables in it. But it wasn't! Fixing this made me change the interface to simplifyInfer slightly. Instead of /emitting/ a residual implication constraint, it now /returns/ it, so that the caller can decide what to do. (cherry picked from commit 9ebfa03d)
Showing
- compiler/typecheck/TcBinds.hs 2 additions, 1 deletioncompiler/typecheck/TcBinds.hs
- compiler/typecheck/TcExpr.hs 3 additions, 1 deletioncompiler/typecheck/TcExpr.hs
- compiler/typecheck/TcPatSyn.hs 42 additions, 33 deletionscompiler/typecheck/TcPatSyn.hs
- compiler/typecheck/TcRnDriver.hs 7 additions, 12 deletionscompiler/typecheck/TcRnDriver.hs
- compiler/typecheck/TcRnMonad.hs 11 additions, 1 deletioncompiler/typecheck/TcRnMonad.hs
- compiler/typecheck/TcRnTypes.hs 21 additions, 16 deletionscompiler/typecheck/TcRnTypes.hs
- compiler/typecheck/TcSimplify.hs 32 additions, 34 deletionscompiler/typecheck/TcSimplify.hs
- testsuite/tests/patsyn/should_fail/T15685.hs 13 additions, 0 deletionstestsuite/tests/patsyn/should_fail/T15685.hs
- testsuite/tests/patsyn/should_fail/T15685.stderr 10 additions, 0 deletionstestsuite/tests/patsyn/should_fail/T15685.stderr
- testsuite/tests/patsyn/should_fail/T15692.hs 9 additions, 0 deletionstestsuite/tests/patsyn/should_fail/T15692.hs
- testsuite/tests/patsyn/should_fail/T15692.stderr 13 additions, 0 deletionstestsuite/tests/patsyn/should_fail/T15692.stderr
- testsuite/tests/patsyn/should_fail/all.T 2 additions, 0 deletionstestsuite/tests/patsyn/should_fail/all.T
Loading
Please register or sign in to comment