[js-api] Are Wasm-gc abstract heap types included in the JS API of e.g. WebAssembly.Global?
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 35/100
- Issue type
- Bug
- Clarity
- Needs clarification
- Activity status
- Stale
- Tech stack
- javascript, wasm
Research direction
Start with the JS-API specification's globals section and the wasm-gc MVP-JS.md document, then review the reported V8, SpiderMonkey, and JavaScriptCore behavior. Done means establishing whether abstract heap types belong in the existing JavaScript APIs and recording the resulting specification change or clarification.
Written by the indexing model from the issue text.
Description
The WebAssembly JS-API spec mentions the following types for globals:
enum ValueType {
"i32",
"i64",
"f32",
"f64",
"v128",
"externref",
"anyfunc",
};
However, both V8 and SpiderMonkey support multiple more values like "anyref" or "i31ref".
After some code-search in V8, I found my commit which added it in 2022 when anyref was introduced for wasm-gc as a separate type hierarchy vs. the existing externref.
In later changes we added more of these new types like i31ref probably assuming some kind of consistency to the already present anyref.
It seems that JavaScriptCore doesn't accept these values.
The wasm-gc JS API document does not list any extensions to these existing APIs.
So from a spec perspective, it looks like this is a bug in V8 and SpiderMonkey?
Was it a conscious decision to not add support for the new abstract heap types to the existing JS APIs?
- Dominant language
- WebAssembly
- Stars
- 3.5k
- Forks
- 540
- Avg merge
- 11h 12m
- Merged PRs (30d)
- 11
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing 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/spec
-
Difficulty 3/5 1-2 days Newbie friendliness 68/100
WebAssembly/spec#2245 ·
Maintainers usually reply within 1 day
-
Difficulty 4/5 3-5 days Newbie friendliness 45/100
WebAssembly/spec#2235 · 9 comments ·
Maintainers usually reply within 1 day
-
Difficulty 4/5 3-5 days Newbie friendliness 35/100
WebAssembly/spec#2196 ·
Maintainers usually reply within 1 day
-
Difficulty 4/5 3-5 days Newbie friendliness 48/100
WebAssembly/spec#2155 · 2 comments ·
Maintainers usually reply within 1 day
-
Difficulty 4/5 3-5 days Newbie friendliness 45/100
WebAssembly/spec#2150 · 1 comment ·
Maintainers usually reply within 1 day
All issues in WebAssembly/spec
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
run-llama/llama_index#23278 ·
Maintainers usually reply within 2 days
-
from-review-extraction priority: low python severity:nit
Difficulty 2/5 1-3 hours Newbie friendliness 90/100
LearningCircuit/local-deep-research#6944 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
iMicknl/python-overkiz-api#2263 ·
Maintainers usually reply within 7 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
meshery/meshery#22119 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
sgl-project/sglang#41482 ·
Maintainers usually reply within 1 day