Fix some minor `bindgen!` issues with `anyhow: true` (#12657)

* Fix some minor `bindgen!` issues with `anyhow: true`

Found when updating Spin to Wasmtime 42.0.0 where some cases weren't
handled:

*

Fix some minor `bindgen!` issues with `anyhow: true` (#12657)

* Fix some minor `bindgen!` issues with `anyhow: true`

Found when updating Spin to Wasmtime 42.0.0 where some cases weren't
handled:

* Trappable functions with no result.
* Resource destructors.
* Functions with custom trappable errors.

* Shuffle some features

show more ...

Migrate the `wasmtime` crate to `wasmtime_environ::error::*` (#12231)

* Migrate the `wasmtime` crate to `wasmtime_environ::error::*`

Instead of `anyhow::Error`.

This commit re-exports the `wasmtim

Migrate the `wasmtime` crate to `wasmtime_environ::error::*` (#12231)

* Migrate the `wasmtime` crate to `wasmtime_environ::error::*`

Instead of `anyhow::Error`.

This commit re-exports the `wasmtime_environ::error` as the `wasmtime::error`
module, updates the prelude to include these new error-handling types, redirects
our top-level `wasmtime::{Error, Result}` re-exports to re-export
`wasmtime::error::{Error, Result}`, and updates various use sites that were
directly using `anyhow` to use the new `wasmtime` versions.

This process also required updating the component macro and wit-bindgen macro to
use the new error types instead of `anyhow`.

Part of https://github.com/bytecodealliance/wasmtime/issues/12069

* Replace wasmtime::error::Thing with wasmtime::Thing where it makes sense

* cargo fmt

* Move `crate::error::Thing` to `crate::Thing` where it makes sense

show more ...

Use `.` instead of `/` for interface members. (#11947)

* Use `.` instead of `/` for interface members.

In the `wasmtime::component::generate` macro, change the syntax for
referencing functions and

Use `.` instead of `/` for interface members. (#11947)

* Use `.` instead of `/` for interface members.

In the `wasmtime::component::generate` macro, change the syntax for
referencing functions and types inside interfaces to use `.` instead
of `/`.

For example, this changes strings like
`wasi:http/types/outgoing-body`
to
`wasi:http/types.outgoing-body`
.

This makes the syntax more consistent with the syntax of
[WIT `use` statements], which use `.` for this purpose.

And, it avoids an incompatibility with the future nested namespaces syntax
([��]), where the `/d` in `a:b/c/d` is for traversing a component export
rather than an interface member.

[WIT `use` statements]: https://github.com/WebAssembly/component-model/blob/main/design/mvp/WIT.md#wit-packages-and-use
[��]: https://github.com/WebAssembly/component-model/blob/main/design/mvp/Explainer.md#gated-features

* Use the new syntax in more places.

* Revert changes to vendored WIT files.

* Revert more changes to vendored files.

* Update syntax in more places.

show more ...

Fix(wit_bindgen): use declared defaults to decide on `Send` Bounds in `Wastime::world_add_to_linker` (#11761)

* feat: make FonctionConfig.default pub(crate)

Signed-off-by: Antoine Lavandier <antoin

Fix(wit_bindgen): use declared defaults to decide on `Send` Bounds in `Wastime::world_add_to_linker` (#11761)

* feat: make FonctionConfig.default pub(crate)

Signed-off-by: Antoine Lavandier <[email protected]>

* fix: use declared imports/exports defaults when deciding on Send bounds

Signed-off-by: Antoine Lavandier <[email protected]>

* fix: add Send bound on relevant test output

Signed-off-by: Antoine Lavandier <[email protected]>

* fix(tests): add test using imports to define send bounds

Signed-off-by: Antoine Lavandier <[email protected]>

* fix(fmt): make rustfmt happy

Signed-off-by: Antoine Lavandier <[email protected]>

* fix(fmt): actually make rustfmt happy this time

Signed-off-by: Antoine Lavandier <[email protected]>

---------

Signed-off-by: Antoine Lavandier <[email protected]>

show more ...

Support store-access in `bindgen!` generated imports (#11628)

* Support store-access in `bindgen!` generated imports

This commit adds support to accessing the store in `bindgen!`-generated
import

Support store-access in `bindgen!` generated imports (#11628)

* Support store-access in `bindgen!` generated imports

This commit adds support to accessing the store in `bindgen!`-generated
import functions in traits. Since the inception of `bindgen!` this has
never been possible and access to the store requires manually working
with `Linker`, for example. This is not easy to do because it requires
surgically editing code or working around what bindings generation parts
you do want.

The implementation here is a small step away from what
component-model-async has already implemented for async functions.
Effectively it's a small extension of the `*WithStore` traits to also
have synchronous functions with `Access` parameters instead of `async`
functions with an `Accessor` parameter.

This is something we're going to want for the WASIp3 implementation
where I've noticed some resource destructors are going to want access to
the store to close out streams and such and this'll provide the bindings
necessary for that.

Closes #11590

* Update test expectations

show more ...

Redesign function configuration in `bindgen!` (#11328)

* Redesign function configuration in `bindgen!`

This commit is a redesign of how function-level configuration works in
Wasmtime's `bindgen!` m

Redesign function configuration in `bindgen!` (#11328)

* Redesign function configuration in `bindgen!`

This commit is a redesign of how function-level configuration works in
Wasmtime's `bindgen!` macro. The main goal of this redesign is to
better support WASIp3 and component model async functions. Prior to this
redesign there was a mish mash of mechanisms to configure behavior of
imports/exports:

* The `async` configuration could turn everything async, nothing async,
only some imports async, or everything except some imports async.

* The `concurrent_{imports,exports}` keys were required to explicitly
opt-in to component model async signatures and applied to all
imports/exports.

* The `trappable_imports` configuration would indicate a list of imports
allowed to trap and it had special configuration for everything,
nothing, and only a certain list.

* The `tracing` and `verbose_tracing` keys could be applied to either
nothing or all functions.

Overall the previous state of configuration in `bindgen!` was clearly a
hodgepodge of systems that organically grew over time. In my personal
opinion it was in dire need of a refresh to take into account how
component-model-async ended up being implemented as well as
consolidating the one-off systems amongst all of these configuration
keys. A major motivation of this redesign, for example, was to inherit
behavior from WIT files by default. An `async` function in WIT should
not require `concurrent_*` keys to be configured, but rather it should
generate correct bindings by default.

In this commit, all of the above keys were removed. All keys have been
replaced with `imports` and `exports` configuration keys. Each behaves
the same way and looks like so:

bindgen!({
// ...
imports: {
// enable tracing for just this function
"my:local/interface/func": tracing,

// enable verbose tracing for just this function
"my:local/interface/other-func": tracing | verbose_tracing,

// this is blocking in WIT, but generate async bindings for
// it
"my:local/interface/[method]io.block": async,

// like above, but use "concurrent" bindings which have
// access to the store.
"my:local/interface/[method]io.block-again": async | store,

// everything else is, by default, trappable
default: trappable,
},
});

Effectively all the function-level configuration items are now bitflags.
These bitflags are by default inherited from the WIT files itself (e.g.
`async` functions are `async | store` by default). Further configuration
is then layered on top at the desires of the embedder. Supported keys are:

* `async` - this means that a Rust-level `async` function should be
generated. This is either `CallStyle::Async` or
`CallStyle::Concurrent` as it was prior, depending on ...

* `store` - this means that the generated function will have access to
the store on the host. This is only implemented right now for `async |
store` functions which map to `CallStyle::Concurrent`. In the future
I'd like to support just-`store` functions which means that you could
define a synchronous function with access to the store in addition to
an asynchronous function.

* `trappable` - this means that the function returns a
`wasmtime::Result<TheWitBindingType>`. If `trappable_errors` is
applicable then it means just a `Result<TheWitOkType,
TrappableErrorType>` is returned (like before)

* `tracing` - this enables `tracing!` integration for this function.

* `verbose_tracing` - this logs all argument values for this function
(including lists).

* `ignore_wit` - this ignores the WIT-level defaults of the function
(e.g. ignoring WIT `async`).

The way this then works is all modeled is that for any WIT function
being generated there are a set of flags associated with that function.
To calculate the flags the algorithm looks like:

1. Find the first matching rule in the `imports` or `exports` map
depending on if the function is imported or exported. If there is no
matching rule then use the `default` rule if present. This is the
initial set of flags for the function (or empty if nothing was
found).

2. If `ignore_wit` is present, return the flags from step 1. Otherwise
add in `async | store` if the function is `async` in WIT.

The resulting set of flags are then used to control how everything is
generated. For example the same split traits of today are still
generated and it's controlled based on the flags. Note though that the
previous `HostConcurrent` trait was renamed to `HostWithStore` to make
space for synchronous functions in this trait in the future too.

The end result of all these changes is that configuring imports/exports
now uses the exact same selection system as the `with` replacement map,
meaning there's only one system of selecting functions instead of 3.
WIT-level `async` is now respected by default meaning that bindings work
by default without further need to configure anything (unless more
functionality is desired).

One final minor change made here as well is that auto-generated
`instantiate` methods are now always synchronous and an
`instantiate_async` method is unconditionally generated for async mode.
This means that bindings always generate both functions and it's up to
the embedder to choose the appropriate one.

Closes #11246
Closes #11247

* Update expanded test expectations

prtest:full

* Fix the min platform embedding example

* Fix doc tests

* Always generate `*WithStore` traits

This helps when using the `with` mapping since that can always assume
that `HostWithStore` is available in the generated bindings, avoiding
the need to duplicate configuration options.

* Update test expectations

* Review comments

show more ...

Re-enable concurrent bindings generation tests (#10972)

* Re-enable concurrent bindings generation tests

This commit re-enables tests for bindings generation for concurrent
calls in the main repo

Re-enable concurrent bindings generation tests (#10972)

* Re-enable concurrent bindings generation tests

This commit re-enables tests for bindings generation for concurrent
calls in the main repo after all syncs have now finished with wasip3.
This additionally adds some skeleton APIs that the bindings generator
uses which are necessary to get tests passing.

* Update test expectations

show more ...

Update Wasmtime to the 2024 Rust Edition (#10806)

* Update Wasmtime to the 2024 Rust Edition

Now that our MSRV supports the 2024 edition it's possible to make this
switch. This commit moves Wasmtim

Update Wasmtime to the 2024 Rust Edition (#10806)

* Update Wasmtime to the 2024 Rust Edition

Now that our MSRV supports the 2024 edition it's possible to make this
switch. This commit moves Wasmtime to the 2024 Edition to keep
up-to-date with Rust idioms and access many of the edition features
exclusive to the 2024 edition.

prtest:full

* Reformat with the 2024 edition

show more ...

Replace `GetHost` with a function pointer, add `HasData` (#10770)

* Replace `GetHost` with a function pointer, add `HasData`

This commit is a refactoring to the fundamentals of the `bindgen!` macro

Replace `GetHost` with a function pointer, add `HasData` (#10770)

* Replace `GetHost` with a function pointer, add `HasData`

This commit is a refactoring to the fundamentals of the `bindgen!` macro
and the functions that it generates. Prior to this change the
fundamental entrypoint generated by `bindgen!` was a function
`add_to_linker_get_host` which takes a value of type `G: GetHost`. This
`GetHost` implementation is effectively an alias for a closure whose
return value is able to close over the parameter given lfietime-wise.

The `GetHost` abstraction was added to Wasmtime originally to enable
using any type that implements `Host` traits, not just `&mut U` as was
originally supported. The definition of `GetHost` was _just_ right to
enable a type such as `MyThing<&mut T>` to implement `Host` and a
closure could be provided that could return it. At the time that
`GetHost` was added it was known to be problematic from an
understandability point of view, namely:

* It has a non-obvious definition.
* It's pretty advanced Rust voodoo to understand what it's actually
doing
* Using `GetHost` required lots of `for<'a> ...` in places which is
unfamiliar syntax for many.
* `GetHost` values couldn't be type-erased (e.g. put in a trait object)
as we couldn't figure out the lifetime syntax to do so.

Despite these issues it was the only known solution at hand so we landed
it and kept the previous `add_to_linker` style (`&mut T -> &mut U`) as a
convenience. While this has worked reasonable well (most folks just try
to not look at `GetHost`) it has reached a breaking point in the WASIp3
work.

In the WASIp3 work it's effectively now going to be required that the
`G: GetHost` value is packaged up and actually stored inside of
accessors provided to host functions. This means that `GetHost` values
now need to not only be taken in `add_to_linker` but additionally
provided to the rest of the system through an "accessor". This was made
possible in #10746 by moving the `GetHost` type into Wasmtime itself (as
opposed to generated code where it lived prior).

While this worked with WASIp3 and it was possible to plumb `G: GetHost`
safely around, this ended up surfacing more issues. Namely all
"concurrent" host functions started getting significantly more
complicated `where` clauses and type signatures. At the end of the day I
felt that we had reached the end of the road to `GetHost` and wanted to
search for alternatives, hence this change.

The fundamental purpose of `GetHost` was to be able to express, in a
generic fashion:

* Give me a closure that takes `&mut T` and returns `D`.
* The `D` type can close over the lifetime in `&mut T`.
* The `D` type must implement `bindgen!`-generated traits.

A realization I had was that we could model this with a generic
associated type in Rust. Rust support for generic associated types is
relatively new and not something I've used much before, but it ended up
being a perfect model for this. The definition of the new `HasData`
trait is deceptively simple:

trait HasData {
type Data<'a>;
}

What this enables us to do though is to generate `add_to_linker`
functions that look like this:

fn add_to_linker<T, D>(
linker: &mut Linker<T>,
getter: fn(&mut T) -> D::Data<'_>,
) -> Result<()>
where
D: HasData,
for<'a> D::Data<'a>: Host;

This definition here models `G: GetHost` as a literal function pointer,
and the ability to close over the `&mut T` lifetime with type (not just
`&mut U`) is expressed through the type constructor `type Data<'a>`).
Ideally we could take a generic generic associated type (I'm not even
sure what to call that), but that's not something Rust has today.

Overall this felt like a much simpler way of modeling `GetHost` and its
requirements. This plumbed well throughout the WASIp3 work and the
signatures for concurrent functions felt much more appropriate in terms
of complexity after this change. Taking this change to the limit means
that `GetHost` in its entirety could be purged since all usages of it
could be replaced with `fn(&mut T) -> D::Data<'a>`, a hopefully much
more understandable type.

This change is not all rainbows however, there are some gotchas that
remain:

* One is that all `add_to_linker` generated functions have a `D:
HasData` type parameter. This type parameter cannot be inferred and
must always be explicitly specified, and it's not easy to know what to
supply here without reading documentation. Actually supplying the type
parameter is quite easy once you know what to do (and what to fill
in), but it may involve defining a small struct with a custom
`HasData` implementation which can be non-obvious.

* Another is that the `G: GetHost` value was previously a full Rust
closure, but now it's transitioning to a function pointer. This is
done in preparation for WASIp3 work where the function needs to be
passed around, and doing that behind a generic parameter is more
effort than it's worth. This means that embedders relying on the true
closure-like nature here will have to update to using a function
pointer instead.

* The function pointer is stored in locations that require `'static`,
and while `fn(T)` might be expected to be `'static` regardless of `T`
is is, in fact, not. This means that practically `add_to_linker`
requires `T: 'static`. Relative to just before this change this is a
possible regression in functionality, but there orthogonal reasons
beyond just this that we want to start requiring `T: 'static` anyway.
That means that this isn't actually a regression relative to #10760, a
related change.

The first point is partially ameliorated with WASIp3 work insofar that
the `D` type parameter will start serving as a location to specify where
concurrent implementations are found. These concurrent methods don't
take `&mut self` but instead are implemented for `T: HasData` types. In
that sense it's more justified to have this weird type parameter, but in
the meantime without this support it'll feel a bit odd to have this
little type parameter hanging off the side.

This change has been integrated into the WASIp3 prototyping repository
with success. This has additionally been integrated into the Spin
embedding which has one of the more complicated reliances on
`*_get_host` functions known. Given that it's expected that while this
is not necessarily a trivial change to rebase over it should at least be
possible.

Finally the `HasData` trait here has been included with what I'm hoping
is a sufficient amount of documentation to at least give folks a spring
board to understand it. If folks have confusion about this `D` type
parameter my hope is they'll make their way to `HasData` which showcases
various patterns for "librarifying" host implementations of WIT
interfaces. These patterns are all used throughout Wasmtime and WASI
currently in crates and tests and such.

* Update expanded test expectations

show more ...

async/stream/future support for wasmtime-wit-bindgen (#10044)

* async/stream/future support for wasmtime-wit-bindgen

I've split this out of #9582 to make review easier.

This patch adds async/strea

async/stream/future support for wasmtime-wit-bindgen (#10044)

* async/stream/future support for wasmtime-wit-bindgen

I've split this out of #9582 to make review easier.

This patch adds async/stream/future/error-context support to the host binding
generator, along with placeholder type and function definitions in the
`wasmtime` crate which the generated bindings can refer to. See
https://github.com/dicej/rfcs/blob/component-async/accepted/component-model-async.md#componentbindgen-updates
for the design and rationale.

Note that I've added temporary `[patch.crates-io]` overrides in Cargo.toml until
https://github.com/bytecodealliance/wit-bindgen/pull/1130 and
https://github.com/bytecodealliance/wasm-tools/pull/1978 have been released.

Also note that we emit a `T: 'static` bound for `AsContextMut<Data = T>` when
generating bindings with `concurrent_imports: true`. This is only because
`rustc` insists that the closure we're passing to
`LinkerInstance::func_wrap_concurrent` captures the lifetime of `T` despite my
best efforts to convince it otherwise. Alex and I suspect this is a limitation
in the compiler, and I asked about it on the rust-lang Zulip, but we haven't
been able to determine a workaround so far.

Signed-off-by: Joel Dice <[email protected]>

remove obsolete TODO comment

Signed-off-by: Joel Dice <[email protected]>

make `futures` dep optional

Signed-off-by: Joel Dice <[email protected]>

update `wasm-tools` and `wit-bindgen`

Signed-off-by: Joel Dice <[email protected]>

* run cargo vet

Signed-off-by: Joel Dice <[email protected]>

---------

Signed-off-by: Joel Dice <[email protected]>

show more ...

Burn down the `allow_attributes_without_reason` backlog (#9712)

* Burn down the `allow_attributes_without_reason` backlog

Just a bit, not everything fixed.

* Fix wasi-nn annotations

* Tweak `#[cf

Burn down the `allow_attributes_without_reason` backlog (#9712)

* Burn down the `allow_attributes_without_reason` backlog

Just a bit, not everything fixed.

* Fix wasi-nn annotations

* Tweak `#[cfg]`

show more ...

Start using `#[expect]` instead of `#[allow]` (#9696)

* Start using `#[expect]` instead of `#[allow]`

In Rust 1.81, our new MSRV, a new feature was added to Rust to use
`#[expect]` to control lint

Start using `#[expect]` instead of `#[allow]` (#9696)

* Start using `#[expect]` instead of `#[allow]`

In Rust 1.81, our new MSRV, a new feature was added to Rust to use
`#[expect]` to control lint levels. This new lint annotation will
silence a lint but will itself cause a lint if it doesn't actually
silence anything. This is quite useful to ensure that annotations don't
get stale over time.

Another feature is the ability to use a `reason` directive on the
attribute with a string explaining why the attribute is there. This
string is then rendered in compiler messages if a warning or error
happens.

This commit migrates applies a few changes across the workspace:

* Some `#[allow]` are changed to `#[expect]` with a `reason`.
* Some `#[allow]` have a `reason` added if the lint conditionally fires
(mostly related to macros).
* Some `#[allow]` are removed since the lint doesn't actually fire.
* The workspace configures `clippy::allow_attributes_without_reason = 'warn'`
as a "ratchet" to prevent future regressions.
* Many crates are annotated to allow `allow_attributes_without_reason`
during this transitionary period.

The end-state is that all crates should use
`#[expect(..., reason = "...")]` for any lint that unconditionally fires
but is expected. The `#[allow(..., reason = "...")]` lint should be used
for conditionally firing lints, primarily in macro-related code.
The `allow_attributes_without_reason = 'warn'` level is intended to be
permanent but the transitionary
`#[expect(clippy::allow_attributes_without_reason)]` crate annotations
to go away over time.

* Fix adapter build

prtest:full

* Fix one-core build of icache coherence

* Use `allow` for missing_docs

Work around rust-lang/rust#130021 which was fixed in Rust 1.83 and isn't
fixed for our MSRV at this time.

* More MSRV compat

show more ...

feat: component bindgen: add support for multiple wit paths (#9288)

* feat: bindgen: add support for multiple wit paths

* expanded tests

* fmt

---------

Co-authored-by: Lochlan Wansbrough <>

wit-bindgen: Don't trace values containing lists by default. (#9262)

* wit-bindgen: Don't trace values containing lists by default.

`list` values in Wit interfaces can represent things like HTTP bo

wit-bindgen: Don't trace values containing lists by default. (#9262)

* wit-bindgen: Don't trace values containing lists by default.

`list` values in Wit interfaces can represent things like HTTP bodies
which can be very large. To enable tracing without spamming logfiles
with all this data, put printing of values containing `list`s behind
a separate `verbose_tracing` option.

This is a coarse-grained approach; but it seems like a pretty good
default for tracing, and enabling full tracing when one needs it is
straightforward.

In the future, we may want to refine the option by implementing
the `Valuable` trait and using `tracing::field::valuable`, which
could allow us to do things like print non-`list` fields of records
that otherwise contain `list`s.

* Use `option_type_contains_lists` more.

* Hook up `verbose_tracing` to the macro.

* Update expected outputs for tests.

show more ...

Improve name lookup for `trappable_error_type` configuration (#8833)

This commit improves the experience around using the
`trappable_error_type` configuration by fixing two issues:

* When an error

Improve name lookup for `trappable_error_type` configuration (#8833)

This commit improves the experience around using the
`trappable_error_type` configuration by fixing two issues:

* When an error can't be resolved it doesn't result in a
`unwrap()`, instead a first-class error is returned to get reported.

* The name lookup procedure is now consistent with the name lookup that
the `with` key does, notably allowing the version to be optional but
still supporting the version.

This fixes an issue that came up recently where a path with a version
was specified but the old lookup logic ended up requiring that the
version wasn't specified because there was only one package with that
version. This behavior resulted in a panic with a very long
backtrace-based error message which was confusing to parse. By returning
an error the error is much more succinct and by supporting more names
the original intuition will work.

show more ...

Always generate the same output structure with `bindgen!` (#8721)

Currently with the `bindgen!` macro when the `with` key is used then the
generated bindings are different than if the `with` key was

Always generate the same output structure with `bindgen!` (#8721)

Currently with the `bindgen!` macro when the `with` key is used then the
generated bindings are different than if the `with` key was not used.
Not only for replacement purposes but the generated bindings are missing
two key pieces:

* In the generated `add_to_linker` functions bounds and invocations of
`with`-overridden interfaces are all missing. This means that the
generated `add_to_linker` functions don't actually represent the full
world.

* The generated module hierarchy has "holes" for all the modules that
are overridden. While it's mostly a minor inconvenience it's also easy
enough to generate everything via `pub use` to have everything hooked
up correctly.

After this PR it means that each `bindgen!` macro should, in isolation,
work for any other `bindgen!` macro invocation. It shouldn't be
necessary to weave things together and remember how each macro was
invoked along the way. This is primarily to unblock #8715 which is
running into a case where tcp/udp are generated as sync but their
dependency, `wasi:sockets/network`, is used from an upstream async
version. The generated `add_to_linker` does not compile because tcp/udp
depend on `wasi:sockets/network` isn't added to the linker. After fixing
that it then required more modules to be generated, hence this PR.

show more ...

Fix missing additional derives (#8482)

Signed-off-by: Brian H <[email protected]>

Support additional_derives option in bindgen (#8441)

Signed-off-by: Brian H <[email protected]>

Update nightly used in CI and fix warnings (#8416)

Fixes some warnings that nightly Rust has started emitting.

Disable traps by default in `bindgen!` imports (#8310)

By default previously all return types were wrapped in
`wasmtime::Result<T>` to enable any import to return a trap to the wasm
guest. This is a

Disable traps by default in `bindgen!` imports (#8310)

By default previously all return types were wrapped in
`wasmtime::Result<T>` to enable any import to return a trap to the wasm
guest. This is a fair bit of boilerplate, however, and it's easy to
accidentally turn a normal error into a trap. This is additionally
somewhat of a power-user method as many imports probably don't end up
wanting to trap.

This commit adds a new configuration option to `bindgen!`:
`trappable_imports`, and switches the default to `false`. The previous
behavior can be recovered with `trappable_imports: true`.

show more ...

fix: bindgen trappable_errors using unversion/versioned packages (#8305)

Signed-off-by: Brian H <[email protected]>

Enable specifying namespaces/packages in `with` (#8083)

This commit implements bytecodealliance/wit-bindgen#840 for Wasmtime.
Currently `with` keys to bindgen only support either mapping resources
o

Enable specifying namespaces/packages in `with` (#8083)

This commit implements bytecodealliance/wit-bindgen#840 for Wasmtime.
Currently `with` keys to bindgen only support either mapping resources
or interfaces. Now they additionally support mapping entire packages or
entire namespaces. This can help clean up some references to interfaces
through our own bindings to avoid listing all of them.

show more ...

Fix generating interface names which are Rust keywords (#7790)

Signed-off-by: Archisman Mridha <[email protected]>

Update syntax for `trappable_error_type` in `bindgen!` (#7170)

* Update syntax for `trappable_error_type` in `bindgen!`

Following through on a suggestion from #7152 this makes the syntax a bit
more

Update syntax for `trappable_error_type` in `bindgen!` (#7170)

* Update syntax for `trappable_error_type` in `bindgen!`

Following through on a suggestion from #7152 this makes the syntax a bit
more consistent with the rest of `bindgen!` today. This additionally
updates the documentation on the `bindgen!` macro itself.

* Update parsing to afford for versions

show more ...

Add a whole lot of semicolons to WIT files (#7159)

To prepare this commit I've run `WIT_REQUIRE_SEMICOLONS=1 ./ci/run-tests.sh`
locally which configures `wit-parser` to generate an error for missing

Add a whole lot of semicolons to WIT files (#7159)

To prepare this commit I've run `WIT_REQUIRE_SEMICOLONS=1 ./ci/run-tests.sh`
locally which configures `wit-parser` to generate an error for missing
semicolons in WIT files. This led me to add quite a few semicolons in
quite a few places in what is going to be the first of a few batches of
semicolons.

CI checks for this cannot be added just yet because the wasi-nn spec is
a submodule which needs to be updated with semicolons before this
repository can require semicolons. Nevertheless that doesn't stop us
from using semicolons in the meantime (yay gradual rollout of changes!)
so I figure this would be good to get in sooner rather than later.

show more ...