TL;DR: rustc will start using the LLD linker by default on the x86_64-unknown-linux-gnu target starting with the next stable release (1.90.0, scheduled for 2025-09-18), which should significantly reduce linking times.

From our prior testing, we don't really expect issues to happen in practice. It is a drop-in replacement for the vast majority of cases, but lld is not bug-for-bug compatible with GNU ld.

In any case, using rust-lld can be disabled if any problem occurs: use the -C linker-features=-lld flag to revert to using the system's default linker.

We received multiple reports of a phishing campaign targeting crates.io users (from the rustfoundation.dev domain name), mentioning a compromise of our infrastructure and asking users to authenticate to limit damage to their crates.

These emails are malicious and come from a domain name not controlled by the Rust Foundation (nor the Rust Project), seemingly with the purpose of stealing your GitHub credentials.

<...>

Do not follow any links in these emails if you receive them, and mark them as phishing with your email provider.

The users in question were immediately disabled, and the crates in question were deleted from crates.io shortly after. We have retained copies of all logs associated with the users and the malicious crate files for further analysis.

The deletion was performed at 15:34 UTC on September 24, 2025.

Why would Rust provide fetch_max as a built-in intrinsic? Intrinsics usually exist to leverage specific hardware instructions. But x86-64 doesn't have an atomic max instruction. So there had to be a CAS loop somewhere in the pipeline.

<...>

So I started digging. What I found was a fascinating journey through five distinct layers of compiler transformations, each one peeling back another level of abstraction, until I found exactly where that loop materialized. Let me share what I discovered.

Tired of manually handling unwrap() results? Let AI do the heavy lifting!

fn process_source(sources: Vec<Source>) {
    for source in sources {
        let mut buffer: Vec<&[u8]> = Vec::new();
        let data: Vec<u8> = source.fetch_data();
        buffer.extend(data.split(splitter));
        process_data(&buffer);
    }
}

error[E0597]: `data` does not live long enough
  --> src/lib.rs:32:23
   |
31 |         let data: Vec<u8> = source.fetch_data();
   |             ---- binding `data` declared here
32 |         buffer.extend(data.split(splitter));
   |         ------        ^^^^ borrowed value does not live long enough
   |         |
   |         borrow later used here
33 |         process_data(&buffer);
34 |     }
   |     - `data` dropped here while still borrowed

struct RecV1 {
    uint32_t x;
    uint32_t y;
}

struct RecV2 {
    uint32_t x;
    uint32_t y;
    uint32_t z;
}

template <typename T>
T InitRec() {
    T res;
    res.x = 1;
    res.y = 2;
    if constexpr(std::is_same_v<T, RecV2>()) {
        res.z = 3;
    }
    return res;
}

I have created a crate called fibonacci-numbers. There are 187 different major versions of the crate, each exporting the Fibonacci number corresponding to that version.
<...>
Version 186 depends on version 184 and 185 and exports the largest Fibonacci number that fits in a u128:

pub const VALUE: u128 = fib184::VALUE + fib185::VALUE;

We identified 68 prominent open source projects with C code, collected their vulnerability history data, and used their CWE designations to explore a best-case speculation on how many vulnerabilities might have been prevented with Rust. We estimate that 58.2% of historical vulnerabilities in our selection of open source C projects would have been virtually impossible in Rust.

fn f() -> *const u8 {
    let x = 0;
    &x // returns a dangling ptr to `x`
}

warning: a dangling pointer will be produced because the local variable x will be dropped
 --> src/lib.rs:3:5
  |
1 | fn f() -> *const u8 {
  |           --------- return type of the function is *const u8
2 |     let x = 0;
  |         - x is part the function and will be dropped at the end of the function
3 |     &x // returns a dangling ptr to x
  |     ^^
  |
  = note: pointers do not have a lifetime; after returning, the u8 will be deallocated at the end of the function because nothing is referencing it as far as the type system is concerned
  = note: #[warn(dangling_pointers_from_locals)] on by default

assert_eq!("foo", Path::new("foo.tar.gz").file_prefix().unwrap());
assert_eq!("foo.tar", Path::new("foo.tar.gz").file_stem().unwrap());