Skip to content

Remove non-Standard basic_istream::ipfx()/isfx(), basic_ostream::opfx()/osfx(), and locale::empty() - #5834

Merged
Stephan T. Lavavej (StephanTLavavej) merged 2 commits into
microsoft:mainfrom
StephanTLavavej:end-of-extensions
Nov 12, 2025
Merged

Conversation

@StephanTLavavej

Copy link
Copy Markdown
Member

Let's finish cleaning house.

I've verified that the DLL's export surface is unchanged.

There appears to have been virtually zero usage; I see no occurrences of the silencing macros in our internal or Real World Code test suites (modulo preprocessed files), which is why I'm being a bit more aggressive here.

Although we shouldn't ever need to change them, I'm keeping the comments on the function definitions. However, the comment on the declaration of locale::empty() serves no purpose, so I'm removing it.

@StephanTLavavej Stephan T. Lavavej (StephanTLavavej) moved this from Final Review to Ready To Merge in STL Code Reviews Nov 10, 2025
@StephanTLavavej Stephan T. Lavavej (StephanTLavavej) moved this from Ready To Merge to Merging in STL Code Reviews Nov 11, 2025
@StephanTLavavej

Copy link
Copy Markdown
Member Author

I'm mirroring this to the MSVC-internal repo - please notify me if any further changes are pushed.

@StephanTLavavej
Stephan T. Lavavej (StephanTLavavej) merged commit e028940 into microsoft:main Nov 12, 2025
41 checks passed
@github-project-automation github-project-automation Bot moved this from Merging to Done in STL Code Reviews Nov 12, 2025
@StephanTLavavej
Stephan T. Lavavej (StephanTLavavej) deleted the end-of-extensions branch November 12, 2025 16:17
@BillyONeal

Copy link
Copy Markdown
Member

There appears to have been virtually zero usage; I see no occurrences of the silencing macros in our internal or Real World Code test suites (modulo preprocessed files), which is why I'm being a bit more aggressive here.

I found one! :(

https://github.com/accellera-official/systemc/blob/3d500fe7b1d3b86bb6f016ba18fb20bd856fb504/src/sysc/datatypes/int/sc_int64_io.cpp#L154

空•灵 (bainian-gudu) pushed a commit to bainian-gudu/GenshinFpsUnlocker that referenced this pull request Sep 12, 2026
Build(41bdbc3,手动触发)里 build-kachina 又失败了,但**已经不是上一个问题**:
CMAKE_GENERATOR=Ninja 生效,seera-msquic 的 FTK1011 没了,构建往后跑了 6 分钟,
挂在另一个依赖上:

  rcedit-sys/src/rescle.cc(87): error C2039: 'empty': is not a member of 'std::locale'
  rcedit-sys/src/rescle.cc(87): error C3861: 'empty': identifier not found
  error: failed to run custom build command for
    `rcedit-sys v0.1.0 (https://github.com/Devolutions/rcedit-rs.git#1bfa3ee6)`

rescle.cc:87 写的是 `std::locale(std::locale::empty(), new std::codecvt_utf8<wchar_t>())`。
`std::locale::empty()` 是 MSVC 的**非标准扩展**:VS 2022 17.14 起弃用(microsoft/STL#5197),
MSVC 14.51 起彻底移除(microsoft/STL#5834,2025-11-12 合并)—— 现在 <xlocale> 里那句
声明只在 #ifdef _CRTBLD 下存在,**没有任何编译开关能把它打开**。
而 windows-latest 现在是 VS 2026 Enterprise / MSVC 14.51.36231(日志里的 cl.exe 路径可证)。

上游 Devolutions/rcedit-rs 最新提交是 2025-10-29 的 CODEOWNERS 变更,没修这个;
等上游不现实。所以按「只从本仓库构建」的既定要求,把它 vendor 进来自己修:

一、installer/kachina/vendor/rcedit-rs/(新增)
   - 来源 rcedit-rs@1bfa3ee6da2092b9b0c93148ce1455c5d45c538c
   - 10 个源文件 + 上游两份 LICENSE(MIT / Copyright (c) 2013 GitHub Inc.)原样保留
   - 不 vendor:上游 Cargo.lock、tests/(含 .exe fixture)、mock_resources_binary/、.github/
   - 与上游只差两处:
     1. rescle.cc:87 `std::locale::empty()` → `std::locale::classic()`
        (ReadFileToString 的意图只是给 wifstream 装 codecvt_utf8 facet,基准 locale
        用哪个都不影响转换;classic() 是标准里的 "C" locale,且不受 locale::global 影响。
        该函数只在设置 application manifest 时调用,本项目不走那条路径,但必须能编过)
     2. 根 Cargo.toml 删掉 [dev-dependencies] tempfile(tests/ 没 vendor,
        留着只会让 tempfile 被解析进 kachina 的 Cargo.lock)
   - LOCAL_PATCHES.md 记录来源、原因、两处差异、升级与校验方法

二、src-tauri/Cargo.toml:rcedit 依赖 git → path = "../vendor/rcedit-rs"(原行以注释保留)
    src-tauri/Cargo.lock:rcedit / rcedit-sys 两个包去掉 source = "git+..." 行,
    版本与依赖列表不变。已用 `cargo metadata --locked` 验证一致
    (解析出 726 个包,rcedit 与 rcedit-sys 的 manifest_path 都指向 vendored 副本)。
    kachina 的 git 依赖从 4 个降到 3 个(都是 xytoki/*)。

三、devcheck 加两道防线,让这类问题在**自动**工作流里就暴露,不用等手动触发 Build:
    - vendor 层第 7 项:vendored 副本 10 个文件齐全、rescle.cc 里没有 locale::empty(、
      rcedit 依赖是 path 形式、Cargo.lock 里不再出现该 git 源。
      扫 Cargo.toml / rescle.cc 时先剥掉注释 —— 这两个文件的注释里就写着
      「原为 git = "...rcedit-rs.git"」「原为 std::locale::empty()」,
      不剥会自己误报自己(第一次跑就中招了)。
    - 新增 native 层:在有 cl.exe 的机器上真编一遍 rcedit-sys
      (cargo build --manifest-path .../rcedit-sys/Cargo.toml,独立 CARGO_TARGET_DIR),
      没有 cl.exe 就 SKIP。devcheck.yml 的 windows job 补 ilammy/msvc-dev-cmd@v1。
    - -SelfTest 增到 8 个用例:新增「往 rescle.cc 末尾追加一行真代码
      std::locale(std::locale::empty())」,确认 vendor 层会报错;用例跑完按字节还原。

四、文档:kachina/LOCAL_PATCHES.md 新增第 4 节;installer/README.md 的目录树与 CI 段;
    根 README 的 CI 段与 devcheck 命令;tools/devcheck/README.md 的层表、vendor 七项、
    SelfTest 表(顺手修好一处早先没替换成功的旧文案:还写着「注入 5 个错误」)。

验证:本地 8 层(native 在 Linux 上 SKIP,其余全绿)、-SelfTest 8/8、
cargo metadata --locked 通过、rescle.cc 与上游的差异只有那一处(diff 已核对)。
rescle.cc 能否在 MSVC 14.51 上编过,要看这次 push 触发的 Devcheck windows job 的
native 层结果;完整 kachina 构建仍需再手动触发一次 Build。
空•灵 (bainian-gudu) added a commit to bainian-gudu/GenshinFpsUnlocker that referenced this pull request Sep 12, 2026
Build(41bdbc3,手动触发)里 build-kachina 又失败了,但**已经不是上一个问题**:
CMAKE_GENERATOR=Ninja 生效,seera-msquic 的 FTK1011 没了,构建往后跑了 6 分钟,
挂在另一个依赖上:

  rcedit-sys/src/rescle.cc(87): error C2039: 'empty': is not a member of 'std::locale'
  rcedit-sys/src/rescle.cc(87): error C3861: 'empty': identifier not found
  error: failed to run custom build command for
    `rcedit-sys v0.1.0 (https://github.com/Devolutions/rcedit-rs.git#1bfa3ee6)`

rescle.cc:87 写的是 `std::locale(std::locale::empty(), new std::codecvt_utf8<wchar_t>())`。
`std::locale::empty()` 是 MSVC 的**非标准扩展**:VS 2022 17.14 起弃用(microsoft/STL#5197),
MSVC 14.51 起彻底移除(microsoft/STL#5834,2025-11-12 合并)—— 现在 <xlocale> 里那句
声明只在 #ifdef _CRTBLD 下存在,**没有任何编译开关能把它打开**。
而 windows-latest 现在是 VS 2026 Enterprise / MSVC 14.51.36231(日志里的 cl.exe 路径可证)。

上游 Devolutions/rcedit-rs 最新提交是 2025-10-29 的 CODEOWNERS 变更,没修这个;
等上游不现实。所以按「只从本仓库构建」的既定要求,把它 vendor 进来自己修:

一、installer/kachina/vendor/rcedit-rs/(新增)
   - 来源 rcedit-rs@1bfa3ee6da2092b9b0c93148ce1455c5d45c538c
   - 10 个源文件 + 上游两份 LICENSE(MIT / Copyright (c) 2013 GitHub Inc.)原样保留
   - 不 vendor:上游 Cargo.lock、tests/(含 .exe fixture)、mock_resources_binary/、.github/
   - 与上游只差两处:
     1. rescle.cc:87 `std::locale::empty()` → `std::locale::classic()`
        (ReadFileToString 的意图只是给 wifstream 装 codecvt_utf8 facet,基准 locale
        用哪个都不影响转换;classic() 是标准里的 "C" locale,且不受 locale::global 影响。
        该函数只在设置 application manifest 时调用,本项目不走那条路径,但必须能编过)
     2. 根 Cargo.toml 删掉 [dev-dependencies] tempfile(tests/ 没 vendor,
        留着只会让 tempfile 被解析进 kachina 的 Cargo.lock)
   - LOCAL_PATCHES.md 记录来源、原因、两处差异、升级与校验方法

二、src-tauri/Cargo.toml:rcedit 依赖 git → path = "../vendor/rcedit-rs"(原行以注释保留)
    src-tauri/Cargo.lock:rcedit / rcedit-sys 两个包去掉 source = "git+..." 行,
    版本与依赖列表不变。已用 `cargo metadata --locked` 验证一致
    (解析出 726 个包,rcedit 与 rcedit-sys 的 manifest_path 都指向 vendored 副本)。
    kachina 的 git 依赖从 4 个降到 3 个(都是 xytoki/*)。

三、devcheck 加两道防线,让这类问题在**自动**工作流里就暴露,不用等手动触发 Build:
    - vendor 层第 7 项:vendored 副本 10 个文件齐全、rescle.cc 里没有 locale::empty(、
      rcedit 依赖是 path 形式、Cargo.lock 里不再出现该 git 源。
      扫 Cargo.toml / rescle.cc 时先剥掉注释 —— 这两个文件的注释里就写着
      「原为 git = "...rcedit-rs.git"」「原为 std::locale::empty()」,
      不剥会自己误报自己(第一次跑就中招了)。
    - 新增 native 层:在有 cl.exe 的机器上真编一遍 rcedit-sys
      (cargo build --manifest-path .../rcedit-sys/Cargo.toml,独立 CARGO_TARGET_DIR),
      没有 cl.exe 就 SKIP。devcheck.yml 的 windows job 补 ilammy/msvc-dev-cmd@v1。
    - -SelfTest 增到 8 个用例:新增「往 rescle.cc 末尾追加一行真代码
      std::locale(std::locale::empty())」,确认 vendor 层会报错;用例跑完按字节还原。

四、文档:kachina/LOCAL_PATCHES.md 新增第 4 节;installer/README.md 的目录树与 CI 段;
    根 README 的 CI 段与 devcheck 命令;tools/devcheck/README.md 的层表、vendor 七项、
    SelfTest 表(顺手修好一处早先没替换成功的旧文案:还写着「注入 5 个错误」)。

验证:本地 8 层(native 在 Linux 上 SKIP,其余全绿)、-SelfTest 8/8、
cargo metadata --locked 通过、rescle.cc 与上游的差异只有那一处(diff 已核对)。
rescle.cc 能否在 MSVC 14.51 上编过,要看这次 push 触发的 Devcheck windows job 的
native 层结果;完整 kachina 构建仍需再手动触发一次 Build。
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement Something can be improved

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants