[Git][ghc/ghc][wip/T21623] 2 commits: Wibbles

Simon Peyton Jones (@simonpj) gitlab at gitlab.haskell.org
Mon Aug 29 18:37:51 UTC 2022



Simon Peyton Jones pushed to branch wip/T21623 at Glasgow Haskell Compiler / GHC


Commits:
0a2c5120 by Simon Peyton Jones at 2022-08-29T19:35:03+01:00
Wibbles

- - - - -
ca80f62b by Simon Peyton Jones at 2022-08-29T19:36:12+01:00
More wibbles

- - - - -


15 changed files:

- compiler/GHC/Builtin/Types.hs
- compiler/GHC/Builtin/Types/Prim.hs
- compiler/GHC/Core/Coercion.hs
- compiler/GHC/Core/Map/Expr.hs
- compiler/GHC/Core/TyCo/Compare.hs
- compiler/GHC/Core/TyCo/Rep.hs
- compiler/GHC/Core/TyCon.hs
- compiler/GHC/Core/Type.hs
- compiler/GHC/Core/Type.hs-boot
- compiler/GHC/Tc/Gen/App.hs
- compiler/GHC/Tc/Gen/Expr.hs
- compiler/GHC/Tc/Gen/Foreign.hs
- compiler/GHC/Tc/Gen/Splice.hs
- compiler/GHC/Tc/Solver/Canonical.hs
- compiler/GHC/Types/Basic.hs


Changes:

=====================================
compiler/GHC/Builtin/Types.hs
=====================================
@@ -590,7 +590,8 @@ pcDataCon n univs tys
                       (map linear tys)
 
 pcDataConConstraint :: Name -> [TyVar] -> ThetaType -> TyCon -> DataCon
--- Used for the data constructor of the Coercible (
+-- Used for data constructors whose arguments are all constraints.
+-- Notably constraint tuples, Eq# etc.
 pcDataConConstraint n univs theta
   = pcDataConWithFixity False n univs
                       []    -- No ex_tvs


=====================================
compiler/GHC/Builtin/Types/Prim.hs
=====================================
@@ -47,7 +47,7 @@ module GHC.Builtin.Types.Prim(
         cONSTRAINTTyCon, cONSTRAINTTyConName, cONSTRAINTKind,
 
         -- Arrows
-        anonArgTyCon,
+        anonArgTyCon, isArrowTyCon,
         fUNTyCon,       fUNTyConName,
         ctArrowTyCon, ctArrowTyConName,
         ccArrowTyCon, ccArrowTyConName,
@@ -129,7 +129,7 @@ import {-# SOURCE #-} GHC.Builtin.Types
   , constraintKind )
 
 import {-# SOURCE #-} GHC.Types.TyThing
-import {-# SOURCE #-} GHC.Core.Type ( mkTyConTy, mkTyConApp, getLevity )
+import {-# SOURCE #-} GHC.Core.Type ( mkTyConApp, getLevity )
 
 import GHC.Types.Var    ( TyVarBinder, TyVar
                         , mkTyVar, mkTyVarBinder, mkTyVarBinders )
@@ -597,6 +597,11 @@ anonArgTyCon (VisArg   ConstraintLike) = tcArrowTyCon
 anonArgTyCon (InvisArg TypeLike)       = ctArrowTyCon
 anonArgTyCon (InvisArg ConstraintLike) = ccArrowTyCon
 
+isArrowTyCon :: TyCon -> Bool
+isArrowTyCon tc
+  = getUnique tc `elem`
+    [fUNTyConKey, ctArrowTyConKey, ccArrowTyConKey, tcArrowTyConKey]
+
 fUNTyConName, ctArrowTyConName, ccArrowTyConName, tcArrowTyConName :: Name
 fUNTyConName     = mkPrimTc        (fsLit "FUN") fUNTyConKey       fUNTyCon
 ctArrowTyConName = mkBuiltInPrimTc (fsLit "=>")  ctArrowTyConKey ctArrowTyCon
@@ -680,7 +685,7 @@ All types that classify values have a kind of the form
 where the `RuntimeRep` parameter, rr, tells us how the value is represented
 at runtime.  TYPE and CONSTRAINT are primitive type constructors.
 
-There are a bunch of type synonyms and data types defined in in the
+There are a bunch of type synonyms and data types defined in the
 library ghc-prim:GHC.Types.  All of them are also wired in to GHC, in
 GHC.Builtin.Types
 
@@ -750,9 +755,9 @@ Note that, as before, nothing prevents writing instances like:
   instance C (Proxy @Type a) where ...
 
 In particular, TYPE and CONSTRAINT (and the synonyms Type, Constraint
-etc) are all allowed in instance heads. It's just that TYPE
-apart from CONSTRAINT so that instance would irretrievably overlap
-with:
+etc) are all allowed in instance heads. It's just that TYPE apart from
+CONSTRAINT, which means that the above instance would irretrievably
+overlap with:
 
   instance C (Proxy @Constraint a) where ...
 


=====================================
compiler/GHC/Core/Coercion.hs
=====================================
@@ -625,7 +625,7 @@ eqTyConRole tc
   = pprPanic "eqTyConRole: unknown tycon" (ppr tc)
 
 -- | Given a coercion @co1 :: (a :: TYPE r1) ~ (b :: TYPE r2)@,
---   (or CONSTRAINT instead of TPYE)
+--   (or CONSTRAINT instead of TYPE)
 -- produce a coercion @rep_co :: r1 ~ r2 at .
 mkRuntimeRepCo :: HasDebugCallStack => Coercion -> Coercion
 mkRuntimeRepCo co


=====================================
compiler/GHC/Core/Map/Expr.hs
=====================================
@@ -146,9 +146,8 @@ instance Eq (DeBruijn CoreExpr) where
 
 eqDeBruijnExpr :: DeBruijn CoreExpr -> DeBruijn CoreExpr -> Bool
 eqDeBruijnExpr (D env1 e1) (D env2 e2) = go e1 e2 where
-    go (Var v1) (Var v2) = eqDeBruijnVar (D env1 v1) (D env2 v2)
+    go (Var v1) (Var v2)             = eqDeBruijnVar (D env1 v1) (D env2 v2)
     go (Lit lit1)    (Lit lit2)      = lit1 == lit2
-    -- See Note [Using tcView inside eqDeBruijnType] in GHC.Core.Map.Type
     go (Type t1)    (Type t2)        = eqDeBruijnType (D env1 t1) (D env2 t2)
     -- See Note [Alpha-equality for Coercion arguments]
     go (Coercion {}) (Coercion {}) = True
@@ -159,7 +158,6 @@ eqDeBruijnExpr (D env1 e1) (D env2 e2) = go e1 e2 where
       && go e1 e2
 
     go (Lam b1 e1)  (Lam b2 e2)
-          -- See Note [Using tcView inside eqDeBruijnType] in GHC.Core.Map.Type
       =  eqDeBruijnType (D env1 (varType b1)) (D env2 (varType b2))
       && D env1 (varMultMaybe b1) == D env2 (varMultMaybe b2)
       && eqDeBruijnExpr (D (extendCME env1 b1) e1) (D (extendCME env2 b2) e2)
@@ -171,9 +169,7 @@ eqDeBruijnExpr (D env1 e1) (D env2 e2) = go e1 e2 where
     go (Let (Rec ps1) e1) (Let (Rec ps2) e2)
       = equalLength ps1 ps2
       -- See Note [Alpha-equality for let-bindings]
-      && all2 (\b1 b2 -> -- See Note [Using tcView inside eqDeBruijnType] in
-                         -- GHC.Core.Map.Type
-                         eqDeBruijnType (D env1 (varType b1))
+      && all2 (\b1 b2 -> eqDeBruijnType (D env1 (varType b1))
                                         (D env2 (varType b2)))
               bs1 bs2
       && D env1' rs1 == D env2' rs2


=====================================
compiler/GHC/Core/TyCo/Compare.hs
=====================================
@@ -5,7 +5,7 @@
 
 {-# LANGUAGE FlexibleContexts, PatternSynonyms, ViewPatterns, MultiWayIf #-}
 
--- | Main functions for manipulating types and type-related things
+-- | Type equality and comparison
 module GHC.Core.TyCo.Compare (
 
     -- * Type comparison
@@ -37,28 +37,46 @@ import GHC.Utils.Outputable
 import GHC.Utils.Misc
 import GHC.Utils.Panic
 
-{- Note [Comparision of types]
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-This module implements type comparison, notably `eqType`.
 
-* It uses a few functions from GHC.Core.Type, notably `typeKind`, so it
-  currently sits "on top of" GHC.Core.Type.
+{- Note [GHC.Core.TyCo.Compare overview]
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+This module implements type equality and comparison
 
+It uses a few functions from GHC.Core.Type, notably `typeKind`,
+so it currently sits "on top of" GHC.Core.Type.
 -}
 
-
 {- *********************************************************************
 *                                                                      *
-            Type equalities
+            Type equality
 *                                                                      *
 ********************************************************************* -}
 
+{- Note [Computing equality on types]
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+This module implements type equality, notably `eqType`. This is
+"definitional equality" or just "equality" for short.
+
+There are several places within GHC that depend on the precise choice of
+definitional equality used. If we change that definition, all these places
+must be updated. This Note merely serves as a place for all these places
+to refer to, so searching for references to this Note will find every place
+that needs to be updated.
+
+* See Note [Non-trivial definitional equality] in GHC.Core.TyCo.Rep.
+
+* See Historical Note [Typechecker equality vs definitional equality]
+  below
+-}
+
+
 tcEqKind :: HasDebugCallStack => Kind -> Kind -> Bool
 tcEqKind = tcEqType
 
 tcEqType :: HasDebugCallStack => Type -> Type -> Bool
--- ^ tcEqType implements typechecker equality, as described in
--- @Note [Typechecker equality vs definitional equality]@.
+-- ^ tcEqType implements typechecker equality
+-- It behaves just like eqType, but is implemented
+-- differently (for now)
 tcEqType ty1 ty2
   =  tcEqTypeNoSyns ki1 ki2
   && tcEqTypeNoSyns ty1 ty2
@@ -215,29 +233,7 @@ cmpForAllVis (Invisible _) Required       = GT
 cmpForAllVis (Invisible _) (Invisible _)  = EQ
 
 
-{- Note [Typechecker equality vs definitional equality]
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-GHC has two notions of equality over Core types:
-
-* Definitional equality, as implemented by GHC.Core.Type.eqType.
-  See Note [Non-trivial definitional equality] in GHC.Core.TyCo.Rep.
-* Typechecker equality, as implemented by tcEqType (in GHC.Tc.Utils.TcType).
-  GHC.Tc.Solver.Canonical.canEqNC also respects typechecker equality.
-
-Typechecker equality implies definitional equality: if two types are equal
-according to typechecker equality, then they are also equal according to
-definitional equality. The converse is not always true, as typechecker equality
-is more finer-grained than definitional equality in two places:
-
-* Unlike definitional equality, which equates Type and Constraint, typechecker
-  treats them as distinct types. See Note [Kind Constraint and kind Type] in
-  GHC.Core.Type.
-* Unlike definitional equality, which does not care about the ArgFlag of a
-  ForAllTy, typechecker equality treats Required type variable binders as
-  distinct from Invisible type variable binders.
-  See Note [ForAllTy and type equality]
-
-Note [ForAllTy and type equality]
+{- Note [ForAllTy and type equality]
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 When we compare (ForAllTy (Bndr tv1 vis1) ty1)
          and    (ForAllTy (Bndr tv2 vis2) ty2)
@@ -271,9 +267,8 @@ specified or inferred can be somewhat subtle, however, especially for kinds
 that aren't explicitly written out in the source code (like in D above).
 
 For now, we decide to not make the specified/inferred status of an invisible
-type variable binder affect GHC's notion of typechecker equality
-(see Note [Typechecker equality vs definitional equality] in
-GHC.Tc.Utils.TcType). That is, we have the following:
+type variable binder affect GHC's notion of equality. That is, we have the
+following:
 
   --------------------------------------------------
   | Type 1            | Type 2            | Equal? |
@@ -291,6 +286,36 @@ GHC.Tc.Utils.TcType). That is, we have the following:
   |                   | forall k -> <...> | Yes    |
   --------------------------------------------------
 
+Historical Note [Typechecker equality vs definitional equality]
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+This Note describes some history, in case there are vesitges of this
+history lying around in the code.
+
+Summary: prior to summer 2022, GHC had have two notions of equality
+over Core types.  But now there is only one: definitional equality,
+or just equality for short.
+
+The old setup was:
+
+* Definitional equality, as implemented by GHC.Core.Type.eqType.
+  See Note [Non-trivial definitional equality] in GHC.Core.TyCo.Rep.
+
+* Typechecker equality, as implemented by tcEqType.
+  GHC.Tc.Solver.Canonical.canEqNC also respects typechecker equality.
+
+Typechecker equality implied definitional equality: if two types are equal
+according to typechecker equality, then they are also equal according to
+definitional equality. The converse is not always true, as typechecker equality
+is more finer-grained than definitional equality in two places:
+
+* Constraint vs Type.  Definitional equality equated Type and
+  Constraint, but typechecker treats them as distinct types.
+
+* Unlike definitional equality, which does not care about the ArgFlag of a
+  ForAllTy, typechecker equality treats Required type variable binders as
+  distinct from Invisible type variable binders.
+  See Note [ForAllTy and type equality]
+
 
 ************************************************************************
 *                                                                      *
@@ -388,17 +413,6 @@ ordering leads to nondeterminism. We hit the same problem in the TyVarTy case,
 comparing type variables is nondeterministic, note the call to nonDetCmpVar in
 nonDetCmpTypeX.
 See Note [Unique Determinism] for more details.
-
-Note [Computing equality on types]
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-There are several places within GHC that depend on the precise choice of
-definitional equality used. If we change that definition, all these places
-must be updated. This Note merely serves as a place for all these places
-to refer to, so searching for references to this Note will find every place
-that needs to be updated.
-
-See also Note [Non-trivial definitional equality] in GHC.Core.TyCo.Rep.
-
 -}
 
 nonDetCmpType :: Type -> Type -> Ordering


=====================================
compiler/GHC/Core/TyCo/Rep.hs
=====================================
@@ -547,12 +547,6 @@ cannot appear outside a coercion. We do not (yet) have a function to
 extract relevant free variables, but it would not be hard to write if
 the need arises.
 
-Besides eqType, another equality relation that upholds the (EQ) property above
-is /typechecker equality/, which is implemented as
-GHC.Tc.Utils.TcType.tcEqType. See
-Note [Typechecker equality vs definitional equality] in GHC.Tc.Utils.TcType for
-what the difference between eqType and tcEqType is.
-
 Note [Respecting definitional equality]
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 Note [Non-trivial definitional equality] introduces the property (EQ).
@@ -1439,7 +1433,7 @@ SelTyCon, SelForAll, and SelFun.
 
 Note [FunCo]
 ~~~~~~~~~~~~
-You might think that a FunCo (which connects two function types should
+You might think that a FunCo (which connects two function types) should
 contain the AnonArgFlag from the function types.  But we are allowed to
 have an axiom (and hence a coercion) connecting Type and Constraint, thus
     co :: (t::Type) ~ (c::Constraint)
@@ -2223,6 +2217,3 @@ So that Mult feels a bit more structured, we provide pattern synonyms and smart
 constructors for these.
 -}
 type Mult = Type
-
-
-


=====================================
compiler/GHC/Core/TyCon.hs
=====================================
@@ -87,7 +87,7 @@ module GHC.Core.TyCon(
         tyConFamilySize,
         tyConStupidTheta,
         tyConArity,
-        tyConNullaryTy,
+        tyConNullaryTy, mkTyConTy,
         tyConRoles,
         tyConFlavour,
         tyConTuple_maybe, tyConClass_maybe, tyConATs,
@@ -525,6 +525,13 @@ mkTyConKind bndrs res_kind = foldr mk res_kind bndrs
     mk (Bndr tv (AnonTCB af))   k = mkNakedKindFunTy af (varType tv) k
     -- mkNakedKindFunTy: see Note [Naked FunTy] in GHC.Builtin.Types
 
+-- | (mkTyConTy tc) returns (TyConApp tc [])
+-- but arranges to share that TyConApp among all calls
+-- See Note [Sharing nullary TyConApps]
+-- So it's just an alias for tyConNullaryTy!
+mkTyConTy :: TyCon -> Type
+mkTyConTy tycon = tyConNullaryTy tycon
+
 tyConInvisTVBinders :: [TyConBinder]   -- From the TyCon
                     -> [InvisTVBinder] -- Suitable for the foralls of a term function
 -- See Note [Building TyVarBinders from TyConBinders]


=====================================
compiler/GHC/Core/Type.hs
=====================================
@@ -428,12 +428,21 @@ coreView _                 = Nothing
 -- See Note [Inlining coreView].
 {-# INLINE coreView #-}
 
---------------------------
--- *** TODO: strange change in coreView ****
---------------------------
+coreFullView, core_full_view :: Type -> Type
+-- ^ Iterates 'coreView' until there is no more to synonym to expand.
+-- NB: coreFullView is non-recursive and can be inlined;
+--     core_full_view is the recursive one
+-- See Note [Inlining coreView].
+coreFullView ty@(TyConApp tc _)
+  | isTypeSynonymTyCon tc = core_full_view ty
+coreFullView ty = ty
+{-# INLINE coreFullView #-}
 
------------------------------------------------
+core_full_view ty
+  | Just ty' <- coreView ty = core_full_view ty'
+  | otherwise               = ty
 
+-----------------------------------------------
 -- | @expandSynTyConApp_maybe tc tys@ expands the RHS of type synonym @tc@
 -- instantiated at arguments @tys@, or returns 'Nothing' if @tc@ is not a
 -- synonym.
@@ -489,21 +498,6 @@ expand_syn tvs rhs arg_tys
     go _ (_:_) [] = pprPanic "expand_syn" (ppr tvs $$ ppr rhs $$ ppr arg_tys)
                    -- Under-saturated, precondition failed
 
-coreFullView, core_full_view :: Type -> Type
--- ^ Iterates 'coreView' until there is no more to synonym to expand.
--- NB: coreFullView is non-recursive and can be inlined;
---     core_full_view is the recursive one
--- See Note [Inlining coreView].
-coreFullView ty@(TyConApp tc _)
-  | isTypeSynonymTyCon tc = core_full_view ty
-coreFullView ty = ty
-{-# INLINE coreFullView #-}
-
-core_full_view ty
-  | Just ty' <- coreView ty = core_full_view ty'
-  | otherwise               = ty
-
-
 {- Note [Inlining coreView]
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
 It is very common to have a function
@@ -522,7 +516,13 @@ in its fast path. For this to really be fast, all calls made
 on its fast path must also be inlined, linked back to this Note.
 -}
 
------------------------------------------------
+
+{- *********************************************************************
+*                                                                      *
+                expandTypeSynonyms
+*                                                                      *
+********************************************************************* -}
+
 expandTypeSynonyms :: Type -> Type
 -- ^ Expand out all type synonyms.  Actually, it'd suffice to expand out
 -- just the ones that discard type variables (e.g.  type Funny a = Int)
@@ -632,6 +632,12 @@ The reason is that we then get better (shorter) type signatures in
 interfaces.  Notably this plays a role in tcTySigs in GHC.Tc.Gen.Bind.
 -}
 
+{- *********************************************************************
+*                                                                      *
+                Random functions (todo: organise)
+*                                                                      *
+********************************************************************* -}
+
 -- | An INLINE helper for function such as 'kindRep_maybe' below.
 --
 -- @isTyConKeyApp_maybe key ty@ returns @Just tys@ iff
@@ -1085,6 +1091,8 @@ the test in repSplitAppTy_maybe, which applies throughout, because
 the other calls to splitAppTy are in GHC.Core.Unify, which is also used by
 the type checker (e.g. when matching type-function equations).
 
+We are willing to split (t1 -=> t2) because the argument is still of
+kind Type, not Constraint.  So the criterion is isVisibleAnonArg.
 -}
 
 -- | Applies a type to another, as in e.g. @k a@
@@ -1130,18 +1138,23 @@ splitAppTy_maybe :: Type -> Maybe (Type, Type)
 -- that type family applications are NEVER unsaturated by this!
 splitAppTy_maybe = repSplitAppTy_maybe . coreFullView
 
+splitAppTy :: Type -> (Type, Type)
+-- ^ Attempts to take a type application apart, as in 'splitAppTy_maybe',
+-- and panics if this is not possible
+splitAppTy ty = splitAppTy_maybe ty `orElse` pprPanic "splitAppTy" (ppr ty)
+
 -------------
 repSplitAppTy_maybe :: HasDebugCallStack => Type -> Maybe (Type,Type)
 -- ^ Does the AppTy split as in 'splitAppTy_maybe', but assumes that
--- any Core view stuff is already done
+-- any coreView stuff is already done
+repSplitAppTy_maybe (AppTy ty1 ty2)
+  = Just (ty1, ty2)
+
 repSplitAppTy_maybe (FunTy af w ty1 ty2)
   | Just (tc, tys)   <- funTyConAppTy_maybe af w ty1 ty2
   , Just (tys', ty') <- snocView tys
   = Just (TyConApp tc tys', ty')
 
-repSplitAppTy_maybe (AppTy ty1 ty2)
-  = Just (ty1, ty2)
-
 repSplitAppTy_maybe (TyConApp tc tys)
   | not (mustBeSaturated tc) || tys `lengthExceeds` tyConArity tc
   , Just (tys', ty') <- snocView tys
@@ -1149,38 +1162,15 @@ repSplitAppTy_maybe (TyConApp tc tys)
 
 repSplitAppTy_maybe _other = Nothing
 
--- This one doesn't break apart (c => t).
--- See Note [Decomposing fat arrow c=>t]
--- Defined here to avoid module loops between Unify and TcType.
 tcRepSplitAppTy_maybe :: Type -> Maybe (Type,Type)
--- ^ Does the AppTy split as in 'tcSplitAppTy_maybe', but assumes that
--- any coreView stuff is already done. Refuses to look through (c => t)
-tcRepSplitAppTy_maybe (FunTy { ft_af = af, ft_mult = w, ft_arg = ty1, ft_res = ty2 })
-  | isVisibleAnonArg af  -- See Note [Decomposing fat arrow c=>t]
-
-  -- See Note [The Purely Kinded Type Invariant (PKTI)] in GHC.Tc.Gen.HsType,
-  -- Wrinkle around FunTy
-  , Just rep1 <- getRuntimeRep_maybe ty1
-  , Just rep2 <- getRuntimeRep_maybe ty2
-  = Just (TyConApp fUNTyCon [w, rep1, rep2, ty1], ty2)
-
-  | otherwise
+-- ^ Just like repSplitAppTy_maybe, but does not split (c => t)
+-- See Note [Decomposing fat arrow c=>t]
+tcRepSplitAppTy_maybe ty
+  | FunTy { ft_af = af } <- ty
+  , not (isVisibleAnonArg af)  -- See Note [Decomposing fat arrow c=>t]
   = Nothing
-
-tcRepSplitAppTy_maybe (AppTy ty1 ty2)    = Just (ty1, ty2)
-tcRepSplitAppTy_maybe (TyConApp tc tys)
-  | not (mustBeSaturated tc) || tys `lengthExceeds` tyConArity tc
-  , Just (tys', ty') <- snocView tys
-  = Just (TyConApp tc tys', ty')    -- Never create unsaturated type family apps!
-tcRepSplitAppTy_maybe _other = Nothing
-
--------------
-splitAppTy :: Type -> (Type, Type)
--- ^ Attempts to take a type application apart, as in 'splitAppTy_maybe',
--- and panics if this is not possible
-splitAppTy ty = case splitAppTy_maybe ty of
-                Just pr -> pr
-                Nothing -> panic "splitAppTy"
+  | otherwise
+  = repSplitAppTy_maybe ty
 
 -------------
 splitAppTys :: Type -> (Type, [Type])
@@ -1341,9 +1331,8 @@ See #11714.
 -----------------------------------------------
 funTyConAppTy_maybe :: AnonArgFlag -> Type -> Type -> Type
                     -> Maybe (TyCon, [Type])
--- Given the components of a FunTy/FuNCo,
+-- Given the components of a FunTy
 -- figure out the corresponding TyConApp.
--- Not used for coercions
 funTyConAppTy_maybe af mult arg res
   | Just arg_rep <- getRuntimeRep_maybe arg
   , Just res_rep <- getRuntimeRep_maybe res
@@ -1642,7 +1631,6 @@ splitTyConAppNoSyn_maybe ty
 -- Differs from splitTyConApp_maybe in that it does *not* split types
 -- headed with (=>), as that's not a TyCon in the type-checker.
 --
---
 -- Note that this may fail (in funTyConAppTy_maybe) in the case
 -- of a 'FunTy' with an argument of unknown kind 'FunTy'
 -- (e.g. `FunTy (a :: k) Int`, since the kind of @a@ isn't of
@@ -1667,9 +1655,8 @@ tcSplitTyConApp_maybe ty
       _               -> Nothing
 
 tcSplitTyConApp :: Type -> (TyCon, [Type])
-tcSplitTyConApp ty = case tcSplitTyConApp_maybe ty of
-                        Just stuff -> stuff
-                        Nothing    -> pprPanic "tcSplitTyConApp" (ppr ty)
+tcSplitTyConApp ty
+  = tcSplitTyConApp_maybe ty `orElse` pprPanic "tcSplitTyConApp" (ppr ty)
 
 ---------------------------
 -- | (mkTyConTy tc) returns (TyConApp tc [])


=====================================
compiler/GHC/Core/Type.hs-boot
=====================================
@@ -14,7 +14,6 @@ isCoercionTy :: Type -> Bool
 
 mkAppTy    :: Type -> Type -> Type
 mkCastTy   :: Type -> Coercion -> Type
-mkTyConTy  :: TyCon -> Type
 mkTyConApp :: TyCon -> [Type] -> Type
 mkCoercionTy :: Coercion -> Type
 piResultTy :: HasDebugCallStack => Type -> Type -> Type


=====================================
compiler/GHC/Tc/Gen/App.hs
=====================================
@@ -8,7 +8,7 @@
 
 {-# OPTIONS_GHC -Wno-incomplete-uni-patterns   #-}
 
-{-a
+{-
 %
 (c) The University of Glasgow 2006
 (c) The GRASP/AQUA Project, Glasgow University, 1992-1998
@@ -1008,7 +1008,7 @@ qlUnify delta ty1 ty2
     -- impredicative instantiation info from there seems...remote.
     go bvs (FunTy { ft_af = af1, ft_arg = arg1, ft_res = res1, ft_mult = mult1 })
            (FunTy { ft_af = af2, ft_arg = arg2, ft_res = res2, ft_mult = mult2 })
-      | af1 == af2
+      | af1 == af2 -- Match the arrow TyCon
       = do { when (isVisibleAnonArg af1) (go bvs arg1 arg2)
            ; when (isFUNAnonArg af1)     (go bvs mult1 mult2)
            ; go bvs res1 res2 }


=====================================
compiler/GHC/Tc/Gen/Expr.hs
=====================================
@@ -1182,7 +1182,7 @@ desugarRecordUpd record_expr rbnds res_ty
           -- the record to disambiguate its fields, so we must infer the record
           -- type here before we can desugar. See Wrinkle [Disambiguating fields]
           -- in Note [Record Updates].
-       ; ((_, record_rho), _lie) <- captureConstraints    $  -- see (1) below
+       ; ((_, record_rho), _lie) <- captureConstraints    $ -- see (1) below
                                     tcScalingUsage ManyTy $ -- see (2) below
                                     tcInferRho record_expr
 


=====================================
compiler/GHC/Tc/Gen/Foreign.hs
=====================================
@@ -141,7 +141,10 @@ normaliseFfiType' env ty0 = runWriterT $ go Representational initRecTc ty0
     go_tc_app role rec_nts tc tys
         -- We don't want to look through the IO newtype, even if it is
         -- in scope, so we have a special case for it:
-        | tc_key `elem` [ioTyConKey, funPtrTyConKey, fUNTyConKey]
+        | isArrowTyCon tc
+        = children_only
+
+        | tc_key `elem` [ioTyConKey, funPtrTyConKey]
         = children_only
 
         | isNewTyCon tc         -- Expand newtypes


=====================================
compiler/GHC/Tc/Gen/Splice.hs
=====================================
@@ -2143,8 +2143,10 @@ reifyTyCon tc
   | Just cls <- tyConClass_maybe tc
   = reifyClass cls
 
+{-  Seems to be just a short cut for the next equation -- omit
   | tc `hasKey` fUNTyConKey -- I'm not quite sure what is happening here
   = return (TH.PrimTyConI (reifyName tc) 2 False)
+-}
 
   | isPrimTyCon tc
   = return (TH.PrimTyConI (reifyName tc) (length (tyConVisibleTyVars tc))


=====================================
compiler/GHC/Tc/Solver/Canonical.hs
=====================================
@@ -952,7 +952,8 @@ second time around.
 Also note that we require the AnonArgFlag to match.  This will stop
 us decomposing
    (Int -> Bool)  ~  (Show a => blah)
-It's as if we treat (->) and (=>) as different type constructors.
+It's as if we treat (->) and (=>) as different type constructors, which
+indeed they are!
 -}
 
 canEqNC :: CtEvidence -> EqRel -> Type -> Type -> TcS (StopOrContinue Ct)


=====================================
compiler/GHC/Types/Basic.hs
=====================================
@@ -1881,7 +1881,7 @@ isKindLevel KindLevel = True
 ********************************************************************* -}
 
 {- The types `Levity` and `TypeOrConstraint` are internal to GHC.
-   They are the same shape as the eponomyous types in the library
+   They have the same shape as the eponymous types in the library
       ghc-prim:GHC.Types
    but they aren't the same types -- after all, they are defined in a
    different module.



View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/f0b0153422736168deb606751f6f5f4f703c409e...ca80f62bd98dcbfab3e45da7dbfc85e734c0c6ee

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/f0b0153422736168deb606751f6f5f4f703c409e...ca80f62bd98dcbfab3e45da7dbfc85e734c0c6ee
You're receiving this email because of your account on gitlab.haskell.org.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-commits/attachments/20220829/7f7324b8/attachment-0001.html>


More information about the ghc-commits mailing list