Consolidate "util" crates for testing (#10423)* Consolidate "util" crates for testingThis commit consolidates all of the existing crates we have for testinginto a smaller set of crates. Specific
Consolidate "util" crates for testing (#10423)* Consolidate "util" crates for testingThis commit consolidates all of the existing crates we have for testinginto a smaller set of crates. Specifically:* `crates/misc/component-fuzz-util` => `wasmtime-test-util` + `component-fuzz` feature* `crates/misc/component-test-util` => `wasmtime-test-util` + `component` feature* `crates/wast-util` => `wasmtime-test-util` + `wast` feature* `crates/misc/component-macro-test` => `wasmtime-test-macros`The goal is to have one location we put various test helpers/macrosrather than our current organically-grown many locations. This isinspired by the test failure on #10405 where I'd like to refactor moreinfrastructure to a "test util" location but it wasn't clear where toput it so I wanted to do this refactoring first.* Remove unused file
show more ...
Add `rust-version.workspace = true` to all crates (#9112)Right now this is only on some crates such as `wasmtime` itself and`wasmtime-cli`, but by applying it to all crates it helps with versions
Add `rust-version.workspace = true` to all crates (#9112)Right now this is only on some crates such as `wasmtime` itself and`wasmtime-cli`, but by applying it to all crates it helps with versionselection of those using just Cranelift for example.
Configure workspace lints, enable running some Clippy lints on CI (#7561)* Configure Rust lints at the workspace levelThis commit adds necessary configuration knobs to have lints configuredat th
Configure workspace lints, enable running some Clippy lints on CI (#7561)* Configure Rust lints at the workspace levelThis commit adds necessary configuration knobs to have lints configuredat the workspace level in Wasmtime rather than the crate level. Thisuses a feature of Cargo first released with 1.74.0 (last week) of the`[workspace.lints]` table. This should help create a more consistent setof lints applied across all crates in our workspace in addition topossibly running select clippy lints on CI as well.* Move `unused_extern_crates` to the workspace levelThis commit configures a `deny` lint level for the`unused_extern_crates` lint to the workspace level rather than theprevious configuration at the individual crate level.* Move `trivial_numeric_casts` to workspace level* Change workspace lint levels to `warn`CI will ensure that these don't get checked into the codebase andotherwise provide fewer speed bumps for in-process development.* Move `unstable_features` lint to workspace level* Move `unused_import_braces` lint to workspace level* Start running Clippy on CIThis commit configures our CI to run `cargo clippy --workspace` for allmerged PRs. Historically this hasn't been all the feasible due to theamount of configuration required to control the number of warnings onCI, but with Cargo's new `[lint]` table it's possible to have aone-liner to silence all lints from Clippy by default. This commit bydefault sets the `all` lint in Clippy to `allow` to by-default disablewarnings from Clippy. The goal of this PR is to enable selective accessto Clippy lints for Wasmtime on CI.* Selectively enable `clippy::cast_sign_loss`This would have fixed #7558 so try to head off future issues with thatby warning against this situation in a few crates. This lint is stillquite noisy though for Cranelift for example so it's not worthwhile atthis time to enable it for the whole workspace.* Fix CI errorprtest:full
Support multiple versions in `bindgen!` (#7172)This commit fixes a bug in the `bindgen!` macro where when faced withmultiple packages that differ only in version number invalid bindingswere gener
Support multiple versions in `bindgen!` (#7172)This commit fixes a bug in the `bindgen!` macro where when faced withmultiple packages that differ only in version number invalid bindingswere generated. The fix here is to add version number information topackage module names if necessary in situations such as this. Thisrequired some refactoring internally to have a single source of truthfor what the name of a module should be and avoid having it implicitlycalculated in two locations.
Disable tests for all proc-macros (#6473)This commit goes through all proc-macros we have in this repository andensures that they're all flagged with `test = false` and `doctest =false`. This com
Disable tests for all proc-macros (#6473)This commit goes through all proc-macros we have in this repository andensures that they're all flagged with `test = false` and `doctest =false`. This comes about as I was curious why CI time was 40m which felta little long and upon inspection the cross-compiled builders weretaking upwards of 30 minutes just to build everything (not includingrunning tests) where the non-cross-compiled builders took only about10-15 minutes to build everything.Further investigation into this discrepancy showed that a lot of cratesare being double-compiled in a cross-compiled situation. This isexpected at a base level and something Cargo transparently handles, forexample if a build script and the final binary need the same dependencythen it's gotta get compiled twice. What was odd is that large portionsof the Wasmtime crate graph were being compiled more than they shouldbe.I tracked this down to some `dev-dependencies` for procedural macrospointing at wasmtime crates. This makes sense for the `tests/*.rs`-styletests which are always compiled for the target, but tests for theproc-macro itself would be compiled for the host. By disabling tests anddoctests for the proc macro itself this removes the need for thehost-compiled version of these dependencies.Overall this reduces a full compile of all tests from ~840 units of workto 700 units of work according to Cargo. The set of extra cratescompiled in a cross-compiled workflow is not much smaller than in anon-cross-compiled workflow and they all generally "make sense" as coreshared dependencies which are rooted in both Wasmtime and someproc-macro's dependency tree, for example.
Update WIT tooling used by Wasmtime (#5565)* Update WIT tooling used by Wasmtime This commit updates the WIT tooling, namely the wasm-tools family of crates, with recent updates. Notably: *
Update WIT tooling used by Wasmtime (#5565)* Update WIT tooling used by Wasmtime This commit updates the WIT tooling, namely the wasm-tools family of crates, with recent updates. Notably: * bytecodealliance/wasm-tools#867 * bytecodealliance/wasm-tools#871 This updates index spaces in components and additionally bumps the minimum required version of the component binary format to be consumed by Wasmtime (because of the index space changes). Additionally WIT tooling now fully supports `use`. Note that WIT tooling doesn't, at this time, fully support packages and depending on remotely defined WIT packages. Currently WIT still needs to be vendored in the project. It's hoped that future work with `cargo component` and possible integration here could make the story about depending on remotely-defined WIT more ergonomic and streamlined. * Fix `bindgen!` codegen tests * Add a test for `use` paths an implement support * Update to crates.io versions of wasm-tools * Uncomment codegen tests
Add a `wasmtime::component::bindgen!` macro (#5317)* Import Wasmtime support from the `wit-bindgen` repo This commit imports the `wit-bindgen-gen-host-wasmtime-rust` crate from the `wit-bindgen
Add a `wasmtime::component::bindgen!` macro (#5317)* Import Wasmtime support from the `wit-bindgen` repo This commit imports the `wit-bindgen-gen-host-wasmtime-rust` crate from the `wit-bindgen` repository into the upstream Wasmtime repository. I've chosen to not import the full history here since the crate is relatively small and doesn't have a ton of complexity. While the history of the crate is quite long the current iteration of the crate's history is relatively short so there's not a ton of import there anyway. The thinking is that this can now continue to evolve in-tree. * Refactor `wasmtime-component-macro` a bit Make room for a `wit_bindgen` macro to slot in. * Add initial support for a `bindgen` macro * Add tests for `wasmtime::component::bindgen!` * Improve error forgetting `async` feature * Add end-to-end tests for bindgen * Add an audit of `unicase` * Add a license to the test-helpers crate * Add vet entry for `pulldown-cmark` * Update publish script with new crate * Try to fix publish script * Update audits * Update lock file