Rust 1.99.1 Fixes FFI Bool Returns and Two Linker Regressions

TLDR

Rust 1.99.1, released October 15, addresses three regressions.
The affected paths involve x86_64 FFI bool returns, wcslen linking and macOS rust-lld startup.
After updating, check the compiler selected inside the project, especially when a toolchain is pinned.

A failing build does not always call for an application or dependency change. This Rust point release addresses compiler and linker behavior. Teams maintaining C bindings, UEFI software or macOS build tooling can narrow the investigation by matching the failure to its target and invocation path.

Match the symptom to the affected path

Symptom	Relevant condition	Fix
Unexpected raw bool return value	x86_64 FFI	Restore required zero-extension.
Missing wcslen symbol	An optimized call on a target lacking the function	Provide a compiler-builtins fallback.
rust-lld cannot load libLLVM.dylib	macOS compiler invocation without the rustup proxy	Add the library directory to rpath.

The release announcement identifies these as regressions from earlier releases.

Updating stable is only part of selecting the compiler

For rustup installations, the release team gives this update command:

rustup update stable

Then check rustc --version from the project directory. The rustup override rules include command-line toolchain selection, RUSTUP_TOOLCHAIN, directory overrides, a rust-toolchain.toml file and the default toolchain.

A project pinned to an older version may therefore keep selecting it after stable has been updated. Check explicit version choices in CI as well. Once the intended compiler is selected, repeat the FFI test or link step that originally failed. That checks the affected path rather than merely confirming an installation completed.

The bool issue occurs across the FFI boundary

The affected x86_64 return path could leave bits 1–7 of the return register unspecified. A caller could consequently observe a raw value outside 0 or 1. Rust 1.99.1 restores the zero-extension marking required by the ABI.

The original issue reports a minimal reproduction on x86_64 Linux with both gcc and clang. That is a concrete interoperability failure to investigate in bindings. It does not imply that every boolean operation in a Rust program is broken.

Missing wcslen and missing libLLVM have different causes

The wcslen issue records a UEFI example that linked with the earlier compiler and failed after the upgrade. Searching application code for an explicit call is insufficient: LLVM can introduce the call while optimizing a loop.

The release notes highlight UEFI projects using the precompiled standard library, while also describing similar user-code patterns. The fallback implementation addresses targets where the resulting call has no available implementation.

The macOS report concerns loading the linker itself. In the Apple silicon reproduction, invoking the toolchain's rustc directly failed while linking a WebAssembly library. Going through the rustup proxy succeeded. That distinction matters for build systems that locate and execute a compiler binary directly; it is not a claim that all Rust builds on a Mac fail.

For this release, the useful starting points are the error, the target and the compiler invocation. Together they show whether a toolchain fix matches the failure being investigated.

Frequently asked questions

Can wcslen matter if my code never calls it?

Yes. Optimization can introduce the call, so a source search alone does not establish whether the build is affected.

Does the macOS issue affect every Rust build?

No. The reported condition involves invoking the compiler without the rustup proxy and rust-lld failing to load its LLVM library.

Does updating stable replace a project pin?

No. Check the project's toolchain selection separately; an override can take precedence over the default.