- The Rust team released 1.99.1 on October 15, 2026 to fix three regressions: a missing wcslen symbol, wrong bool returns over FFI on x86_64, and a rust-lld failure on macOS.
- The lesson is that a compiler is part of what you ship, so toolchain changes can alter behavior without any change to your own code.
- Teams should check whether they use the affected targets or build paths, and test beta releases in CI.
Your compiler is part of your product
Most leaders think of software risk as the code their teams write and the libraries they download. There is a third layer: the tools that turn that code into a running program. When those tools regress, the program can change even though nobody touched the source.
The Rust project's 1.99.1 point release, published October 15, 2026, shows this clearly. It fixes three regressions from prior releases. None is dramatic. Together they show how many places a toolchain can fail.
A build that stopped linking
The first fix concerns a missing symbol named wcslen. Some Rust targets were hitting link errors, the stage where a build joins its pieces into one program.
The cause was an optimization. An LLVM pass called loop-idiom-wcslen may replace a loop with a call to wcslen. Some targets had no such function available in libc or elsewhere.
The Rust team says the UEFI targets were broken for any project using std, because some of these calls appeared in the precompiled standard library. Similar patterns in user code could also trigger the error. The fix adds wcslen to Rust's compiler-builtins library as a fallback.
The lesson: an optimizer can add dependencies that nobody wrote. A team can pass every test on one target and fail to build on another.
A true-or-false answer that was neither
The second fix is the one that deserves the most attention. It concerns Rust functions that return a bool through FFI, the foreign function interface that lets Rust talk to code written in other languages.
On x86_64, such functions could leave bits 1 to 7 of the return register unspecified. The return register is where the processor hands back a result. A caller could therefore see raw values other than 0 or 1.
The release notes say the return type is now marked for zero-extension again, as the ABI requires. The ABI is the agreed contract for how compiled code passes data.
The report describes wrong values, not an attack. Still, this kind of fault does not stop the build. It may only appear when two codebases meet, and a failure there is hard to trace.
A linker that would not start
The third fix covers rust-lld on macOS. The linker could fail to load libLLVM if the compiler ran without the rustup proxy, because no direct setting told it where to find the library. It is now built with an rpath entry for the directory containing libLLVM.dylib.
This affects teams that call the compiler directly instead of through rustup. Build scripts and CI images often do exactly that.
What to ask your team
These questions need short answers, not a project.
First, do we build for UEFI or other less common targets? If so, did 1.99.0 builds fail with a missing wcslen?
Second, do any Rust functions return bool to C or C++ code on x86_64? If so, who tests that boundary?
Third, do any macOS build jobs call the compiler without rustup? Those are the paths the rust-lld fix addresses.
Fourth, do we run beta or nightly builds in CI? The Rust team asks users to do this and report bugs. A regression caught on your CI is cheaper than one found in production.
Updating with rustup is the route the Rust team describes. Pinning a version is sensible. A pin only protects you if someone owns the decision to move it.
Software teams are judged on the code they write. They are also responsible for the tools that interpret it.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Rust.
