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

Adding tests #2

Open
sbc100 opened this issue Sep 30, 2020 · 5 comments
Open

Adding tests #2

sbc100 opened this issue Sep 30, 2020 · 5 comments

Comments

@sbc100
Copy link
Member

sbc100 commented Sep 30, 2020

Since initial support was added to binaryen (#1) I decided to add preliminary support to wabt : WebAssembly/wabt#1554

I wonder if its time to add some tests here and try to move this proposal forward to the next stage?

@tlively
Copy link
Member

tlively commented Apr 10, 2024

@rossberg, do we have precedent for how we would even test the extended name section?

@yuri91
Copy link

yuri91 commented Apr 10, 2024

@tlively in the annotations proposal the reference interpreter is extended to handle arbitrary custom sections (and annotations).

here is the handler for the name section: https://github.com/WebAssembly/annotations/blob/main/interpreter/custom/handler_name.ml

and corresponding tests: https://github.com/WebAssembly/annotations/blob/main/test/custom/name/name_annot.wast

a custom handler can do any validation it wishes, and in the tests one can write a regular (module ...) block, (for tests that should pass parsing and validation), and assert_malformed_custom / assert_invalid_custom for tests that should fail.

The tests for name are currently quite basic and should probably include binary modules and not only text ones, but you get the idea.

The ones for branch hinting are here: https://github.com/WebAssembly/branch-hinting/blob/main/test/custom/metadata.code.branch_hint/branch_hint.wast

What is needed is a way to represent the section in the text format. This can be either a corresponding annotation, or the generic @custom annotation.

If we are going to remove the @name annotation, then we can still use @custom since the name section does not depend on the binary representation of the rest of the module.

@rossberg
Copy link
Member

What @yuri91 said, i.e., not until now, but there is infrastructure for validating and round-tripping custom sections in the annotations repo. So perhaps it's easiest to rebase on that proposal.

However, that repo is a bit outdated, and I'm currently in the process of syncing it with upstream (which is a bit painful since we switched parsers upstream). Will let you know here when I'm done.

@rossberg
Copy link
Member

Okay, that was really painful, but this repo is now up to date with upstream.

@tlively
Copy link
Member

tlively commented Apr 10, 2024

Thank you, both!

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

4 participants