Fix typechecking bug with implicit parameters (Trac #1445)
authorsimonmar@microsoft.com <unknown>
Thu, 28 Jun 2007 08:11:05 +0000 (08:11 +0000)
committersimonmar@microsoft.com <unknown>
Thu, 28 Jun 2007 08:11:05 +0000 (08:11 +0000)
tcSplitFunTy_maybe wasn't dealing with types like
(?x::Bool) => Int
Here, tcSplitFunTy_maybe should fail (as it would if there
was a for-all), because the type is a quantified type.

See Trac #1445, and test tc230.

compiler/typecheck/TcType.lhs

index 5928630..01796c3 100644 (file)
@@ -715,9 +715,16 @@ tcSplitFunTys ty = case tcSplitFunTy_maybe ty of
                                          (args,res') = tcSplitFunTys res
 
 tcSplitFunTy_maybe :: Type -> Maybe (Type, Type)
-tcSplitFunTy_maybe ty | Just ty' <- tcView ty = tcSplitFunTy_maybe ty'
-tcSplitFunTy_maybe (FunTy arg res)  = Just (arg, res)
-tcSplitFunTy_maybe other           = Nothing
+tcSplitFunTy_maybe ty | Just ty' <- tcView ty           = tcSplitFunTy_maybe ty'
+tcSplitFunTy_maybe (FunTy arg res) | not (isPredTy arg) = Just (arg, res)
+tcSplitFunTy_maybe other                               = Nothing
+       -- Note the (not (isPredTy arg)) guard
+       -- Consider     (?x::Int) => Bool
+       -- We don't want to treat this as a function type!
+       -- A concrete example is test tc230:
+       --      f :: () -> (?p :: ()) => () -> ()
+       --
+       --      g = f () ()
 
 tcSplitFunTysN
        :: TcRhoType