Series: The Rust Annals
Vol. I Issue 82 nlopes.dev
Announcing Rust 1.81.0
Stabilizes core::error::Error for #![no_std] and fixes extern'C' ABI soundness.
core::error::Error
1.81 stabilizes the Error trait in core, allowing usage of the trait in
#![no_std] libraries. This primarily enables the wider Rust ecosystem to
standardize on the same Error trait, regardless of what environments the
library targets.
New sort implementations
Both the stable and unstable sort implementations in the standard library have been updated to new algorithms, improving their runtime performance and compilation time.
Additionally, both of the new sort algorithms try to detect incorrect
implementations of Ord that prevent them from being able to produce a
meaningfully sorted result, and will now panic on such cases rather than
returning effectively randomly arranged data. Users encountering these panics
should audit their ordering implementations to ensure they satisfy the
requirements documented in PartialOrd and Ord.
#[expect(lint)]
1.81 stabilizes a new lint level, expect, which allows explicitly noting that
a particular lint should occur, and warning if it doesn’t. The intended use
case for this is temporarily silencing a lint, whether due to lint
implementation bugs or ongoing refactoring, while wanting to know when the lint
is no longer required.
For example, if you’re moving a code base to comply with a new restriction
enforced via a Clippy lint like
undocumented_unsafe_blocks,
you can use #[expect(clippy::undocumented_unsafe_blocks)] as you transition,
ensuring that once all unsafe blocks are documented you can opt into denying
the lint to enforce it.
Clippy also has two lints to enforce the usage of this feature and help with migrating existing attributes:
clippy::allow_attributesto restrict allow attributes in favor of#[expect]or to migrate#[allow]attributes to#[expect]clippy::allow_attributes_without_reasonTo require a reason for#[allow]attributes
Lint reasons
Changing the lint level is often done for some particular reason. For example,
if code runs in an environment without floating point support, you could use
Clippy to lint on such usage with #![deny(clippy::float_arithmetic)].
However, if a new developer to the project sees this lint fire, they need to
look for (hopefully) a comment on the deny explaining why it was added. With
Rust 1.81, they can be informed directly in the compiler message:
error: floating-point arithmetic detected
--> src/lib.rs:4:5
|
4 | a + b
| ^^^^^
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#float_arithmetic
= note: no hardware float support
note: the lint level is defined here
--> src/lib.rs:1:9
|
1 | #![deny(clippy::float_arithmetic, reason = "no hardware float support")]
| ^^^^^^^^^^^^^^^^^^^^^^^^