-
Notifications
You must be signed in to change notification settings - Fork 628
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
Enable WASI tests on Windows CI #2699
Enable WASI tests on Windows CI #2699
Conversation
486bedf
to
4046d63
Compare
ba70ea5
to
19af6f3
Compare
DWORD win_error = GetLastError(); | ||
if (win_error != ERROR_IO_PENDING) { | ||
error = convert_windows_error_code(win_error); | ||
break; |
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.
Is this an error, shall we check whether i == iovcnt
or error
after the for loop to check whether there was an error?
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.
Not sure if I'm understanding fully but even if there is an error for one of the read operations, we should still wait on the previous successful read operations. successful_read_count
is used to make sure we only wait on the operations which were started successfully.
GetOverlappedResult(handle, &read_operations[j], | ||
&bytes_transferred, true); | ||
} | ||
break; |
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.
Same as above
DWORD win_error = GetLastError(); | ||
if (win_error != ERROR_IO_PENDING) { | ||
error = convert_windows_error_code(win_error); | ||
break; |
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.
Same as above
d60fbff
to
da5ce7f
Compare
In order to start running WASI tests in CI on Windows, add the ability to filter WASI tests in the test runner scripts. The WASI libc implementation is not yet complete on Windows so not all the tests are passing. Once the implementation is complete, we can remove the filter (although it's probably still useful to keep the filtering functionality in the test runner either way).
29656c6
to
1997ef6
Compare
#define PATH_SEPARATORS "/\\" | ||
#else | ||
#define PATH_SEPARATORS "/" | ||
#endif |
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.
Not strictly related to this PR but I realized we'll need it on Windows so paths with backslashes are split into components properly. It would probably be good to verify the behaviour of backslashes with an additional WASI test.
f0ae5aa
to
ced80c9
Compare
Most of the WASI filesystem tests require at least creating/deleting a file to test filesystem functionality so some additional filesystem APIs have been implemented on Windows so we can test what has been implemented so far. For those WASI functions which haven't been implemented, we skip the tests. These will be implemented in a future PR after which we can remove the relevant filters. Additionally, in order to run the WASI socket and thread tests, we need to install the wasi-sdk in CI and build the test source code prior to running the tests.
ced80c9
to
8091329
Compare
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.
LGTM
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.
LGTM
13875f4
into
bytecodealliance:dev/wasi-libc-windows
Most of the WASI filesystem tests require at least creating/deleting a file to test filesystem functionality so some additional filesystem APIs have been implemented on Windows so we can test what has been implemented so far. For those WASI functions which haven't been implemented, we skip the tests. These will be implemented in a future PR after which we can remove the relevant filters. Additionally, in order to run the WASI socket and thread tests, we need to install the wasi-sdk in CI and build the test source code prior to running the tests.
I've split this up change into two commits to make it (hopefully!) easier to review.