Commit bdaf685c authored by's avatar

Fix Trac #1813: generalise over *all* type variables at top level, even phantom ones

See Note [Silly type synonym] in TcType for further details.  This bug
(or at least infelicity) has been in GHC for quite a long time.
parent 3f1b316d
......@@ -741,9 +741,9 @@ generalise dflags top_lvl bind_list sig_fn mono_infos lie_req
bndrs = bndrNames mono_infos
sigs = [sig | (_, Just sig, _) <- mono_infos]
tau_tvs = foldr (unionVarSet . exactTyVarsOfType . getMonoType) emptyVarSet mono_infos
-- NB: exactTyVarsOfType; see Note [Silly type synonym]
-- near defn of TcType.exactTyVarsOfType
get_tvs | isTopLevel top_lvl = tyVarsOfType -- See Note [Silly type synonym] in TcType
| otherwise = exactTyVarsOfType
tau_tvs = foldr (unionVarSet . get_tvs . getMonoType) emptyVarSet mono_infos
is_mono_sig sig = null (sig_theta sig)
doc = ptext SLIT("type signature(s) for") <+> pprBinders bndrs
......@@ -1062,6 +1062,15 @@ exactTyVarsOfType is used by the type checker to figure out exactly
which type variables are mentioned in a type. It's also used in the
smart-app checking code --- see TcExpr.tcIdApp
On the other hand, consider a *top-level* definition
f = (\x -> x) :: T a -> T a
If we don't abstract over 'a' it'll get fixed to GHC.Prim.Any, and then
if we have an application like (f "x") we get a confusing error message
involving Any. So the conclusion is this: when generalising
- at top level use tyVarsOfType
- in nested bindings use exactTyVarsOfType
See Trac #1813 for example.
exactTyVarsOfType :: TcType -> TyVarSet
-- Find the free type variables (of any kind)
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment