The Rust Programming Language Blog @blog.rust-lang.org.web.brid.gy

Announcing Rust 1.89.0 The Rust team is happy to announce a new version of Rust, 1.89.0. Rust is a programming language empowering everyone to build reliable and efficient software. If you have a previous version of Rust installed via `rustup`, you can get 1.89.0 with: $ rustup update stable If you don't have it already, you can get `rustup` from the appropriate page on our website, and check out the detailed release notes for 1.89.0. If you'd like to help us out by testing future releases, you might consider updating locally to use the beta channel (`rustup default beta`) or the nightly channel (`rustup default nightly`). Please report any bugs you might come across! ## What's in 1.89.0 stable ### Explicitly inferred arguments to const generics Rust now supports `_` as an argument to const generic parameters, inferring the value from surrounding context: pub fn all_false<const LEN: usize>() -> [bool; LEN] { [false; _] } Similar to the rules for when `_` is permitted as a type, `_` is not permitted as an argument to const generics when in a signature: // This is not allowed pub const fn all_false<const LEN: usize>() -> [bool; _] { [false; LEN] } // Neither is this pub const ALL_FALSE: [bool; _] = all_false::<10>(); ### Mismatched lifetime syntaxes lint Lifetime elision in function signatures is an ergonomic aspect of the Rust language, but it can also be a stumbling point for newcomers and experts alike. This is especially true when lifetimes are inferred in types where it isn't syntactically obvious that a lifetime is even present: // The returned type `std::slice::Iter` has a lifetime, // but there's no visual indication of that. // // Lifetime elision infers the lifetime of the return // type to be the same as that of `scores`. fn items(scores: &[u8]) -> std::slice::Iter<u8> { scores.iter() } Code like this will now produce a warning by default: warning: hiding a lifetime that's elided elsewhere is confusing --> src/lib.rs:1:18 | 1 | fn items(scores: &[u8]) -> std::slice::Iter<u8> { | ^^^^^ -------------------- the same lifetime is hidden here | | | the lifetime is elided here | = help: the same lifetime is referred to in inconsistent ways, making the signature confusing = note: `#[warn(mismatched_lifetime_syntaxes)]` on by default help: use `'_` for type paths | 1 | fn items(scores: &[u8]) -> std::slice::Iter<'_, u8> { | +++ We first attempted to improve this situation back in 2018 as part of the `rust_2018_idioms` lint group, but strong feedback about the `elided_lifetimes_in_paths` lint showed that it was too blunt of a hammer as it warns about lifetimes which don't matter to understand the function: use std::fmt; struct Greeting; impl fmt::Display for Greeting { fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result { // -----^^^^^^^^^ expected lifetime parameter // Knowing that `Formatter` has a lifetime does not help the programmer "howdy".fmt(f) } } We then realized that the confusion we want to eliminate occurs when both 1. lifetime elision inference rules _connect_ an input lifetime to an output lifetime 2. it's not syntactically obvious that a lifetime exists There are two pieces of Rust syntax that indicate that a lifetime exists: `&` and `'`, with `'` being subdivided into the inferred lifetime `'_` and named lifetimes `'a`. When a type uses a named lifetime, lifetime elision will not infer a lifetime for that type. Using these criteria, we can construct three groups: Self-evident it has a lifetime| Allow lifetime elision to infer a lifetime| Examples ---|---|--- No| Yes| `ContainsLifetime` Yes| Yes| `&T`, `&'_ T`, `ContainsLifetime<'_>` Yes| No| `&'a T`, `ContainsLifetime<'a>` The `mismatched_lifetime_syntaxes` lint checks that the inputs and outputs of a function belong to the same group. For the initial motivating example above, `&[u8]` falls into the second group while `std::slice::Iter<u8>` falls into the first group. We say that the lifetimes in the first group are _hidden_. Because the input and output lifetimes belong to different groups, the lint will warn about this function, reducing confusion about when a value has a meaningful lifetime that isn't visually obvious. The `mismatched_lifetime_syntaxes` lint supersedes the `elided_named_lifetimes` lint, which did something similar for named lifetimes specifically. Future work on the `elided_lifetimes_in_paths` lint intends to split it into more focused sub-lints with an eye to warning about a subset of them eventually. ### More x86 target features The `target_feature` attribute now supports the `sha512`, `sm3`, `sm4`, `kl` and `widekl` target features on x86. Additionally a number of `avx512` intrinsics and target features are also supported on x86: #[target_feature(enable = "avx512bw")] pub fn cool_simd_code(/* .. */) -> /* ... */ { /* ... */ } ### Cross-compiled doctests Doctests will now be tested when running `cargo test --doc --target other_target`, this may result in some amount of breakage due to would-be-failing doctests now being tested. Failing tests can be disabled by annotating the doctest with `ignore-<target>` (docs): /// ```ignore-x86_64 /// panic!("something") /// ``` pub fn my_function() { } ### `i128` and `u128` in `extern "C"` functions `i128` and `u128` no longer trigger the `improper_ctypes_definitions` lint, meaning these types may be used in `extern "C"` functions without warning. This comes with some caveats: * The Rust types are ABI- and layout-compatible with (unsigned) `__int128` in C when the type is available. * On platforms where `__int128` is not available, `i128` and `u128` do not necessarily align with any C type. * `i128` is _not_ necessarily compatible with `_BitInt(128)` on any platform, because `_BitInt(128)` and `__int128` may not have the same ABI (as is the case on x86-64). This is the last bit of follow up to the layout changes from last year: https://blog.rust-lang.org/2024/03/30/i128-layout-update. ### Demoting `x86_64-apple-darwin` to Tier 2 with host tools GitHub will soon discontinue providing free macOS x86_64 runners for public repositories. Apple has also announced their plans for discontinuing support for the x86_64 architecture. In accordance with these changes, the Rust project is in the process of demoting the `x86_64-apple-darwin` target from Tier 1 with host tools to Tier 2 with host tools. This means that the target, including tools like `rustc` and `cargo`, will be guaranteed to build but is not guaranteed to pass our automated test suite. We expect that the RFC for the demotion to Tier 2 with host tools will be accepted between the releases of Rust 1.89 and 1.90, which means that Rust 1.89 will be the last release of Rust where `x86_64-apple-darwin` is a Tier 1 target. For users, this change will not immediately cause impact. Builds of both the standard library and the compiler will still be distributed by the Rust Project for use via `rustup` or alternative installation methods while the target remains at Tier 2. Over time, it's likely that reduced test coverage for this target will cause things to break or fall out of compatibility with no further announcements. ### Standards Compliant C ABI on the `wasm32-unknown-unknown` target `extern "C"` functions on the `wasm32-unknown-unknown` target now have a standards compliant ABI. See this blog post for more information: https://blog.rust-lang.org/2025/04/04/c-abi-changes-for-wasm32-unknown-unknown. ### Platform Support * `x86_64-apple-darwin` is in the process of being demoted to Tier 2 with host tools * Add new Tier-3 targets `loongarch32-unknown-none` and `loongarch32-unknown-none-softfloat` Refer to Rust’s platform support page for more information on Rust’s tiered platform support. ### Stabilized APIs * `NonZero<char>` * Many intrinsics for x86, not enumerated here * AVX512 intrinsics * `SHA512`, `SM3` and `SM4` intrinsics * `File::lock` * `File::lock_shared` * `File::try_lock` * `File::try_lock_shared` * `File::unlock` * `NonNull::from_ref` * `NonNull::from_mut` * `NonNull::without_provenance` * `NonNull::with_exposed_provenance` * `NonNull::expose_provenance` * `OsString::leak` * `PathBuf::leak` * `Result::flatten` * `std::os::linux::net::TcpStreamExt::quickack` * `std::os::linux::net::TcpStreamExt::set_quickack` These previously stable APIs are now stable in const contexts: * `<[T; N]>::as_mut_slice` * `<[u8]>::eq_ignore_ascii_case` * `str::eq_ignore_ascii_case` ### Other changes Check out everything that changed in Rust, Cargo, and Clippy. ## Contributors to 1.89.0 Many people came together to create Rust 1.89.0. We couldn't have done it without all of you. Thanks!

07.08.2025 00:00 — 👍 0 🔁 0 💬 0 📌 0

05.08.2025 00:00 — 👍 0 🔁 0 💬 0 📌 0

crates.io: development update Since our last development update in February 2025, we have continued to make significant improvements to crates.io. In this blog post, we want to give you an update on the latest changes that we have made to crates.io over the past few months. ## Trusted Publishing We are excited to announce that we have implemented "Trusted Publishing" support on crates.io, as described in RFC #3691. This feature was inspired by the PyPI team's excellent work in this area, and we want to thank them for the inspiration! Trusted Publishing eliminates the need for GitHub Actions secrets when publishing crates from your CI/CD pipeline. Instead of managing API tokens, you can now configure which GitHub repository you trust directly on crates.io. That repository is then allowed to request a short-lived API token for publishing in a secure way using OpenID Connect (OIDC). While Trusted Publishing is currently limited to GitHub Actions, we have built it in a way that allows other CI/CD providers like GitLab CI to be supported in the future. To get started with Trusted Publishing, you'll need to publish your first release manually. After that, you can set up trusted publishing for future releases. The detailed documentation is available at https://crates.io/docs/trusted-publishing. Here's an example of how to set up GitHub Actions to use Trusted Publishing: name: Publish to crates.io on: push: tags: ['v*'] # Triggers when pushing tags starting with 'v' jobs: publish: runs-on: ubuntu-latest environment: release # Optional: for enhanced security permissions: id-token: write # Required for OIDC token exchange steps: - uses: actions/checkout@v4 - uses: rust-lang/crates-io-auth-action@v1 id: auth - run: cargo publish env: CARGO_REGISTRY_TOKEN: ${{ steps.auth.outputs.token }} ## OpenGraph Images Previously, crates.io used a single OpenGraph image for all pages. We have now implemented dynamic OpenGraph image generation, where each crate has a dedicated image that is regenerated when new versions are published. These images include the crate name, keywords, description, latest version (or rather the default version that we show for the crate), number of releases, license, and crate size. This provides much more useful information when crates.io links are shared on social media platforms or in chat applications. The image generation has been extracted to a dedicated crate: crates_io_og_image (GitHub). We're also adding basic theming support in PR #3 to allow docs.rs to reuse the code for their own OpenGraph images. Under the hood, the image generation uses two other excellent Rust projects: Typst for layout and text rendering, and oxipng for PNG optimization. ## docs.rs rebuilds Crate owners can now trigger documentation rebuilds for docs.rs directly from the crate's version list on crates.io. This can be useful when docs.rs builds have failed or when you want to take advantage of new docs.rs features without having to publish a new release just for that. We would like to thank our crates.io team member @eth3lbert for implementing the initial version of this feature in PR #11422. ## README alert support We've added support for rendering GitHub-style alerts in README files. This feature allows crate authors to use alert blocks like `> [!NOTE]`, `> [!WARNING]`, and `> [!CAUTION]` in their README markdown, which will now be properly styled and displayed on crates.io. This enhancement was also implemented by @eth3lbert in PR #11441, building on initial work by @kbdharun. ## Miscellaneous These were some of the more visible changes to crates.io over the past couple of months, but a lot has happened "under the hood" as well. Here are a couple of examples: ### Email system refactoring Previously, we used the `format!()` macro and string concatenation to create emails, which made them hard to maintain and inconsistent in styling. We have migrated to the minijinja crate and now use templates instead. The new system includes a template inheritance system for consistent branding across all emails. This change also enables us to support HTML emails in the future. ### SemVer sorting optimization Previously, we had to load all versions from the database and sort them by SemVer on the API server, which was inefficient for crates with many versions. Our PostgreSQL provider did not support the semver extension, so we had to implement sorting in application code. PR #10763 takes advantage of JSONB support in PostgreSQL and their btree ordering specification to implement SemVer sorting on the database side. This reduces the load on our API servers and improves response times for crates with many versions. ## Feedback We hope you enjoyed this update on the development of crates.io. If you have any feedback or questions, please let us know on Zulip or GitHub. We are always happy to hear from you and are looking forward to your feedback!

11.07.2025 00:00 — 👍 0 🔁 0 💬 0 📌 0

Stabilizing naked functions Rust 1.88.0 stabilizes the `#[unsafe(naked)]` attribute and the `naked_asm!` macro which are used to define naked functions. A naked function is marked with the `#[unsafe(naked)]` attribute, and its body consists of a single `naked_asm!` call. For example: /// SAFETY: Respects the 64-bit System-V ABI. #[unsafe(naked)] pub extern "sysv64" fn wrapping_add(a: u64, b: u64) -> u64 { // Equivalent to `a.wrapping_add(b)`. core::arch::naked_asm!( "lea rax, [rdi + rsi]", "ret" ); } What makes naked functions special — and gives them their name — is that the handwritten assembly block defines the _entire_ function body. Unlike non-naked functions, the compiler does not add any special handling for arguments or return values. This feature is a more ergonomic alternative to defining functions using `global_asm!`. Naked functions are used in low-level settings like Rust's `compiler-builtins`, operating systems, and embedded applications. ## Why use naked functions? But wait, if naked functions are just syntactic sugar for `global_asm!`, why add them in the first place? To see the benefits, let's rewrite the `wrapping_add` example from the introduction using `global_asm!`: // SAFETY: `wrapping_add` is defined in this module, // and expects the 64-bit System-V ABI. unsafe extern "sysv64" { safe fn wrapping_add(a: u64, b: u64) -> u64 } core::arch::global_asm!( r#" // Platform-specific directives that set up a function. .section .text.wrapping_add,"ax",@progbits .p2align 2 .globl wrapping_add .type wrapping_add,@function wrapping_add: lea rax, [rdi + rsi] ret .Ltmp0: .size wrapping_add, .Ltmp0-wrapping_add "# ); The assembly block starts and ends with the directives (`.section`, `.p2align`, etc.) that are required to define a function. These directives are mechanical, but they are different between object file formats. A naked function will automatically emit the right directives. Next, the `wrapping_add` name is hardcoded, and will not participate in Rust's name mangling. That makes it harder to write cross-platform code, because different targets have different name mangling schemes (e.g. x86_64 macOS prefixes symbols with `_`, but Linux does not). The unmangled symbol is also globally visible — so that the `extern` block can find it — which can cause symbol resolution conflicts. A naked function's name does participate in name mangling and won't run into these issues. A further limitation that this example does not show is that functions defined using global assembly cannot use generics. Especially const generics are useful in combination with assembly. Finally, having just one definition provides a consistent place for (safety) documentation and attributes, with less risk of them getting out of date. Proper safety comments are essential for naked functions. The `naked` attribute is unsafe because the ABI (`sysv64` in our example), the signature, and the implementation have to be consistent. ## How did we get here? Naked functions have been in the works for a long time. The original RFC for naked functions is from 2015. That RFC was superseded by RFC 2972 in 2020. Inline assembly in Rust had changed substantially at that point, and the new RFC limited the body of naked functions to a single `asm!` call with some additional constraints. And now, 10 years after the initial proposal, naked functions are stable. Two additional notable changes helped prepare naked functions for stabilization: ##### Introduction of the `naked_asm!` macro The body of a naked function must be a single `naked_asm!` call. This macro is a blend between `asm!` (it is in a function body) and `global_asm!` (only some operand types are accepted). The initial implementation of RFC 2972 added lints onto a standard `asm!` call in a naked function. This approach made it hard to write clear error messages and documentation. With the dedicated `naked_asm!` macro the behavior is much easier to specify. ##### Lowering to `global_asm!` The initial implementation relied on LLVM to lower functions with the `naked` attribute for code generation. This approach had two issues: * LLVM would sometimes add unexpected additional instructions to what the user wrote. * Rust has non-LLVM code generation backends now, and they would have had to implement LLVM's (unspecified!) behavior. The implementation that is stabilized now instead converts the naked function into a piece of global assembly. The code generation backends can already emit global assembly, and this strategy guarantees that the whole body of the function is just the instructions that the user wrote. ## What's next for assembly? We're working on further assembly ergonomics improvements. If naked functions are something you are excited about and (may) use, we'd appreciate you testing these new features and providing feedback on their designs. ##### `extern "custom"` functions Naked functions usually get the `extern "C"` calling convention. But often that calling convention is a lie. In many cases, naked functions don't implement an ABI that Rust knows about. Instead they use some custom calling convention that is specific to that function. The `abi_custom` feature adds `extern "custom"` functions and blocks, which allows us to correctly write code like this example from compiler-builtins: #![feature(abi_custom)] /// Division and modulo of two numbers using Arm's nonstandard ABI. /// /// ```c /// typedef struct { int quot; int rem; } idiv_return; /// __value_in_regs idiv_return __aeabi_idivmod(int num, int denom); /// ``` // SAFETY: The assembly implements the expected ABI, and "custom" // ensures this function cannot be called directly. #[unsafe(naked)] pub unsafe extern "custom" fn __aeabi_idivmod() { core::arch::naked_asm!( "push {{r0, r1, r4, lr}}", // Back up clobbers. "bl {trampoline}", // Call an `extern "C"` function for a / b. "pop {{r1, r2}}", "muls r2, r2, r0", // Perform the modulo. "subs r1, r1, r2", "pop {{r4, pc}}", // Restore clobbers, implicit return by setting `pc`. trampoline = sym crate::arm::__aeabi_idiv, ); } A consequence of using a custom calling convention is that such functions cannot be called using a Rust call expression; the compiler simply does not know how to generate correct code for such a call. Instead the compiler will error when the program does try to call an `extern "custom"` function, and the only way to execute the function is using inline assembly. ##### `cfg` on lines of inline assembly The `cfg_asm` feature adds the ability to annotate individual lines of an assembly block with `#[cfg(...)]` or `#[cfg_attr(..., ...)]`. Configuring specific sections of assembly is useful to make assembly depend on, for instance, the target, target features, or feature flags. For example: #![feature(cfg_asm)] global_asm!( // ... // If enabled, initialise the SP. This is normally // initialised by the CPU itself or by a bootloader, but // some debuggers fail to set it when resetting the // target, leading to stack corruptions. #[cfg(feature = "set-sp")] "ldr r0, =_stack_start msr msp, r0", // ... ) This example is from the cortex-m crate that currently has to use a custom macro that duplicates the whole assembly block for every use of `#[cfg(...)]`. With `cfg_asm`, that will no longer be necessary.

03.07.2025 00:00 — 👍 0 🔁 0 💬 0 📌 0

Announcing Rust 1.88.0 The Rust team is happy to announce a new version of Rust, 1.88.0. Rust is a programming language empowering everyone to build reliable and efficient software. If you have a previous version of Rust installed via `rustup`, you can get 1.88.0 with: $ rustup update stable If you don't have it already, you can get `rustup` from the appropriate page on our website, and check out the detailed release notes for 1.88.0. If you'd like to help us out by testing future releases, you might consider updating locally to use the beta channel (`rustup default beta`) or the nightly channel (`rustup default nightly`). Please report any bugs you might come across! ## What's in 1.88.0 stable ### Let chains This feature allows `&&`-chaining `let` statements inside `if` and `while` conditions, even intermingling with boolean expressions, so there is less distinction between `if`/`if let` and `while`/`while let`. The patterns inside the `let` sub-expressions can be irrefutable or refutable, and bindings are usable in later parts of the chain as well as the body. For example, this snippet combines multiple conditions which would have required nesting `if let` and `if` blocks before: if let Channel::Stable(v) = release_info() && let Semver { major, minor, .. } = v && major == 1 && minor == 88 { println!("`let_chains` was stabilized in this version"); } Let chains are only available in the Rust 2024 edition, as this feature depends on the `if let` temporary scope change for more consistent drop order. Earlier efforts tried to work with all editions, but some difficult edge cases threatened the integrity of the implementation. 2024 made it feasible, so please upgrade your crate's edition if you'd like to use this feature! ### Naked functions Rust now supports writing naked functions with no compiler-generated epilogue and prologue, allowing full control over the generated assembly for a particular function. This is a more ergonomic alternative to defining functions in a `global_asm!` block. A naked function is marked with the `#[unsafe(naked)]` attribute, and its body consists of a single `naked_asm!` call. For example: #[unsafe(naked)] pub unsafe extern "sysv64" fn wrapping_add(a: u64, b: u64) -> u64 { // Equivalent to `a.wrapping_add(b)`. core::arch::naked_asm!( "lea rax, [rdi + rsi]", "ret" ); } The handwritten assembly block defines the _entire_ function body: unlike non-naked functions, the compiler does not add any special handling for arguments or return values. Naked functions are used in low-level settings like Rust's `compiler-builtins`, operating systems, and embedded applications. Look for a more detailed post on this soon! ### Boolean configuration The `cfg` predicate language now supports boolean literals, `true` and `false`, acting as a configuration that is always enabled or disabled, respectively. This works in Rust conditional compilation with `cfg` and `cfg_attr` attributes and the built-in `cfg!` macro, and also in Cargo `target]` tables in both configuration and [manifests. Previously, empty predicate lists could be used for unconditional configuration, like `cfg(all())` for enabled and `cfg(any())` for disabled, but this meaning is rather implicit and easy to get backwards. `cfg(true)` and `cfg(false)` offer a more direct way to say what you mean. See RFC 3695 for more background! ### Cargo automatic cache cleaning Starting in 1.88.0, Cargo will automatically run garbage collection on the cache in its home directory! When building, Cargo downloads and caches crates needed as dependencies. Historically, these downloaded files would never be cleaned up, leading to an unbounded amount of disk usage in Cargo's home directory. In this version, Cargo introduces a garbage collection mechanism to automatically clean up old files (e.g. `.crate` files). Cargo will remove files downloaded from the network if not accessed in 3 months, and files obtained from the local system if not accessed in 1 month. Note that this automatic garbage collection will not take place if running offline (using `--offline` or `--frozen`). Cargo 1.78 and newer track the access information needed for this garbage collection. This was introduced well before the actual cleanup that's starting now, in order to reduce cache churn for those that still use prior versions. If you regularly use versions of Cargo even older than 1.78, in addition to running current versions of Cargo, and you expect to have some crates accessed exclusively by the older versions of Cargo and don't want to re-download those crates every ~3 months, you may wish to set `cache.auto-clean-frequency = "never"` in the Cargo configuration, as described in the docs. For more information, see the original unstable announcement of this feature. Some parts of that design remain unstable, like the `gc` subcommand tracked in cargo#13060, so there's still more to look forward to! ### Stabilized APIs * `Cell::update` * `impl Default for *const T` * `impl Default for *mut T` * `mod ffi::c_str` * `HashMap::extract_if` * `HashSet::extract_if` * `hint::select_unpredictable` * `proc_macro::Span::line` * `proc_macro::Span::column` * `proc_macro::Span::start` * `proc_macro::Span::end` * `proc_macro::Span::file` * `proc_macro::Span::local_file` * `<[T]>::as_chunks` * `<[T]>::as_rchunks` * `<[T]>::as_chunks_unchecked` * `<[T]>::as_chunks_mut` * `<[T]>::as_rchunks_mut` * `<[T]>::as_chunks_unchecked_mut` These previously stable APIs are now stable in const contexts: * `NonNull<T>::replace` * `<*mut T>::replace` * `std::ptr::swap_nonoverlapping` * `Cell::replace` * `Cell::get` * `Cell::get_mut` * `Cell::from_mut` * `Cell::as_slice_of_cells` ### Other changes The `i686-pc-windows-gnu` target has been demoted to Tier 2, as mentioned in an earlier post. This won't have any immediate effect for users, since both the compiler and standard library tools will still be distributed by `rustup` for this target. However, with less testing than it had at Tier 1, it has more chance of accumulating bugs in the future. Check out everything that changed in Rust, Cargo, and Clippy. ## Contributors to 1.88.0 Many people came together to create Rust 1.88.0. We couldn't have done it without all of you. Thanks!

26.06.2025 00:00 — 👍 0 🔁 0 💬 0 📌 0

20.06.2025 00:00 — 👍 0 🔁 0 💬 0 📌 0

Rust compiler performance survey 2025 We're launching a Rust Compiler Performance Survey. Long compile times of Rust code are frequently being cited as one of the biggest challenges limiting the productivity of Rust developers. Rust compiler contributors are of course aware of that, and they are continuously working to improve the situation, by finding new ways of speeding up the compiler, triaging performance regressions and measuring our long-term performance improvements. Recently, we also made progress on some large changes that have been in the making for a long time, which could significantly improve compiler performance by default. When we talk about compilation performance, it is important to note that it is not always so simple as determining how long does it take `rustc` to compile a crate. There are many diverse development workflows that might have competing trade-offs, and that can be bottlenecked by various factors, such as the integration of the compiler with the used build system. In order to better understand these workflows, we have prepared a Rust Compiler Performance Survey. This survey is focused specifically on compilation performance, which allows us to get more detailed data than what we usually get from the annual State of Rust survey. The data from this survey will help us find areas where we should focus our efforts on improving the productivity of Rust developers. **You can fill out the surveyhere.** Filling the survey should take you approximately 10 minutes, and the survey is fully anonymous. We will accept submissions until Monday, July 7th, 2025. After the survey ends, we will evaluate the results and post key insights on this blog. We invite you to fill the survey, as your responses will help us improve Rust compilation performance. Thank you!

16.06.2025 00:00 — 👍 0 🔁 0 💬 0 📌 0

Demoting i686-pc-windows-gnu to Tier 2 In Rust 1.88.0, the Tier 1 target `i686-pc-windows-gnu` will be demoted to Tier 2. As a Tier 2 Target, builds will continue to be distributed for both the standard library and the compiler. ## Background Rust has supported Windows for a long time, with two different flavors of Windows targets: MSVC-based and GNU-based. MSVC-based targets (for example the most popular Windows target `x86_64-pc-windows-msvc`) use Microsoft’s native linker and libraries, while GNU-based targets (like `i686-pc-windows-gnu`) are built entirely from free software components like `gcc`, `ld`, and mingw-w64. The major reason to use a GNU-based toolchain instead of the native MSVC-based one is cross-compilation and licensing. `link.exe` only runs on Windows (barring Wine hacks) and requires a license for commercial usage. `x86_64-pc-windows-gnu` and `i686-pc-windows-gnu` are currently both Tier 1 with host tools. The Target Tier Policy contains more details on what this entails, but the most important part is that tests for these targets are being run on every merged PR. This is the highest level of support we have, and is only used for the most high value targets (the most popular Linux, Windows, and Apple targets). The `*-windows-gnu` targets currently do not have any dedicated target maintainers. We do not have a lot of expertise for this toolchain, and issues often aren't fixed and cause problems in CI that we have a hard time to debug. The 32-bit version of this target is especially problematic and has significantly less usage than `x86_64-pc-windows-gnu`, which is why `i686-pc-windows-gnu` is being demoted to Tier 2. ## What changes? After Rust 1.88.0, `i686-pc-windows-gnu` will now be Tier 2 with host tools. For users, nothing will change immediately. Builds of both the standard library and the compiler will still be distributed by the Rust Project for use via `rustup` or alternative installation methods. This does mean that this target will likely accumulate bugs faster in the future because of the reduced testing. ## Future If no maintainers are found and the `*-windows-gnu` targets continue causing problems, they may be demoted further. No concrete plans about this have been made yet. If you rely on the `*-windows-gnu` targets and have expertise in this area, we would be very happy to have you as a target maintainer. You can check the Target Tier Policy for what exactly that would entail. For more details on the motivation of the demotion, see RFC 3771 which proposed this change.

26.05.2025 00:00 — 👍 0 🔁 0 💬 0 📌 0

Announcing Rust 1.87.0 and ten years of Rust! Live from the 10 Years of Rust celebration in Utrecht, Netherlands, the Rust team is happy to announce a new version of Rust, 1.87.0! Today's release day happens to fall exactly on the 10 year anniversary of Rust 1.0! Thank you to the myriad contributors who have worked on Rust, past and present. Here's to many more decades of Rust! 🎉 * * * As usual, the new version includes all the changes that have been part of the beta version in the past six weeks, following the consistent regular release cycle that we have followed since Rust 1.0. If you have a previous version of Rust installed via `rustup`, you can get 1.87.0 with: $ rustup update stable If you don't have it already, you can get `rustup` from the appropriate page on our website, and check out the detailed release notes for 1.87.0. If you'd like to help us out by testing future releases, you might consider updating locally to use the beta channel (`rustup default beta`) or the nightly channel (`rustup default nightly`). Please report any bugs you might come across! ## What's in 1.87.0 stable ### Anonymous pipes 1.87 adds access to anonymous pipes to the standard library. This includes integration with `std::process::Command`'s input/output methods. For example, joining the stdout and stderr streams into one is now relatively straightforward, as shown below, while it used to require either extra threads or platform-specific functions. use std::process::Command; use std::io::Read; let (mut recv, send) = std::io::pipe()?; let mut command = Command::new("path/to/bin") // Both stdout and stderr will write to the same pipe, combining the two. .stdout(send.try_clone()?) .stderr(send) .spawn()?; let mut output = Vec::new(); recv.read_to_end(&mut output)?; // It's important that we read from the pipe before the process exits, to avoid // filling the OS buffers if the program emits too much output. assert!(command.wait()?.success()); ### Safe architecture intrinsics Most `std::arch` intrinsics that are unsafe only due to requiring target features to be enabled are now callable in safe code that has those features enabled. For example, the following toy program which implements summing an array using manual intrinsics can now use safe code for the core loop. #![forbid(unsafe_op_in_unsafe_fn)] use std::arch::x86_64::*; fn sum(slice: &[u32]) -> u32 { #[cfg(target_arch = "x86_64")] { if is_x86_feature_detected!("avx2") { // SAFETY: We have detected the feature is enabled at runtime, // so it's safe to call this function. return unsafe { sum_avx2(slice) }; } } slice.iter().sum() } #[target_feature(enable = "avx2")] #[cfg(target_arch = "x86_64")] fn sum_avx2(slice: &[u32]) -> u32 { // SAFETY: __m256i and u32 have the same validity. let (prefix, middle, tail) = unsafe { slice.align_to::<__m256i>() }; let mut sum = prefix.iter().sum::<u32>(); sum += tail.iter().sum::<u32>(); // Core loop is now fully safe code in 1.87, because the intrinsics require // matching target features (avx2) to the function definition. let mut base = _mm256_setzero_si256(); for e in middle.iter() { base = _mm256_add_epi32(base, *e); } // SAFETY: __m256i and u32 have the same validity. let base: [u32; 8] = unsafe { std::mem::transmute(base) }; sum += base.iter().sum::<u32>(); sum } ### `asm!` jumps to Rust code Inline assembly (`asm!`) can now jump to labeled blocks within Rust code. This enables more flexible low-level programming, such as implementing optimized control flow in OS kernels or interacting with hardware more efficiently. * The `asm!` macro now supports a label operand, which acts as a jump target. * The label must be a block expression with a return type of `()` or `!`. * The block executes when jumped to, and execution continues after the `asm!` block. * Using output and label operands in the same `asm!` invocation remains unstable. unsafe { asm!( "jmp {}", label { println!("Jumped from asm!"); } ); } For more details, please consult the reference. ### Precise capturing (`+ use<...>`) in `impl Trait` in trait definitions This release stabilizes specifying the specific captured generic types and lifetimes in trait definitions using `impl Trait` return types. This allows using this feature in trait definitions, expanding on the stabilization for non-trait functions in 1.82. Some example desugarings: trait Foo { fn method<'a>(&'a self) -> impl Sized; // ... desugars to something like: type Implicit1<'a>: Sized; fn method_desugared<'a>(&'a self) -> Self::Implicit1<'a>; // ... whereas with precise capturing ... fn precise<'a>(&'a self) -> impl Sized + use<Self>; // ... desugars to something like: type Implicit2: Sized; fn precise_desugared<'a>(&'a self) -> Self::Implicit2; } ### Stabilized APIs * `Vec::extract_if` * `vec::ExtractIf` * `LinkedList::extract_if` * `linked_list::ExtractIf` * `<[T]>::split_off` * `<[T]>::split_off_mut` * `<[T]>::split_off_first` * `<[T]>::split_off_first_mut` * `<[T]>::split_off_last` * `<[T]>::split_off_last_mut` * `String::extend_from_within` * `os_str::Display` * `OsString::display` * `OsStr::display` * `io::pipe` * `io::PipeReader` * `io::PipeWriter` * `impl From<PipeReader> for OwnedHandle` * `impl From<PipeWriter> for OwnedHandle` * `impl From<PipeReader> for Stdio` * `impl From<PipeWriter> for Stdio` * `impl From<PipeReader> for OwnedFd` * `impl From<PipeWriter> for OwnedFd` * `Box<MaybeUninit<T>>::write` * `impl TryFrom<Vec<u8>> for String` * `<*const T>::offset_from_unsigned` * `<*const T>::byte_offset_from_unsigned` * `<*mut T>::offset_from_unsigned` * `<*mut T>::byte_offset_from_unsigned` * `NonNull::offset_from_unsigned` * `NonNull::byte_offset_from_unsigned` * `<uN>::cast_signed` * `NonZero::<uN>::cast_signed`. * `<iN>::cast_unsigned`. * `NonZero::<iN>::cast_unsigned`. * `<uN>::is_multiple_of` * `<uN>::unbounded_shl` * `<uN>::unbounded_shr` * `<iN>::unbounded_shl` * `<iN>::unbounded_shr` * `<iN>::midpoint` * `<str>::from_utf8` * `<str>::from_utf8_mut` * `<str>::from_utf8_unchecked` * `<str>::from_utf8_unchecked_mut` These previously stable APIs are now stable in const contexts: * `core::str::from_utf8_mut` * `<[T]>::copy_from_slice` * `SocketAddr::set_ip` * `SocketAddr::set_port`, * `SocketAddrV4::set_ip` * `SocketAddrV4::set_port`, * `SocketAddrV6::set_ip` * `SocketAddrV6::set_port` * `SocketAddrV6::set_flowinfo` * `SocketAddrV6::set_scope_id` * `char::is_digit` * `char::is_whitespace` * `<[[T; N]]>::as_flattened` * `<[[T; N]]>::as_flattened_mut` * `String::into_bytes` * `String::as_str` * `String::capacity` * `String::as_bytes` * `String::len` * `String::is_empty` * `String::as_mut_str` * `String::as_mut_vec` * `Vec::as_ptr` * `Vec::as_slice` * `Vec::capacity` * `Vec::len` * `Vec::is_empty` * `Vec::as_mut_slice` * `Vec::as_mut_ptr` ### `i586-pc-windows-msvc` target removal The Tier 2 target `i586-pc-windows-msvc` has been removed. `i586-pc-windows-msvc`'s difference to the much more popular Tier 1 target `i686-pc-windows-msvc` is that `i586-pc-windows-msvc` does not require SSE2 instruction support. But Windows 10, the minimum required OS version of all `windows` targets (except the `win7` targets), requires SSE2 instructions itself. All users currently targeting `i586-pc-windows-msvc` should migrate to `i686-pc-windows-msvc`. You can check the Major Change Proposal for more information. ### Other changes Check out everything that changed in Rust, Cargo, and Clippy. ## Contributors to 1.87.0 Many people came together to create Rust 1.87.0. We couldn't have done it without all of you. Thanks!

15.05.2025 00:00 — 👍 0 🔁 0 💬 0 📌 0

Announcing Google Summer of Code 2025 selected projects The Rust Project is participating in Google Summer of Code (GSoC) again this year. GSoC is a global program organized by Google that is designed to bring new contributors to the world of open-source. In March, we published a list of GSoC project ideas, and started discussing these projects with potential GSoC applicants on our Zulip. We had many interesting discussions with the potential contributors, and even saw some of them making non-trivial contributions to various Rust Project repositories, even before GSoC officially started! After the initial discussions, GSoC applicants prepared and submitted their project proposals. We received 64 proposals this year, almost exactly the same number as last year. We are happy to see that there was again so much interest in our projects. A team of mentors primarily composed of Rust Project contributors then thoroughly examined the submitted proposals. GSoC required us to produce a ranked list of the best proposals, which was a challenging task in itself since Rust is a big project with many priorities! Same as last year, we went through several rounds of discussions and considered many factors, such as prior conversations with the given applicant, the quality of their proposal, the importance of the proposed project for the Rust Project and its wider community, but also the availability of mentors, who are often volunteers and thus have limited time available for mentoring. As is usual in GSoC, even though some project topics received multiple proposals1, we had to pick only one proposal per project topic. We also had to choose between great proposals targeting different work to avoid overloading a single mentor with multiple projects. In the end, we narrowed the list down to a smaller number of the best proposals that we could still realistically support with our available mentor pool. We submitted this list and eagerly awaited how many of them would be accepted into GSoC. ## Selected projects On the 8th of May, Google has announced the accepted projects. We are happy to share that **19** Rust Project proposals were accepted by Google for Google Summer of Code 2025. That's a lot of projects, which makes us super excited about GSoC 2025! Below you can find the list of accepted proposals (in alphabetical order), along with the names of their authors and the assigned mentor(s): * **ABI/Layout handling for the automatic differentiation feature** by Marcelo Domínguez, mentored by Manuel Drehwald and Oli Scherer * **Add safety contracts** by Dawid Lachowicz, mentored by Michael Tautschnig * **Bootstrap of rustc with rustc_codegen_gcc** by Michał Kostrubiec, mentored by antoyo * **Cargo: Build script delegation** by Naman Garg, mentored by Ed Page * **Distributed and resource-efficient verification** by Zhou Jiping, mentored by Michael Tautschnig * **Enable Witness Generation in cargo-semver-checks** by Talyn Veugelers, mentored by Predrag Gruevski * **Extend behavioural testing of std::arch intrinsics** by Madhav Madhusoodanan, mentored by Amanieu d'Antras * **Implement merge functionality in bors** by Sakibul Islam, mentored by Jakub Beránek * **Improve bootstrap** by Shourya Sharma, mentored by Jakub Beránek, Jieyou Xu and Onur Özkan * **Improve Wild linker test suites** by Kei Akiyama, mentored by David Lattimore * **Improving the Rustc Parallel Frontend: Parallel Macro Expansion** by Lorrens, mentored by Sparrow Li * **Make cargo-semver-checks faster** by JosephC, mentored by Predrag Gruevski * **Make Rustup Concurrent** by Francisco Gouveia, mentored by rami3l * **Mapping the Maze of Rust's UI Test Suite with Established Continuous Integration Practices** by Julien Robert, mentored by Jieyou Xu * **Modernising the libc Crate** by Abdul Muiz, mentored by Trevor Gross * **New proc-macro Server API for Rust-Analyzer** by Neil Wang, mentored by Lukas Wirth * **Prepare stable_mir crate for publishing** by Makai, mentored by Celina Val * **Prototype an alternative architecture for cargo fix using cargo check** by Glen Thalakottur, mentored by Ed Page * **Prototype Cargo Plumbing Commands** by Vito Secona, mentored by Cassaundra **Congratulations to all applicants whose project was selected!** The mentors are looking forward to working with you on these exciting projects to improve the Rust ecosystem. You can expect to hear from us soon, so that we can start coordinating the work on your GSoC projects. We would also like to thank all the applicants whose proposal was sadly not accepted, for their interactions with the Rust community and contributions to various Rust projects. There were some great proposals that did not make the cut, in large part because of limited mentorship capacity. However, even if your proposal was not accepted, we would be happy if you would consider contributing to the projects that got you interested, even outside GSoC! Our project idea list is still actual and could serve as a general entry point for contributors that would like to work on projects that would help the Rust Project maintainers and the Rust ecosystem. Some of the Rust Project Goals are also looking for help. There is also a good chance we'll participate in GSoC next year as well (though we can't promise anything at this moment), so we hope to receive your proposals again in the future! The accepted GSoC projects will run for several months. After GSoC 2025 finishes (in autumn of 2025), we will publish a blog post in which we will summarize the outcome of the accepted projects. 1. The most popular project topic received seven different proposals! ↩

08.05.2025 00:00 — 👍 0 🔁 0 💬 0 📌 0

Announcing rustup 1.28.2 The rustup team is happy to announce the release of rustup version 1.28.2. Rustup is the recommended tool to install Rust, a programming language that empowers everyone to build reliable and efficient software. ## What's new in rustup 1.28.2 The headlines of this release are: * The cURL download backend and the native-tls TLS backend are now officially deprecated and a warning will start to show up when they are used. pr#4277 * While rustup predates reqwest and rustls, the rustup team has long wanted to standardize on an HTTP + TLS stack with more components in Rust, which should increase security, potentially improve performance, and simplify maintenance of the project. With the default download backend already switched to reqwest since 2019, the team thinks it is time to focus maintenance on the default stack powered by these two libraries. * For people who have set `RUSTUP_USE_CURL=1` or `RUSTUP_USE_RUSTLS=0` in their environment to work around issues with rustup, please try to unset these after upgrading to 1.28.2 and file an issue if you still encounter problems. * The version of `rustup` can be pinned when installing via `rustup-init.sh`, and `rustup self update` can be used to upgrade/downgrade rustup 1.28.2+ to a given version. To do so, set the `RUSTUP_VERSION` environment variable to the desired version (for example `1.28.2`). pr#4259 * `rustup set auto-install disable` can now be used to disable automatic installation of the toolchain. This is similar to the `RUSTUP_AUTO_INSTALL` environment variable introduced in 1.28.1 but with a lower priority. pr#4254 * Fixed a bug in Nushell integration that might generate invalid commands in the shell configuration. Reinstalling rustup might be required for the fix to work. pr#4265 ## How to update If you have a previous version of rustup installed, getting the new one is as easy as stopping any programs which may be using rustup (e.g. closing your IDE) and running: $ rustup self update Rustup will also automatically update itself at the end of a normal toolchain update: $ rustup update If you don't have it already, you can get rustup from the appropriate page on our website. Rustup's documentation is also available in the rustup book. ## Caveats Rustup releases can come with problems not caused by rustup itself but just due to having a new release. In particular, anti-malware scanners might block rustup or stop it from creating or copying files, especially when installing `rust-docs` which contains many small files. Issues like this should be automatically resolved in a few weeks when the anti-malware scanners are updated to be aware of the new rustup release. ## Thanks Thanks again to all the contributors who made this rustup release possible!

05.05.2025 00:00 — 👍 0 🔁 0 💬 0 📌 0

crates.io security incident: improperly stored session cookies Today the crates.io team discovered that the contents of the `cargo_session` cookie were being persisted to our error monitoring service, Sentry, as part of event payloads sent when an error occurs in the crates.io backend. The value of this cookie is a signed value that identifies the currently logged in user, and therefore these cookie values could be used to impersonate any logged in user. Sentry access is limited to a trusted subset of the crates.io team, Rust infrastructure team, and the crates.io on-call rotation team, who already have access to the production environment of crates.io. There is no evidence that these values were ever accessed or used. Nevertheless, out of an abundance of caution, we have taken these actions today: 1. We have merged and deployed a change to redact all cookie values from all Sentry events. 2. We have invalidated all logged in sessions, thus making the cookies stored in Sentry useless. In effect, this means that every crates.io user has been logged out of their browser session(s). Note that API tokens are **not** affected by this: they are transmitted using the `Authorization` HTTP header, and were already properly redacted before events were stored in Sentry. All existing API tokens will continue to work. We apologise for the inconvenience. If you have any further questions, please contact us on Zulip or GitHub.

11.04.2025 00:00 — 👍 0 🔁 0 💬 0 📌 0

08.04.2025 00:00 — 👍 0 🔁 0 💬 0 📌 0

04.04.2025 00:00 — 👍 0 🔁 0 💬 0 📌 0

Announcing Rust 1.86.0 The Rust team is happy to announce a new version of Rust, 1.86.0. Rust is a programming language empowering everyone to build reliable and efficient software. If you have a previous version of Rust installed via `rustup`, you can get 1.86.0 with: $ rustup update stable If you don't have it already, you can get `rustup` from the appropriate page on our website, and check out the detailed release notes for 1.86.0. If you'd like to help us out by testing future releases, you might consider updating locally to use the beta channel (`rustup default beta`) or the nightly channel (`rustup default nightly`). Please report any bugs you might come across! ## What's in 1.86.0 stable ### Trait upcasting This release includes a long awaited feature — the ability to upcast trait objects. If a trait has a supertrait you can coerce a reference to said trait object to a reference to a trait object of the supertrait: trait Trait: Supertrait {} trait Supertrait {} fn upcast(x: &dyn Trait) -> &dyn Supertrait { x } The same would work with any other kind of (smart-)pointer, like `Arc<dyn Trait> -> Arc<dyn Supertrait>` or `*const dyn Trait -> *const dyn Supertrait`. Previously this would have required a workaround in the form of an `upcast` method in the `Trait` itself, for example `fn as_supertrait(&self) -> &dyn Supertrait`, and this would work only for one kind of reference/pointer. Such workarounds are not necessary anymore. Note that this means that raw pointers to trait objects carry a non-trivial invariant: "leaking" a raw pointer to a trait object with an invalid vtable into safe code may lead to undefined behavior. It is not decided yet whether creating such a raw pointer temporarily in well-controlled circumstances causes immediate undefined behavior, so code should refrain from creating such pointers under any conditions (and Miri enforces that). Trait upcasting may be especially useful with the `Any` trait, as it allows upcasting your trait object to `dyn Any` to call `Any`'s downcast methods, without adding any trait methods or using external crates. use std::any::Any; trait MyAny: Any {} impl dyn MyAny { fn downcast_ref<T>(&self) -> Option<&T> { (self as &dyn Any).downcast_ref() } } You can learn more about trait upcasting in the Rust reference. ### `HashMap`s and slices now support indexing multiple elements mutably The borrow checker prevents simultaneous usage of references obtained from repeated calls to `get_mut` methods. To safely support this pattern the standard library now provides a `get_disjoint_mut` helper on slices and `HashMap` to retrieve mutable references to multiple elements simultaneously. See the following example taken from the API docs of `slice::get_disjoint_mut`: let v = &mut [1, 2, 3]; if let Ok([a, b]) = v.get_disjoint_mut([0, 2]) { *a = 413; *b = 612; } assert_eq!(v, &[413, 2, 612]); if let Ok([a, b]) = v.get_disjoint_mut([0..1, 1..3]) { a[0] = 8; b[0] = 88; b[1] = 888; } assert_eq!(v, &[8, 88, 888]); if let Ok([a, b]) = v.get_disjoint_mut([1..=2, 0..=0]) { a[0] = 11; a[1] = 111; b[0] = 1; } assert_eq!(v, &[1, 11, 111]); ### Allow safe functions to be marked with the `#[target_feature]` attribute. Previously only `unsafe` functions could be marked with the `#[target_feature]` attribute as it is unsound to call such functions without the target feature being enabled. This release stabilizes the `target_feature_11` feature, allowing _safe_ functions to be marked with the `#[target_feature]` attribute. Safe functions marked with the target feature attribute can only be safely called from other functions marked with the target feature attribute. However, they cannot be passed to functions accepting generics bounded by the `Fn*` traits and only support being coerced to function pointers inside of functions marked with the `target_feature` attribute. Inside of functions not marked with the target feature attribute they can be called inside of an `unsafe` block, however it is the caller's responsibility to ensure that the target feature is available. #[target_feature(enable = "avx2")] fn requires_avx2() { // ... snip } #[target_feature(enable = "avx2")] fn safe_callsite() { // Calling `requires_avx2` here is safe as `safe_callsite` // requires the `avx2` feature itself. requires_avx2(); } fn unsafe_callsite() { // Calling `requires_avx2` here is unsafe, as we must // ensure that the `avx2` feature is available first. if is_x86_feature_detected!("avx2") { unsafe { requires_avx2() }; } } You can check the `target_features_11` RFC for more information. ### Debug assertions that pointers are non-null when required for soundness The compiler will now insert debug assertions that a pointer is not null upon non-zero-sized reads and writes, and also when the pointer is reborrowed into a reference. For example, the following code will now produce a non-unwinding panic when debug assertions are enabled: let _x = *std::ptr::null::<u8>(); let _x = &*std::ptr::null::<u8>(); Trivial examples like this have produced a warning since Rust 1.53.0, the new runtime check will detect these scenarios regardless of complexity. These assertions only take place when debug assertions are enabled which means that they **must not** be relied upon for soundness. This also means that dependencies which have been compiled with debug assertions disabled (e.g. the standard library) will not trigger the assertions even when called by code with debug assertions enabled. ### Make `missing_abi` lint warn by default Omitting the ABI in extern blocks and functions (e.g. `extern {}` and `extern fn`) will now result in a warning (via the `missing_abi` lint). Omitting the ABI after the `extern` keyword has always implicitly resulted in the `"C"` ABI. It is now recommended to explicitly specify the `"C"` ABI (e.g. `extern "C" {}` and `extern "C" fn`). You can check the Explicit Extern ABIs RFC for more information. ### Target deprecation warning for 1.87.0 The tier-2 target `i586-pc-windows-msvc` will be removed in the next version of Rust, 1.87.0. Its difference to the much more popular `i686-pc-windows-msvc` is that it does not require SSE2 instruction support, but Windows 10, the minimum required OS version of all `windows` targets (except the `win7` targets), requires SSE2 instructions itself. All users currently targeting `i586-pc-windows-msvc` should migrate to `i686-pc-windows-msvc` before the `1.87.0` release. You can check the Major Change Proposal for more information. ### Stabilized APIs * `{float}::next_down` * `{float}::next_up` * `<[_]>::get_disjoint_mut` * `<[_]>::get_disjoint_unchecked_mut` * `slice::GetDisjointMutError` * `HashMap::get_disjoint_mut` * `HashMap::get_disjoint_unchecked_mut` * `NonZero::count_ones` * `Vec::pop_if` * `sync::Once::wait` * `sync::Once::wait_force` * `sync::OnceLock::wait` These APIs are now stable in const contexts: * `hint::black_box` * `io::Cursor::get_mut` * `io::Cursor::set_position` * `str::is_char_boundary` * `str::split_at` * `str::split_at_checked` * `str::split_at_mut` * `str::split_at_mut_checked` ### Other changes Check out everything that changed in Rust, Cargo, and Clippy. ## Contributors to 1.86.0 Many people came together to create Rust 1.86.0. We couldn't have done it without all of you. Thanks!

03.04.2025 00:00 — 👍 0 🔁 0 💬 0 📌 0

Adopting the FLS # Adopting the FLS Some years ago, Ferrous Systems and AdaCore worked together to assemble a description of Rust called the FLS1. Ferrous Systems has since been faithfully maintaining and updating this document for new versions of Rust, and they've successfully used it to qualify toolchains based on Rust for use in safety-critical industries. Seeing this success, others have also begun to rely on the FLS for their own qualification efforts when building with Rust. The members of the Rust Project are passionate about shipping high quality tools that enable people to build reliable software at scale. Such software is exactly the kind needed by those in safety-critical industries, and consequently we've become increasingly interested in better understanding and serving the needs of these customers of our language and of our tools. It's in that light that we're pleased to announce that we'll be adopting the FLS into the Rust Project as part of our ongoing specification efforts. This adoption is being made possible by Ferrous Systems. We're grateful to them for the work they've done in making the FLS fit for qualification purposes, in promoting its use and the use of Rust generally in safety-critical industries, and now, for working with us to take the next step and to bring it into the Project. With this adoption, we look forward to better integrating the FLS with the processes of the Project and to providing ongoing and increased assurances to all those who use Rust in safety-critical industries and, in particular, to those who use the FLS as part of their qualification efforts. This adoption would not have been possible without the efforts of the Rust Foundation, and in particular of Joel Marcey, the Director of Technology at the Foundation, who has worked tirelessly to facilitate this on our behalf. We're grateful to him and to the Foundation for this support. The Foundation has published its own post about this adoption. ## I'm relying on the FLS today; what should I expect? We'll be bringing the FLS within the Project, so expect some URLs to change. We plan to release updates to the FLS in much the same way as they have been happening up until now. We're sensitive to the fact that big changes to this document can result in costs for those using it for qualification purposes, and we don't have any immediate plans for big changes here. ## What's this mean for the Rust Reference? The Reference is still the Reference. Adopting the FLS does not change the status of the Reference, and we plan to continue to improve and expand the Reference as we've been doing. We'll of course be looking for ways that the Reference can support the FLS, and that the FLS can support the Reference, and in the long term, we're hopeful we can find ways to bring these two documents closer together. 1. The FLS stood for the "Ferrocene Language Specification". The minimal fork of Rust that Ferrous Systems qualifies and ships to their customers is called "Ferrocene", hence the name. We'll be dropping the expansion and just calling it the FLS within the Project. ↩

26.03.2025 00:00 — 👍 0 🔁 0 💬 0 📌 0

Announcing Rust 1.85.1 The Rust team has published a new point release of Rust, 1.85.1. Rust is a programming language that is empowering everyone to build reliable and efficient software. If you have a previous version of Rust installed via rustup, getting Rust 1.85.1 is as easy as: rustup update stable If you don't have it already, you can get `rustup` from the appropriate page on our website. ## What's in 1.85.1 ### Fixed combined doctest compilation Due to a bug in the implementation, combined doctests did not work as intended in the stable 2024 Edition. Internal errors with feature stability caused rustdoc to automatically use its "unmerged" fallback method instead, like in previous editions. Those errors are now fixed in 1.85.1, realizing the performance improvement of combined doctest compilation as intended! See the backport issue for more details, including the risk analysis of making this behavioral change in a point release. ### Other fixes 1.85.1 also resolves a few regressions introduced in 1.85.0: * Relax some `target_feature` checks when generating docs. * Fix errors in `std::fs::rename` on Windows 1607. * Downgrade bootstrap `cc` to fix custom targets. * Skip submodule updates when building Rust from a source tarball. ### Contributors to 1.85.1 Many people came together to create Rust 1.85.1. We couldn't have done it without all of you. Thanks!

18.03.2025 00:00 — 👍 0 🔁 0 💬 0 📌 0

Announcing rustup 1.28.1 The rustup team is happy to announce the release of rustup version 1.28.1. Rustup is the recommended tool to install Rust, a programming language that is empowering everyone to build reliable and efficient software. ## Challenges with rustup 1.28.0 rustup 1.28.0 was a significant release with many changes, and there was a quick response from many folks that this release broke their processes. While we considered yanking the release, we worried that this would cause problems for people who had already updated to adopt some of the changes. Instead, we are rolling forward with 1.28.1 today and potentially further bugfix releases to address the feedback that comes in. We value all constructive feedback -- please keep it coming in the issue tracker. In particular, the change with regard to implicit toolchain installation is being discussed in this issue. ## What's new in rustup 1.28.1 This release contains the following fixes: * Automatic install is enabled by default but can be opted out by setting `RUSTUP_AUTO_INSTALL` environment variable to `0`. pr#4214 pr#4227 * `rustup show active-toolchain` will only print a single line, as it did in 1.27. pr#4221 * Fixed a bug in the reqwest backend that would erroneously timeout downloads after 30s. pr#4218 * Use relative symlinks for proxies. pr#4226 ## How to update If you have a previous version of rustup installed, getting rustup 1.28.1 is as easy as stopping any programs which may be using Rustup (e.g. closing your IDE) and running: $ rustup self update Rustup will also automatically update itself at the end of a normal toolchain update: $ rustup update If you don't have it already, you can get rustup from the appropriate page on our website. Rustup's documentation is also available in the rustup book. ## Caveats Rustup releases can come with problems not caused by rustup itself but just due to having a new release. As such, we recommend paying attention to the following potential issues in particular: * Anti-malware scanners might be blocking rustup or stopping it from creating or copying files (especially when installing `rust-docs`, since it contains many small files). * In your CI environment, rustup might fail when trying to perform a self-update. This is a known issue, and in the case where this issue does occur, we recommend applying the following workaround at the beginning of your workflow: $ rustup set auto-self-update disable Also, starting from 1.28.0, rustup will no longer attempt to self-update in CI environments, so this workaround should not be necessary in the future. These issues should be automatically resolved in a few weeks when the anti-malware scanners are updated to be aware of the new rustup release, and the hosted version is updated across all CI runners. ## Thanks Thanks to the rustup and t-release team members who came together to quickly address these issues.

04.03.2025 00:00 — 👍 0 🔁 0 💬 0 📌 0

03.03.2025 00:00 — 👍 0 🔁 0 💬 0 📌 0

Announcing Rustup 1.28.0 The rustup team is happy to announce the release of rustup version 1.28.0. Rustup is the recommended tool to install Rust, a programming language that is empowering everyone to build reliable and efficient software. ## What's new in rustup 1.28.0 This new release of rustup has been a long time in the making and comes with substantial changes. Before digging into the details, it is worth mentioning that Chris Denton has joined the team. Chris has a lot of experience contributing to Windows-related parts of the Rust Project -- expertise we were previously lacking -- so we're happy to have him on board to help address Windows-specific issues. The following improvements might require changes to how you use rustup: * rustup will no longer automatically install the active toolchain if it is not installed. * To ensure its installation, run `rustup toolchain install` with no arguments. * The following command installs the active toolchain both before and after this change: rustup show active-toolchain || rustup toolchain install # Or, on older versions of PowerShell: rustup show active-toolchain; if ($LASTEXITCODE -ne 0) { rustup toolchain install } * Installing a host-incompatible toolchain via `rustup toolchain install` or `rustup default` will now be rejected unless you explicitly add the `--force-non-host` flag. Rustup now officially supports the following host platforms: * `aarch64-pc-windows-msvc` * `loongarch64-unknown-linux-musl` This release also comes with various quality-of-life improvements, to name a few: * `rustup show`'s output format has been cleaned up, making it easier to find out about your toolchains' status. * `rustup doc` now accepts a flag and a topic at the same time, enabling quick navigation to specific parts of more books. * rustup's `remove` subcommands now support more aliases such as `rm` and `del`. * Basic support for nushell has been added. We have additionally made the following internal changes: * The default download backend has been changed from reqwest with native-tls to reqwest with rustls. * `RUSTUP_USE_CURL` and `RUSTUP_USE_RUSTLS` can still be used to change the download backend if the new backend causes issues. If issues do happen, please let us know. * The default backend now uses rustls-platform-verifier to verify server certificates, taking advantage of the platform's certificate store on platforms that support it. * When creating proxy links, rustup will now try symlinks first and fall back to hardlinks, as opposed to trying hardlinks first. * A new `RUSTUP_LOG` environment variable can be used to control tracing-based logging in rustup binaries. See the dev guide for more details. Finally, there are some notable changes to our official website as well: * The overall design of the website has been updated to better align with the Rust Project's branding. * It is now possible to download the prebuilt `rustup-init.sh` installer for the `aarch64-pc-windows-msvc` host platform via https://win.rustup.rs/aarch64. Further details are available in the changelog! ## How to update If you have a previous version of rustup installed, getting rustup 1.28.0 is as easy as stopping any programs which may be using Rustup (e.g. closing your IDE) and running: $ rustup self update Rustup will also automatically update itself at the end of a normal toolchain update: $ rustup update If you don't have it already, you can get rustup from the appropriate page on our website. Rustup's documentation is also available in the rustup book. ## Caveats Rustup releases can come with problems not caused by rustup itself but just due to having a new release. As such, we recommend paying attention to the following potential issues in particular: * Anti-malware scanners might be blocking rustup or stopping it from creating or copying files (especially when installing `rust-docs`, since it contains many small files). * In your CI environment, rustup might fail when trying to perform a self-update. This is a known issue, and in the case where this issue does occur, we recommend applying the following workaround at the beginning of your workflow: $ rustup set auto-self-update disable Also, starting from 1.28.0, rustup will no longer attempt to self-update in CI environments, so this workaround should not be necessary in the future. These issues should be automatically resolved in a few weeks when the anti-malware scanners are updated to be aware of the new rustup release, and the hosted version is updated across all CI runners. ## Thanks Thanks again to all the contributors who made rustup 1.28.0 possible!

02.03.2025 00:00 — 👍 0 🔁 0 💬 0 📌 0

Announcing Rust 1.85.0 and Rust 2024 The Rust team is happy to announce a new version of Rust, 1.85.0. This stabilizes the 2024 edition as well. Rust is a programming language empowering everyone to build reliable and efficient software. If you have a previous version of Rust installed via `rustup`, you can get 1.85.0 with: $ rustup update stable If you don't have it already, you can get `rustup` from the appropriate page on our website, and check out the detailed release notes for 1.85.0. If you'd like to help us out by testing future releases, you might consider updating locally to use the beta channel (`rustup default beta`) or the nightly channel (`rustup default nightly`). Please report any bugs you might come across! ## What's in 1.85.0 stable ### Rust 2024 We are excited to announce that the Rust 2024 Edition is now stable! Editions are a mechanism for opt-in changes that may otherwise pose a backwards compatibility risk. See the edition guide for details on how this is achieved, and detailed instructions on how to migrate. This is the largest edition we have released. The edition guide contains detailed information about each change, but as a summary, here are all the changes: * Language * RPIT lifetime capture rules — Changes the default capturing of parameters by `impl Trait` types when `use<..>` is not present. * `if let` temporary scope — Changes the scope of temporaries for `if let` expressions. * Tail expression temporary scope — Changes the scope of temporaries for the tail expression in a block. * Match ergonomics reservations — Disallow some pattern combinations to avoid confusion and allow for future improvements. * Unsafe `extern` blocks — `extern` blocks now require the `unsafe` keyword. * Unsafe attributes — The `export_name`, `link_section`, and `no_mangle` attributes must now be marked as `unsafe`. * `unsafe_op_in_unsafe_fn` warning — The `unsafe_op_in_unsafe_fn` lint now warns by default, requiring explicit `unsafe {}` blocks in `unsafe` functions. * Disallow references to `static mut` — References to `static mut` items now generate a deny-by-default error. * Never type fallback change — Changes to how the never type `!` coerces, and changes the `never_type_fallback_flowing_into_unsafe` lint level to "deny". * Macro fragment specifiers — The `expr` macro fragment specifier in `macro_rules!` macros now also matches `const` and `_` expressions. * Missing macro fragment specifiers — The `missing_fragment_specifier` lint is now a hard error, rejecting macro meta variables without a fragment specifier kind. * `gen` keyword — Reserves the `gen` keyword in anticipation of adding generator blocks in the future. * Reserved syntax — Reserves `#"foo"#` style strings and `##` tokens in anticipation of changing how guarded string literals may be parsed in the future. * Standard library * Changes to the prelude — Adds `Future` and `IntoFuture` to the prelude. * Add `IntoIterator` for `Box<[T]>` — Changes how iterators work with boxed slices. * Newly unsafe functions — `std::env::set_var`, `std::env::remove_var`, and `std::os::unix::process::CommandExt::before_exec` are now unsafe functions. * Cargo * Cargo: Rust-version aware resolver — Changes the default dependency resolver behavior to consider the `rust-version` field. * Cargo: Table and key name consistency — Removes some outdated `Cargo.toml` keys. * Cargo: Reject unused inherited default-features — Changes how `default-features = false` works with inherited workspace dependencies. * Rustdoc * Rustdoc combined tests — Doctests are now combined into a single executable, significantly improving performance. * Rustdoc nested `include!` change — Changes to the relative path behavior of nested `include!` files. * Rustfmt * Rustfmt: Style edition — Introduces the concept of "style editions", which allow you to independently control the formatting edition from the Rust edition. * Rustfmt: Formatting fixes — A large number of fixes to formatting various situations. * Rustfmt: Raw identifier sorting — Changes to how `r#foo` identifiers are sorted. * Rustfmt: Version sorting — Changes to how identifiers that contain integers are sorted. #### Migrating to 2024 The guide includes migration instructions for all new features, and in general transitioning an existing project to a new edition. In many cases `cargo fix` can automate the necessary changes. You may even find that no changes in your code are needed at all for 2024! Note that automatic fixes via `cargo fix` are very conservative to avoid ever changing the semantics of your code. In many cases you may wish to keep your code the same and use the new semantics of Rust 2024; for instance, continuing to use the `expr` macro matcher, and ignoring the conversions of conditionals because you want the new 2024 drop order semantics. The result of `cargo fix` should not be considered a recommendation, just a conservative conversion that preserves behavior. _Many_ people came together to create this edition. We'd like to thank them all for their hard work! ### `async` closures Rust now supports asynchronous closures like `async || {}` which return futures when called. This works like an `async fn` which can also capture values from the local environment, just like the difference between regular closures and functions. This also comes with 3 analogous traits in the standard library prelude: `AsyncFn`, `AsyncFnMut`, and `AsyncFnOnce`. In some cases, you could already approximate this with a regular closure and an asynchronous block, like `|| async {}`. However, the future returned by such an inner block is not able to borrow from the closure captures, but this does work with `async` closures: let mut vec: Vec<String> = vec![]; let closure = async || { vec.push(ready(String::from("")).await); }; It also has not been possible to properly express higher-ranked function signatures with the `Fn` traits returning a `Future`, but you can write this with the `AsyncFn` traits: use core::future::Future; async fn f<Fut>(_: impl for<'a> Fn(&'a u8) -> Fut) where Fut: Future<Output = ()>, { todo!() } async fn f2(_: impl for<'a> AsyncFn(&'a u8)) { todo!() } async fn main() { async fn g(_: &u8) { todo!() } f(g).await; //~^ ERROR mismatched types //~| ERROR one type is more general than the other f2(g).await; // ok! } So `async` closures provide first-class solutions to both of these problems! See RFC 3668 and the stabilization report for more details. ### Hiding trait implementations from diagnostics The new `#[diagnostic::do_not_recommend]` attribute is a hint to the compiler to not show the annotated trait implementation as part of a diagnostic message. For library authors, this is a way to keep the compiler from making suggestions that may be unhelpful or misleading. For example: pub trait Foo {} pub trait Bar {} impl<T: Foo> Bar for T {} struct MyType; fn main() { let _object: &dyn Bar = &MyType; } error[E0277]: the trait bound `MyType: Bar` is not satisfied --> src/main.rs:9:29 | 9 | let _object: &dyn Bar = &MyType; | ^^^^ the trait `Foo` is not implemented for `MyType` | note: required for `MyType` to implement `Bar` --> src/main.rs:4:14 | 4 | impl<T: Foo> Bar for T {} | --- ^^^ ^ | | | unsatisfied trait bound introduced here = note: required for the cast from `&MyType` to `&dyn Bar` For some APIs, it might make good sense for you to implement `Foo`, and get `Bar` indirectly by that blanket implementation. For others, it might be expected that most users should implement `Bar` directly, so that `Foo` suggestion is a red herring. In that case, adding the diagnostic hint will change the error message like so: #[diagnostic::do_not_recommend] impl<T: Foo> Bar for T {} error[E0277]: the trait bound `MyType: Bar` is not satisfied --> src/main.rs:10:29 | 10 | let _object: &dyn Bar = &MyType; | ^^^^ the trait `Bar` is not implemented for `MyType` | = note: required for the cast from `&MyType` to `&dyn Bar` See RFC 2397 for the original motivation, and the current reference for more details. ### `FromIterator` and `Extend` for tuples Earlier versions of Rust implemented convenience traits for iterators of `(T, U)` tuple pairs to behave like `Iterator::unzip`, with `Extend` in 1.56 and `FromIterator` in 1.79. These have now been _extended_ to more tuple lengths, from singleton `(T,)` through to 12 items long, `(T1, T2, .., T11, T12)`. For example, you can now use `collect()` to fanout into multiple collections at once: use std::collections::{LinkedList, VecDeque}; fn main() { let (squares, cubes, tesseracts): (Vec<_>, VecDeque<_>, LinkedList<_>) = (0i32..10).map(|i| (i * i, i.pow(3), i.pow(4))).collect(); println!("{squares:?}"); println!("{cubes:?}"); println!("{tesseracts:?}"); } [0, 1, 4, 9, 16, 25, 36, 49, 64, 81] [0, 1, 8, 27, 64, 125, 216, 343, 512, 729] [0, 1, 16, 81, 256, 625, 1296, 2401, 4096, 6561] ### Updates to `std::env::home_dir()` `std::env::home_dir()` has been deprecated for years, because it can give surprising results in some Windows configurations if the `HOME` environment variable is set (which is not the normal configuration on Windows). We had previously avoided changing its behavior, out of concern for compatibility with code depending on this non-standard configuration. Given how long this function has been deprecated, we're now updating its behavior as a bug fix, and a subsequent release will remove the deprecation for this function. ### Stabilized APIs * `BuildHasherDefault::new` * `ptr::fn_addr_eq` * `io::ErrorKind::QuotaExceeded` * `io::ErrorKind::CrossesDevices` * `{float}::midpoint` * Unsigned `{integer}::midpoint` * `NonZeroU*::midpoint` * impl `std::iter::Extend` for tuples with arity 1 through 12 * `FromIterator<(A, ...)>` for tuples with arity 1 through 12 * `std::task::Waker::noop` These APIs are now stable in const contexts * `mem::size_of_val` * `mem::align_of_val` * `Layout::for_value` * `Layout::align_to` * `Layout::pad_to_align` * `Layout::extend` * `Layout::array` * `std::mem::swap` * `std::ptr::swap` * `NonNull::new` * `HashMap::with_hasher` * `HashSet::with_hasher` * `BuildHasherDefault::new` * `<float>::recip` * `<float>::to_degrees` * `<float>::to_radians` * `<float>::max` * `<float>::min` * `<float>::clamp` * `<float>::abs` * `<float>::signum` * `<float>::copysign` * `MaybeUninit::write` ### Other changes Check out everything that changed in Rust, Cargo, and Clippy. ## Contributors to 1.85.0 Many people came together to create Rust 1.85.0. We couldn't have done it without all of you. Thanks!

20.02.2025 00:00 — 👍 0 🔁 0 💬 0 📌 0

13.02.2025 00:00 — 👍 0 🔁 0 💬 0 📌 0

crates.io: development update Back in July 2024, we published a blog post about the ongoing development of crates.io. Since then, we have made a lot of progress and shipped a few new features. In this blog post, we want to give you an update on the latest changes that we have made to crates.io. ## Crate deletions In RFC #3660 we proposed a new feature that allows crate owners to delete their crates from crates.io under certain conditions. This can be useful if you have published a crate by mistake or if you want to remove a crate that is no longer maintained. After the RFC was accepted by all team members at the end of August, we began implementing the feature. We created a new API endpoint `DELETE /api/v1/crates/:name` that allows crate owners to delete their crates and then created the corresponding user interface. If you are the owner of a crate, you can now go to the crate page, open the "Settings" tab, and find the "Delete this crate" button at the bottom. Clicking this button will lead you to a confirmation page telling you about the potential impact of the deletion and requirements that need to be met in order to delete the crate: As you can see from the screenshot above, a crate can only be deleted if either: the crate has been published for less than 72 hours or the crate only has a single owner, and the crate has been downloaded less than 500 times for each month it has been published, and the crate is not depended upon by any other crate on crates.io. These requirements were put in place to prevent abuse of the deletion feature and to ensure that crates that are widely used by the community are not deleted accidentally. If you have any feedback on this feature, please let us know! ## OpenAPI description Around the holiday season we started experimenting with generating an OpenAPI description for the crates.io API. This was a long-standing request from the community, and we are happy to announce that we now have an experimental OpenAPI description available at https://crates.io/api/openapi.json! Please note that this is still considered work-in-progress and e.g. the stability guarantees for the endpoints are not written down and the response schemas are also not fully documented yet. You can view the OpenAPI description in e.g. a Swagger UI at https://petstore.swagger.io/ by putting `https://crates.io/api/openapi.json` in the top input field. We decided to not ship a viewer ourselves for now due to security concerns with running it on the same domain as crates.io itself. We may reconsider whether to offer it on a dedicated subdomain in the future if there is enough interest. The OpenAPI description is generated by the utoipa crate, which is a tool that can be integrated with the axum web framework to automatically generate OpenAPI descriptions for all of your endpoints. We would like to thank Juha Kukkonen for his great work on this tool! ## Support form and "Report Crate" button Since the crates.io team is small and mostly consists of volunteers, we do not have the capacity to manually monitor all publishes. Instead, we rely on you, the Rust community, to help us catch malicious crates and users. To make it easier for you to report suspicious crates, we added a "Report Crate" button to all the crate pages. If you come across a crate that you think is malicious or violates the code of conduct or our usage policy, you can now click the "Report Crate" button and fill out the form that appears. This will send an email to the crates.io team, who will then review the crate and take appropriate action if necessary. Thank you to crates.io team member @eth3lbert who worked on the majority of this. If you have any issues with the support form or the "Report Crate" button, please let us know. You can also always email us directly at help@crates.io if you prefer not to use the form. ## Publish notifications We have added a new feature that allows you to receive email notifications when a new version of your crate is published. This can be useful in detecting unauthorized publishes of your crate or simply to keep track of publishes from other members of your team. This feature was another long-standing feature request from our community, and we were happy to finally implement it. If you'd prefer not to receive publish notifications, then you can go to your account settings on crates.io and disable these notifications. ## Miscellaneous These were some of the more visible changes to crates.io over the past couple of months, but a lot has happened "under the hood" as well. * RFC #3691 was opened and accepted to implement "Trusted Publishing" support on crates.io, similar to other ecosystems that adopted it. This will allow you to specify on crates.io which repository/system is allowed to publish new releases of your crate, allowing you to publish crates from CI systems without having to deal with API tokens anymore. * Slightly related to the above: API tokens created on crates.io now expire after 90 days by default. It is still possible to disable the expiry or choose other expiry durations though. * The crates.io team was one of the first projects to use the diesel database access library, but since that only supported synchronous execution it was sometimes a little awkward to use in our codebase, which was increasingly moving into an async direction after our migration to axum a while ago. The maintainer of diesel, Georg Semmler, did a lot of work to make it possible to use diesel in an async way, resulting in the diesel-async library. Over the past couple of months we incrementally ported crates.io over to `diesel-async` queries, which now allows us to take advantage of the internal query pipelining in `diesel-async` that resulted in some of our API endpoints getting a 10-15% performance boost. Thank you, Georg, for your work on these crates! * Whenever you publish a new version or yank/unyank existing versions a couple of things need to be updated. Our internal database is immediately updated, and then we synchronize the sparse and git index in background worker jobs. Previously, yanking and unyanking a high number of versions would each queue up another synchronization background job. We have now implemented automatic deduplication of redundant background jobs, making our background worker a bit more efficient. * The final big, internal change that was just merged last week is related to the testing of our frontend code. In the past we used a tool called Mirage to implement a mock version of our API, which allowed us to run our frontend test suite without having to spin up a full backend server. Unfortunately, the maintenance situation around Mirage had lately forced us to look into alternatives, and we are happy to report that we have now fully migrated to the "Industry standard API mocking" package msw. If you want to know more, you can find the details in the "small" migration pull request. ## Feedback We hope you enjoyed this update on the development of crates.io. If you have any feedback or questions, please let us know on Zulip or GitHub. We are always happy to hear from you and are looking forward to your feedback!

05.02.2025 00:00 — 👍 0 🔁 0 💬 0 📌 0

Announcing Rust 1.84.1 The Rust team has published a new point release of Rust, 1.84.1. Rust is a programming language that is empowering everyone to build reliable and efficient software. If you have a previous version of Rust installed via rustup, getting Rust 1.84.1 is as easy as: rustup update stable If you don't have it already, you can get `rustup` from the appropriate page on our website. ## What's in 1.84.1 1.84.1 resolves a few regressions introduced in 1.84.0: * Fix ICE 132920 in duplicate-crate diagnostics. * Fix errors for overlapping impls in incremental rebuilds. * Fix slow compilation related to the next-generation trait solver. * Fix debuginfo when LLVM's location discriminator value limit is exceeded. It also includes several fixes for those building Rust from source: * Only try to distribute `llvm-objcopy` if LLVM tools are enabled. * Add Profile Override for Non-Git Sources. * Resolve symlinks of LLVM tool binaries before copying them. * Make it possible to use ci-rustc on tarball sources. ### Contributors to 1.84.1 Many people came together to create Rust 1.84.1. We couldn't have done it without all of you. Thanks!

30.01.2025 00:00 — 👍 0 🔁 0 💬 0 📌 0

December Project Goals Update Over the last six months, the Rust project has been working towards a slate of 26 project goals, with 3 of them designated as Flagship Goals. This post provides a final update on our progress towards these goals (or, in some cases, lack thereof). We are currently finalizing plans for the next round of project goals, which will cover 2025H1. The full details for any particular goal are available in its associated tracking issue on the rust-project-goals repository. ## Flagship goals **Bring the Async Rust experience closer to parity with sync Rust** Our big goal for this period was async closures, and we are excited to announce that work there is done! Stable support for async closures landed on nightly on Dec 12 and it will be included in Rust 1.85, which ships on Feb 20. Big kudos to compiler-errors for driving that. For our other goals, we made progress, but there remains work to be done: * **Return Type Notation (RTN)** is implemented and we had a call for experimentation but it has not yet reached stable. This will be done as part of our 2025H1 goal. * Async Functions in Traits (and Return Position Impl Trait in Trait) are currently not consided `dyn` compatible. We would eventually like to have first-class `dyn` support, but as an intermediate step we created a procedural macro crate `dynosaur`1 that can create wrappers that enable **dynamic dispatch**. We are planning a comprehensive blog post in 2025H1 that shows how to use this crate and lays out the overall plan for async functions in traits. * Work was done to prototype an **implementation for async drop** but we didn't account for reviewing bandwidth. nikomatsakis has done initial reads and is working with PR author to get this done in 2025H1. To be clear though the scope of this is an experiment with the goal of uncovering implementation hurdles. There remains significant language design work before this feature would be considered for stabilization (we don't even have an RFC, and there are lots of unknowns remaining). * We have had fruitful discussions about the trait for **async iteration** but do not have widespread consensus, that's on the docket for 2025H1. **Resolve the biggest blockers to Linux building on stable Rust** We largely completed our goal to stabilize the language features used by the Rust for Linux project. In some cases a small amount of work remains. Over the last six months, we... * stabilized the `offset_of!` macro to get the offset of fields; * _almost_ stabilized the `CoercePointee` trait -- but discovered that the current implementaton was revealing unstable details, which is currently being resolved; * `asm_goto` stabilization PR and reference updates are up, excluding the "output" feature. * completed the majority of the work for arbitrary self types, which is being used by RfL and just needs documentation before stabilisation We also began work on compiler flag stabilization with RFC 3716, which outlines a scheme for stabilizing flags that modify the target ABI. Big shout-outs to Ding Xiang Fei, Alice Ryhl, Adrian Taylor, and Gary Guo for doing the lion's share of the work here. **Rust 2024 Edition** The final release of Rust 2024 is confirmed for February 20, 2025 as part of Rust 1.85. Rust 1.85 is currently in beta. Feedback from the nightly beta and crater runs has been actively addressed, with adjustments to migrations and documentation to enhance user experience. Big shout-outs to TC and Eric Huss for their hard work driving this program forward. ## Final goal updates **" Stabilizable" prototype for expanded const generics** Over the last six months a number of internal refactorings have taken place that are necessary to support a `min_generic_const_args` prototype. One refactoring is that we have changed how we represent const arguments in the compiler to allow for adding a separate representation for the kinds of const arguments that `min_generic_const_args` will add. Another big refactoring is that we have changed the API surface for our representation of const arguments in the type system layer, there is no longer a way to evaluate a const argument without going through our general purpose type system logic. This was necessary to ensure that we correctly handle equality of the kinds of const arguments that `min_generic_const_args` will support. With all of these pre-requisite refactorings completed, a feature gate has been added to the compiler (`feature(min_generic_const_args)`) that uses the new internal representation of const arguments. We are now beginning to implement the actual language changes under this feature gate. Shout-out to camelid, boxy and compiler-errors. **Begin resolving `cargo-semver-checks` blockers for merging into cargo** Over the course of the last six months... * cargo semver-checks began to include generic parameters and bounds in its schema, allowing for more precise lints; * cargo manifest linting was implemented and merged, allowing for lints that look at the cargo manifest; * building on cargo manifest linting, the `feature_missing` lint was added, which identifies breakage caused by the removal of a package feature. In addition, we fleshed out a design sketch for the changes in rustdoc's JSON support that are needed to support cross-crate item linting. This in turn requires compiler extensions to supply that information to rustdoc. **Const traits** * Progress was made on adding const traits and implementation in the compiler, with improvements being carefully considered. `Add` was constified in rust#133237 and `Deref`/`DerefMut` in rust#133260. * Further progress was made on implementing stability for the const traits feature in rust#132823 and rust#133999, with additional PRs constifying more traits open at rust#133995 and rust#134628. **Ergonomic ref-counting** * Over the last six months, we created a lang-team experiment devoted to this issue and spastorino began work on an experimental implementation. joshtriplett authored RFC 3680, which has received substantial feedback. The current work is focused on identifying "cheaply cloneable" types and making it easy to create closures that clone them instead of moving them. **Explore sandboxed build scripts** * Alternatives to sandboxed build scripts are going to be investigated instead of continuing this project goal into 2025h1 - namely, declaratively configuring system dependencies with `system-deps`, using an approach similar to code-checker Cackle and its sandbox environment Bubblewrap, or fully-sandboxed build environments like Docker or Nix. **Extend pubgrub to match cargo 's dependency resolution** * Significant speedups have been achieved, reducing the slowest crate resolution time from over 120 seconds to 11 seconds, and decreasing the time to check all crates from 178 minutes to 71.42 minutes. * Performance improvements have been made to both the existing resolver and the new implementation, with the lock file verification time for all crates reduced from 44.90 minutes to 32.77 minutes (excluding some of the hardest cases). **Make Rustdoc Search easier to learn** * Our pull request adding example searches and adding a search button has been added to the agenda for the rustdoc team next meeting. **Next-generation trait solver** * The `-Znext-solver=coherence` stabilization is now stable in version 1.84, with a new update blogpost published. * Significant progress was made on bootstrap with `-Znext-solver=globally`. We're now able to compile rustc and cargo, enabling try-builds and perf runs. **Optimizing Clippy & linting** * An optimisation for the `#[clippy::msrv]` lint is open, benchmarked, and currently under review. * Help is needed on any issue marked with `performance-project`, especially on issue #13714. **Patterns of empty types** * Over the course of this goal, Nadrieril wrote and posted the never patterns RFC as an attempt to make progress without figuring out the whole picture, and the general feedback was "we want to see the whole picture". Next step will be to write up an RFC that includes a clear proposal for which empty patterns can and cannot be omitted. This is 100% bottlenecked on my own writing bandwidth (reach out if you want to help!). Work will continue but the goal won't be resubmitted for 2025h1. **Scalable Polonius support on nightly** * Amanda has made progress on removing placeholders, focusing on lazy constraints and early error reporting, as well as investigating issues with rewriting type tests; a few tests are still failing, and it seems error reporting and diagnostics will be hard to keep exactly as today. * @lqd has opened PRs to land the prototype of the location-sensitive analysis. It's working well enough that it's worthwhile to land; there is still a lot of work left to do, but it's a major milestone, which we hoped to achieve with this project goal. **Stabilize cargo-script** * A fix stopping cargo-script from overriding the release profile was posted and merged. * Help is wanted for writing frontmatter support in rustc, as rustfmt folks are requesting it to be represented in the AST. **Stabilize doc_cfg** * RFC is done, waiting for all rustdoc team members to take a look before implementation can start. **Stabilize parallel front end** * SparrowLii proposed a 2025H1 project goal to continue stabilizing the parallel front end, focusing on solving reproducible deadlock issues and improving parallel compilation performance. * The team discussed solutions to avoid potential deadlocks, finding that disabling work-stealing in rayon's subloops is effective, and will incorporate related modifications in a PR. **Use annotate-snippets for rustc diagnostic output** * Progress on `annotate-snippets` continued despite a busy schedule, with a focus on improving suggestions and addressing architectural challenges. * A new API was designed in collaboration with epage, aiming to align `annotate-snippets` more closely with `rustc` for easier contribution and integration. **Assemble project goal slate** * The project goal slate for 2025h1 has been posted as an RFC and is waiting on approval from project team leads. **Expose experimental LLVM features for automatic differentiation and GPU offloading** * Another pull request was merged with only one remaining until a working MVP is available on nightly. * Some features were removed to simplify upstreaming and will be added back as single PRs. * Will start work on `batching` feature of LLVM/Enzyme which allows Array of Struct and Struct of Array vectorisation. * There's been a push to add a AMD GPU target to the compiler which would have been needed for the LLVM offload project. **Survey tools suitability for Std safety verification** * We have written and verified around 220 safety contracts in the verify-rust-std fork. * 3 out of 14 challenges have been solved. * We have successfully integrated Kani in the repository CI, and we are working on the integration of 2 other verification tools: VeriFast and Goto-transcoder (ESBMC) **Testing infra + contributors for a-mir-formality** * There wasn't any progress on this goal, but building a community around a-mir-formality is still a goal and future plans are coming. ## Goals without updates The following goals have not received updates in the last month: **Associated type position impl trait** **Implement "merged doctests" to save doctest time** **Provided reasons for yanked crates** **User-wide build cache** 1. As everyone knows, the hardest part of computer-science is naming. I think we rocked this one. ↩

23.01.2025 00:00 — 👍 0 🔁 0 💬 0 📌 0

Rust 2024 in beta channel # Rust 2024 in beta channel The next edition, Rust 2024, has entered the beta channel. It will live there until 2025-02-20, when Rust 1.85 and Rust 2024 will be released as stable. We're really happy with how Rust 2024 has turned out, and we're looking forward to putting it in your hands. You can get a head start in preparing your code for the new edition, and simultaneously help us with final testing of Rust 2024, by following these steps within a project: 1. Run `rustup update beta`. 2. Run `cargo update`. 3. Run `cargo +beta fix --edition`. 4. Set `edition = "2024"` and, if needed, `rust-version = "1.85"`, in `Cargo.toml`. 5. Run `cargo +beta check`, address any remaining warnings, and then run other tests. More details on how to migrate can be found here and within each of the chapters describing the changes in Rust 2024. For more on the changes themselves, see the Edition Guide. If you encounter any problems or see areas where we could make the experience better, tell us about it by filing an issue.

22.01.2025 00:00 — 👍 0 🔁 0 💬 0 📌 0

09.01.2025 00:00 — 👍 0 🔁 0 💬 0 📌 0

November project goals update The Rust project is currently working towards a slate of 26 project goals, with 3 of them designed as Flagship Goals. This post provides selected updates on our progress towards these goals (or, in some cases, lack thereof). The full details for any particular goal are available in its associated tracking issue on the rust-project-goals repository. ## Flagship goals **Bring the Async Rust experience closer to parity with sync Rust** Async closure stabilization has been approved, though the stabilization has not yet landed! The lang team ultimately opted to stabilize the trait name `AsyncFn` rather than the keyword-based `async Fn` syntax that was originally proposed. This decision came after discussion on the Flavors RFC which made it clear we were not at a consensus about whether the `async Trait` keyword would be used more generally or not. Given that, the team felt that the `AsyncFn` synta was a fine "next step". If we do ultimately adopt some form of `async Trait` keyword syntax, then `AsyncFn` can become a trait alias. Regarding return-type notation, an extension of return-type notation to cover Self::foo(..): Send landed and we landed #132047 which fixes a known ICE. Stabilization PR is now unblocked. No major progress towards async drop reviews or team reorganization. **Resolve the biggest blockers to Linux building on stable Rust** This month saw steady progress on our checklist. dingxiangfei2009's PR renaming `derive(SmartPointer)` to `derive(CoercePointee)` was merged and he began the work to port the RFL codebase to use the new name. Alice Ryhl opened RFC #3716 proposing a way to manage compiler flags that alter the ABI and discussion (and some implementation work) has ensued. Finally, we landed PR #119364 making target blocks in asm-goto safe by default; this was based directly on experience from RFL which showed that safe would be more useful]. We are still working to finalize another extension to asm-goto that arose from RFL requirements, allowing `const` to support embedded pointers. Finally we prepared reference PR #1610 describing the change to permit [Pointers to Statics in Constants that was stabilized last month. **Rust 2024 Edition** Rust 2024 has now entered the nightly beta and is expected to stabilize as part of Rust 1.85 on 2025-02-20. It has a great many improvements that make the language more consistent and ergonomic, that further upon our relentless commitment to safety, and that will open the door to long-awaited features such as gen blocks, let chains, and the never type `!`. For more on the changes, see the nightly Edition Guide. The call for testing blog post contains more information and instructions on how you can try it yourself. ## Goals with updates **" Stabilizable" prototype for expanded const generics** * `min_generic_const_args` now exists as a feature gate, though without any functionality, only some gated refactorings, but shouldn't be long before it has actual functionality behind it. * The refactoring to remove all the `eval_x` methods on `ty::Const` has been completed, making it possible to correctly implement normalization for constants. **Assemble project goal slate** * Posted the October update. * Created more automated infrastructure to prepare the October update, making use of an LLM to summarize updates into one or two sentences for a concise table. **Begin resolving `cargo-semver-checks` blockers for merging into cargo** * Support for cargo manifest linting is now merged, making it possible to catch breakage caused by _manifest_ (`Cargo.toml`) changes, not just source code changes. An example of such breakage is the removal of a package feature: any crates that enabled the removed feature will no longer build. * Partial schema design and implementation of type information in lints, enabling the creation of breaking-change lints and improving diagnostic quality for a subset of type-related breaking changes. * Resolved multi-team questions that were blocking cross-crate checking, with the compiler team MCP merged and rustdoc improvements discussed and agreed upon. **Const traits** * The way const traits are desugared was completely restructured, making the design easier to understand and more robust against current unit tests. * Significant development and cleanup for the feature has been done, with several pull requests merged and two still open, bringing the feature closer to being able to dogfood on the standard library and closer to stabilization. **Ergonomic ref-counting** * @joshtriplett opened https://github.com/rust-lang/rfcs/pull/3680. The @rust-lang/lang team has not yet truly discussed or reached a decision on that RFC. * @spastorino began implementation work on a prototype. **Explore sandboxed build scripts** * The sandboxed build scripts exploration is complete. We are unlikely to continue this work in next year but the research may be useful in other areas, such as the possible addition of POSIX process support to WASI or a declarative system dependency configuration in Cargo. **Expose experimental LLVM features for automatic differentiation and GPU offloading** * The re-design of the autodiff middle/backend was implemented, reducing the remaining LoC to be upstreamed from 2.5k to 1.1k, split into two PRs (1 and 2), which received initial feedback and are expected to land in early December. * The preprint of the first paper utilizing `std::autodiff` is available on Arxiv, with code available at ChemAI-Lab/molpipx, showcasing significantly faster compilation times in Rust compared to JAX. **Extend pubgrub to match cargo 's dependency resolution** * The core data structures of PubGrub have been published as a separate `version-ranges` crate, enabling multiple projects to share this core abstraction and benefit from improvements without waiting for the rest of the project. * This is one of many steps required to publish a new `0.3.0` version of the PubGrub crate. **Make Rustdoc Search easier to learn** * Rustdoc will now show type signatures in the search results page, and the boxing transform behaves more like Hoogle's does. * Improvements to matching behavior have been made to fit user expectations. **Next-generation trait solver** * We stabilized `-Znext-solver=coherence` again in https://github.com/rust-lang/rust/pull/130654. It's looking like the stabilization will actually go through this time. * We're currently refactoring the way the current "typing mode" is tracked, working to fix trait-system-refactoring#106. An FCP was started to clean up the way we merge candidates when proving trait goals. **Optimizing Clippy & linting** * rust-lang/rust#125116 has been merged, marking half of the goal as formally completed. * Discussions on using `cargo cache` on CI are beginning to take form. * rust-lang/rust#125116 may be contested in results. The impact may not be as large as expected, even on Clippy. * We've been experimenting with Clippy using `rustc_driver` as a static library, instead of dynamic linking. This would be us both a way to check the performance impact of `rustc_driver` as a shared library, **and** a way to profile Clippy without filtering between `dl_*` calls. **Patterns of empty types** * The never patterns RFC was posted. * Feedback on the RFC suggests that the question of "which arms can be omitted" isn't as orthogonal as hoped, so the focus will switch to that. **Provided reasons for yanked crates** * The PR https://github.com/rust-lang/crates.io/pull/9423 has been merged. * Work is ongoing on the frontend feature. **Scalable Polonius support on nightly** * Amanda's EuroRust talk on polonius from last month is also now available on YouTube. * Implementation work continues, mostly on a branch. Major developments include a new debugger which has accelerated progress. There are about 70 test failures left to be analyzed. **Stabilize cargo-script** * rust-lang/cargo#14670 and rust-lang/cargo#14749 have been posted and merged. * rust-lang/cargo#14792 has been posted. **Stabilize parallel front end** * Still in the process of determining the cause of the deadlock through local testing and compiler code analysis. * **Help wanted:** Try to reproduce deadlocks described in the issue list. **Survey tools suitability for Std safety verification** * A new partnership between the Rust Foundation and AWS will help fund this effort. The verification challenges in the verify-rust-std fork now have financial rewards for those completing them. * **Help wanted:** Help needed to write more contracts, to integrate new tools, to review pull requests or to participate in the repository discussions. **Testing infra + contributors for a-mir-formality** * We decided to close this goal as we have not been making steady progress. We are evaluating what to propose the 2025h1 round of goals. ## Goals without updates The following goals have not received updates in the last month: **Associated type position impl trait** **Implement "merged doctests" to save doctest time** **Stabilize doc_cfg** **Use annotate-snippets for rustc diagnostic output** **User-wide build cache**

16.12.2024 00:00 — 👍 0 🔁 0 💬 0 📌 0

Launching the 2024 State of Rust Survey It’s time for the 2024 State of Rust Survey! Since 2016, the Rust Project has collected valuable information and feedback from the Rust programming language community through our annual State of Rust Survey. This tool allows us to more deeply understand how the Rust Project is performing, how we can better serve the global Rust community, and who our community is composed of. Like last year, the 2024 State of Rust Survey will likely take you between 10 and 25 minutes, and responses are anonymous. We will accept submissions until Monday, December 23rd, 2024. Trends and key insights will be shared on blog.rust-lang.org as soon as possible. We invite you to take this year’s survey whether you have just begun using Rust, you consider yourself an intermediate to advanced user, or you have not yet used Rust but intend to one day. Your responses will help us improve Rust over time by shedding light on gaps to fill in the community and development priorities, and more. **Once again, we are offering the State of Rust Survey in the following languages (if you speak multiple languages, please pick one). Language options are available on themain survey page:** * English * Simplified Chinese * French * German * Japanese * Russian * Spanish > Note: the non-English translations of the survey are provided in a best-effort manner. If you find any issues with the translations, we would be glad if you could send us a pull request to improve the quality of the translations! Please help us spread the word by sharing the survey link via your social media networks, at meetups, with colleagues, and in any other community that makes sense to you. This survey would not be possible without the time, resources, and attention of members of the Survey Working Group, the Rust Foundation, and other collaborators. We would also like to thank the following contributors who helped with translating the survey (in no particular order): * @albertlarsan68 * @GuillaumeGomez * @Urgau * @Jieyou Xu * @llogiq * @avrong * @YohDeadfall * @tanakakz * @ZuseZ4 * @igaray Thank you! If you have any questions, please see our frequently asked questions. We appreciate your participation! _Clickhere to read a summary of last year's survey findings._

05.12.2024 00:00 — 👍 0 🔁 0 💬 0 📌 0

Announcing Rust 1.83.0 The Rust team is happy to announce a new version of Rust, 1.83.0. Rust is a programming language empowering everyone to build reliable and efficient software. If you have a previous version of Rust installed via `rustup`, you can get 1.83.0 with: $ rustup update stable If you don't have it already, you can get `rustup` from the appropriate page on our website, and check out the detailed release notes for 1.83.0. If you'd like to help us out by testing future releases, you might consider updating locally to use the beta channel (`rustup default beta`) or the nightly channel (`rustup default nightly`). Please report any bugs you might come across! ## What's in 1.83.0 stable ### New const capabilities This release includes several large extensions to what code running in const contexts can do. This refers to all code that the compiler has to evaluate at compile-time: the initial value of `const` and `static` items, array lengths, enum discriminant values, const generic arguments, and functions callable from such contexts (`const fn`). **References to statics.** So far, const contexts except for the initializer expression of a `static` item were forbidden from referencing `static` items. This limitation has now been lifted: static S: i32 = 25; const C: &i32 = &S; Note, however, that reading the value of a mutable or interior mutable static is still not permitted in const contexts. Furthermore, the final value of a constant may not reference any mutable or interior mutable statics: static mut S: i32 = 0; const C1: i32 = unsafe { S }; // error: constant accesses mutable global memory const C2: &i32 = unsafe { &S }; // error: encountered reference to mutable memory in `const` These limitations ensure that constants are still "constant": the value they evaluate to, and their meaning as a pattern (which can involve dereferencing references), will be the same throughout the entire program execution. That said, a constant is permitted to evaluate to a raw pointer that points to a mutable or interior mutable static: static mut S: i32 = 64; const C: *mut i32 = &raw mut S; **Mutable references and pointers.** It is now possible to use mutable references in const contexts: const fn inc(x: &mut i32) { *x += 1; } const C: i32 = { let mut c = 41; inc(&mut c); c }; Mutable raw pointers and interior mutability are also supported: use std::cell::UnsafeCell; const C: i32 = { let c = UnsafeCell::new(41); unsafe { *c.get() += 1 }; c.into_inner() }; However, mutable references and pointers can only be used _inside_ the computation of a constant, they cannot become a part of the final value of the constant: const C: &mut i32 = &mut 4; // error[E0764]: mutable references are not allowed in the final value of constants This release also ships with a whole bag of new functions that are now stable in const contexts (see the end of the "Stabilized APIs" section). These new capabilities and stabilized APIs unblock an entire new category of code to be executed inside const contexts, and we are excited to see how the Rust ecosystem will make use of this! ### Stabilized APIs * `BufRead::skip_until` * `ControlFlow::break_value` * `ControlFlow::continue_value` * `ControlFlow::map_break` * `ControlFlow::map_continue` * `DebugList::finish_non_exhaustive` * `DebugMap::finish_non_exhaustive` * `DebugSet::finish_non_exhaustive` * `DebugTuple::finish_non_exhaustive` * `ErrorKind::ArgumentListTooLong` * `ErrorKind::Deadlock` * `ErrorKind::DirectoryNotEmpty` * `ErrorKind::ExecutableFileBusy` * `ErrorKind::FileTooLarge` * `ErrorKind::HostUnreachable` * `ErrorKind::IsADirectory` * `ErrorKind::NetworkDown` * `ErrorKind::NetworkUnreachable` * `ErrorKind::NotADirectory` * `ErrorKind::NotSeekable` * `ErrorKind::ReadOnlyFilesystem` * `ErrorKind::ResourceBusy` * `ErrorKind::StaleNetworkFileHandle` * `ErrorKind::StorageFull` * `ErrorKind::TooManyLinks` * `Option::get_or_insert_default` * `Waker::data` * `Waker::new` * `Waker::vtable` * `char::MIN` * `hash_map::Entry::insert_entry` * `hash_map::VacantEntry::insert_entry` These APIs are now stable in const contexts: * `Cell::into_inner` * `Duration::as_secs_f32` * `Duration::as_secs_f64` * `Duration::div_duration_f32` * `Duration::div_duration_f64` * `MaybeUninit::as_mut_ptr` * `NonNull::as_mut` * `NonNull::copy_from` * `NonNull::copy_from_nonoverlapping` * `NonNull::copy_to` * `NonNull::copy_to_nonoverlapping` * `NonNull::slice_from_raw_parts` * `NonNull::write` * `NonNull::write_bytes` * `NonNull::write_unaligned` * `OnceCell::into_inner` * `Option::as_mut` * `Option::expect` * `Option::replace` * `Option::take` * `Option::unwrap` * `Option::unwrap_unchecked` * `Option::<&_>::copied` * `Option::<&mut _>::copied` * `Option::<Option<_>>::flatten` * `Option::<Result<_, _>>::transpose` * `RefCell::into_inner` * `Result::as_mut` * `Result::<&_, _>::copied` * `Result::<&mut _, _>::copied` * `Result::<Option<_>, _>::transpose` * `UnsafeCell::get_mut` * `UnsafeCell::into_inner` * `array::from_mut` * `char::encode_utf8` * `{float}::classify` * `{float}::is_finite` * `{float}::is_infinite` * `{float}::is_nan` * `{float}::is_normal` * `{float}::is_sign_negative` * `{float}::is_sign_positive` * `{float}::is_subnormal` * `{float}::from_bits` * `{float}::from_be_bytes` * `{float}::from_le_bytes` * `{float}::from_ne_bytes` * `{float}::to_bits` * `{float}::to_be_bytes` * `{float}::to_le_bytes` * `{float}::to_ne_bytes` * `mem::replace` * `ptr::replace` * `ptr::slice_from_raw_parts_mut` * `ptr::write` * `ptr::write_unaligned` * `<*const _>::copy_to` * `<*const _>::copy_to_nonoverlapping` * `<*mut _>::copy_from` * `<*mut _>::copy_from_nonoverlapping` * `<*mut _>::copy_to` * `<*mut _>::copy_to_nonoverlapping` * `<*mut _>::write` * `<*mut _>::write_bytes` * `<*mut _>::write_unaligned` * `slice::from_mut` * `slice::from_raw_parts_mut` * `<[_]>::first_mut` * `<[_]>::last_mut` * `<[_]>::first_chunk_mut` * `<[_]>::last_chunk_mut` * `<[_]>::split_at_mut` * `<[_]>::split_at_mut_checked` * `<[_]>::split_at_mut_unchecked` * `<[_]>::split_first_mut` * `<[_]>::split_last_mut` * `<[_]>::split_first_chunk_mut` * `<[_]>::split_last_chunk_mut` * `str::as_bytes_mut` * `str::as_mut_ptr` * `str::from_utf8_unchecked_mut` ### Other changes Check out everything that changed in Rust, Cargo, and Clippy. ## Contributors to 1.83.0 Many people came together to create Rust 1.83.0. We couldn't have done it without all of you. Thanks!

28.11.2024 00:00 — 👍 0 🔁 0 💬 0 📌 0

Latest posts by blog.rust-lang.org.web.brid.gy on Bluesky