Rust 1.67.1 restores thin-archive interoperability

Replacing an archive writer also requires preserving the formats it can read. Rust 1.67.0 introduced a new writer that could not consume thin archives, causing affected builds to fail with an unsupported-archive error. The February 9 release of Rust 1.67.1 restores LLVM's archive writer until the new implementation supports that input format.

The versioned release notes describe the correction as an interoperability fix. That is the useful angle for a maintenance release. A compiler change can be internal to Rust while breaking the point at which Rust consumes objects produced by another part of a build.

I find Rust attractive for work that would otherwise require C, which makes these integration details significant. The language can provide strong semantics for Rust source while the surrounding build still needs to accept native artifacts in established formats. Supporting those inputs is part of making the language usable within a larger system.

A thin archive refers to objects elsewhere

The release announcement defines thin archives as .a files that reference external .o objects. That differs from an archive that contains the object data itself. Consuming a thin archive therefore requires understanding the references represented by its format, rather than assuming all object content resides within the archive.

The replacement writer in Rust 1.67.0 could not read those archives as inputs. A project encountering that path received an error before completing the intended linking workflow. The defect was not a new Rust type error or a change in how the source expressed a foreign function. It concerned the representation of an input artifact.

This distinction helps locate the remedy. Rewriting application abstractions would not supply the missing archive-format support. The patch instead restores an implementation that already understands the input, allowing the existing native build arrangement to work again.

The release team's choice also preserves a clear boundary around the repair. Rust 1.67.1 does not claim that the new writer has learned the format. It returns to LLVM's writer while that work remains incomplete. Describing the patch as new thin-archive support would miss the regression and the restoration of previous interoperability.

Internal replacement work has an external contract

Archive handling may look like a compiler implementation detail until a user supplies an archive produced elsewhere. At that point, accepted input formats become externally observable behavior. An implementation replacement needs to preserve the cases on which existing builds depend, including cases not generated by its own most common path.

That is why a small patch release can have a large effect for a narrow group of users. A build that cannot consume one required native artifact cannot produce its executable, regardless of improvements elsewhere in the compiler. The release announcement scopes the failure to projects linking thin archives, which is more precise than claiming a general linking failure.

My preference is for a maintenance correction that restores the working boundary and states what remains unsupported in the replacement. It gives users a concrete reason to move to the patched compiler without implying that they need to adopt a new archive convention.

A style lint depends on more than compiler acceptance

The patch also changes Clippy's uninlined_format_args lint. According to the announcement, the lint is temporarily moved to the pedantic category, where it is allowed by default. The compiler has supported the encouraged formatting syntax since Rust 1.58, but rust-analyzer does not yet support it according to the release post.

This creates a distinction between legal source and a suitable default recommendation. A compiler can accept a style while editor tooling still handles it poorly. Encouraging that style everywhere can impose costs on users even though the resulting program compiles correctly.

Moving the lint changes the recommendation's default prominence. It does not remove the syntax or classify existing uses as invalid. Projects can still choose stricter lint policy, but the general default no longer pushes users toward a form whose editor support is incomplete.

The issue is relevant to how a language evolves as a working environment. The compiler defines acceptance, while other tools help people understand and change accepted code. A style recommendation affects that editing experience. The patch recognizes that those tools can be at different stages without changing the language itself.

Bootstrap receives a separate soundness correction

The final change repairs soundness in Rust's own bootstrap code. The announcement reports no known problematic uses. It says the issue did produce an error when bootstrap was compiled with Rust 1.67 itself, instead of the usual preceding Rust 1.66 release.

That scope matters. The release does not describe an identified soundness failure in arbitrary user programs. It describes code used to build the compiler and a configuration that exposed the problem. Keeping that distinction avoids turning an internal build correction into an unsupported claim about application behavior.

Together, these changes repair separate toolchain boundaries. Thin archives regain a compatible reader, the lint default reflects editor capability, and bootstrap works with the compiler configuration that exposed its issue. Each correction addresses the behavior of a concrete tool rather than asking application authors to compensate through unrelated source changes.