Feature Proposal

Problem

The current language/OS support matrix and LLVM-specific consumer assertions do not prove actual Microsoft/GCC/custom backend support or independence from preinstalled developer tools.

Proposed Scope

Part of #4809. Roadmap task 16/16.

Ownership: Existing C/C++ external consumers, .github/workflows/ci.yml and generated support-matrix evidence; integration-only closure owner.

Prerequisites: #4810, #4811, #4812, #4813, #4814, #4815, #4816, #4817, #4818, #4819, #4820, #4821, #4822, #4823, #4824.

Extend existing consumer/CI and generated support facts with compiler, driver, version and execution/target identity. Parameterize LLVM-only consumer assertions while retaining their baseline coverage. Qualify the required matrix from the parent tracker using the delivered leaves; do not duplicate their implementations.

Use genuinely clean developer environments or demonstrably deny access to preinstalled toolchains; removing PATH entries alone is not proof. Test compiler/version switching, unsupported selections, a renamed independent consumer, custom toolchains, relocated execution and network-denied rebuilding with legally prepared pinned cache inputs.

Collect real native Windows x64/ARM64 and Linux x64/ARM64 execution evidence. Preserve current LLVM support on its existing five-host matrix. Include native Rust/Python and permitted-runtime package cases. Missing runner, licensing, upstream or platform facts remain explicit blockers rather than skips counted as support.

Update user-facing help/configuration examples, CI instructions and generated support records. Do not add plan/design-history documents. Hosted execution, publication, signing and deployment still need separate authorization.

Acceptance criteria

• Each advertised compiler/host/target cell has commands, exact source SHA, versions/digests, job/artifact links and native execution outcomes.
• Fresh Windows builds use actual provisioned cl.exe with no VS/MSVC/SDK installation; fresh Linux GCC builds use no ambient compiler/sysroot.
• Selection/version changes, incompatible options and missing inputs produce correct actions, artifacts, reports and exits; no silent fallback or stale cache masking.
• Real native consumers, relocation, permitted-runtime package execution and network-denied repeat builds pass with their declared prerequisites.
• Support-matrix generation/drift checks and user docs match verified capabilities, including explicit unsupported analysis/coverage cells. All applicable leaf acceptance is verified before closure.

Alternatives Considered

A preconfigured hosted Windows runner, mocked compiler, selected platform label, cross-build or another revision's evidence is not sufficient clean/native qualification.

Compatibility Impact

Extend existing CI and consumer harnesses, preserving LLVM defaults and current supported hosts. This is the final acceptance owner, not a reason to block independent leaf implementation on the whole tracker.

Agent handoff and evidence

Read current AGENTS.md and inspect merged code before editing. Work in a focused worktree; keep shared MODULE/platform/CI wiring with the integration owner. Reuse existing libraries, upstream providers and tests. Run the repository's affected fix/test workflow, inspect JSON results, and attach exact base/final SHA, tool versions, execution/target identities and real commands/results. Keep warnings as errors and preserve user work.

Prerequisites identify delivered interfaces/primitives, not whole-tracker closure; agreed fixture/parser/scaffolding work may proceed independently. Record missing native runner, licensing or upstream evidence rather than claiming support. Filing is not authorization for license acceptance, privileged installation, hosted dispatch, signing, publication or deployment.

Research baseline: c6c0f67; verify current main before implementation.