Update cmake, cc, and find-msvc-tools for Visual Studio 2026 - #293

Cargo.lock only: cmake 0.1.54 to 0.1.58, cc 1.2.41 to 1.4.0, find-msvc-tools 0.1.4 to 0.1.9.

The problem

GitHub repointed windows-latest from windows-2025 to windows-2025-vs2026. That image carries Visual Studio 2026 (18.7) and MSBuild 18.7, and no VS 2022. Since then every build that calls cmake from a build script panics with couldn't determine visual studio generator. Three Windows jobs have been red on main ever since: cargo-tests, gradle-tests, and examples-tokio-boring-app. There are no commits between the last green run and the first red one.

The panic surfaces in the cmake crate but the message is written elsewhere:

cmake::Config::visual_studio_generator()    cmake 0.1.54, lib.rs:970  <- panics here
  cc::windows_registry::find_vs_version()   cc 1.2.41, lib.rs:321
    find_msvc_tools::find_vs_version()      find-msvc-tools 0.1.4     <- message written here

find-msvc-tools 0.1.4 knows MSBuild 17.0 down to 14.0. Nothing matches on the new image, so it returns an error and cmake re-panics with it.

Why all three crates

Each is an independent blocker, and a partial bump is worse than none: cc 1.2.41 accepts find-msvc-tools 0.1.9 under semver and then hits unreachable!("unknown VS version") on the Vs18 it gets back.

cargo update -p cmake --precise 0.1.58 produces exactly this. Plain cargo update -p cmake does nothing, because cargo holds the other locked packages fixed and cmake 0.1.55+ needs cc ^1.2.46.

What was ruled out

Running vcvars first does not help. It sets VisualStudioVersion=18.0, which 0.1.4 fails to recognise from the environment just as it does from the registry. I confirmed that by running it rather than reasoning about it.

CMAKE_GENERATOR=Ninja is worse. boring-sys picks its output subdirectory from target.ends_with("-msvc") rather than from the generator, so under single-config Ninja the libraries land where none of its link search paths look.

Testing

Reproduced and fixed locally on macOS first, since find_vs_version() reads VisualStudioVersion before any Windows-only code. Under VisualStudioVersion=18.0 the locked versions fail and the new ones return Ok(Vs18); VS 2022 still returns Ok(Vs17). Through the cmake crate, the old versions panic at lib.rs:970:25, the same line and column CI reports, and the new ones emit -G "Visual Studio 18 2026" -Thost=x64 -Ax64.

Then on a trimmed CI matrix, all three previously red Windows jobs pass, including BoringSSL compiling under the VS 2026 toolchain. cargo check --workspace --all-targets is clean with cc 1.4.0, covering both cmake consumers.

One thing worth knowing: gobley-wasm-transformer's dependency closure includes cc, so this also changes what a future cargo install --locked of that tool pins.

No CHANGELOG entry, following the precedent of recent CI and dependency commits (fbaec69, c49e8a9, a4d0a0e, 034cc27). These crates are build dependencies of test fixtures and examples only.

Written with AI assistance (Claude Code) and pending human review, per CONTRIBUTING.md.

🤖 Generated with Claude Code