Problem:
Two attempted migrations in #6613 were reverted because ChildTyper
constraints lose the sharedness dimension. Type::isSubType
distinguishes shared from unshared heap types, but two of
ChildTyper'svisitors emit constraints that do not carry that distinction, so a validator usingPrincipalType::matches` rejects
inputs the pre-migration code accepted.
Case 1: visitI31Get. ChildTyper::visitI31Get emits
Type(HeapType::i31, Nullable), fixed to unshared. The validator's
pre-existing check uses shouldBeSubTypeIgnoringShared, which
accepts (ref null (shared i31)) as a subtype. Migrating rejects
shared i31 modules. Failing tests: basic/shared-i31.wast,
passes/make-shared-objects.wast, passes/unsubtyping.wast.
Case 2: visitCallRef. ChildTyper::visitCallRef computes
ht = curr->target->type.getHeapType().getSignature() and notes
the target as Type(*ht, Nullable). For a shared function reference
(ref null (shared $sig)), getSignature() returns the unshared
$sig, so the note rejects the shared target. Failing tests: 25
lit tests including passes/gufa-refs.wast,
passes/signature-pruning.wast, passes/type-generalizing.wast, and
passes/dae2*.wast.
Impact:
These two methods cannot be migrated to ChildTyper until the
constraints carry sharedness. A third case may exist: any
ChildTyper visitor that uses Type(HeapType::X, ...) with a
concrete heap type is potentially affected, and only sharedness
testing exposes it.
Proposed fix (Path A): Introduce a sharedness-polymorphic
constraint. The machinery already exists — VarSharedness, and the
VarAbsHeapType variant used by ChildTyper::visitRefEq — but the
affected visitors use concrete Type rather than VarRef with a
sharedness variable. Change ChildTyper::visitI31Get to emit a
VarRef whose heap type is var-shared i31, and change
ChildTyper::visitCallRef to preserve the target's sharedness when
computing the signature heap type.
Path A affects the IRBuilder, not just the validator. The IR
builder consumes the same constraints when parsing; a constraint
that is more permissive on sharedness may change parse-time
behavior. Any change should be verified against
python3 check.py and against the parser tests specifically.
Alternatives considered:
Path B: Add a mode to PrincipalType::matches that ignores
sharedness, mirroring shouldBeSubTypeIgnoringShared. Rejected
because it would make the validator accept malformed modules the
spec rejects, and because the parser has the same constraint
semantics and would diverge.
Path C: Leave the two methods unmigrated. This is the current
state after #6613's partial PR. Acceptable as a stopgap; not a
long-term answer, since the same incompatibility will recur for
every new shared-type visitor.
Follow-up: After Path A lands, re-attempt the visitI31Get and
visitCallRef migrations in #6613.
Refs #6613.
Problem:
Two attempted migrations in #6613 were reverted because ChildTyper
constraints lose the sharedness dimension.
Type::isSubTypedistinguishes shared from unshared heap types, but two of
ChildTyper's
visitors emit constraints that do not carry that distinction, so a validator usingPrincipalType::matches` rejectsinputs the pre-migration code accepted.
Case 1:
visitI31Get. ChildTyper::visitI31GetemitsType(HeapType::i31, Nullable), fixed to unshared. The validator'spre-existing check uses
shouldBeSubTypeIgnoringShared, whichaccepts
(ref null (shared i31))as a subtype. Migrating rejectsshared i31 modules. Failing tests:
basic/shared-i31.wast,passes/make-shared-objects.wast,passes/unsubtyping.wast.Case 2:
visitCallRef. ChildTyper::visitCallRefcomputesht = curr->target->type.getHeapType().getSignature()and notesthe target as
Type(*ht, Nullable). For a shared function reference(ref null (shared $sig)), getSignature()returns the unshared$sig, so the note rejects the shared target. Failing tests: 25lit tests including
passes/gufa-refs.wast,passes/signature-pruning.wast,passes/type-generalizing.wast, andpasses/dae2*.wast.Impact:
These two methods cannot be migrated to
ChildTyperuntil theconstraints carry sharedness. A third case may exist: any
ChildTypervisitor that usesType(HeapType::X, ...)with aconcrete heap type is potentially affected, and only sharedness
testing exposes it.
Proposed fix (Path A): Introduce a sharedness-polymorphic
constraint. The machinery already exists —
VarSharedness, and theVarAbsHeapTypevariant used byChildTyper::visitRefEq— but theaffected visitors use concrete Type rather than VarRef with a
sharedness variable. Change
ChildTyper::visitI31Getto emit aVarRefwhose heap type isvar-shared i31, and changeChildTyper::visitCallRefto preserve the target's sharedness whencomputing the signature heap type.
Path A affects the
IRBuilder, not just the validator. The IRbuilder consumes the same constraints when parsing; a constraint
that is more permissive on sharedness may change parse-time
behavior. Any change should be verified against
python3 check.pyand against the parser tests specifically.Alternatives considered:
Path B: Add a mode to
PrincipalType::matchesthat ignoressharedness, mirroring
shouldBeSubTypeIgnoringShared. Rejectedbecause it would make the validator accept malformed modules the
spec rejects, and because the parser has the same constraint
semantics and would diverge.
Path C: Leave the two methods unmigrated. This is the current
state after #6613's partial PR. Acceptable as a stopgap; not a
long-term answer, since the same incompatibility will recur for
every new shared-type visitor.
Follow-up: After Path A lands, re-attempt the
visitI31GetandvisitCallRefmigrations in #6613.Refs #6613.