Alex Crichton (Feb 27 2024 at 20:19): Alex Crichton (Feb 27 2024 at 20:19):@Dan Gohman is https://github.com/bytecodealliance/wit-bindgen/pull/870 only blocked on a wasm-tools release?
Dan Gohman (Feb 27 2024 at 20:20):Yes; I've tested it with a local dependency.
Alex Crichton (Feb 27 2024 at 20:20):Could I perhaps recruit you as a guinea pig to do a wasm-tools release without me?
Dan Gohman (Feb 27 2024 at 20:20):Sure
Alex Crichton (Feb 27 2024 at 20:20):in the theory that the recent changes should make it much simpler
Alex Crichton (Feb 27 2024 at 20:21):ok then in the hopes that it can be done without me I'm going to say "alright it's on you now" and do nothing else
Alex Crichton (Feb 27 2024 at 20:21):or at least try to do nothing else :)
Dan Gohman (Feb 27 2024 at 20:21):Ok, I'll give it a try!
Dan Gohman (Feb 27 2024 at 20:25):Ok, we have https://github.com/bytecodealliance/wasm-tools/pull/1427
Alex Crichton (Feb 27 2024 at 20:25):I'm contractually obliged to have no comment
Dan Gohman (Feb 27 2024 at 20:44):it is a little silly to think about the number of times CI runs on exactly the same codebase
Alex Crichton (Feb 27 2024 at 20:45):it's ok we just say "that's not my problem for today"
Dan Gohman (Feb 27 2024 at 20:45):oh totally, just musing
Alex Crichton (Feb 27 2024 at 20:45):I'd like to set up something Wasmtime-like where PRs only run a subset of CI, but it was kind of hard to do that in wasmtime
Alex Crichton (Feb 27 2024 at 20:45):in infra in rust I was always convinced that 90% of rust/crate downloads are from CI
Alex Crichton (Feb 27 2024 at 20:46):probably from like the same set of machines that are all used on github actions
Dan Gohman (Feb 27 2024 at 20:53):and we're done!
Alex Crichton (Feb 27 2024 at 20:53):huzzah it worked!
Christof Petig (Feb 28 2024 at 06:39):@Dan Gohman congratulations, this was very fast!
In the same time I was only able to get to a working prototype of the c++ binding on 64bit with lots of open codegen issues I hand-patched around. Now I need to clean it up to get closer to releasable state.
But this PoC was only possible leveraging your ground work in wasm tools. :bouquet:
Alex Crichton (Feb 28 2024 at 19:47):@Dan Gohman I hit this panic when testing if Wasmtime worked with wit-bindgen main now that this provenance work has landed. I think there's some missing bitcasts in there.
I started to write a test for tests/codegen/*.wit and got as far as:
package test:variants-unioning-types;
world a {
variant v1 {
a(list<u8>),
b(tuple<u32, u32>),
}
import f1: func(x: v1);
variant v2 {
a(list<u8>),
b(tuple<f32, f32>),
}
import f2: func(x: v2);
}
but I fear that this rabbit hole may be a bit deeper than I imagined. Would you be up for filling out that test and the panics there?
Alex Crichton (Feb 28 2024 at 19:48):basically I think more conversions need to be handled in the into-and-out-of pointer/length cases
Dan Gohman (Feb 28 2024 at 19:48):Ah, ok. Yeah, I'll write more tests for variants and implement them.
Alex Crichton (Feb 28 2024 at 19:49):ok cool, thanks!
Alex Crichton (Feb 28 2024 at 19:49):all of these cases are already handled by join in wasm-tools so no need to touch things there, I think it's basically more of those join cases that need to be reflected in the bitcasts
Dan Gohman (Feb 28 2024 at 19:50):Cool, should be straightforward then
Alex Crichton (Feb 28 2024 at 19:51):we can theoretically generate these tests with wasm-tools wit-smith and then use that to fuzz the bindings generators
Alex Crichton (Feb 28 2024 at 19:51):but honestly I'm afraid of the volume of bugs when hooking up bindings generators to the fuzzer
Dan Gohman (Feb 28 2024 at 20:49):Ok, https://github.com/bytecodealliance/wit-bindgen/pull/872 is up. It's straightforward, but there are getting to be a lot of bitcasts. I'm thinking about whether to remove the Bitcast enum and just have each backend match on the (to, from) pair itself.
Alex Crichton (Feb 28 2024 at 21:01):(following up on the PR)
Last updated: Nov 22 2024 at 17:03 UTC