-
Notifications
You must be signed in to change notification settings - Fork 19
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
Port more tests from Wasmtime's testsuite #68
Port more tests from Wasmtime's testsuite #68
Conversation
Following up on ac32f57, port several more tests from Wasmtime's testsuite to wasi-testsuite. It is likely that at least some of these tests are testing behavior which differs between Wasm engine implementations. The intent here is not to instate these as authoritative, but to help surface these differences so that we can discuss whether it's best to change the test, or add documentation to the spec. Other Wasm engines are welcome to submit their tests to wasi-testsuite as well.
@sunfishcode thanks for the PR. Do you already have a list of checks in the test that is not currently documented in the spec? I think that'd help with the discussion. |
I don't have such a list, but realistically, it's probably almost everything isn't documented yet. I don't think a complete specification of all behavior is realistic in the short term, so I'm proposing we focus on resolving incompatibilities and documenting the resolutions. |
right now, tests don't run even on wasmtime on PR. can we please get this fixed? Even if it is ok for some runtimes to fail, I think at least one should be able to pass, and without knowing that it is a hard to justify merging new tests. |
Since the goal is discussion and acknowledged value in beyond wasmtime, I would suggest this:
There have been other changes that went in quickly today, they should have been looked at diversely before merge. Let's get a better practice in. It doesn't have to be as robust as for example Go's process, but it should have some diversity in it considering these rules define a large part of technology. |
"the event.userdata should contain CLOCK_ID", | ||
); | ||
} else if event.type_ == wasi::EVENTTYPE_FD_READ { | ||
assert_errno!(event.error, wasi::ERRNO_SUCCESS); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FYI, i ended up with this: yamt/toywasm@570e670
is it intentional that this batch doesn't include |
My idea here was just to port a lot of tests over to get things started, so I left out a few tests that I anticipated would be more involved. |
After reviewing those tests now I think it makes sense to have them merged. If there are any points for discussions, please open separate issue or PR. |
* I couldn't find this in wasmtime repo. I suppose this was a local modification done as a part of WebAssembly#68 * As some implementations have implemented it, it isn't appropriate to assert NOTSUP by default.
* I couldn't find this in wasmtime repo. I suppose this was a local modification done as a part of #68 * As some implementations have implemented it, it isn't appropriate to assert NOTSUP by default.
Following up on ac32f57, port several more tests from Wasmtime's testsuite to wasi-testsuite.
It is likely that at least some of these tests are testing behavior which differs between Wasm engine implementations. The intent here is not to instate these as authoritative, but to help surface these differences so that we can discuss whether it's best to change the test, or add documentation to the spec.
Other Wasm engines are welcome to submit their tests to wasi-testsuite as well.