Rust 1.91 gives Windows ARM64 Tier 1 testing

A compiler can produce code for a platform without the project running its tests there after every change. That distinction is the substance of Rust's platform tiers. Promoting Windows ARM64 changes the evidence required to keep the compiler healthy on that target, rather than merely adding another architecture name to a build command.

Rust 1.91, released on October 30, promotes aarch64-pc-windows-msvc to Tier 1. The versioned platform documentation lists it under Tier 1 with host tools. The release also adds a warning for raw pointers returned from local variables, another change concerned with detecting a gap between an apparently usable interface and its actual guarantees.

I find Rust attractive as a systems language partly because it can bring precise contracts to platforms where native integration matters. A stronger target commitment makes that choice more practical. It still needs to be interpreted at the right level, since compiler testing does not automatically validate every application dependency.

Tier 1 includes execution evidence

The Rust 1.91 platform-support document distinguishes targets guaranteed to build from targets tested after each change. Tier 1 requires official releases and automated testing that checks builds and test results. Tier 1 with host tools also covers native compiler and Cargo use.

That host qualification matters. A platform can be a destination for cross-compiled programs without serving as a supported development machine. Host tools add a commitment that the compiler and related tools can run there, with testing for that use. Windows ARM64 now belongs to that stronger category.

The promotion therefore affects the project's development process. A regression on the target enters the required testing expectations for changes, instead of depending on later reports from users. This can catch platform-specific assumptions before a stable release reaches application developers.

It does not establish that every crate on a registry supports ARM64 Windows. A crate may call a native library whose binaries exist only for another architecture or contain its own target-specific assembly. Those are downstream support decisions, even when the compiler and standard library have the highest project tier.

The full target identifies the calling environment

The versioned MSVC target guide identifies the ARM64 target alongside the x86 Windows MSVC targets. The targets implement the full standard library and produce native PE/COFF binaries with CodeView debugging information.

For extern "C", the target follows Microsoft's calling convention for the selected architecture. An ARM64 build therefore needs ARM64-compatible foreign code. Using the same C function declaration in Rust does not make a library built for x86-64 usable in that executable.

The guide also distinguishes architectural cross-compilation from one Windows host to another Windows architecture, supported with the appropriate MSVC components, from cross-compilation on a non-Windows host, which it does not support. A target component is not a complete substitute for the native toolchain pieces needed to link external code.

These details explain why the suffix of a target identifier matters. aarch64 alone describes the architecture but leaves out the operating-system and toolchain environment. A native dependency has to agree with the complete environment at the compiled boundary.

Diagnostics catch a local lifetime mistake

The new dangling_pointers_from_locals lint warns by default when a function returns a raw pointer derived from local storage that ends with the function. The release contrasts this with borrowed references, whose lifetimes the borrow checker tracks. Raw pointer types do not express that same lifetime relationship.

A minimal problematic function can return a pointer to a local byte without performing any unsafe operation itself. Creating that raw pointer is not the invalid access. The problem appears when a later operation tries to use it after the local value has ceased to exist.

The diagnostic therefore provides an earlier warning about a likely error. It does not transform raw pointers into lifetime-checked references or prove that every returned pointer is valid. A pointer returned from a function may refer to caller-owned storage or a separately owned allocation, and its correctness depends on that ownership contract.

I prefer diagnostics that identify the concrete origin of a likely dangling value. A warning about the local variable gives a reader a direct path to the ownership mistake. It also avoids the misleading claim that every raw-pointer construction is inherently an unsafe operation.

Atomic pointer operations preserve another distinction

The release adds operations such as AtomicPtr::fetch_ptr_add. The method changes the address atomically in units of the pointed-to type and returns the previous pointer. Byte-oriented variants express a different unit of offset.

These methods make pointer manipulation available without first treating the stored pointer as an unrelated integer. They do not establish that the new address can be dereferenced. Atomicity of updating the pointer and validity of the memory access remain separate conditions.

The memory-ordering argument also remains explicit. Selecting an atomic operation does not by itself define an application's publication protocol. A shared pointer can be updated without a data race on its own storage while the pointed-to object still requires correct lifetime management and synchronization.

This relates to the dangling-pointer diagnostic because both distinguish possession of a pointer value from permission to use the referenced storage. An address can survive after the object does not. An atomic update can produce an address without proving that an object exists there under the intended access conditions.

Platform and application guarantees remain separate

The Windows ARM64 promotion strengthens Rust's own build and execution-testing commitment. A native application still needs its dependencies to match the architecture and ABI, and its own code must preserve valid resource lifetimes. Those obligations are specific to the application even when the underlying compiler receives continuous Tier 1 testing.

Rust 1.91 makes the platform commitment stronger and gives raw-pointer authors another focused diagnostic. The practical result is improved evidence at two different boundaries. The project tests the native target as part of compiler development, while the warning identifies a common local source of invalid pointers before a later dereference turns it into a memory error.