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 形态。

v0.0.83

修复

• 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 形态。

v0.0.82

(no CHANGELOG entry found for 0.0.82)

v0.0.81

(no CHANGELOG entry found for 0.0.81)