Skip to content

Conversation

@fitzgen
Copy link
Member

@fitzgen fitzgen commented Jan 9, 2026

This commit polyfills wasmtime_internal_error::ToWasmtimeResult in wasmtime_environ, adds the cargo feature plumbing that will eventually connect to the "wasmtime_internal_error/anyhow" cargo feature but for now just configures this polyfill, and adds uses of the polyfill at all the sites that will be necessary once we swap out anyhow for
wasmtime_internal_error. Currently, the polyfill is just an identity function, because wasmtime::Result/wasmtime_environ::error::Result is just another name for anyhow::Result. Once we do move away from anyhow, however, that will no longer be the case, and these uses will do the necessary conversion.

My goal with landing this as an incremental commit is to make it so that the actual commit that does the error crate swap out can be as close to just the Cargo.toml dependency change, without any other code changes as much as possible. This, in turn, means that swap out should be super easy to revert, if necessary.

This commit polyfills `wasmtime_internal_error::ToWasmtimeResult` in
`wasmtime_environ`, adds the cargo feature plumbing that will eventually connect
to the `"wasmtime_internal_error/anyhow"` cargo feature but for now just
configures this polyfill, and adds uses of the polyfill at all the sites that
will be necessary once we swap out `anyhow` for
`wasmtime_internal_error`. Currently, the polyfill is just an identity function,
because `wasmtime::Result`/`wasmtime_environ::error::Result` is just another
name for `anyhow::Result`. Once we do move away from `anyhow`, however, that
will no longer be the case, and these uses will do the necessary conversion.

My goal with landing this as an incremental commit is to make it so that the
actual commit that does the error crate swap out can be as close to _just_ the
`Cargo.toml` dependency change, without any other code changes as much as
possible. This, in turn, means that swap out should be super easy to revert, if
necessary.
@fitzgen fitzgen requested review from a team as code owners January 9, 2026 20:31
@fitzgen fitzgen requested review from pchickey and removed request for a team January 9, 2026 20:31
@alexcrichton
Copy link
Member

Personally I'd like to see this trait used as an absolute last resort "quick hack before we figure out what's best to do instead" ideally. What would you think about, instead of using this trait internally, instead propagating the usage of anyhow::Error to the callers? This looks like it's mostly used in tests and such so I don't think it'll affect our public API or anything like that.

Additionally, looking forward a bit, one thing I'm worried about is bindgen!-generated traits all written with anyhow::Error previously and deeply integrated with the rest of an embedding, and that would all in theory need to change and use this trait. What do you think about a new bindgen! configuration flag which, when enabled, uses to_wasmtime_result() and this trait on the result of all functions? It would generate trait signatures with anyhow::Result instead of wasmtime::Result, for example.

@alexcrichton alexcrichton requested review from alexcrichton and removed request for a team and pchickey January 9, 2026 21:02
@github-actions github-actions bot added wasmtime:api Related to the API of the `wasmtime` crate itself wizer Issues related to Wizer snapshotting, pre-initialization, and the `wasmtime wizer` subcommand labels Jan 9, 2026
@github-actions
Copy link

github-actions bot commented Jan 9, 2026

Subscribe to Label Action

cc @fitzgen

Details This issue or pull request has been labeled: "wasmtime:api", "wizer"

Thus the following users have been cc'd because of the following labels:

  • fitzgen: wizer

To subscribe or unsubscribe from this label, edit the .github/subscribe-to-label.json configuration file.

Learn more.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

wasmtime:api Related to the API of the `wasmtime` crate itself wizer Issues related to Wizer snapshotting, pre-initialization, and the `wasmtime wizer` subcommand

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants