From 51442d35dd02b1786be5710cc7902c5096424bc2 Mon Sep 17 00:00:00 2001 From: Patrick Palka Date: Tue, 6 Mar 2012 19:27:40 -0500 Subject: [PATCH] Don't defer type errors when evaluating a GHCi expression It is unhelpful here because the expression will get evaluated right away anyway, thus emitting a redundant warning followed by an equivalent runtime exception. If the expression were an ill-typed pure expression, _three_ equivalent type errors would get emitted (due to the two-phase typechecking done in 'Plan C') --- compiler/typecheck/TcRnDriver.lhs | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/compiler/typecheck/TcRnDriver.lhs b/compiler/typecheck/TcRnDriver.lhs index f22c988..62bbf53 100644 --- a/compiler/typecheck/TcRnDriver.lhs +++ b/compiler/typecheck/TcRnDriver.lhs @@ -1308,7 +1308,13 @@ tcUserStmt (L loc (ExprStmt expr _ _ _)) -- A. [it <- e; print it] but not if it::() -- B. [it <- e] -- C. [let it = e; print it] - ; runPlans [ -- Plan A + -- + -- Ensure that type errors don't get deferred when type checking the + -- naked expression. Deferring type errors here is unhelpful because the + -- expression gets evaluated right away anyway. It also would potentially + -- emit two redundant type-error warnings. + ; unsetDOptM Opt_DeferTypeErrors $ runPlans [ + -- Plan A do { stuff@([it_id], _) <- tcGhciStmts [bind_stmt, print_it] ; it_ty <- zonkTcType (idType it_id) ; when (isUnitTy it_ty) failM -- 1.7.9.3