Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

wasm-core-2 Spec 5.5.12. Element Section decoding funcref/func types do not match elem.wast or 3.0 Spec #1854

Closed
kelnishi opened this issue Dec 9, 2024 · 4 comments

Comments

@kelnishi
Copy link

kelnishi commented Dec 9, 2024

When decoding an element section according to 5.5.12. Element Section, the segment type is incorrectly listed as func (ref func) for case 4. This is covered under elem.wast and should be (ref null func) like in the 3.0 draft spec. Posted versions of the core 2.0 spec also have a similar discrepancy where both decode case 0 and case 4 are listed as funcref (ref null func). According to elem.wast testing, the types of case 0 and case 4 differ and should be (ref func) and (ref null func), respectively.

@rossberg
Copy link
Member

rossberg commented Dec 9, 2024

The GC proposal has been merged into the main repo's Wasm 3.0 branch, so the gc repo generally isn't updated with upstream changes anymore. It is correct in the Wasm 3.0 draft.

@rossberg
Copy link
Member

rossberg commented Dec 9, 2024

As for the 2.0 spec, that is correct as is, since non-nullable references do not exist in 2.0 yet. The change in 3.0 (and according tests) is a backwards-compatible refinement.

@kelnishi
Copy link
Author

kelnishi commented Dec 9, 2024

Thank you for the explanation. I've been building against the gc spec and testing with the gc test suite. Maybe I missed it, but I did not see any information on where to find the appropriate spec for a given test suite. I had just assumed that the test suite from gc would have matched the spec that was also it linked in the gc repo's readme.

@kelnishi kelnishi closed this as completed Dec 9, 2024
@rossberg
Copy link
Member

rossberg commented Dec 9, 2024

It was a spec bug in the funcref proposal that got fixed in that repo. Not sure why the fix didn't make it downstream to the GC repo in the first place, might have been some screw-up when resolving merge conflicts. To avoid further confusion, I added it now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants