-
Notifications
You must be signed in to change notification settings - Fork 312
wasm-compose: Update heck dependency to 0.5.0
#2359
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
alexcrichton
merged 1 commit into
bytecodealliance:main
from
fitzgen:update-heck-dep-to-0.5.0
Oct 23, 2025
Merged
wasm-compose: Update heck dependency to 0.5.0
#2359
alexcrichton
merged 1 commit into
bytecodealliance:main
from
fitzgen:update-heck-dep-to-0.5.0
Oct 23, 2025
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Removes duplicate versions of `heck` in the crate graph.
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
approved these changes
Oct 23, 2025
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
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Removes duplicate versions of
heckin the crate graph.