Rust 1.99.1：修 wcslen 缺失与 x86_64 FFI bool 返回值

Rust 团队发布了 1.99.1 点版本，修的是几个回归问题。这类点版本看着不起眼，但踩上就很麻烦。

第一个：wcslen 符号缺失

部分 Rust 目标的链接报缺少 wcslen，现在这个函数已经作为回退实现在 compiler-builtins 库里提供。根源是 LLVM 的 loop-idiom-wcslen 优化会引入对 wcslen 的调用，而有些目标的 libc 里没有这个函数。UEFI 目标受影响最严重，任何用了 std 的项目都会挂，因为相关调用被提前编译进了预编译标准库。普通用户代码里类似的写法也能复现。

第二个：x86_64 上 FFI bool 返回值被错误编译

通过 FFI 返回 bool 的 Rust 函数，可能让返回寄存器的第 1 到 7 位处于未指定状态，调用方会看到 0 和 1 之外的值。现在这个返回类型重新被标记为需要零扩展，符合 ABI 要求。这个 bug 的隐蔽性在于：多数时候返回值恰好是 0 或 1，只有在特定寄存器残留值下才出问题，测试很难覆盖。

第三个：rust-lld 在 macOS 上加载不了 libLLVM

如果编译器不是通过 rustup 代理调用，链接器可能起不来，因为没有设置正确的库搜索路径。现在 rust-lld 编译时带了指向 libLLVM.dylib 所在目录的 rpath。

什么时候必须升

用 UEFI 目标、有通过 FFI 返回 bool 的外部接口、在 macOS 上交叉链接的项目，这三个命中任一就尽快升。纯应用层项目可以等下个小版本，但要记得升。

本文由奇幻维度内容助手整理发布，欢迎在评论区交流你的看法。

跨语言返回布尔这个 bug 隐蔽在于多数时候返回值恰好是 0 或 1，只有特定寄存器残留值下才出错，测试很难覆盖。用 UEFI 目标、有跨语言布尔返回、或在 macOS 上交叉链接的项目，命中任一就尽快升。

x86_64 上 FFI 返回 bool 那个问题比 wcslen 更隐蔽。C 侧返回的是 int，寄存器高位是脏的，Rust 按 bool 读只取最低位，多数情况碰巧对，偶发才错。这种未定义行为靠测试根本抓不住，只能老实跟点版本，两个修复都值得升。

UEFI 这块我没太看懂：wcslen 的调用是 LLVM 的循环优化自己插进去的，那编译器凭什么认为目标 libc 里一定有这个符号？如果是靠 target spec 声明，那自己写 spec 的人是不是也会踩同一个坑，得手动在 compiler-builtins 里开回退？