Skip to content
  • sheaf's avatar
    Do primop rep-poly checks when instantiating · 889c2bbb
    sheaf authored and Marge Bot's avatar Marge Bot committed
    This patch changes how we perform representation-polymorphism checking
    for primops (and other wired-in Ids such as coerce).
    When instantiating the primop, we check whether each type variable
    is required to instantiated to a concrete type, and if so we create a
    new concrete metavariable (a ConcreteTv) instead of a simple MetaTv.
    (A little subtlety is the need to apply the substitution obtained from
    instantiating to the ConcreteTvOrigins, see
    Note [substConcreteTvOrigin] in GHC.Tc.Utils.TcMType.)
    
    This allows us to prevent representation-polymorphism in non-argument
    position, as that is required for some of these primops.
    
    We can also remove the logic in tcRemainingValArgs, except for
    the part concerning representation-polymorphic unlifted newtypes.
    The function has been renamed rejectRepPolyNewtypes; all it does now
    is reject unsaturated occurrences of representation-polymorphic newtype
    constructors when the representation of its argument isn't a concrete
    RuntimeRep (i.e. still a PHASE 1 FixedRuntimeRep check).
    The Note [Eta-expanding rep-poly unlifted newtypes] in GHC.Tc.Gen.Head
    gives more explanation about a possible path to PHASE 2, which would be
    in line with the treatment for primops taken in this patch.
    
    We also update the Core Lint check to handle this new framework. This
    means Core Lint now checks representation-polymorphism in continuation
    position like needed for catch#.
    
    Fixes #21906
    
    -------------------------
    Metric Increase:
        LargeRecord
    -------------------------
    889c2bbb