Skip to content

feat(toolchain): MSVC system-toolchain detection & selection (msvc@system) — 0.0.88#208

Merged
Sunrisepeak merged 6 commits into
mainfrom
feat/msvc-system-toolchain
Jul 13, 2026
Merged

feat(toolchain): MSVC system-toolchain detection & selection (msvc@system) — 0.0.88#208
Sunrisepeak merged 6 commits into
mainfrom
feat/msvc-system-toolchain

Conversation

@Sunrisepeak

Copy link
Copy Markdown
Member

Summary

MSVC joins as mcpp's first system toolchain: mcpp locates and identifies an installed Visual Studio / Build Tools but never installs or removes MSVC itself (detection-first; the native cl.exe/.ifc build pipeline is a later phase).

Design doc: .agents/docs/2026-07-13-msvc-system-toolchain-detection-design.md
Implementation plan: .agents/docs/2026-07-13-msvc-system-toolchain-implementation-plan.md

What works

  • mcpp toolchain default msvc — three-strategy discovery (vswhere → VSINSTALLDIR/VS*COMNTOOLS → well-known paths, incl. new major-version dirs like …\18\Enterprise), identifies VS product / VC tools / cl.exe banner version (localization-tolerant token parsing), reports import std (std.ixx) availability, persists the stable spec msvc@system (survives VS updates). Absent MSVC → actionable install guidance (VS Installer C++ workload / winget install Microsoft.VisualStudio.2022.BuildTools) + non-zero exit.
  • msvc@<prefix> (e.g. msvc@19.51) — pin-verify against the detected install.
  • mcpp toolchain list — Windows System: section with effective-default star; install msvc reports what's there or guides; remove msvc refuses (system component).
  • mcpp self doctor — Windows "msvc (system)" check section.
  • Manifest [toolchain] windows = "msvc@system" now actually works (the schema documented in types.cppm since long ago); msvc specs on non-Windows hosts error clearly.
  • mcpp build with msvc selected fails early with one owned message naming the detected version and pointing at llvm@20.1.7 (MSVC-ABI Clang) — never an incidental error deep in GCC/Clang-shaped flag machinery.
  • detect() classifies cl.exe (filename short-circuit; banner → version/arch/triple; driverIdent from the banner so MSVC patch updates invalidate BMI fingerprints correctly); bmi_traits gains the .ifc branch for the future pipeline.

Verified on real Windows CI (temp PR #207, green)

Detected msvc 19.51.36248 (VS 18 Enterprise) (VC tools 14.51.36231)
         cl: C:\Program Files\Microsoft Visual Studio\18\Enterprise\VC\Tools\MSVC\14.51.36231\bin\Hostx64\x64\cl.exe
Default  set to msvc@system (was: llvm@20.1.7)
Resolved msvc@system → msvc 19.51.36248 (…\cl.exe)   # then the owned build gate fires

Tests

  • unit: tests/unit/test_toolchain_msvc.cpp (banner incl. localized/arm64, guidance, spec classification, msvc@system default matching, .ifc traits) — 9 tests
  • e2e: 95_msvc_system_toolchain.sh (requires: msvc, passed on Windows CI) + 96_msvc_unavailable_nonwindows.sh (requires: unix-shell, passed locally)
  • ci-windows.yml: new step "Toolchain: MSVC — detection & selection" (runs before the LLVM self-host rebuild which invalidates $MCPP_SELF)

Version

0.0.88 (mcpp.toml + fingerprint.cppm + CHANGELOG)

…stem) (0.0.88)

MSVC joins as the first *system* toolchain: mcpp locates and identifies an
installed Visual Studio / Build Tools (vswhere → env → well-known paths;
cl.exe banner → compiler version/arch, localization-tolerant) but never
installs or removes MSVC itself.

- toolchain default msvc: detect + report (VS product, VC tools, cl version,
  std.ixx availability), persist stable 'msvc@system'; absent → install
  guidance (VS Installer C++ workload / winget BuildTools), exit non-zero.
  msvc@<prefix> acts as pin-verify against the detected install.
- toolchain list: Windows 'System:' section; install msvc reports what's
  there or guides; remove msvc refuses (system component).
- self doctor: Windows 'msvc (system)' check section.
- manifest [toolchain] windows = "msvc@system" now actually works; msvc
  specs on non-Windows hosts error clearly.
- build: native cl.exe (.ifc) pipeline is gated off with one owned message
  pointing at llvm@20.1.7 (MSVC-ABI Clang) until it lands.
- detect(): cl.exe classification path (filename short-circuit, banner
  enrich); bmi_traits gains the MSVC .ifc branch.
- tests: unit (banner/guidance/spec/traits) + e2e 95 (Windows, requires msvc
  cap) / 96 (non-Windows rejection); run_all.sh msvc capability.
- design: .agents/docs/2026-07-13-msvc-system-toolchain-detection-design.md
toolchain list stars the *effective* default; the repo root's mcpp.toml
[toolchain] windows=llvm@20.1.7 would shadow the freshly-set global
msvc@system when run_all.sh executes from the workspace.
The rebuild cleans target/, invalidating the job's $MCPP_SELF fingerprint
path — the MSVC step then failed with exit 127 (binary gone).
windows-latest now installs VS under 'Microsoft Visual Studio\18\Enterprise'
(major version, not year branding) — vswhere finds it, but the strategy-3
path scan should too.
…poraries

GCC/libstdc++ and Clang/MSVC-STL accepted 'auto&' here; Clang/libc++ (macOS
job) correctly rejects binding a non-const lvalue ref to the temporary.
@Sunrisepeak Sunrisepeak merged commit a1f4429 into main Jul 13, 2026
6 checks passed
@Sunrisepeak Sunrisepeak deleted the feat/msvc-system-toolchain branch July 13, 2026 00:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant