GeezerVison

LLM Description written by Claude Code:claude-opus-5-5

Fixes #653
Fixes #651

What it does

• Hosted cargo redirect writes a sparse+ registry even when the project declares rust-version < 1.68, so every build on that cargo fails with "usage of sparse registries requires -Z sparse-registry" while scan reports success #653 (hosted): scan --mode hosted points a Cargo patch at a
  per-patch sparse+ registry, and cargo only loads those from 1.68.
  A project that declared an older cargo used to get success, and
  every build then failed with usage of sparse registries requires -Z sparse-registry. Now each Cargo patch in such a project is refused
  with redirect_cargo_old_cargo. Nothing is written, and the message
  points at --mode vendored (which builds on 1.41+). If an earlier run
  already wrote pins, the message names the socket-patch rollback pkg:cargo/<name>@<version> that removes them. A project that declares
  no floor, or a rolling channel, redirects as before.
• Vendored cargo warns cargo_multi_version_old_cargo ("declares no rust-version") when the root package inherits rust-version from [workspace.package] #651 (vendored): rust-version.workspace = true now reads
  [workspace.package]. A standard modern workspace no longer gets a
  false cargo_multi_version_old_cargo ("declares no rust-version")
  warning.

Root cause

The project's declared cargo floor was read by one private helper in
vendor/cargo.rs, and only vendored mode called it. The helper took
[package].rust-version with .get(), so the { workspace = true }
table blocked the [workspace.package] fallback (#651). Hosted mode
never asked for the floor at all (#653).

The fix is one pure reader, formats/cargo/floor.rs, that both modes
call. It reads the floor the way cargo and rustup do:

• the root rust-version, with .workspace = true inheritance;
• for hosted, also the lowest floor among the member manifests the planner
  pins, because one cargo builds the whole lock;
• else the toolchain rustup picks: the legacy rust-toolchain file over
  rust-toolchain.toml when both exist (rustup's own order);
• a dated nightly-/beta-YYYY-MM-DD channel maps to its release train
  (stable ships every 6 weeks; 1.68 shipped on 2023-03-09).

rust-toolchain.toml and rust-toolchain are new read-only
(HOSTED | PRESENCE_ONLY) rows in formats/registry.rs. The hosted
planner sees them, but no rewriter edits them and they never trigger the
symlinked-read refusal. The contract and docs/ecosystems.md now give
the hosted cargo floor.

Not covered: toolchain files in ancestor directories, which rustup also
walks to. Hosted mode reads only the project root.

Tests

Red first, on the unchanged code (cargo test -p socket-patch-core --lib -- cargo_declared_floor_below_sparse_support_is_refused a_workspace_inherited_rust_version_is_the_declared_floor): 2 failed.
For example, the hosted test got left: [], right: ["redirect_cargo_old_cargo"]. Both are green after the fix.

Local runs on e482907 (plus the blank-toolchain fix in bbd74db, re-tested with the floor and hosted unit tests):

• cargo fmt --all -- --check: clean.
• cargo clippy --workspace --all-features -- -D warnings: clean.
• cargo test -p socket-patch-core --all-features (lib and every
  integration test): all pass except 4 permission tests (copy_tree
  symlinked root, vlt_heal unremovable lock, poetry/requirements
  write-failure). Those fail the same way on main because this sandbox
  runs as uid 0, which ignores chmod.
• cargo test -p socket-patch-cli --all-features --lib --bins: 913
  passed.
• The cargo e2e suites, with SOCKET_PATCH_CARGO_E2E_REQUIRED=1:
  e2e_redirect_cargo_build 22, e2e_redirect_cargo_shapes 31,
  e2e_vendor_cargo_build 39, mode_migration_cargo 29. All pass.
• I couldn't build the full cargo test --workspace locally: its 150+ CLI
  test binaries need more disk than this session allows. CI runs the rest.

The npm, PyPI and gem wrappers have no cargo logic, so they needed no
change. /code-review high raised 7 findings. I fixed 6 in a follow-up
commit; the 7th (ancestor toolchain files) is out of scope, as noted above.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Pr4cZSSSuEsv1rzzGoxTpg

Generated by Claude Code