Update to the next version of the witx crate #2659
Conversation
|
Oh and one other change with this PR, some errors which were previously classified as EINVAL or similar are now classified as traps. For example if you return a bad return pointer and we fail trying to write to it we'll generate a trap instead of returning EINVAL. |
Subscribe to Label Actioncc @kubkon
This issue or pull request has been labeled: "wasi"
Thus the following users have been cc'd because of the following labels:
To subscribe or unsubscribe from this label, edit the |
|
Looks like https://github.com/bytecodealliance/wasmtime/pull/2659/checks?check_run_id=1921259948 is the same type of error that I saw in @sunfishcode's PR... I told him that I am willing to take a look at upgrading the witx for wasi-nn but that may not be the only thing going wrong here. Let me know if you need me to take a look. |
| fn try_from(value: #abi_repr) -> Result<#ident, #rt::GuestError> { | ||
| #ident::try_from(value as #repr) | ||
| fn try_from(value: #abi_repr) -> Result<Self, #rt::GuestError> { | ||
| #ident::try_from(#repr::try_from(value)?) |
| @@ -299,7 +299,7 @@ impl SumIntAndPtrExercise { | |||
| self.return_loc.ptr as i32, | |||
| ); | |||
|
|
|||
| assert_eq!(res, Ok(types::Errno::Ok.into()), "sum of int and ptr errno"); | |||
| assert_eq!(res, Ok(types::Errno::Ok as i32), "sum of int and ptr errno"); | |||
There was a problem hiding this comment.
@pchickey do you have thoughts on adding back the to/from abi repr traits? I originally removed them because I figured it was good to trim things down to just the in-memory type to avoid too many conversions being available, but it ended up showing up a good amount in tests.
There was a problem hiding this comment.
I'm fine with either - using as in tests is OK with me, or maybe we should do types::Errno::try_from(res).unwrap() on the lhs? If you don't want to provide too many From impls maybe define a FromAbi trait in wiggle that has the same shape, but has docs saying its just for wiggle use?
|
@abrown no worries, I'll probably need to send a merge change to the wasi-nn repo once the wasi changes land which updates the witx as well. I don't mind doing that inline here as well. |
This commit updates to the 0.9 version of the witx crate implemented in WebAssembly/WASI#395. This new version drastically changes code generation and how we interface with the crate. The intention is to abstract the code generation aspects and allow code generators to implement much more low-level instructions to enable more flexible APIs in the future. Additionally a bunch of `*.witx` files were updated in the WASI repository. It's worth pointing out, however, that `wasi-common` does not change as a result of this change. The shape of the APIs that we need to implement are effectively the same and the only difference is that the shim functions generated by wiggle are a bit different.
alexcrichton
force-pushed
the
witx-next
branch
from
21fecee
to
6fa95d4
Compare
|
Ok all submodules have been merged and this is now updated, so this is ready for merge when approved |
|
Looking good! |
|
And thanks @alexcrichton for the changes to wasi-nn as well! |
This commit updates to the 0.9 version of the witx crate implemented in
WebAssembly/WASI#395. This new version drastically changes code
generation and how we interface with the crate. The intention is to
abstract the code generation aspects and allow code generators to
implement much more low-level instructions to enable more flexible APIs
in the future. Additionally a bunch of
*.witxfiles were updated inthe WASI repository.
It's worth pointing out, however, that
wasi-commondoes not change asa result of this change. The shape of the APIs that we need to implement
are effectively the same and the only difference is that the shim
functions generated by wiggle are a bit different.