-
Notifications
You must be signed in to change notification settings - Fork 1.6k
feat: begin wasip3 implementation #11221
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
feat: begin wasip3 implementation #11221
Conversation
c904ef4 to
8549fc5
Compare
|
#11127 has been added to the merge queue, so looks like I'll have to rebase this on Monday, moving back to draft |
alexcrichton
left a comment
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.
A few minor thoughts here and there, but overall looks great, thank you @rvolosatovs! With #11127 merged as well mind removing the #[ignore] on the tests to confirm they pass too?
8549fc5 to
2185f9d
Compare
2185f9d to
c822293
Compare
c822293 to
9d79694
Compare
Signed-off-by: Roman Volosatovs <[email protected]>
Signed-off-by: Roman Volosatovs <[email protected]>
Signed-off-by: Roman Volosatovs <[email protected]>
Signed-off-by: Roman Volosatovs <[email protected]>
Signed-off-by: Roman Volosatovs <[email protected]>
Signed-off-by: Roman Volosatovs <[email protected]>
Signed-off-by: Roman Volosatovs <[email protected]>
ref bytecodealliance#11245 Signed-off-by: Roman Volosatovs <[email protected]>
- hide `CommandPre`, since it is currently unusable bytecodealliance#11249 - use `Command::new` directly in examples, since `instantiate_async` does not provide a way to call an export Signed-off-by: Roman Volosatovs <[email protected]>
Signed-off-by: Roman Volosatovs <[email protected]>
9d79694 to
63a9517
Compare
|
@alexcrichton review comments addressed, mind giving this another look? |
* ci: add subdir support Signed-off-by: Roman Volosatovs <[email protected]> * feat: extract common `WasiCtxBuilder` Signed-off-by: Roman Volosatovs <[email protected]> * chore: vendor p3 WIT Signed-off-by: Roman Volosatovs <[email protected]> * feat: begin wasip3 implementation Signed-off-by: Roman Volosatovs <[email protected]> * chore(wasip3): remove now-redundant async stubs Signed-off-by: Roman Volosatovs <[email protected]> * test(wasip3): link wasip2 Signed-off-by: Roman Volosatovs <[email protected]> * refactor: `allow` -> `expect` Signed-off-by: Roman Volosatovs <[email protected]> * chore: add bindgen `tracing` issue ref ref bytecodealliance#11245 Signed-off-by: Roman Volosatovs <[email protected]> * chore: adapt to `Accessor` API changes - hide `CommandPre`, since it is currently unusable bytecodealliance#11249 - use `Command::new` directly in examples, since `instantiate_async` does not provide a way to call an export Signed-off-by: Roman Volosatovs <[email protected]> * doc: add a link to p3 `add_to_linker` Signed-off-by: Roman Volosatovs <[email protected]> --------- Signed-off-by: Roman Volosatovs <[email protected]>
This starts the process of moving wasip3 implementation from https://github.com/bytecodealliance/wasip3-prototyping/tree/0bcd54e714e70dbee4dd2d440abb3017997a061e/crates/wasi
wasi:clockstimezoneinterface is not implemented yetwasi:randomadd stubs forAccess::getandAccessor::with.for now, these are implemented directly in the file they're used in to avoid an import. There is only one occurrence where we need these in this PR and the hoping is that by the time next PR lands, we'll have them available in the runtime.but ignore them, since async machinery still panics.the tests are adapted from analogous p2 testsWasiCtxBuilderto use for both p2 and p3. Unfortunately, inheritance is sort of tricky here - I originally hoped to implementDerefon the p2/p3 builders, but that breaks the chaining that users are used to, e.g.builder.inherit_env().build()would not work, sinceinherit_envwould return a reference to the inner builder, rather than the outer one. Just duplicate the methods for p2 and p3 for now - let's revisit once we have all of the interfaces implemented and more context on how we can handle this. A macro is potential solution. The reason these contexts are different types is primarily stdio - the abstractions are very different for wasip2 and wasip3.closes #10061
closes #10063
refs bytecodealliance/wasip3-prototyping#228