Repository navigation
Reference types for phase 4? #61
Description
After going through the open issues, there appear to be two substantive core language issues (#55, #60), both of which can probably be postponed if we want to or if we can't find agreement quickly. There is one corner case (#40) that should probably be resolved in favor of current behavior, because sentiment in the discussion is tilting in that direction. The JS API also has a small number of mop-up issues that may or may not already be done (#9, #20, #22, #51); investigating. The remaining open issues are discussion items or feature requests that have been postponed.
The process document requires these for phase 4 (with my comments about status):
- Two or more Web VMs implement the feature.
- Firefox is tracking the spec, as is Chrome, I believe. @mstarzinger?
- At least one toolchain implements the feature.
- Don't know what the status is here. @alexcrichton @kripken @sbc100, comments?
- The formalization and the reference interpreter are usually updated
- These seem fine to me, @rossberg do you believe we're complete, modulo issues listed above?
- Community Group has reached consensus in support of the feature.
- We have to have a poll to gauge this
We may need to ship bulk memory at the same time, as the two proposals touch in various ways, but if anything that proposal is even closer to a shipping state.
Activity
rossberg commentedon Nov 15, 2019
I'm afraid #31 is still open in terms of incorporating it into the proposal, see my latest comment there.
gahaas commentedon Nov 15, 2019
Chrome/V8 is passing all spec tests at the moment.
alexcrichton commentedon Nov 15, 2019
The Rust and WebAssembly toolchain, specifically
wasm-bindgen, does have support for reference types. There is not native support in the Rust compiler itself (nor LLVM, although that is being worked on). The support inwasm-bindgenis definitely "MVP status" where it doesn't really exercise a huge amount of features of the reference types proposal, largely just growing tables and get/set in tables.That being said though it is well tested (against Node) and should be ready to ship and/or promote to a stable feature of the toolchain! A lot of the surrounding tooling has support for it too such as
wabt, Rust toolchain crates, etc.sbc100 commentedon Nov 15, 2019
I'm hoping to land the final PRs in
wabtto allow it to pass all the current spec tests today.aheejin commentedon Nov 15, 2019
I’m working on Binaryen support.
tlively commentedon Nov 15, 2019
Binaryen support alone is enough to get AssemblyScript working, but I'm not sure what their roadmap is for supporting reference types. cc @dcodeIO who can supply more AssemblyScript information.
dcodeIO commentedon Nov 16, 2019
AssemblyScript supports the opaque anyref type as implemented in Binaryen behind
--enable reference-types, that is one can declare variables and function parameters of typeanyrefand pass these around. Limitations are that one can't currently store anyrefs in non-imported globals because we are missing a way to initialize them (thinkingref.null) before these are set for the first time, one can't compare them (ref.is_null,ref.eq) and there is no table support yet. Expectation is that we are overly thrilled to follow close as soon as the respective bits land in Binaryen :)[Interpreter] Handle 0-byte copies properly. (#61)
rossberg commentedon Jan 16, 2020
I rebased this proposal on the bulk proposal and filled the gaps between the two. Also implemented declarative element segments (#31) and addressed remaining todos in core spec and interpreter.
Remaining technical tasks for phase 4:
Other than that, the main open issue is #69, which is recent and awaiting more feedback from @lukewagner.
aheejin commentedon Jan 16, 2020
Toolchain support is not complete yet. Emscripten (including LLVM + Binaryen) has a partial support:
eqrion commentedon May 21, 2020
The two major issues blocking this, #69 and #76, are now resolved. Spidermonkey has updated our implementation for the latest changes. At least one toolchain, wasm-bindgen, implements the spec and is up to date with the latest changes. I believe the reference interpreter is up to date with all agreed upon changes.
Are there any other issues that should block us from moving this feature to phase 4 now?
I see WebAssembly/design#1343 mentioned an impact on this proposal, but appears to have reached a conclusion that it doesn't need to block this proposal. Is that accurate @RossTate?
RossTate commentedon May 21, 2020
Yep!
rossberg commentedon May 25, 2020
I created a PR to add it tomorrow's agenda.
binji commentedon Jun 24, 2020
🎉 Reference types advanced to phase 4 in the June 23rd CG meeting! 🎉