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.

compiler/typecheck/TcBinds.lhs

@@ -741,9 +741,9 @@ generalise dflags top_lvl bind_list sig_fn mono_infos lie_req
   where
     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
 

compiler/typecheck/TcType.lhs

@@ -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.
+
 \begin{code}
 exactTyVarsOfType :: TcType -> TyVarSet
 -- Find the free type variables (of any kind)