wasm-compose: Update `heck` dependency to `0.5.0` by fitzgen · Pull Request #2359 · bytecodealliance/wasm-tools
Removes duplicate versions of `heck` in the crate graph.
fitzgen
deleted the
update-heck-dep-to-0.5.0
branch
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
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