Skip to content

Conversation

@fitzgen
Copy link
Member

@fitzgen fitzgen commented Oct 23, 2025

Removes duplicate versions of heck in the crate graph.

Removes duplicate versions of `heck` in the crate graph.
@fitzgen fitzgen requested a review from a team as a code owner October 23, 2025 00:05
@fitzgen fitzgen requested review from dicej and removed request for a team October 23, 2025 00:05
fitzgen added a commit to fitzgen/wasmtime that referenced this pull request Oct 23, 2025
Until bytecodealliance/wasm-tools#2359 is merged,
released, and updated in this tree.
@alexcrichton alexcrichton added this pull request to the merge queue Oct 23, 2025
Merged via the queue into bytecodealliance:main with commit dffed68 Oct 23, 2025
34 checks passed
@fitzgen fitzgen deleted the update-heck-dep-to-0.5.0 branch October 23, 2025 00:35
github-merge-queue bot pushed a commit to bytecodealliance/wasmtime that referenced this pull request Oct 23, 2025
* `CodeBuilder` APIs for defining compile-time builtins

Compile-time builtins, as described in [the
RFC](https://github.com/bytecodealliance/rfcs/blob/main/accepted/wasmtime-compile-time-builtins.md),
are effectively the sum of three parts:

1. Function inlining
2. Unsafe intrinsics
3. Component composition

The first two have already been implemented in Wasmtime. This commit implements
the final part, leveraging `wasm-compose` to link host-defined compile-time
builtin components with guest-defined main components. It exposes Wasmtime's
unsafe intrinsics only to the host-defined compile-time builtins, not the
guest-defined main Wasm component.

Why `wasm-compose` and not `wac`? Because it is in the same repo as the rest of
the `wasm-tools` crates, and therefore it is easy to depend on without bringing
in duplicate copies of that family of crates into our workspace and builds. Also
its programmatic API is somewhat easier to use, and is not spread across
multiple crates.

* Fix unused lifetime in `cfg(not(feature = "compile-time-builtins"))`

* Fix an unused warning when `cfg(not(feature = "compile-time-builtins"))`

* Add cargo vet audit for `fixedbitset` version `0.4.2`

* Add cargo vet audit for `bitmaps` version 2.10.0

* Add cargo vet audit for `sized-chunks` diff `0.6.5 -> 0.7.0`

* Add/tweak cargo vet exemptions for some deps

These all have >10,000 daily downloads, and so are okay to exempt per our
policy:
https://docs.wasmtime.dev/contributing-coding-guidelines.html#policy-for-adding-cargo-vet-entries

* Add cargo vet audit for `wasm-compose` diff `0.236.0 -> 0.238.1`

Don't know why I have to do this certification even though we have a wildcard
audit for this crate because it is authored by the Bytecode Alliance...

* Fix visibility of type

* Move compile-time builtins methods to module to cut down on `cfg`s

* Skip checking `heck` in `cargo deny`

Until bytecodealliance/wasm-tools#2359 is merged,
released, and updated in this tree.

* Always read compile-time inputs

* Tighten up parse loop and level tracking

* as_deref instead of clone

* Remove 'b lifetime from CodeBuilder

* fix `cfg(not(feature = "compile-time-builtins"))` build
github-merge-queue bot pushed a commit to bytecodealliance/wasmtime that referenced this pull request Oct 23, 2025
* `CodeBuilder` APIs for defining compile-time builtins

Compile-time builtins, as described in [the
RFC](https://github.com/bytecodealliance/rfcs/blob/main/accepted/wasmtime-compile-time-builtins.md),
are effectively the sum of three parts:

1. Function inlining
2. Unsafe intrinsics
3. Component composition

The first two have already been implemented in Wasmtime. This commit implements
the final part, leveraging `wasm-compose` to link host-defined compile-time
builtin components with guest-defined main components. It exposes Wasmtime's
unsafe intrinsics only to the host-defined compile-time builtins, not the
guest-defined main Wasm component.

Why `wasm-compose` and not `wac`? Because it is in the same repo as the rest of
the `wasm-tools` crates, and therefore it is easy to depend on without bringing
in duplicate copies of that family of crates into our workspace and builds. Also
its programmatic API is somewhat easier to use, and is not spread across
multiple crates.

* Fix unused lifetime in `cfg(not(feature = "compile-time-builtins"))`

* Fix an unused warning when `cfg(not(feature = "compile-time-builtins"))`

* Add cargo vet audit for `fixedbitset` version `0.4.2`

* Add cargo vet audit for `bitmaps` version 2.10.0

* Add cargo vet audit for `sized-chunks` diff `0.6.5 -> 0.7.0`

* Add/tweak cargo vet exemptions for some deps

These all have >10,000 daily downloads, and so are okay to exempt per our
policy:
https://docs.wasmtime.dev/contributing-coding-guidelines.html#policy-for-adding-cargo-vet-entries

* Add cargo vet audit for `wasm-compose` diff `0.236.0 -> 0.238.1`

Don't know why I have to do this certification even though we have a wildcard
audit for this crate because it is authored by the Bytecode Alliance...

* Fix visibility of type

* Move compile-time builtins methods to module to cut down on `cfg`s

* Skip checking `heck` in `cargo deny`

Until bytecodealliance/wasm-tools#2359 is merged,
released, and updated in this tree.

* Always read compile-time inputs

* Tighten up parse loop and level tracking

* as_deref instead of clone

* Remove 'b lifetime from CodeBuilder

* fix `cfg(not(feature = "compile-time-builtins"))` build

* Ignore tests that run wasm when in MIRI
github-merge-queue bot pushed a commit to bytecodealliance/wasmtime that referenced this pull request Oct 23, 2025
* `CodeBuilder` APIs for defining compile-time builtins

Compile-time builtins, as described in [the
RFC](https://github.com/bytecodealliance/rfcs/blob/main/accepted/wasmtime-compile-time-builtins.md),
are effectively the sum of three parts:

1. Function inlining
2. Unsafe intrinsics
3. Component composition

The first two have already been implemented in Wasmtime. This commit implements
the final part, leveraging `wasm-compose` to link host-defined compile-time
builtin components with guest-defined main components. It exposes Wasmtime's
unsafe intrinsics only to the host-defined compile-time builtins, not the
guest-defined main Wasm component.

Why `wasm-compose` and not `wac`? Because it is in the same repo as the rest of
the `wasm-tools` crates, and therefore it is easy to depend on without bringing
in duplicate copies of that family of crates into our workspace and builds. Also
its programmatic API is somewhat easier to use, and is not spread across
multiple crates.

* Fix unused lifetime in `cfg(not(feature = "compile-time-builtins"))`

* Fix an unused warning when `cfg(not(feature = "compile-time-builtins"))`

* Add cargo vet audit for `fixedbitset` version `0.4.2`

* Add cargo vet audit for `bitmaps` version 2.10.0

* Add cargo vet audit for `sized-chunks` diff `0.6.5 -> 0.7.0`

* Add/tweak cargo vet exemptions for some deps

These all have >10,000 daily downloads, and so are okay to exempt per our
policy:
https://docs.wasmtime.dev/contributing-coding-guidelines.html#policy-for-adding-cargo-vet-entries

* Add cargo vet audit for `wasm-compose` diff `0.236.0 -> 0.238.1`

Don't know why I have to do this certification even though we have a wildcard
audit for this crate because it is authored by the Bytecode Alliance...

* Fix visibility of type

* Move compile-time builtins methods to module to cut down on `cfg`s

* Skip checking `heck` in `cargo deny`

Until bytecodealliance/wasm-tools#2359 is merged,
released, and updated in this tree.

* Always read compile-time inputs

* Tighten up parse loop and level tracking

* as_deref instead of clone

* Remove 'b lifetime from CodeBuilder

* fix `cfg(not(feature = "compile-time-builtins"))` build

* Ignore tests that run wasm when in MIRI
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants