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

Copy some of the WASI Rust tests from wasmtime #32

Merged
merged 7 commits into from
Jan 20, 2023
Merged

Conversation

loganek
Copy link
Collaborator

@loganek loganek commented Dec 8, 2022

No description provided.

@loganek loganek force-pushed the loganek/rust-tests branch from 9df0046 to bfd68ac Compare December 9, 2022 15:24
@yamt
Copy link
Contributor

yamt commented Dec 11, 2022

why not all of them?
what was the criteria?

@loganek
Copy link
Collaborator Author

loganek commented Dec 13, 2022

For now I only migrated tests starting from A to F; haven't done all of them to get early feedback before I spend more time on that.

@yamt
Copy link
Contributor

yamt commented Dec 13, 2022

For now I only migrated tests starting from A to F; haven't done all of them to get early feedback before I spend more time on that.

ok. it makes sense.

i have concerns on some of test cases: #24 (comment)

@loganek loganek force-pushed the loganek/rust-tests branch from bfd68ac to d5ef781 Compare January 3, 2023 17:53
@loganek
Copy link
Collaborator Author

loganek commented Jan 3, 2023

For now I only migrated tests starting from A to F; haven't done all of them to get early feedback before I spend more time on that.

ok. it makes sense.

i have concerns on some of test cases: #24 (comment)

Thanks, I've taken the ones related to this PR into account.

@@ -27,7 +27,7 @@ unsafe fn test_directory_seek(dir_fd: wasi::Fd) {
wasi::fd_seek(fd, 0, wasi::WHENCE_CUR)
.expect_err("seek on a directory")
.raw_error(),
wasi::ERRNO_BADF
wasi::ERRNO_ISDIR
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i guess it's more reasonable to accept both.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd rather have tests very specific so implementers can use it as a guidance. IIRC @sunfishcode will look into changing that in wasmtime, do you know of any other runtime where the error code for this case is BADF?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd rather have tests very specific so implementers can use it as a guidance.

without having it in the spec itself? why?

IIRC @sunfishcode will look into changing that in wasmtime, do you know of any other runtime where the error code for this case is BADF?

toywasm. (because it followed wasmtime)

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

without having it in the spec itself? why?

There's no error code mentioned in spec itself, so are you suggesting we should just check if there's any error, and ignore its value? I don't mind doing it either way, but I think even if the spec doesn't mention the value of the error code, we can still have a specific assertion here, and use it as a guidance for the future spec changes.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

my suggestion is

  • accept both values here for now (not necessarily "any error". probably just BADF and ISDIR are enough.)
  • start mentioning error codes in the spec

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok, I updated it so it accepts BADF, ISDIR and NOTCAPABLE (this one is returned by WAMR).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

although NOTCAPABLE sounds very awkward to me, i guess it isn't a problem in this PR

The return value is not documented so we allow for a few reasonable
error codes here.
So we fail the script if one of the test doesn't compile
@loganek loganek force-pushed the loganek/rust-tests branch from d5ef781 to 0b39314 Compare January 4, 2023 15:52
@loganek loganek requested a review from yamt January 5, 2023 13:53
@loganek
Copy link
Collaborator Author

loganek commented Jan 10, 2023

@sunfishcode / @yamt let me know if you have any more comments, otherwise I'll go ahead and merge that (we can always update the code if needed).

@sunfishcode
Copy link
Member

Looks good to me; we can iterate from here.

I also agree that ENOTCAPABLE is awkward. WASI inherited it from CloudABI, and within WASI at least, it hasn't turned out to be useful, because most application code isn't expecting it. So I think we want to migrate away from using it in general. But it's fine to accept here for now.

@loganek loganek merged commit 63c7dc1 into main Jan 20, 2023
@loganek loganek deleted the loganek/rust-tests branch January 20, 2023 15:31
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

Successfully merging this pull request may close these issues.

3 participants