D4: a compiler that cannot isolate a graph-supplied C library is degraded

The revert (bcbb3e0) removed the hard refusal for "graph-supplied C
library + a compiler that cannot isolate" because it broke the "report
before refusing" contract. That left GCC silent again on this combination
-- which is what D4 actually ruled out. This adds the third option: a
degradation, not a refusal and not silence.

`mcpp::diag::degraded("target/c-abi-isolation", ...)` fires once resolution
knows the C library came from the graph and the resolved compiler is not
Clang-family. It names the C library (interface and package@version) and
the compiler, points at a Clang-family toolchain as the one that isolates,
and changes nothing about the command line -- `hostflags.cppm` was already
not emitting an isolation token for GCC, and still is not. `--strict`
promotes it to an error through the existing `diag::flush` policy, which
is the one place that decision already lives.

- `prepare.cppm`: the check sits right where `resolvedTargetSide` becomes
  available, beside the existing `target/compiler-runtime` degradation,
  and before `format_report` prints -- so the report is unaffected either
  way, which is what the earlier refusal got wrong.
- e2e 740: names the library and the compiler in the warning, asserts the
  target-side report still prints (the exact thing the reverted refusal
  broke), and controls against a Clang-family toolchain over the same
  graph getting no such note. 268, 282, 303 re-verified green.
- CHANGELOG's D4 bullet rewritten to describe what this branch actually
  does, not the removed refusal.

Author: speak-agent

CHANGELOG.md

@@ -20,15 +20,21 @@
   条件改为只看这一层自己的来源,不再看 `c-abi` 是否也来自图。两个 token 出现在 `cflags`/
   `cxxflags`/`asmflags` 这组全局 flags 里,C、C++、汇编、依赖扫描、std 模块预编译同时受益。
   (`src/toolchain/hostflags.cppm`,单测 `test_hostflags.cpp`)
-- **GCC 家族没有等价的单一 flag,保持原样不隔离。** `-nostdinc` 加 `-isystem <gcc
-  -print-file-name=include>`、`<…/include-fixed>` 才能拼出等价物,且 GCC 本就没有
-  `<driver>.cfg` 可供 `bypassCfg` 打开这整块——`hostflags.cppm` 因此对 GCC 不做任何改动。
-  最初的草案在 `prepare.cppm` 里加了一条「图供给 C 库 + GCC」的硬拒绝,想着比静默不隔离更
-  诚实;实测(268、282、303 三个既有 e2e)显示这个组合是这几个文件的常规夹具——它们用一个
-  只声明 `provides = ["mcpp:c-abi=..."]`、不含真实头文件的假包在**原生**目标上验证与隔离
-  完全无关的其它事实,且都依赖 268 自己注释所陈述的设计:目标侧的解析报告先于编译打印,
-  失败与否不影响这条报告——而这条硬拒绝恰好抢在报告打印之前退出,三个文件全部转红。撤回
-  该拒绝;GCC 在这一组合上的行为与 #662 之前逐字节相同。
+- **GCC 家族没有等价的单一 flag,命令行不变,但不再静默。** `-nostdinc` 加
+  `-isystem <gcc -print-file-name=include>`、`<…/include-fixed>` 才能拼出等价物,且
+  GCC 本就没有 `<driver>.cfg` 可供 `bypassCfg` 打开这整块——`hostflags.cppm` 因此对 GCC
+  不做任何改动,这一组合上产出的编译命令与 #662 之前逐字节相同。
+  中途试过两种更强的处理,都被实测推翻:静默不隔离(#662 之前的状态,`GCC 家族没有等价的
+  单一 flag` 的最初读法)什么也不说;`prepare.cppm` 里一条「图供给 C 库 + GCC」的硬拒绝
+  (想着比静默更诚实)在既有 e2e 268、282、303 上转红——它们用一个只声明
+  `provides = ["mcpp:c-abi=..."]`、不含真实头文件的假包在**原生**目标上验证与隔离完全无关
+  的其它事实,且都依赖 268 自己注释所陈述的设计:目标侧的解析报告先于编译打印,失败与否
+  不影响这条报告——而硬拒绝恰好抢在报告打印之前退出。第三种形状落地:`mcpp::diag::degraded`
+  在目标侧解析出「c-abi 来自图 且 编译器不是 Clang 家族」时报一条 warning,点名 C 库
+  (名字与 `包名@版本`)和编译器,并指向 Clang 家族能做到隔离——不拒绝构建,不改动任何命令行
+  (`hostflags.cppm` 本就没有为这一组合追加过 token),也不再沉默。`--strict` 下
+  `mcpp::diag::flush` 按其既有策略把它提升为错误,复用的是这一整块已经存在的策略,不是新写
+  的一条。(`src/build/prepare.cppm`,e2e 740;268、282、303 仍然全绿)
 - **隔离后原本靠宿主补齐的包会确定地失败,失败信息现在可读。** 构建失败、目标侧 `c-abi`
   来自图、且编译器输出含 `file not found` 时,追加一条说明,点名 C 库(名字与
   `包名@版本`)并给出两条路:按 `cfg(c-abi = "...")` 适配,或把平台依赖以私有可见性带进
@@ -44,11 +50,13 @@
   构建与载荷提供 C 库的构建命令行逐字节不变(单测守卫)。这类构建的 flags 指纹变化,升级后
   会重建一次。原先只因为宿主头文件补上缺口才能编译的包,现在会确定地失败——这类构建此前只在
   装了对应宿主包的机器上成功,产物还混用了两个 C 库的声明;新增的说明使这类失败可以诊断。
+  C 库来自图、编译器却是 GCC 家族的构建会多打印一条 warning(命令行不变,构建照常继续)。
 - 单测:`test_hostflags.cpp`(选项矩阵 `cAbiPrebuilt × cxxFromGraph × {clang, gcc}`,以及
   载荷提供两层时命令行不变的回归守卫)、`test_ninja_backend.cpp`。e2e:738(openkal
   `x86_64-windows-gnu` 构建,逐单元核对 clang 自己报告的头文件搜索列表,门在
   `mingw-host-headers` capability 上,`openkal-cross.yml` 的 `ecosystem-e2e` job 安装
-  `mingw-w64` 使其在 CI 上成立)、739(私有 feature-dep 的双向锁定)。
+  `mingw-w64` 使其在 CI 上成立)、739(私有 feature-dep 的双向锁定)、740(GCC 家族在
+  图供给 C 库上得到警告而非拒绝,且既有的 268/282/303 仍然全绿)。
 
 ### 声明的 C 运行时由 mcpp 安装,查找只做精确匹配:#660(2026.9.17.2)
 

src/build/prepare.cppm

@@ -10769,6 +10769,39 @@ prepare_build(bool print_fingerprint,
         resolvedTargetSide = tsd::resolve(in);
         targetSideResolved = true;
 
+        // REPORTED, NOT REFUSED (mcpp#662, D4). `mcpp.toolchain.hostflags`
+        // closes the compiler's own C-library search with `-nostdlibinc`
+        // when a package supplies the target's C library (M1) — but only on
+        // a Clang-family driver; GCC has no one-token equivalent
+        // (`hostflags.cppm`'s own note on the shape it would need). Silently
+        // building unisolated was ruled out once already: the resolver
+        // refusing the combination outright was ALSO tried and reverted —
+        // it fired before `format_report` below and broke three existing
+        // e2e fixtures (268, 282, 303) that use a synthetic C-library
+        // provider on this host's native, GCC-default target to assert
+        // something else entirely, none of them about isolation. A
+        // degradation is the third option: it changes no command line
+        // (this branch decides nothing `hostflags.cppm` does not already
+        // decide on its own), and it does not stop a build the previous
+        // release would have allowed — it names, once, the gap the previous
+        // release left silent.
+        if (tc && resolvedTargetSide.cAbi.fromGraph()
+            && !mcpp::toolchain::is_clang(*tc)) {
+            mcpp::diag::degraded("target/c-abi-isolation", std::format(
+                "the target's C library ('{}', {}) comes from the "
+                "dependency graph, and the resolved compiler ('{}') has no "
+                "way to stop its own driver from also searching the host's "
+                "C library headers",
+                resolvedTargetSide.cAbi.interfaceName,
+                resolvedTargetSide.cAbi.impl, tc->compiler_family()),
+                "a host header can still satisfy an #include the graph's "
+                "own headers do not, silently — a Clang-family toolchain "
+                "closes that search entirely (docs/22 'Adaptation To The "
+                "Resolved Target Side')",
+                "add [toolchain] default = \"llvm@<version>\", or for one "
+                "target only [target.<triple>] toolchain = \"llvm@<version>\"");
+        }
+
         // REPORTED ONCE, NOT REFUSED. A program that never reaches an
         // availability check links and runs without the archive; refusing it
         // would trade a diagnosed hazard for a regression. The degradation

tests/e2e/740_gcc_over_a_graph_c_library_is_degraded_not_refused.sh

@@ -0,0 +1,100 @@
+#!/usr/bin/env bash
+# requires: gcc
+# 740 -- when the target's C library comes from the dependency graph and the
+# resolved compiler cannot isolate it from the host's own (GCC: no single
+# flag equivalent to Clang's `-nostdlibinc`), mcpp reports a degradation and
+# proceeds. It neither refuses the build nor stays silent.
+#
+# THE HISTORY, BECAUSE BOTH OTHER SHAPES WERE TRIED AND MEASURED WRONG.
+#
+# Silent was the state before mcpp#662's M1: GCC never emitted the isolation
+# token (hostflags.cppm's `bypassCfg` is unconditionally false for GCC, no
+# `<driver>.cfg` beside it), and nothing said so.
+#
+# A hard refusal at `prepare_build` was tried next, reasoning "never
+# silently unisolated" all the way to a build error. Measured against the
+# existing suite it broke three files (268, 282, 303) that use a synthetic
+# `provides = ["mcpp:c-abi=..."]` package with the AMBIENT default toolchain
+# (gcc on a fresh Linux runner) to assert something about the target-side
+# REPORT, none of them about isolation -- and the refusal fired before that
+# report printed, which is exactly what 268's own comment says must never
+# happen: "the resolution is reported during planning ... before a single
+# object is compiled ... complete whether or not the link afterwards
+# succeeds".
+#
+# `mcpp::diag::degraded` is the third option this test locks in: the build
+# is not refused (268/282/303 stay green -- this file's own half two
+# reproduces 303's shape and checks the report line still prints), and the
+# gap is not silent either (half one).
+set -e
+
+MCPP="${MCPP:-mcpp}"
+work="$(mktemp -d)"
+trap 'rm -rf "$work"' EXIT
+cd "$work"
+
+mkdir -p libc/src
+printf '[package]\nname     = "fake-libc"\nversion  = "0.1.0"\nprovides = ["mcpp:c-abi=musl"]\n\n[build]\nsources  = []\n' \
+    > libc/mcpp.toml
+printf '[package]\nname    = "clibdeg"\nversion = "0.1.0"\n\n[dependencies]\nfake-libc = { path = "libc" }\n' \
+    > mcpp.toml
+
+# `why toolchain`, NOT `build`: this file's subject is what mcpp REPORTS
+# during resolution, and a real link additionally needs a working sandbox
+# C-runtime setup that has nothing to do with the claim here (`build`'s own
+# behaviour on this exact fixture is 303's territory).
+out="$("$MCPP" why toolchain 2>&1)"
+
+# ── Half one: the degradation names the library and the compiler ───────────
+echo "$out" | grep -q '^warning: ' || {
+    echo "FAIL: no warning at all on a GCC toolchain over a graph-supplied C library:"
+    echo "$out"; exit 1
+}
+echo "$out" | grep -qF "C library ('musl'" || {
+    echo "FAIL: the warning does not name the C library:"; echo "$out"; exit 1
+}
+echo "$out" | grep -qF "resolved compiler ('gcc')" || {
+    echo "FAIL: the warning does not name the compiler that cannot isolate:"
+    echo "$out"; exit 1
+}
+echo "$out" | grep -qi 'clang' || {
+    echo "FAIL: the warning does not point at the toolchain that does isolate:"
+    echo "$out"; exit 1
+}
+echo "  ok  a GCC toolchain over a graph-supplied C library is named, not silent"
+
+# ── Half two: it is a note, not a refusal -- the report still reaches print ─
+#
+# THE EXACT FAILURE MODE THE HARD REFUSAL HAD: firing before `format_report`
+# printed anything at all. Asserting the report line is present is what
+# distinguishes "advisory" from "the build's replacement".
+echo "$out" | grep -qE 'c-abi *musl' || {
+    echo "FAIL: the target-side report did not print at all -- looks like the"
+    echo "      refusal this file exists to keep reverted:"
+    echo "$out"; exit 1
+}
+echo "  ok  the target-side report still prints (this is advisory, not a refusal)"
+
+# ── Half three: the control -- a Clang-family toolchain gets no such note ──
+#
+# THE HARNESS'S OWN VALIDITY. Without this, half one could be passing because
+# the message ALWAYS prints, on every toolchain, which would say nothing
+# about GCC specifically.
+llvmspec="$("$MCPP" toolchain list --format json 2>/dev/null \
+    | jq -r '[.data.toolchains[] | select(.family=="llvm") | "llvm@"+.version]
+              | unique | .[0] // empty' | tr -d '\r')"
+if [ -n "$llvmspec" ]; then
+    printf '[package]\nname    = "clibdeg"\nversion = "0.1.0"\n\n[toolchain]\ndefault = "%s"\n\n[dependencies]\nfake-libc = { path = "libc" }\n' \
+        "$llvmspec" > mcpp.toml
+    out2="$("$MCPP" why toolchain 2>&1)"
+    if echo "$out2" | grep -q "has no way to stop"; then
+        echo "FAIL: the same degradation fired on a Clang-family toolchain, which"
+        echo "      DOES isolate the graph's C library:"
+        echo "$out2"; exit 1
+    fi
+    echo "  ok  a Clang-family toolchain over the same graph gets no such note"
+else
+    echo "SKIP: no llvm installed here to run the control against"
+fi
+
+echo "OK: 740 a compiler that cannot isolate a graph-supplied C library is degraded, not refused"