ChildTyper constraints drop sharedness, blocking validator migration
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 35/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- wasm
- Domain
- compilers, testing-qa
Research direction
Start with ChildTyper::visitI31Get and visitCallRef, then read VarSharedness, VarAbsHeapType, and the IRBuilder constraint path. Run python3 check.py and inspect the named shared-i31, make-shared-objects, unsubtyping, gufa-refs, signature-pruning, type-generalizing, and dae2* tests, plus parser tests. Done means sharedness is preserved without introducing parser or validator regressions.
Written by the indexing model from the issue text.
Description
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.
- Dominant language
- WebAssembly
- Stars
- 8.6k
- Forks
- 885
- Avg merge
- 2d 4h
- Merged PRs (30d)
- 77
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from WebAssembly/binaryen
-
Difficulty 1/5 Under an hour Newbie friendliness 88/100
WebAssembly/binaryen#9135 · 1 comment ·
-
Difficulty 2/5 Half a day Newbie friendliness 76/100
WebAssembly/binaryen#9018 · 3 comments ·
-
Difficulty 5/5 Over a week Newbie friendliness 25/100
WebAssembly/binaryen#9133 ·
-
Difficulty 4/5 3-5 days Newbie friendliness 52/100
WebAssembly/binaryen#9123 ·
-
Difficulty 4/5 3-5 days Newbie friendliness 48/100
WebAssembly/binaryen#9086 · 2 comments ·
All issues in WebAssembly/binaryen
Similar issues
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
bradcypert/plum#58 ·
-
flang:fir-hlfir
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
llvm/llvm-project#225935 ·
-
area:cards hand-tail ready-for-agent
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
fil-donadoni/tolaria#4446 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
objectionary/eo#8923 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100