Skip to content

Do primop rep-poly checks when instantiating

sheaf requested to merge sheaf/ghc:T21868 into master

Main ticket: #21906 (closed). See also #21868.

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 TauTv.

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#.

Edited by sheaf

Merge request reports