← BACK TO THE WIRE
N°0454Rust4 MIN4 SOURCES

Rust 1.99.1 fixes FFI bool miscompilation and wcslen link errors

Rust 1.99.1 fixes three 1.99.0 regressions: wrong FFI bool return values on x86_64, missing wcslen at link time on UEFI and similar targets, and rust-lld failing on macOS. Update with rustup and rebuild any affected binaries.

SHARE
Rust
Rust 1.99.1 fixes FFI bool miscompilation and wcslen link errors
IMAGE: AI-GENERATED

The Rust Release Team published Rust 1.99.1 on October 15, 2026. It is a point release that fixes three regressions: a miscompilation of FFI bool return values on x86_64, link errors for a missing wcslen symbol, and rust-lld failing to load libLLVM on macOS. If you build C-facing libraries, UEFI images or WebAssembly on Apple Silicon with 1.99.0, run rustup update stable and rebuild.

What changed in 1.99.1

The release post lists three fixes. Each one is a regression from an earlier stable release. All three were introduced in 1.99.0, which we covered in Rust 1.99 Makes FFI and Raw-Pointer Contracts Explicit.

IssueSymptom on 1.99.0Fix in 1.99.1Last good version (per issue report)
#163911Rust functions returning bool through FFI on x86_64 leave bits 1-7 of the return register unspecifiedReturn type marked for zero-extension again, as the ABI requires1.98.0
#163614Link errors for missing wcslen, mainly on UEFI targetswcslen added to compiler-builtins as a fallback1.98.1
#163947rust-lld cannot load libLLVM.dylib when rustc runs without the rustup proxyrust-lld built with an rpath entry for the libLLVM.dylib directory1.96.1

FFI bool returns. The release post says these functions could leave "bits 1-7 of the return register unspecified", so C callers could see raw values other than 0 or 1. The reporter tested on x86_64 Linux with a function like (flags & 0x1) == 0x1, called from C with 0x10. The function returned 16. In the reporter's disassembly, 1.98.0 had an andb $0x1, %al before retq, and 1.99.0 did not. The same report says aarch64 and loongarch64 masked the value correctly.

Missing wcslen. LLVM's loop-idiom-wcslen pass can replace a loop with a call to wcslen, and some targets have no such function in libc or anywhere else. The release post says UEFI targets "were broken for any project using std", because some of these calls were already in the precompiled standard library. User code with similar loops could trigger the same error. The issue report shows a minimal x86_64-unknown-uefi binary that failed to link with rust-lld only in release builds (cargo b -r).

rust-lld on macOS. Since 1.98.0, LLVM is linked dynamically on aarch64-apple-darwin. The issue shows that 1.99.0's rust-lld looked for @rpath/libLLVM.dylib in the wrong directory. The rustup proxy hid the problem by adding the toolchain's lib/ directory to the library search path. Without the proxy, rust-lld aborted with SIGABRT. The reporter hit this while linking a wasm32-unknown-unknown cdylib by calling <sysroot>/bin/rustc directly.

Who is affected

  • Crates that export extern "C" functions returning bool on x86_64. This is the most serious fix because the code compiles without errors and then gives wrong results. C, C++ and other FFI callers may treat any non-zero value as true. They may also compare the result with == 1, or use it as an index or a bit field. The result can be quiet logic errors. If you shipped a cdylib, staticlib or Python/Node extension built with 1.99.0 on x86_64, it may contain the bug.
  • UEFI and other targets without wcslen. Release builds that use std failed to link. You noticed this one right away: the build simply broke.
  • Build tools on Apple Silicon that pin a sysroot and call rustc by path. Normal cargo use through rustup was not affected. Custom build systems, IDE integrations and CI scripts that call the toolchain binary directly were affected. One example is canister build scripts on Macs that call the toolchain's rustc directly for wasm32-unknown-unknown. They should rebuild on 1.99.1.

What to do now

These steps use rustup and apply to Rust 1.99.1:

  1. Update the stable toolchain and check the version:
bash
rustup update stable
rustc --version   # should report 1.99.1
  1. If your project pins a version in rust-toolchain.toml, change the pin. The rustup docs show this format:
toml
[toolchain]
channel = "1.99.1"
  1. Update any CI image or toolchain action that hard-codes 1.99.0 or 1.99. Pinning 1.99 without a patch number also installs the latest 1.99.x patch release, but cached toolchains may still be 1.99.0. Clear the cache or check the version in the job log.
  2. Rebuild and redeploy every x86_64 artifact that exports a bool-returning function to non-Rust callers. Upgrading the compiler does not fix binaries you already shipped.
  3. For UEFI projects, rebuild in release mode, for example cargo build --release --target x86_64-unknown-uefi, and confirm that the wcslen link error is gone.
  4. On macOS, if you followed the issue thread and added a symlink to libLLVM.dylib inside lib/rustlib/aarch64-apple-darwin/lib/, remove it after upgrading. It is no longer needed.

To catch regressions like these before they reach stable, the Rust team asks users to test the beta (rustup default beta) and nightly (rustup default nightly) channels locally and in CI.

Caveats

The 1.99.1 release post describes the bool miscompilation only for x86_64. The details above (the value 16 and the missing mask instruction) come from the reporter's test on x86_64 Linux. The 1.99.0 changes covered in Rust 1.99 Turns Box::leak Into an Ownership Review Trigger are unchanged in this patch release.

TAGSRust 1.99.1FFIUEFIrust-lld
Grounded sources4 REFS
  1. [01]Announcing Rust 1.99.1blog.rust-lang.org ↗
  2. [02]Miscompilation of FFI bool return values on x86_64 (rust-lang/rust #163911)github.com ↗
  3. [03]Regression in Rust 1.99: missing symbol wcslen (rust-lang/rust #163614)github.com ↗
  4. [04]rust-lld on aarch64-apple-darwin cannot load libLLVM.dylib (rust-lang/rust #163947)github.com ↗
Read next

Get the wire in your inbox

Every new signal, straight from the generator. No noise, unsubscribe anytime.

RSS AVAILABLE · NO SPAM