Rust 1.99.1 fixes FFI bool miscompile and two link bugs

The Rust Release Team shipped Rust 1.99.1 on October 15, 2026, two weeks after Rust 1.99.0. The point release fixes three regressions, things that worked in earlier versions and then broke. The most serious one made some functions that return a bool to C code hand back values other than 0 or 1 on x86_64, with no warning at compile time.

The three fixes

The Rust blog's announcement lists one fix each for the standard library, the compiler and the linker.

Bug	Who was hit	The fix	Issue
Missing wcslen symbol	Some targets, UEFI in particular	wcslen added to compiler-builtins as a fallback	#163614
FFI bool return miscompiled	x86_64	Return type marked for zero-extension again	#163911
rust-lld cannot load libLLVM	macOS, without the rustup proxy	rust-lld built with an rpath to libLLVM.dylib	#163947

Update with rustup update stable. The blog also suggests testing beta and nightly toolchains so regressions like these are caught before a release.

The bool bug on x86_64

FFI, the foreign function interface, is how Rust calls C code and how C calls Rust. A bool must arrive as exactly 0 or 1. On x86_64, the calling rules say a returned bool has to be zero-extended, meaning the unused upper bits of the register are cleared.

In 1.99.0, bits 1 through 7 of the return register were left unspecified, the blog says, so a caller could see values other than 0 or 1. The fix marks the return type for zero-extension again, "as required by the ABI." One report saw the value 16, according to Linux Compatible.

Linux Compatible traces the cause to an earlier change, PR #142389, that dropped zero-extension from scalar return types on x86_64. It only surfaced once a later change removed a safety net. The site says aarch64 and loongarch64 were not affected. PBXScience calls this the most serious of the three bugs because it failed silently.

The wcslen and macOS linker bugs

wcslen is a C function that measures a wide-character string. An LLVM optimization pass can insert calls to it, but some targets do not provide it. On UEFI, the firmware layer that starts a PC, any project using std was broken, the blog says.

Linux Compatible adds that the error only showed up in release builds. Until you update, it lists a workaround: set RUSTFLAGS="-C llvm-args=-disable-loop-idiom-wcslen" to turn the pass off.

The third bug hit macOS. When rust-lld, the linker Rust ships, was run without the rustup proxy, it could not find libLLVM.dylib. An rpath is a library search path built into a program, and 1.99.1 now includes one. Linux Compatible reports the crash on Apple Silicon. It says toolchains installed with fenix were affected, because they do not go through rustup's proxy.

This release follows Rust 1.99.0 on October 1, which stabilized C-variadic function definitions and moved to LLVM 23. PBXScience notes that Rust 1.100.0 is in beta and due on November 12.

What this means for developers

Update now if any Rust code returns a bool to C on x86_64. The bad values do not crash on their own. A C caller that checks == 1 or uses the value as an array index can take the wrong branch quietly. Rebuild and redeploy every library built with 1.99.0 that exposes such a function.

Check your logs and test results from the past two weeks for odd FFI behavior. A test that only checks "truthy" results would not have caught values like 16.

If you build for UEFI or embedded targets in release mode, 1.99.1 should fix link errors about wcslen. Remove the RUSTFLAGS workaround once you upgrade, so the optimization runs again.

On macOS, fenix and other setups that call rustc directly, without rustup, get a working rust-lld again. That includes WebAssembly builds that link through it.

Pin your toolchain version in CI. A rust-toolchain.toml file makes the move from 1.99.0 to 1.99.1 an explicit, reviewable change.