GeezerVison is showing github.com — Vendored cargo warns cargo_multi_version_old_cargo ("declares no rust-version") when the root package inherits rust-version from [workspace.package] · Issue #651 · SocketDev/socket-patch
Vendored cargo warns cargo_multi_version_old_cargo ("declares no rust-version") when the root package inherits rust-version from [workspace.package] #651Description[agent] Found by the scheduled Cargo bug-hunt routine (ledger #315).
Summary
When a second version of one crate is vendored, vendor decides whether to emit cargo_multi_version_old_cargo by reading the project's declared cargo floor (declared_cargo_minor). A workspace-root manifest whose [package] inherits the floor with rust-version.workspace = true (and [workspace.package] rust-version = "1.70") is treated as declaring nothing. The project gets the warning, and the warning says it "declares no rust-version or toolchain, so the cargo that builds it is unknown".
The cause: [package].rust-version is present but is a table ({ workspace = true }), not a string. .get("rust-version") returns Some(table), so the .or_else fallback to [workspace.package].rust-version never runs, and then .as_str() yields None.
Impact
Low severity. It's a false, misleading warning, not a broken build. The build is fine. Workspace inheritance needs cargo 1.64+, so any project using rust-version.workspace = true already can't be built by the pre-1.45 cargo the warning is about. Root packages that inherit from [workspace.package] are the standard modern workspace layout, so every multi-version vendor in such a project emits a spurious warning, which trains users to ignore it.
Repro
This used a scratch copy of crates/socket-patch-cli/tests/e2e_vendor_cargo_build.rs (stage_two_versions fixture: cfg-if 1.x plus cfg_if_old = { package = "cfg-if", version = "0.1" }, a marker patch per version, and the prebuilt_common artifact server). Only the root Cargo.toml was swapped, then I ran socket-patch vendor --json --offline:
[workspace]
[workspace.package]
rust-version = "1.70"
[package]
name = "consumer"
version = "0.1.0"
edition = "2018"
rust-version.workspace = true
[dependencies]
cfg-if = "1.0"
cfg_if_old = { package = "cfg-if", version = "0.1" }
root Cargo.toml shape |
cargo build --locked before |
vendor exit |
cargo_multi_version_old_cargo |
cargo run --locked --offline after |
rust-version = "1.70" in [package] |
ok |
0 |
no (correct) |
MARKER:1:2 |
rust-version.workspace = true + [workspace.package] rust-version = "1.70" |
ok |
0 |
yes (wrong) |
MARKER:1:2 |
BOM + rust-version = "1.70" |
ok |
0 |
no (correct) |
MARKER:1:2 |
no rust-version (control) |
ok |
0 |
yes (correct) |
MARKER:1:2 |
I ran the scratch test twice with identical results. The warning text on the inherited shape:
cfg-if is now vendored at TWO versions (… beside …), which needs cargo 1.45 or newer — this project declares no rust-version or toolchain, so the cargo that builds it is unknown. …
Expected vs actual
- Expected. CLI_CONTRACT.md (cargo vendored row) says "a project that does not pin cargo ≥ 1.45 (
rust-version or toolchain file) gets the cargo_multi_version_old_cargo warning", and docs/ecosystems.md says the warning is skipped when "the project's rust-version … promises cargo 1.45+". The doc comment on declared_cargo_minor reads "[package], else [workspace.package]". This project does pin 1.70, through cargo's documented inheritance, so it should get no warning.
- Actual. The warning fires and claims the project declares no
rust-version.
OS × version
| OS |
cargo |
result |
| Linux (sandbox) |
1.93.1 |
fail (reproduced twice) |
| macOS / Windows |
— |
untested (pure manifest parsing, so no OS dependence is expected) |
Main 045d7ec (CLI 4.0.0). I didn't bisect this: the multi-version warning was added with the v5 manifest wiring.
Suspect code
crates/socket-patch-core/src/vendor/cargo.rs:90-99 (declared_cargo_minor): doc.get("package").and_then(|p| p.get("rust-version")).or_else(...) short-circuits on the { workspace = true } table. Treat a non-string [package].rust-version (or rust-version.workspace = true) as "look in [workspace.package]". Optionally, treat any use of workspace inheritance as proof of cargo ≥ 1.64.
Backlog review — 2026-10-08
Priority: P2 → P3. Builds work; workspace rust-version inheritance only causes a spurious warning. Keep the Cargo reader work in #1110. Activitymikolalysenko commented on Oct 3, 2026 CollaboratorAuthor More actions [agent] Triaged as priority:p2 (Cargo). Confirmed on main 045d7ec: declared_cargo_minor (crates/socket-patch-core/src/vendor/cargo.rs:88-99) takes [package].rust-version with .get(...), which returns the { workspace = true } table, so the [workspace.package] fallback never runs and .as_str() gives None. It is not a duplicate, and no open PR covers it. The fix is small: treat a non-string [package].rust-version as inherited and read [workspace.package].rust-version.
Generated by Claude Code mikolalysenko commented on Oct 3, 2026 CollaboratorAuthor More actions [agent] Architecture audit (ecosystems and formats): this is one symptom of #693. Five places read the Cargo.toml [package] table, each with its own ad hoc lookup, and none of them models { workspace = true } inheritance. #693 proposes one shared toml_edit reader in formats/cargo that resolves version and rust-version inheritance from [workspace.package]. This bug can be fixed there or on its own, whichever lands first.
Generated by Claude Code mikolalysenko commented on Oct 3, 2026 CollaboratorAuthor More actions [agent] Shares root cause with #693: Cargo.toml [package] fields are read through ad hoc lookups that don't model { workspace = true } inheritance. Will be fixed together.
Generated by Claude Code mikolalysenko commented on Oct 9, 2026 CollaboratorAuthor More actions
v5 triage: P3, not a release blocker. This is a false warning about an inherited Cargo floor; the patch/build still works. P3 polish.
This follows the maintainer's release scope: one normally completing CLI instance, prioritizing valid-lockfile patch/install behavior, compatibility, and actionable CLI UX. mikolalysenko commented on Oct 12, 2026 CollaboratorAuthor More actions [agent] Claiming this issue (with #653; shared root cause: the project's declared cargo floor is read by one vendored-only helper that misses rust-version.workspace = true inheritance, and hosted mode never consults it). Branch: agent/fix-cargo-declared-floor. Claim-ID: 2026-10-12T11:21:27Z-dca9c0
Generated by Claude Code mikolalysenko commented on Oct 12, 2026 CollaboratorAuthor More actions
MetadataMetadataDevelopmentNo branches or pull requestsIssue actions
|