Incoming breaking change · cargo-component

Stream: cargo-component

Topic: Incoming breaking change

Peter Huene (Mar 01 2024 at 19:31):

Just a heads up that I will be publishing 0.9.0 of cargo-component shortly, which will include a breaking change introduced with wit-bindgen 0.20.0.

It was decided that we'd return to using a generated export! macro that accepts the name of the type implementing the world (typically Component in cargo-component projects).

This was done for good reason: now the generated code does not refer to any user-defined types directly and it also moves naming the implementing types out of Cargo.toml into type-checked Rust source.

Besides adding this macro invocation to your cargo-component projects, there are additional steps to take if you're implementing worlds that export resources: a trait-associated type now names the type implementing the resource.

I'll have detailed instructions in the release notes.

Alex Crichton (Mar 01 2024 at 19:47):

Apologies again for the whiplash here on generated bindings and effort in cargo component to adapt to this, but my hope is that this is well worth the change!

Peter Huene (Mar 01 2024 at 19:59):

@Alex Crichton now that we have most of what was in the rt module of wit-bindgen now generated, do you think it might be possible to refactor the realloc feature out as a separate crate that we could reexport from wit-bindgen (and also perhaps the reexport of bitflags), like a wit-bindgen-rt crate?

The reason I ask is that currently cargo-component user projects add a wit-bindgen dependency with no-default-features and features = ["realloc"]; this happens via an implicit cargo add when cargo component new is run.

However, if a user specifies the dependency at the workspace level, cargo add refuses to add it at a workspace member level because of no-default-features (despite being set the same).

If we had a crate that exported everything we needed for "runtime" that we could activate without feature flags, I think that would probably be a better DX; cargo-component would just add a dependency to the "rt" crate and not wit-bindgen at all (we still have Opts::runtime_path that cargo-component can use to switch it to wit_bindgen_rt or whatever in the bindings).

Alex Crichton (Mar 01 2024 at 20:05):

I like that idea yeah, I can work on adding that :+1:

Alex Crichton (Mar 01 2024 at 20:26):

https://github.com/bytecodealliance/wit-bindgen/pull/876

Move `cabi_realloc` to a `wit-bindgen-rt` crate by alexcrichton · Pull Request #876 · bytecodealliance/wit-bindgen

This commit extracts out a wit-bindgen-rt crate which unconditionally provides the cabi_realloc function. This'll exist for cargo component to add a dependency on and otherwise the wit-bindgen crat...

Peter Huene (Mar 01 2024 at 21:05):

One last thing: would it be possible to kick off a publish job to get 0.20.0 of wit-bindgen-rt on crates.io? While it won't be used (reexported) from wit-bindgen until 0.21.0, a 0.20.0 of wit-bindgen-rt would allow me to switch cargo component new over to it as part of this breaking change release

crates.io: Rust Package Registry