Update Deps

Update Deps

Overview

Use this skill when updating Rust dependencies in this repository. The job is not finished when versions change in Cargo.toml; you must also adapt the code to API changes, raise the repo MSRV when newer releases require it, and run the repo validation flow until it is clean.

Repo Rules

• Work from the repo root: /home/basti/src/futuresdr.
• Inspect the root Cargo.toml first for rust-version, shared features, target-specific dependencies, and workspace members.
• Treat rust-version as movable. Do not let the current MSRV force dependency downgrades or block upgrades to the most recent stable release line.
• Enumerate manifests with scripts/find-cargo-tomls.sh. Do not assume only workspace members matter; this repo also has independent examples/* and perf/* crates.
• Keep version requirements as specific as they already are.
  • If a dependency is 0.17, update to the new major.minor form, not "0" or "^0.18".
  • If a dependency is pinned to 0.0.13, keep that patch-level specificity.
  • Preserve existing table style, features, default-features, optional, path, and target-specific sections.
• Prefer the most recent stable release line for each dependency family.
  • Use cargo upgrade --ignore-rust-version when surveying or applying upgrades.
  • If the selected releases require a newer Rust toolchain, update the root rust-version to the minimum needed by the chosen dependency set.
  • Do not keep an older crate version just because it matches the previous MSRV.
• Do not introduce [workspace.dependencies], broaden requirements, or normalize formatting beyond what cargo fmt or local style already does unless the user asks for that refactor.
• Check for local overrides such as [patch.crates-io] in leaf manifests before changing versions.

Workflow

1. Inventory manifests.
   • Run scripts/find-cargo-tomls.sh.
   • Read the root manifest plus any leaf manifests that own the dependencies you intend to change.
2. Plan the update surface.
   • Group related crates together, for example wgpu, burn, audio, async, or GUI stacks.
   • Prefer coherent upgrades over random one-off bumps inside the same dependency family.
   • Identify the Rust version implied by the target upgrades and plan to raise rust-version early if needed.
3. Update manifest entries.
   • Edit only the version numbers or dependency tables that need to change.
   • Preserve the original specificity and structure of each entry.
   • Update the root rust-version when required by the selected dependency versions.
4. Compile and adapt.
   • Use targeted cargo check or cargo clippy runs first near the changed area.
   • Fix API changes in source code, examples, and perf crates, not just the library crate.
   • Use rg on compiler error symbols and renamed methods/types to find all affected call sites.
5. Run full validation.
   • Always finish with ./check.sh.
   • Keep iterating until it exits successfully.

Validation Targets

Use focused validation while iterating, then the full repo check:

cargo check --lib --workspace --features=burn,audio,seify_dummy,wgpu
cargo clippy --lib --workspace --features=burn,audio,seify_dummy,wgpu --target=wasm32-unknown-unknown -- -D warnings
./check.sh

Prefer narrower commands first when a dependency family only affects one crate, but ./check.sh is the final gate.

When using cargo upgrade, prefer:

cargo upgrade --ignore-rust-version

API Change Triage

• Read the actual compiler or clippy errors before patching.
• Update all downstream call sites for renamed methods, constructor signature changes, trait-bound changes, and feature-gated API moves.
• If an upgrade forces a newer Rust version, treat that as a normal part of the update and adapt the repo accordingly.
• Expect fallout in:
  • src/
  • examples/*
  • perf/*
  • wasm-specific builds
• If a dependency upgrade requires a semantic redesign instead of a local patch, stop and explain the tradeoff before forcing a risky rewrite.

Output Expectations

When reporting back:

• Name the dependency groups that changed.
• Call out any rust-version bump and why it was necessary.
• Call out any intentionally skipped upgrades and why.
• State whether ./check.sh passed.

Source: FutureSDR/FutureSDR — distributed by TomeVault.