v0.0.93

变更(命名统一,全部旧拼写永久兼容)

• 工具链 × 目标 命名统一 —— 二轴身份模型。toolchain = family@version
  (family 只剩 gcc | llvm | msvc),target = mcpp 自有三段 triple
  arch-os[-env](Zig 式砍 vendor)。变体(gnu/musl/msvc)进 triple env 段,
  "cross"/"musl"/"mingw" 不再是工具链名字——mingw-cross 16.1.0 的本体是
  gcc@16.1.0 → x86_64-windows-gnu,交叉只是 host≠target 的关系。业界对照
  (rustup 零 "cross" 命名/Zig 三段 triple/musl.cc 分发层先例)与决策记录见
  .agents/docs/2026-07-15-toolchain-target-naming-unification-design.md。
  • canonical triple:x86_64-windows-gnu 为正典(D1);GNU 拼写
    x86_64-w64-mingw32 及 4 段 Rust 拼写为永久别名,归一后进同一
    target/<canonical>/ 目录(同一构建缓存)。macOS 产物目录随 canonical 变为
    aarch64-macos。
  • --target 封闭词汇表校验:打错字硬错 + did-you-mean
    (did you mean 'x86_64-linux-musl'?),不再静默 fall through 编成宿主产物
    (最坏失败模式根治);自定义 triple 走显式 [target.X] 节逃生舱;planned
    档位(riscv64 等)报「registered but not yet supported」。两条硬编码约定
    (*-musl、x86_64-w64-mingw32)改为词汇表数据行(pin + 默认 static)。
  • 单一 triple 解析器 triple.cppm:cfgpred/abi/model 谓词/registry 四处
    平行解析收敛;abi 的 os 维 darwin→macos(与 cfg 词汇分叉消灭,
    darwin/arm64 作为约束别名接受)。
  • compat.cppm 兼容层:唯一知道旧拼写的文件(musl-gcc/gcc@V-musl/
    -gcc/mingw/mingw-cross/clang),归一 + 单行 note: 提示;xim 分发包名
    (mingw-cross-gcc 等)不动——"cross" 在分发层合法(musl.cc/Debian 先例)。
  • CLI 单名词 + --target 选项(D4,不设 mcpp target 子命令):
    toolchain install [gcc 16] --target <triple>(family 可省→约定 pin)、
    toolchain default gcc@16 --target <triple>(默认变 pair,持久化
    default + default_target 两键)、toolchain remove … --target <triple>;
    主路径仍是 mcpp build --target <triple> 自动装链(零仪式)。
  • [build] target = "<triple>" 新 manifest 键(≙ cargo build.target):
    「默认全静态 musl」的正确归宿(产物属性,非编译器家族属性);优先级
    --target flag > [build] target > 全局 default_target > host。
  • toolchain list 两轴重排:Toolchains 块(family@version)+ Targets 块
    (target × 状态 installed/available/planned,planned 行使词汇表用户可见);
    修版本字典序排序 bug(9.4.0 不再排在 15.1.0 前);gcc X-musl 行不再被
    llvm 劈开。README 平台表从词汇表重画(target × tier 维度,补 MSVC=✅ 与
    windows-gnu 行——旧表 MSVC 仍标 planned 是错的)。
  • 修 Windows host 上 mingw 的门:Linux 上 toolchain install mingw 现在
    合法(= 装交叉 payload,同一身份 host 分流);mcpp run 位置参数 help 改为
    「Binary name」消除与 --target 的语义撞名。
  • 验证:单测 35(新增 triple/compat 套件);e2e 新增 103(typo/planned/逃生舱/
    [build] target/别名同目录)、102 双拼写断言;本机实测双拼写同 Resolved
    行+同缓存(alias 二跑 0.07s 全命中)、PE wine 真跑、musl 静态链、typo
    did-you-mean。

v0.0.92

新增

• Linux → Windows MinGW-w64 交叉工具链(mingw-cross)—— host≠target 一等公民。
  在 Linux 主机上交叉编译出 Windows x86_64 PE,含 import std。补 0.0.89
  msvc-mingw-design §4.4/§7 登记的延期项(交叉维:host≠target)。
  • 工具链:从源码构建的 GCC 16.1.0 mingw-w64 MSVCRT 交叉链(triple
    x86_64-w64-mingw32,跟随 Rust Tier-1 x86_64-pc-windows-gnu 的 CRT 选型);
    自包含(自带 binutils/CRT/libstdc++ 含 bits/std.cc + libstdc++exp);
    发布于 xlings-res/mingw-cross-gcc(GitHub+GitCode)+ xim-pkgindex。
  • mcpp 侧:用户名 mingw-cross → xim mingw-cross-gcc(前端
    x86_64-w64-mingw32-g++);解除 MinGW 的 Windows-host 门(Linux 主机可装,native
    mingw 仍 Windows-only);--target x86_64-w64-mingw32 约定解析(默认 static);
    跳过 glibc/linux-headers(PE 自带 CRT)。
  • host≠target 化:PE 产物形态判断一律按 target 而非 host constexpr——std 模块源
    探测补 <prefix>/<triple>/include/c++/ 子目录;自包含工具链跳过外部 binutils -B
    (musl + mingw);MinGW link 分支(-static / -lstdc++exp)由 if constexpr(is_windows)
    host 门提为运行期 is_mingw_target target 判定。
  • 验证:e2e 102_mingw_cross_wine.sh(# requires: mingw-cross wine,build --target
    → PE 静态自包含断言 → wine 跑 import std + 多模块);CI cross-build-test.yml 加
    mingw-cross-wine job(OS-cross,wine)。全链实测闭环(install→build→wine)。
  • 设计:.agents/docs/2026-07-15-mingw-linux-cross-windows-design.md。

v0.0.91

新增

• standard = "c++fly" — 一行启用"最新标准 + 全部实验特性"(语言 + 标准库)。
  语义三件套,全部按 resolved 工具链自动判定:①族最新 -std= 档位(GCC16→c++26、
  Clang→c++2c、MSVC→/std:c++latest);②该工具链支持的全部实验性语言特性门
  (GCC≥16:反射 -freflection;契约随 -std=c++26 默认启用,实机探测定案);
  ③标准库实验门(libc++→-fexperimental-library)。不支持的特性软跳过并打印
  summary(c++fly on <toolchain>: <std>; enabled: ...; skipped: ...)。
  新模块 src/toolchain/cppfly.cppm 承载三张数据表(族×版本×stdlib)——首个真正
  使用 Toolchain::version 做门控的查询点;产物汇入 0.0.90 的图全局方言旗标通道
  (全图 TU + P1689 扫描 + std BMI 预构建同源),派生旗标并入指纹。
  设计:.agents/docs/2026-07-14-std-features-experimental-gate-design.md。
  e2e 100(gcc16 硬路径:零手写旗标跑通 std::meta 反射)/ 101(clang 软路径:
  c++2c + skipped summary)。

修复

• standard = "c++latest" 在 GNU 族误拼 -std=c++latest(GCC/Clang 不识别,
  构建必败):canonical 现经 cppfly 的"族最新档"表解析为真实档位(GCC16→
  -std=c++26)。e2e 100 尾段回归覆盖。

v0.0.90

新增

• MSVC 原生构建后端(cl.exe)落地,0.0.88 的构建门移除。选定 msvc@system
  后 mcpp build/run 直接用系统 MSVC 编译链接:
  • 环境模型:find_windows_sdk() + 从检测到的 VC tools/SDK 直接合成
    INCLUDE/LIB/PATH(+VSLANG=1033),不跑 vcvarsall;SDK 缺失时检测/选择仍可用,
    构建报带指引的明确错误;doctor 新增 SDK 与 mingw 检查行。
  • 模块管线:std/std.compat.ixx 单命令 staging(/ifcOutput → ifc.cache),
    命名模块 .cppm 经 /interface /TP 编译、/ifcSearchDir 消费;
    /scanDependencies 作为第三个编译器内建 P1689 扫描驱动接入 dyndep。
  • 链接:link.exe/lib.exe(SeparateLinker)+ 响应文件(绕 cmd 8191 限制),
    DLL=/DLL /IMPLIB:;deps=msvc(/showIncludes)头文件依赖;/MD|/MT CRT
    随 linkage;/std:c++20|c++latest 映射;.obj 扩展名全链路。
  • fast-path 增量:构建缓存 env 槽新增 @env 多变量编码,增量构建重建
    INCLUDE/LIB 环境。e2e 99(模块/import std/增量)+ 95 改造为真实构建断言。
• [build] dialect_cxxflags + 方言旗标全图化(issue #210 修复)。
  -freflection 等"改变标准库头声明集"的 flag 现随 -std= 的通道到达:
  全局 cxxflags(项目+依赖所有 TU)、std/std.compat BMI 预构建命令、P1689 扫描。
  known-list 自动提升(reflection/contracts/char8_t/_GLIBCXX_USE_CXX11_ABI)+
  显式 dialect_cxxflags 逃生舱;指纹早已包含这些 flag,修的是命令构造。
  实证:#210 的最小复现(gcc16 + import std; + std::meta)输出 x 2/y 3;
  e2e 98 含依赖模块变体。

修复与优化

• mingw 在非 Windows 主机的 toolchain install/default 现在明确报
  windows-only(此前是 invalid xpkg target 'xim:mingw-gcc@')。
• std 模块 staging 命令在 Windows 用 cd /d(跨盘;工作区 D: + 缓存 C: 的
  真实 CI 布局)。
• release 的 publish-ecosystem:镜像脚本改为批量上传+带耐心的 ranged-GET 验证、
  验证超时不再删除资产(0.0.89 因逐资产"18s 即删重传"+全量 GET 探测触顶
  20min 被杀);timeout 兜底 20→30。
• stdmod 执行层支持工具链声明环境(capture_with_env);shell 引用平台化。

v0.0.89

新增

• MinGW-w64 工具链入 xlings 生态(Windows 原生 GCC,无需 Visual Studio)。
  mcpp toolchain install mingw 16.1.0 / default mingw@16.1.0:xim 包
  mingw-gcc(winlibs GCC 16.1.0 + MinGW-w64 14.0.0 UCRT 独立构建,镜像于
  xlings-res/mingw-gcc,GitHub+GitCode 双端)。复用既有 GCC 后端
  (gcm 模块管线、libstdc++ bits/std.cc 的 import std);Windows 上
  libstdc++/libgcc 默认静态链接(产物免带 DLL,[build] static_stdlib=false
  可关),linkage="static" 升级全静态。e2e 97 覆盖 install→default→
  多模块 build/run→独立 exe 验证;ci-windows 新增专项步骤。
  连带修复:toolchain list 的 Available 段与部分版本解析此前硬编码按
  "linux" 平台读取 xpkg 版本(Windows/macOS 上恒空);toolchain install
  在 Windows/macOS 不再错误安装 glibc/linux-headers 依赖。

重构

• 工具链后端抽象层(Part A,对 GCC/Clang 零行为变化,build.ninja 零 diff
  实证)。新增 mcpp.toolchain.dialect(命令行拼写 traits:gnu/msvc 两行
  数据,-I/-D/-std=/-c/-o/-O/-g/ar 及归档命令模板经其发射);BmiTraits
  并入模块旗标拼写(compileModulesFlag/stdBmiUsePrefix/
  moduleOutputPrefix/bmiSearchPrefix),flags.cppm 的 is_clang 分支改由
  数据驱动;ProviderCapabilities.has_builtin_p1689_scan 取代 ninja 后端的
  is_gcc 门;Toolchain::envOverrides(EnvVar 表,注入 ninja 子进程环境,
  为 MSVC 后端 INCLUDE/LIB/PATH 预留);gcc provider 增加与 clang 同形的
  std_module_build_commands(命令序列);resolve_link_model 在 Windows
  显式返回 PE 空模型。设计:.agents/docs/2026-07-13-toolchain-backend- abstraction-msvc-mingw-design.md + 同日触点审计文档。

v0.0.88

新增

• MSVC 系统工具链支持(msvc@system,detection-first)。MSVC 作为首个
  "系统工具链"接入:mcpp 负责定位与识别(vswhere → VSINSTALLDIR/
  VS*COMNTOOLS → 标准安装路径三级发现;cl.exe banner 解析出编译器版本/架构,
  容错本地化 banner),从不安装/卸载 MSVC 本体。
  • mcpp toolchain default msvc:检测系统 MSVC,打印 VS 产品/VC tools/
    cl 版本与 std.ixx(import std)可用性,持久化稳定 spec msvc@system
    (不落具体版本,VS 升级后配置依然有效);未安装时输出安装指引
    (VS Installer C++ 工作负载 / winget install …BuildTools)并退出非零。
    msvc@19.44 形式为 pin 校验(仍取最新 VC tools,前缀不符则报错)。
  • mcpp toolchain list:Windows 上新增 System: 段展示检测到的 MSVC;
    install msvc 报告已装现状或给指引;remove msvc 明确拒绝(系统组件)。
  • mcpp self doctor:Windows 上新增 "msvc (system)" 检查段。
  • manifest 支持 [toolchain] windows = "msvc@system"(types.cppm 注释中的
    既有 schema 首次落地);非 Windows 主机使用 msvc spec 时给出明确报错。
  • mcpp build:原生 cl.exe 构建(.ifc 管线)本版暂不支持,在工具链解析
    后以单一 owned 错误信息拦截,并提示可用的 llvm@20.1.7(MSVC-ABI Clang)。
  • detect() 新增 cl.exe 分类路径(文件名短路,banner → 版本/triple),
    bmi_traits 预置 MSVC .ifc 分支;e2e 95/96 + 单测覆盖。
  • 设计文档:.agents/docs/2026-07-13-msvc-system-toolchain-detection-design.md。

v0.0.87

修复

• 项目本地模式:不再把官方全局索引 xim 注入项目作用域。此前带自定义
  [indices](本地 path 索引)的工程进入项目本地模式时,ensure_project_index_dir
  会无条件把官方 xim 索引 append 进项目 .xlings.json 的 index_repos
  (config.cppm),意在让 xim:* 依赖在项目模式可解析。但 xlings 按"repo 落在
  哪一组"决定作用域——项目 index_repos 里的包一律 PackageScope::Project,于是
  xim 的全局工具(cmake/glibc/gcc/make/binutils 等)整体被错误地"项目化"、
  装进项目 store 而非共享 registry。由此 build-dep 工具(如 xim:cmake)的 ELF
  interpreter 被指向项目 store 里未物化的 glibc → cannot execute,任何在
  install() 里执行 glibc-动态 build-dep 工具的 compat 包(如从源码 CMake 构建的
  OpenCV)在 mcpp test 下必现,且与宿主历史无关(fresh MCPP_HOME 亦复现)。
  修复:移除该注入及配套的项目 data dir xim 副本暴露。xim(及其动态发现的
  sub-index)是 xlings 全局默认索引,global 即默认作用域——xim:* 经全局
  index_repos + registry 本地 clone 正常解析、装 registry,并经 additive 对项目
  可见;只有用户在 [indices] 声明的本地自定义索引才项目化。设计与分析见
  .agents/docs/2026-07-09-project-index-scope-global-infra-fix.md。

v0.0.86

(no CHANGELOG entry found for 0.0.86)

v0.0.85

(no CHANGELOG entry found for 0.0.85)

v0.0.84

修复

• clang 驱动配置文件(cfg)补全头文件搜索路径:fixup_clang_cfg 再生成的
  cfg 此前仅包含链接相关条目(-B/-L/动态链接器/rpath),缺少 C 标准库头文件
  与内核头文件的搜索路径。该 cfg 服务于直接调用打包内 clang/clang++
  (不经由 mcpp)的场景:缺少这两项时,此类调用仅在宿主系统存在
  /usr/include 时可编译(依赖宿主环境,违背沙箱自包含约束),在无宿主开发头
  文件的环境中直接报头文件缺失错误。本次补充
  -isystem <glibc payload>/include 与 -isystem <linux-headers payload>/include,
  置于 libc++ 头文件条目之后以保持 #include_next 搜索链;生成内容与
  xim-pkgindex 侧 llvm.lua 安装期生成的 cfg 保持一致,消除两个生成端之间的
  内容差异。fixup 修订号升级至 hermetic-3,既有 payload 在下一次构建时自动
  重新收敛,无需重新安装。验证方式:以 --sysroot=<空目录> 屏蔽宿主头文件后,
  由 cfg 驱动的 clang/clang++ 直接调用编译与运行均通过;移除上述搜索路径的
  对照组按预期失败。mcpp 自身构建路径不受影响(构建 flags 由 linkmodel
  独立提供,不读取 cfg)。

修复

• Linux llvm 工具链链接失败 cannot open Scrt1.o/crti.o/crtn.o(#195):clang-with-cfg
  的 payload 链接路径此前只带 -L/-rpath/--dynamic-linker,缺少 CRT 启动对象的发现前缀
  -B<glibc payload lib>——driver 查找 Scrt1.o/crti.o/crtn.o 只走 -B 前缀与 sysroot
  派生路径,不查 -L。在装有宿主 libc6-dev 的机器上 driver 会静默兜底宿主 /lib 的 CRT
  (污染式"假绿"),在没有的机器(如全新 WSL2)上则把裸文件名传给 lld 直接失败。

新增 / 架构

• 工具链链接模型单一化(hermetic toolchain link model):新增 mcpp.toolchain.linkmodel
  作为「如何对该工具链的 C 库编译/链接」的唯一解析器(payload-first,--sysroot 回退),
  flags / stdmod / build_program / cfg 再生全部消费同一模型,消除四份漂移实现;
  动态链接器名按 声明式 payload 元数据 → 按 triple 的 arch 映射 → glob 三级解析,全链
  不再硬编码 ld-linux-x86-64.so.2(aarch64 glibc 的 loader 障碍随之消除)。详见
  .agents/docs/2026-07-07-hermetic-toolchain-link-model-design.md。
• post-install fixup 归位为统一管线:ensure_post_install_fixup 成为所有工具链安装
  路径(显式 install / 默认工具链 auto-install / manifest [toolchain] auto-install)共享
  的唯一 fixup 入口,内容指纹 marker 幂等;此前 manifest 路径不跑任何 fixup。clang cfg
  由行级补丁改为从链接模型确定性再生(同一 payload 在任何机器/安装路径产出一致 cfg,
  人类直接使用 clang++ 同样获得 hermetic 的 CRT 发现)。
• hermetic 链接校验:构建前用 -### 干跑断言 CRT 对象与生效 dynamic linker 全部解析
  在沙箱(xpkgs registry)内,越界即报错并指明泄漏路径;逃生阀
  [build] allow_host_libs = true / MCPP_ALLOW_HOST_LIBS=1。按 flag 集缓存判定。
• 测试与 CI:新增 e2e 86_llvm_hermetic_link.sh(-### 前缀断言,双向防「链接失败」
  与「宿主污染」回归);llvm e2e 解除 20.1.7 硬 pin(MCPP_E2E_LLVM_VERSION,默认最新
  已装 payload);ci-linux-e2e 新增 无宿主工具链容器 job(debian:stable-slim,无 gcc /
  无宿主 CRT)——唯一能真实复现 #195 环境类的 CI 形态。