Latest in branch 1.64
1.64.0
Released 22 Sep 2022
(3 years ago)
SoftwareRust
Version1.64
Initial release1.64.0
22 Sep 2022
(3 years ago)
Latest release1.64.0
22 Sep 2022
(3 years ago)
Support status04 Nov 2022
(Ended 3 years, 7 months ago)
Release noteshttps://github.com/rust-lang/rust/releases/tag/1.64.0
Source codehttps://github.com/rust-lang/rust/tree/1.64.0
Downloadhttps://github.com/rust-lang/rust/releases/tag/1.64.0
Rust 1.64 ReleasesView full list

What Is New in Rust 1.64

CategoryHighlights
New FeaturesStabilized IntoFuture trait, core/alloc FFI type aliases, rust-analyzer as a rustup component, Cargo workspace inheritance and multi-target builds.
ImprovementsWindows compiler PGO, unused_tuple_struct_fields lint, const-context APIs, Poll helpers, more const-compatible functions.
Bug FixesCompatibility updates for Linux kernel ≥ 3.2 and glibc ≥ 2.17, memory-layout fixes for IP address types, RLS removal.
Breaking ChangesMinimum Linux kernel 3.2 and glibc 2.17 requirements; internal layout change of Ipv4Addr/Ipv6Addr may break unsafe transmute code.
DeprecationsRLS is deprecated and will be removed in the next release.

How does the stabilized IntoFuture trait improve async code ergonomics?

IntoFuture lets you .await on any type that can be converted into a Future, removing the explicit .send() call.

In practice you can turn a builder that previously required:

let response = StorageRequest::new()
    .set_debug(true)
    .send()
    .await?;

into a single await step:

let response = StorageRequest::new()
    .set_debug(true)
    .await?;

This matters if you want a more fluent API without exposing the intermediate future type. Implementing IntoFuture does require a named future (often a boxed one) but future work on TAIT will make it lighter.

What C-compatible FFI types are now available in core and alloc?

core::ffi and alloc::ffi now expose the full set of c_* type aliases (e.g., c_uint, c_ulong) and CString utilities without pulling in std.

Example usage in a no-std environment:

use core::ffi::{c_int, CStr};

extern "C" {
    fn libc_function(arg: c_int) -> c_int;
}

alloc::ffi::CString can be used when you have an allocator but not the full standard library, simplifying embedded FFI code.

How can Cargo workspace inheritance and multi-target builds reduce duplication?

Cargo now lets you define common package metadata at the workspace level and pass multiple --target flags to build several binaries at once.

  • Workspace inheritance: put shared fields like version, repository, or rust-version under [workspace.package] or [workspace.dependencies] to keep them in sync.
  • Multi-target builds: run cargo build --target x86_64-unknown-linux-gnu --target aarch64-apple-darwin or set an array of targets in .cargo/config.toml under build.target.

This matters for teams maintaining libraries for both desktop and embedded platforms, as it eliminates repetitive Cargo.toml entries and enables a single CI step for all targets.

What tooling updates arrived via rustup in 1.64?

rust-analyzer is shipped as a rustup component, making installation and version management easier.

To add it run rustup component add rust-analyzer. The installed binary can be invoked with rustup run stable rust-analyzer. Future rustup releases will proxy the command so you can call rust-analyzer directly.

Most users will still prefer the upstream rust-analyzer releases for more frequent updates, but the rustup component ensures a baseline version is always available on supported platforms.

Frequently Asked Questions

Does IntoFuture require any nightly features to use?
No, IntoFuture is stable in Rust 1.64 and can be used on the stable channel.

How do I add rust-analyzer via rustup?
Run rustup component add rust-analyzer and then invoke it with rustup run stable rust-analyzer.

Can I build for both x86_64-unknown-linux-gnu and aarch64-apple-darwin in one cargo command?
Yes, use cargo build --target x86_64-unknown-linux-gnu --target aarch64-apple-darwin.

What lint warns about unused fields in tuple structs?
The unused_tuple_struct_fields lint, which can be enabled with #![warn(unused_tuple_struct_fields)].

Do I need to update my code for the new Linux kernel requirement?
Most code works unchanged, but binaries targeting older kernels must be rebuilt for at least kernel 3.2.

Is the memory layout change of Ipv4Addr a breaking API?
It is not a public API change, but code that used std::mem::transmute on those types must be updated.

Releases In Branch 1.64

VersionRelease date
1.64.022 Sep 2022
(3 years ago)