crates.io security incident: improperly stored session cookies

Today the crates.io team discovered that the contents of the cargo_sessioncookie 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 onZulip orGitHub.

Continue Reading…

crates.io security incident: improperly stored session cookies

Today the crates.io team discovered that the contents of the cargo_sessioncookie 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 onZulip orGitHub.

Continue Reading…

C ABI Changes for `wasm32-unknown-unknown`

The extern "C" ABI for the wasm32-unknown-unknown target has been using a non-standard definition since the inception of the target in that it does not implement the official C ABI of WebAssembly and it additionally leaks internal compiler implementation details of both the Rust compiler and LLVM. This will change in a future version of the Rust compiler and the official C ABI will be used instead.

This post details some history behind this change and the rationale for why it's being announced here, but you can skip straight to "Am I affected?" as well.

History of wasm32-unknown-unknown's C ABI

When the wasm32-unknown-unknown target was originally added in 2017, not much care was given to the exact definition of the extern "C" ABI at the time. In 2018 an ABI definition was added just for wasm and the target is still using this definition to this day. This definitions has become more and more problematic over time and while some issues have been fixed, the root cause still remains.

Notably this ABI definition does not match the tool-conventions definition of the C API, which is the current standard for how WebAssembly toolchains should talk to one another. Originally this non-standard definition was used for all WebAssembly based targets except Emscripten, but this changed in 2021where the WASI targets for Rust use a corrected ABI definition. Still, however, the non-standard definition remained in use for wasm32-unknown-unknown.

The time has now come to correct this historical mistake and the Rust compiler will soon be using a correct ABI definition for the wasm32-unknown-unknowntarget. This means, however, that generated WebAssembly binaries will be different than before.

What is a WebAssembly C ABI?

The definition of an ABI answers questions along the lines of:

• What registers are arguments passed in?
• What registers are results passed in?
• How is a 128-bit integers passed as an argument?
• How is a union passed as a return value?
• When are parameters passed through memory instead of registers?
• What is the size and alignment of a type in memory?

For WebAssembly these answers are a little different than native platforms. For example, WebAssembly does not have physical registers and functions must all be annotated with a type. What WebAssembly does have is types such as i32,i64, f32, and f64. This means that for WebAssembly an ABI needs to define how to represent values in these types.

This is where the tool-conventions document comes in. That document provides a definition for how to represent primitives in C in the WebAssembly format, and additionally how function signatures in C are mapped to function signatures in WebAssembly. For example a Rust u32 is represented by a WebAssembly i32 and is passed directly as a parameter as a function argument. If the Rust structure#[repr(C)] struct Pair(f32, f64) is returned from a function then a return pointer is used which must have alignment 8 and size of 16 bytes.

In essence, the WebAssembly C ABI is acting as a bridge between C's type system and the WebAssembly type system. This includes details such as in-memory layouts and translations of a C function signature to a WebAssembly function signature.

How is wasm32-unknown-unknown non-standard?

Despite the ABI definition today being non-standard, many aspects of it are still the same as what tool-conventions specifies. For example, size/alignment of types is the same as it is in C. The main difference is how function signatures are calculated. An example (where you can follow along on godbolt) is:

#[repr(C)]
pub struct Pair {
    x: u32,
    y: u32,
}

#[unsafe(no_mangle)]
pub extern "C" fn pair_add(pair: Pair) -> u32 {
    pair.x + pair.y
}

This will generate the following WebAssembly function:

(func $pair_add (param i32 i32) (result i32)
  local.get 1
  local.get 0
  i32.add
)

Notably you can see here that the struct Pair was "splatted" into its two components so the actual $pair_add function takes two arguments, the x andy fields. The tool-conventions, however specifically says that "other struct[s] or union[s]" are passed indirectly, notably through memory. We can see this by compiling this C code:

struct Pair {
    unsigned x;
    unsigned y;
};

unsigned pair_add(struct Pair pair) {
    return pair.x + pair.y;
}

which yields the generated function:

(func (param i32) (result i32)
  local.get 0
  i32.load offset=4
  local.get 0
  i32.load
  i32.add
)

Here we can see, sure enough, that pair is passed in linear memory and this function only has a single argument, not two. This argument is a pointer into linear memory which stores the x and y fields.

The Diplomat project has compiled a much more comprehensive overviewthan this and it's recommended to check that out if you're curious for an even deeper dive.

Why hasn't this been fixed long ago already?

For wasm32-unknown-unknown it was well-known at the time in 2021 when WASI's ABI was updated that the ABI was non-standard. Why then has the ABI not been fixed like with WASI? The main reason originally for this was the wasm-bindgen project.

In wasm-bindgen the goal is to make it easy to integrate Rust into a web browser with WebAssembly. JavaScript is used to interact with host APIs and the Rust module itself. Naturally, this communication touches on a lot of ABI details! The problem was that wasm-bindgen relied on the above example, specifically having Pair "splatted" across arguments instead of passed indirectly. The generated JS wouldn't work correctly if the argument was passed in-memory.

At the time this was discovered it was found to be significantly difficult to fix wasm-bindgen to not rely on this splatting behavior. At the time it also wasn't thought to be a widespread issue nor was it costly for the compiler to have a non-standard ABI. Over the years though the pressure has mounted. The Rust compiler is carrying an ever-growing list of hacks to work around the non-standard C ABI on wasm32-unknown-unknown. Additionally more projects have started to rely on this "splatting" behavior and the risk has gotten greater that there are more unknown projects relying on the non-standard behavior.

In late 2023 the wasm-bindgen project fixed bindings generation to be unaffected by the transition to the standard definition of extern "C". In the following months a future-incompat lint was added to rustc to specifically migrate users of old wasm-bindgen versions to a "fixed" version. This was in anticipation of changing the ABI of wasm32-unknown-unknown once enough time had passed. Since early 2025 users of old wasm-bindgen versions will now receive a hard error asking them to upgrade.

Despite all this heroic effort done by contributors, however, it has now come to light that there are more projects than wasm-bindgen relying on this non-standard ABI definition. Consequently this blog post is intended to serve as a notice to other users on wasm32-unknown-unknown that the ABI break is upcoming and projects may need to be changed.

Am I affected?

If you don't use the wasm32-unknown-unknown target, you are not affected by this change. If you don't use extern "C" on the wasm32-unknown-unknowntarget, you are also not affected. If you fall into this bucket, however, you may be affected!

To determine the impact to your project there are a few tools at your disposal:

• A new future-incompat warning has been added to the Rust compiler which will issue a warning if it detects a signature that will change when the ABI is changed.
• In 2023 a -Zwasm-c-abi=(legacy|spec) flag was added to the Rust compiler. This defaults to -Zwasm-c-abi=legacy, the non-standard definition. Code can use -Zwasm-c-abi=spec to use the standard definition of the C ABI for a crate to test out if changes work.

The best way to test your crate is to compile with nightly-2025-03-27or later, ensure there are no warnings, and then test your project still works with -Zwasm-c-abi=spec. If all that passes then you're good to go and the upcoming change to the C ABI will not affect your project.

I'm affected, now what?

So you're using wasm32-unknown-unknown, you're using extern "C", and the nightly compiler is giving you warnings. Additionally your project is broken when compiled with -Zwasm-c-abi=spec. What now?

At this time this will unfortunately be a somewhat rough transition period for you. There are a few options at your disposal but they all have their downsides:

1. Pin your Rust compiler version to the current stable, don't update until the ABI has changed. This means that you won't get any compiler warnings (as old compilers don't warn) and additionally you won't get broken when the ABI changes (as you're not changing compilers). Eventually when you update to a stable compiler with -Zwasm-c-abi=spec as the default you'll have to port your JS or bindings to work with the new ABI.
2. Update to Rust nightly as your compiler and pass -Zwasm-c-abi=spec. This is front-loading the work required in (1) for your target. You can get your project compatible with -Zwasm-c-abi=spec today. The downside of this approach is that your project will only work with a nightly compiler and-Zwasm-c-abi=spec and you won't be able to use stable until the default is switched.
3. Update your project to not rely on the non-standard behavior of-Zwasm-c-abi=legacy. This involves, for example, not passing structs-by-value in parameters. You can pass &Pair above, for example, instead of Pair. This is similar to (2) above where the work is done immediately to update a project but has the benefit of continuing to work on stable Rust. The downside of this, however, is that you may not be able to easily change or update your C ABI in some situations.
4. Update to Rust nightly as your compiler and pass -Zwasm-c-abi=legacy. This will silence compiler warnings for now but be aware that the ABI will still change in the future and the -Zwasm-c-abi=legacy option will be removed entirely. When the -Zwasm-c-abi=legacy option is removed the only option will be the standard C ABI, what -Zwasm-c-abi=spec today enables.

If you have uncertainties, questions, or difficulties, feel free to reach out onthe tracking issue for the future-incompat warning or on Zulip.

Timeline of ABI changes

At this time there is not an exact timeline of how the default ABI is going to change. It's expected to take on the order of 3-6 months, however, and will look something roughly like this:

• 2025 March: (soon) - a future-incompat warning will be added to the compiler to warn projects if they're affected by this ABI change.
• 2025-05-15: this future-incompat warning will reach the stable Rust channel as 1.87.0.
• 2025 Summer: (ish) - the -Zwasm-c-abi flag will be removed from the compiler and the legacy option will be entirely removed.

Exactly when -Zwasm-c-abi is removed will depend on feedback from the community and whether the future-incompat warning triggers much. It's hoped that soon after the Rust 1.87.0 is stable, though, that the old legacy ABI behavior can be removed.

Help us create a vision for Rust's future

tl;dr: Please take our survey here

Rust turns 10 this year. It's a good time to step back and assess where we are at and to get aligned around where we should be going. Where is Rust succeeding at empowering everyone to build reliable, efficient software (as it says on our webpage)? Where are there opportunities to do better? To that end, we have taken on the goal of authoring a Rust Vision RFC, with the first milestone being to prepare a draft for review at the upcoming Rust All Hands.

Goals and non-goals

The vision RFC has two goals

• to build a shared understanding of where we are and
• to identify where we should be going at a high-level.

The vision RFC also has a non-goal, which is to provide specific designs or feature recommendations. We'll have plenty of time to write detailed RFCs for that. The vision RFC will instead focus more on higher-level recommendations and on understanding what people need and want from Rust in various domains.

We hope that by answering the above questions, we will then be able to evolve Rust with more confidence. It will also help Rust users (and would-be users) to understand what Rust is for and where it is going.

Community and technology are both in scope

The scope of the vision RFC is not limited to the technical design of Rust. It will also cover topics like

• the experience of open-source maintainers and contributors, both for the Rust project and for Rust crates;
• integrating global Rust communities across the world;
• and building momentum and core libraries for particular domains, like embedded, CLI, or gamedev.

Gathering data

To answer the questions we have set, we need to gather data - we want to do our best not to speculate. This is going to come in two main formats:

1. A survey about peoples' experiences with Rust (see below). Unlike the Annual Rust survey, the questions are open-ended and free-form, and cover somewhat different topics. This also us to gather a list of people to potentially interview:
2. Interviews of people from various backgrounds and domains. In an ideal world, we would interview everyone who wants to be interviewed, but in reality we're going to try to interview as many people as we can to form a diverse and representative set.

While we have some idea of who we want to talk to, we may be missing some! We're hoping that the survey will not only help us connect to the people that we want to talk to, but also potentially help us uncover people we haven't yet thought of. We are currently planning to talk to

• Rust users, novice to expert;
• Rust non-users (considering or not);
• Companies using (or considering) Rust, from startup to enterprise;
• Global or language-based Rust affinity groups;
• Domain-specific groups;
• Crate maintainers, big and small;
• Project maintainers and contributors, volunteer or professional;
• Rust Foundation staff.

Our roadmap and timeline

Our current "end goal" is to author and open a vision RFC sometime during the second half of the year, likely in the fall. For this kind of RFC, though, the journey is really more important than the destination. We plan to author several drafts along the way and take feedback, both from Rust community members and from the public at large. The first milestone we are targeting is to prepare an initial report for review at the Rust All Hands in May. To that end, the data gathering process starts now with the survey, but we intend to spend the month of April conducting interviews (and more after that).

How you can help

For starters, fill out our survey here. This survey has three sections

1. To put the remaining responses into context, the survey asks a few demographic questions to allow us to ensure we are getting good representation across domains, experience, and backgrounds.
2. It asks a series of questions about your experiences with Rust. As mentioned before, this survey is quite different from the Annual Rust survey. If you have experiences in the context of a company or organization, please feel free to share those (submitting this separately is best)!
3. It asks for recommendations as to whom we ought to speak to. Please only recommend yourself or people/companies/groups for which you have a specific contact.

Note: The first part of the survey will only be shared publicly in aggregate, the second may be made public directly, and the third section will not be made public. For interviews, we can be more flexible with what information is shared publicly or not.

Of course, other than taking the survey, you can also share it with people. We really want to reach people that may not otherwise see it through our typical channels. So, even better if you can help us do that!

Finally, if you are active in the Rust maintainer community, feel free to join the #vision-doc-2025 channel on Zulip and say hello.

Continue Reading…

C ABI Changes for `wasm32-unknown-unknown`

The extern "C" ABI for the wasm32-unknown-unknown target has been using a non-standard definition since the inception of the target in that it does not implement the official C ABI of WebAssembly and it additionally leaks internal compiler implementation details of both the Rust compiler and LLVM. This will change in a future version of the Rust compiler and the official C ABI will be used instead.

This post details some history behind this change and the rationale for why it's being announced here, but you can skip straight to "Am I affected?" as well.

History of wasm32-unknown-unknown's C ABI

When the wasm32-unknown-unknown target was originally added in 2017, not much care was given to the exact definition of the extern "C" ABI at the time. In 2018 an ABI definition was added just for wasm and the target is still using this definition to this day. This definitions has become more and more problematic over time and while some issues have been fixed, the root cause still remains.

Notably this ABI definition does not match the tool-conventions definition of the C API, which is the current standard for how WebAssembly toolchains should talk to one another. Originally this non-standard definition was used for all WebAssembly based targets except Emscripten, but this changed in 2021where the WASI targets for Rust use a corrected ABI definition. Still, however, the non-standard definition remained in use for wasm32-unknown-unknown.

The time has now come to correct this historical mistake and the Rust compiler will soon be using a correct ABI definition for the wasm32-unknown-unknowntarget. This means, however, that generated WebAssembly binaries will be different than before.

What is a WebAssembly C ABI?

The definition of an ABI answers questions along the lines of:

• What registers are arguments passed in?
• What registers are results passed in?
• How is a 128-bit integers passed as an argument?
• How is a union passed as a return value?
• When are parameters passed through memory instead of registers?
• What is the size and alignment of a type in memory?

For WebAssembly these answers are a little different than native platforms. For example, WebAssembly does not have physical registers and functions must all be annotated with a type. What WebAssembly does have is types such as i32,i64, f32, and f64. This means that for WebAssembly an ABI needs to define how to represent values in these types.

This is where the tool-conventions document comes in. That document provides a definition for how to represent primitives in C in the WebAssembly format, and additionally how function signatures in C are mapped to function signatures in WebAssembly. For example a Rust u32 is represented by a WebAssembly i32 and is passed directly as a parameter as a function argument. If the Rust structure#[repr(C)] struct Pair(f32, f64) is returned from a function then a return pointer is used which must have alignment 8 and size of 16 bytes.

In essence, the WebAssembly C ABI is acting as a bridge between C's type system and the WebAssembly type system. This includes details such as in-memory layouts and translations of a C function signature to a WebAssembly function signature.

How is wasm32-unknown-unknown non-standard?

Despite the ABI definition today being non-standard, many aspects of it are still the same as what tool-conventions specifies. For example, size/alignment of types is the same as it is in C. The main difference is how function signatures are calculated. An example (where you can follow along on godbolt) is:

#[repr(C)]
pub struct Pair {
    x: u32,
    y: u32,
}

#[unsafe(no_mangle)]
pub extern "C" fn pair_add(pair: Pair) -> u32 {
    pair.x + pair.y
}

This will generate the following WebAssembly function:

(func $pair_add (param i32 i32) (result i32)
  local.get 1
  local.get 0
  i32.add
)

Notably you can see here that the struct Pair was "splatted" into its two components so the actual $pair_add function takes two arguments, the x andy fields. The tool-conventions, however specifically says that "other struct[s] or union[s]" are passed indirectly, notably through memory. We can see this by compiling this C code:

struct Pair {
    unsigned x;
    unsigned y;
};

unsigned pair_add(struct Pair pair) {
    return pair.x + pair.y;
}

which yields the generated function:

(func (param i32) (result i32)
  local.get 0
  i32.load offset=4
  local.get 0
  i32.load
  i32.add
)

Here we can see, sure enough, that pair is passed in linear memory and this function only has a single argument, not two. This argument is a pointer into linear memory which stores the x and y fields.

The Diplomat project has compiled a much more comprehensive overviewthan this and it's recommended to check that out if you're curious for an even deeper dive.

Why hasn't this been fixed long ago already?

For wasm32-unknown-unknown it was well-known at the time in 2021 when WASI's ABI was updated that the ABI was non-standard. Why then has the ABI not been fixed like with WASI? The main reason originally for this was the wasm-bindgen project.

In wasm-bindgen the goal is to make it easy to integrate Rust into a web browser with WebAssembly. JavaScript is used to interact with host APIs and the Rust module itself. Naturally, this communication touches on a lot of ABI details! The problem was that wasm-bindgen relied on the above example, specifically having Pair "splatted" across arguments instead of passed indirectly. The generated JS wouldn't work correctly if the argument was passed in-memory.

At the time this was discovered it was found to be significantly difficult to fix wasm-bindgen to not rely on this splatting behavior. At the time it also wasn't thought to be a widespread issue nor was it costly for the compiler to have a non-standard ABI. Over the years though the pressure has mounted. The Rust compiler is carrying an ever-growing list of hacks to work around the non-standard C ABI on wasm32-unknown-unknown. Additionally more projects have started to rely on this "splatting" behavior and the risk has gotten greater that there are more unknown projects relying on the non-standard behavior.

In late 2023 the wasm-bindgen project fixed bindings generation to be unaffected by the transition to the standard definition of extern "C". In the following months a future-incompat lint was added to rustc to specifically migrate users of old wasm-bindgen versions to a "fixed" version. This was in anticipation of changing the ABI of wasm32-unknown-unknown once enough time had passed. Since early 2025 users of old wasm-bindgen versions will now receive a hard error asking them to upgrade.

Despite all this heroic effort done by contributors, however, it has now come to light that there are more projects than wasm-bindgen relying on this non-standard ABI definition. Consequently this blog post is intended to serve as a notice to other users on wasm32-unknown-unknown that the ABI break is upcoming and projects may need to be changed.

Am I affected?

If you don't use the wasm32-unknown-unknown target, you are not affected by this change. If you don't use extern "C" on the wasm32-unknown-unknowntarget, you are also not affected. If you fall into this bucket, however, you may be affected!

To determine the impact to your project there are a few tools at your disposal:

• A new future-incompat warning has been added to the Rust compiler which will issue a warning if it detects a signature that will change when the ABI is changed.
• In 2023 a -Zwasm-c-abi=(legacy|spec) flag was added to the Rust compiler. This defaults to -Zwasm-c-abi=legacy, the non-standard definition. Code can use -Zwasm-c-abi=spec to use the standard definition of the C ABI for a crate to test out if changes work.

The best way to test your crate is to compile with nightly-2025-03-27or later, ensure there are no warnings, and then test your project still works with -Zwasm-c-abi=spec. If all that passes then you're good to go and the upcoming change to the C ABI will not affect your project.

I'm affected, now what?

So you're using wasm32-unknown-unknown, you're using extern "C", and the nightly compiler is giving you warnings. Additionally your project is broken when compiled with -Zwasm-c-abi=spec. What now?

At this time this will unfortunately be a somewhat rough transition period for you. There are a few options at your disposal but they all have their downsides:

1. Pin your Rust compiler version to the current stable, don't update until the ABI has changed. This means that you won't get any compiler warnings (as old compilers don't warn) and additionally you won't get broken when the ABI changes (as you're not changing compilers). Eventually when you update to a stable compiler with -Zwasm-c-abi=spec as the default you'll have to port your JS or bindings to work with the new ABI.
2. Update to Rust nightly as your compiler and pass -Zwasm-c-abi=spec. This is front-loading the work required in (1) for your target. You can get your project compatible with -Zwasm-c-abi=spec today. The downside of this approach is that your project will only work with a nightly compiler and-Zwasm-c-abi=spec and you won't be able to use stable until the default is switched.
3. Update your project to not rely on the non-standard behavior of-Zwasm-c-abi=legacy. This involves, for example, not passing structs-by-value in parameters. You can pass &Pair above, for example, instead of Pair. This is similar to (2) above where the work is done immediately to update a project but has the benefit of continuing to work on stable Rust. The downside of this, however, is that you may not be able to easily change or update your C ABI in some situations.
4. Update to Rust nightly as your compiler and pass -Zwasm-c-abi=legacy. This will silence compiler warnings for now but be aware that the ABI will still change in the future and the -Zwasm-c-abi=legacy option will be removed entirely. When the -Zwasm-c-abi=legacy option is removed the only option will be the standard C ABI, what -Zwasm-c-abi=spec today enables.

If you have uncertainties, questions, or difficulties, feel free to reach out onthe tracking issue for the future-incompat warning or on Zulip.

Timeline of ABI changes

At this time there is not an exact timeline of how the default ABI is going to change. It's expected to take on the order of 3-6 months, however, and will look something roughly like this:

• 2025 March: (soon) - a future-incompat warning will be added to the compiler to warn projects if they're affected by this ABI change.
• 2025-05-15: this future-incompat warning will reach the stable Rust channel as 1.87.0.
• 2025 Summer: (ish) - the -Zwasm-c-abi flag will be removed from the compiler and the legacy option will be entirely removed.

Exactly when -Zwasm-c-abi is removed will depend on feedback from the community and whether the future-incompat warning triggers much. It's hoped that soon after the Rust 1.87.0 is stable, though, that the old legacy ABI behavior can be removed.

Continue Reading…

Help us create a vision for Rust's future

tl;dr: Please take our survey here

Rust turns 10 this year. It's a good time to step back and assess where we are at and to get aligned around where we should be going. Where is Rust succeeding at empowering everyone to build reliable, efficient software (as it says on our webpage)? Where are there opportunities to do better? To that end, we have taken on the goal of authoring a Rust Vision RFC, with the first milestone being to prepare a draft for review at the upcoming Rust All Hands.

Goals and non-goals

The vision RFC has two goals

• to build a shared understanding of where we are and
• to identify where we should be going at a high-level.

The vision RFC also has a non-goal, which is to provide specific designs or feature recommendations. We'll have plenty of time to write detailed RFCs for that. The vision RFC will instead focus more on higher-level recommendations and on understanding what people need and want from Rust in various domains.

We hope that by answering the above questions, we will then be able to evolve Rust with more confidence. It will also help Rust users (and would-be users) to understand what Rust is for and where it is going.

Community and technology are both in scope

The scope of the vision RFC is not limited to the technical design of Rust. It will also cover topics like

• the experience of open-source maintainers and contributors, both for the Rust project and for Rust crates;
• integrating global Rust communities across the world;
• and building momentum and core libraries for particular domains, like embedded, CLI, or gamedev.

Gathering data

To answer the questions we have set, we need to gather data - we want to do our best not to speculate. This is going to come in two main formats:

1. A survey about peoples' experiences with Rust (see below). Unlike the Annual Rust survey, the questions are open-ended and free-form, and cover somewhat different topics. This also allows us to gather a list of people to potentially interview.
2. Interviews of people from various backgrounds and domains. In an ideal world, we would interview everyone who wants to be interviewed, but in reality we're going to try to interview as many people as we can to form a diverse and representative set.

While we have some idea of who we want to talk to, we may be missing some! We're hoping that the survey will not only help us connect to the people that we want to talk to, but also potentially help us uncover people we haven't yet thought of. We are currently planning to talk to

• Rust users, novice to expert;
• Rust non-users (considering or not);
• Companies using (or considering) Rust, from startup to enterprise;
• Global or language-based Rust affinity groups;
• Domain-specific groups;
• Crate maintainers, big and small;
• Project maintainers and contributors, volunteer or professional;
• Rust Foundation staff.

Our roadmap and timeline

Our current "end goal" is to author and open a vision RFC sometime during the second half of the year, likely in the fall. For this kind of RFC, though, the journey is really more important than the destination. We plan to author several drafts along the way and take feedback, both from Rust community members and from the public at large. The first milestone we are targeting is to prepare an initial report for review at the Rust All Hands in May. To that end, the data gathering process starts now with the survey, but we intend to spend the month of April conducting interviews (and more after that).

How you can help

For starters, fill out our survey here. This survey has three sections

1. To put the remaining responses into context, the survey asks a few demographic questions to allow us to ensure we are getting good representation across domains, experience, and backgrounds.
2. It asks a series of questions about your experiences with Rust. As mentioned before, this survey is quite different from the Annual Rust survey. If you have experiences in the context of a company or organization, please feel free to share those (submitting this separately is best)!
3. It asks for recommendations as to whom we ought to speak to. Please only recommend yourself or people/companies/groups for which you have a specific contact.

Note: The first part of the survey will only be shared publicly in aggregate, the second may be made public directly, and the third section will not be made public. For interviews, we can be more flexible with what information is shared publicly or not.

Of course, other than taking the survey, you can also share it with people. We really want to reach people that may not otherwise see it through our typical channels. So, even better if you can help us do that!

Finally, if you are active in the Rust maintainer community, feel free to join the #vision-doc-2025 channel on Zulip and say hello.

Continue Reading…

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.

HashMaps 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!

Continue Reading…

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.

HashMaps 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 callers 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 `bar`
    // 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!

Continue Reading…

Adopting the FLS

Adopting the FLS

Some years ago, Ferrous Systems assembled a description of Rust called the FLS1. They've 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 the gracious donation of the FLS by Ferrous Systems. We're grateful to them for the work they've done in assembling the FLS, in making it 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 the FLS 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 and donation 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. ↩

Continue Reading…

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. ↩

Continue Reading…

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!

Continue Reading…

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!

Continue Reading…

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_INSTALLenvironment 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.

Continue Reading…

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_INSTALLenvironment 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.

Continue Reading…

Rust participates in Google Summer of Code 2025

We are happy to announce that the Rust Project will again be participating in Google Summer of Code (GSoC) 2025, same as last year. If you're not eligible or interested in participating in GSoC, then most of this post likely isn't relevant to you; if you are, this should contain some useful information and links.

Google Summer of Code (GSoC) is an annual global program organized by Google that aims to bring new contributors to the world of open-source. The program pairs organizations (such as the Rust Project) with contributors (usually students), with the goal of helping the participants make meaningful open-source contributions under the guidance of experienced mentors.

The organizations that have been accepted into the program have been announced by Google. The GSoC applicants now have several weeks to discuss project ideas with mentors. Later, they will send project proposals for the projects that they found the most interesting. If their project proposal is accepted, they will embark on a several month journey during which they will try to complete their proposed project under the guidance of an assigned mentor.

We have prepared a list of project ideas that can serve as inspiration for potential GSoC contributors that would like to send a project proposal to the Rust organization. However, applicants can also come up with their own project ideas. You can discuss project ideas or try to find mentors in the #gsoc Zulip stream. We have also prepared a proposal guide that should help you with preparing your project proposals.

You can start discussing the project ideas with Rust Project mentors and maintainers immediately, but you might want to keep the following important dates in mind:

• The project proposal application period starts on March 24, 2025. From that date you can submit project proposals into the GSoC dashboard.
• The project proposal application period ends on April 8, 2025 at 18:00 UTC. Take note of that deadline, as there will be no extensions!

If you are interested in contributing to the Rust Project, we encourage you to check out our project idea list and send us a GSoC project proposal! Of course, you are also free to discuss these projects and/or try to move them forward even if you do not intend to (or cannot) participate in GSoC. We welcome all contributors to Rust, as there is always enough work to do.

Last year was our first time participating in GSoC, and it was a success! This year we are very excited to participate again. We hope that participants in the program can improve their skills, but also would love for this to bring new contributors to the Project and increase the awareness of Rust in general. Like last year, we expect to publish blog posts in the future with updates about our participation in the program.

Continue Reading…

Rust participates in Google Summer of Code 2025

We are happy to announce that the Rust Project will again be participating in Google Summer of Code (GSoC) 2025, same as last year. If you're not eligible or interested in participating in GSoC, then most of this post likely isn't relevant to you; if you are, this should contain some useful information and links.

Google Summer of Code (GSoC) is an annual global program organized by Google that aims to bring new contributors to the world of open-source. The program pairs organizations (such as the Rust Project) with contributors (usually students), with the goal of helping the participants make meaningful open-source contributions under the guidance of experienced mentors.

The organizations that have been accepted into the program have been announced by Google. The GSoC applicants now have several weeks to discuss project ideas with mentors. Later, they will send project proposals for the projects that they found the most interesting. If their project proposal is accepted, they will embark on a several month journey during which they will try to complete their proposed project under the guidance of an assigned mentor.

We have prepared a list of project ideas that can serve as inspiration for potential GSoC contributors that would like to send a project proposal to the Rust organization. However, applicants can also come up with their own project ideas. You can discuss project ideas or try to find mentors in the #gsoc Zulip stream. We have also prepared a proposal guide that should help you with preparing your project proposals.

You can start discussing the project ideas with Rust Project mentors and maintainers immediately, but you might want to keep the following important dates in mind:

• The project proposal application period starts on March 24, 2025. From that date you can submit project proposals into the GSoC dashboard.
• The project proposal application period ends on April 8, 2025 at 18:00 UTC. Take note of that deadline, as there will be no extensions!

If you are interested in contributing to the Rust Project, we encourage you to check out our project idea list and send us a GSoC project proposal! Of course, you are also free to discuss these projects and/or try to move them forward even if you do not intend to (or cannot) participate in GSoC. We welcome all contributors to Rust, as there is always enough work to do.

Last year was our first time participating in GSoC, and it was a success! This year we are very excited to participate again. We hope that participants in the program can improve their skills, but also would love for this to bring new contributors to the Project and increase the awareness of Rust in general. Like last year, we expect to publish blog posts in the future with updates about our participation in the program.

Continue Reading…

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!

Continue Reading…

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 generaltransitioning 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
• ::recip
• ::to_degrees
• ::to_radians
• ::max
• ::min
• ::clamp
• ::abs
• ::signum
• ::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!

Continue Reading…

2024 State of Rust Survey Results

Hello, Rustaceans!

The Rust Survey Team is excited to share the results of our 2024 survey on the Rust Programming language, conducted between December 5, 2024 and December 23, 2024. As in previous years, the 2024 State of Rust Survey was focused on gathering insights and feedback from Rust users, and all those who are interested in the future of Rust more generally.

This ninth edition of the survey surfaced new insights and learning opportunities straight from the global Rust language community, which we will summarize below. In addition to this blog post, we have also prepared a report containing charts with aggregated results of all questions in the survey.

Our sincerest thanks to every community member who took the time to express their opinions and experiences with Rust over the past year. Your participation will help us make Rust better for everyone.

There's a lot of data to go through, so strap in and enjoy!

Participation

| Survey | Started | Completed | Completion rate | Views | | ---------- | ----------- | ------------- | ------------------- | --------- | | 2023 | 11 950 | 9 710 | 82.2% | 16 028 | | 2024 | 9 450 | 7 310 | 77.4% | 13 564 |

As shown above, in 2024, we have received fewer survey views than in the previous year. This was likely caused simply by the fact that the survey ran only for two weeks, while in the previous year it ran for almost a month. However, the completion rate has also dropped, which seems to suggest that the survey might be a bit too long. We will take this into consideration for the next edition of the survey.

Community

The State of Rust survey not only gives us excellent insight into how many Rust users around the world are using and experiencing the language but also gives us insight into the makeup of our global community. This information gives us a sense of where the language is being used and where access gaps might exist for us to address over time. We hope that this data and our related analysis help further important discussions about how we can continue to prioritize global access and inclusivity in the Rust community.

Same as every year, we asked our respondents in which country they live in. The top 10 countries represented were, in order: United States (22%), Germany (14%), United Kingdom (6%), France (6%), China (5%), Canada (3%), Netherlands (3%), Russia (3%), Australia (2%), and Sweden (2%). We are happy to see that Rust is enjoyed by users from all around the world! You can try to find your country in the chart below:

[PNG] [SVG]

We also asked whether respondents consider themselves members of a marginalized community. Out of those who answered, 74.5% selected no, 15.5% selected yes, and 10% preferred not to say.

We have asked the group that selected “yes” which specific groups they identified as being a member of. The majority of those who consider themselves a member of an underrepresented or marginalized group in technology identify as lesbian, gay, bisexual, or otherwise non-heterosexual. The second most selected option was neurodivergent at 46% followed by trans at 35%.

[PNG] [SVG]

Each year, we must acknowledge the diversity, equity, and inclusivity (DEI) related gaps in the Rust community and open source as a whole. We believe that excellent work is underway at the Rust Foundation to advance global access to Rust community gatherings and distribute grants to a diverse pool of maintainers each cycle, which you can learn more about here. Even so, global inclusion and access is just one element of DEI, and the survey working group will continue to advocate for progress in this domain.

Rust usage

The number of respondents that self-identify as a Rust user was quite similar to last year, around 92%. This high number is not surprising, since we primarily target existing Rust developers with this survey.

[PNG] [SVG]

Similarly as last year, around 31% of those who did not identify as Rust users cited the perception of difficulty as the primary reason for not using Rust. The most common reason for not using Rust was that the respondents simply haven’t had the chance to try it yet.

[PNG] [SVG] [Wordcloud of open answers]

Of the former Rust users who participated in the 2024 survey, 36% cited factors outside their control as a reason why they no longer use Rust, which is a 10pp decrease from last year. This year, we also asked respondents if they would consider using Rust again if an opportunity comes up, which turns out to be true for a large fraction of the respondents (63%). That is good to hear!

[PNG] [SVG] [Wordcloud of open answers]

Closed answers marked with N/A were not present in the previous version(s) of the survey.

Those not using Rust anymore told us that it is because they don't really need it (or the goals of their company changed) or because it was not the right tool for the job. A few reported being overwhelmed by the language or its ecosystem in general or that switching to or introducing Rust would have been too expensive in terms of human effort.

Of those who used Rust in 2024, 53% did so on a daily (or nearly daily) basis — an increase of 4pp from the previous year. We can observe an upward trend in the frequency of Rust usage over the past few years, which suggests that Rust is being increasingly used at work. This is also confirmed by other answers mentioned in the Rust at Work section later below.

[PNG] [SVG]

Rust expertise is also continually increasing amongst our respondents! 20% of respondents can write (only) simple programs in Rust (a decrease of 3pp from 2023), while 53% consider themselves productive using Rust — up from 47% in 2023. While the survey is just one tool to measure the changes in Rust expertise overall, these numbers are heartening as they represent knowledge growth for many Rustaceans returning to the survey year over year.

[PNG] [SVG]

Unsurprisingly, the most popular version of Rust is latest stable, either the most recent one or whichever comes with the users' Linux distribution. Almost a third of users also use the latest nightly release, due to various reasons (see below). However, it seems that the beta toolchain is not used much, which is a bit unfortunate. We would like to encourage Rust users to use the beta toolchain more (e.g. in CI environments) to help test soon-to-be stabilized versions of Rust.

[PNG] [SVG] [Wordcloud of open answers]

People that use the nightly toolchain mostly do it to gain access to specific unstable language features. Several users have also mentioned that rustfmt works better for them on nightly or that they use the nightly compiler because of faster compilation times.

[PNG] [SVG] [Wordcloud of open answers]

Learning Rust

To use Rust, programmers first have to learn it, so we are always interested in finding out how do they approach that. Based on the survey results, it seems that most users learn from Rust documentation and also from The Rust Programming Language book, which has been a favourite learning resource of new Rustaceans for a long time. Many people also seem to learn by reading the source code of Rust crates. The fact that both the documentation and source code of tens of thousands of Rust crates is available on docs.rs and GitHub makes this easier.

[PNG] [SVG] [Wordcloud of open answers]

In terms of answers belonging to the "Other" category, they can be clustered into three categories: people using LLM (large language model) assistants (Copilot, ChatGPT, Claude, etc.), reading the official Rust forums (Discord, URLO) or being mentored while contributing to Rust projects. We would like to extend a big thank you to those making our spaces friendly and welcoming for newcomers, as it is important work and it pays off. Interestingly, a non-trivial number of people "learned by doing" and used rustc error messages and clippy as a guide, which is a good indicator of the quality of Rust diagnostics.

In terms of formal education, it seems that Rust has not yet penetrated university curriculums, as this is typically a very slowly moving area. Only a very small number of respondents (around 3%) have taken a university Rust course or used university learning materials.

[PNG] [SVG]

Programming environment

In terms of operating systems used by Rustaceans, Linux was the most popular choice, and it seems that it is getting increasingly popular year after year. It is followed by macOS and Windows, which have a very similar share of usage.

[PNG] [SVG] [Wordcloud of open answers]

As you can see in the wordcloud, there are also a few users that prefer Arch, btw.

Rust programmers target a diverse set of platforms with their Rust programs. We saw a slight uptick in users targeting embedded and mobile platforms, but otherwise the distribution of platforms stayed mostly the same as last year. Since the WebAssembly target is quite diverse, we have split it into two separate categories this time. Based on the results it is clear that when using WebAssembly, it is mostly in the context of browsers (23%) rather than other use-cases (7%).

[PNG] [SVG] [Wordcloud of open answers]

We cannot of course forget the favourite topic of many programmers: which IDE (developer environment) they use. Although Visual Studio Code still remains the most popular option, its share has dropped by 5pp this year. On the other hand, the Zed editor seems to have gained considerable traction recently. The small percentage of those who selected "Other" are using a wide range of different tools: from CursorAI to classics like Kate or Notepad++. Special mention to the 3 people using "ed", that's quite an achievement.

[PNG] [SVG] [Wordcloud of open answers]

You can also take a look at the linked wordcloud that summarizes open answers to this question (the "Other" category), to see what other editors are also popular.

Rust at Work

We were excited to see that more and more people use Rust at work for the majority of their coding, 38% vs 34% from last year. There is a clear upward trend in this metric over the past few years.

[PNG] [SVG]

The usage of Rust within companies also seems to be rising, as 45% of respondents answered that their organisation makes non-trivial use of Rust, which is a 7pp increase from 2023.

[PNG] [SVG]

Once again, the top reason employers of our survey respondents invested in Rust was the ability to build relatively correct and bug-free software. The second most popular reason was Rust’s performance characteristics. 21% of respondents that use Rust at work do so because they already know it, and it's thus their default choice, an uptick of 5pp from 2023. This seems to suggest that Rust is becoming one of the baseline languages of choice for more and more companies.

[PNG] [SVG]

Similarly to the previous year, a large percentage of respondents (82%) report that Rust helped their company achieve its goals. In general, it seems that programmers and companies are quite happy with their usage of Rust, which is great!

[PNG] [SVG]

In terms of technology domains, the situation is quite similar to the previous year. Rust seems to be especially popular for creating server backends, web and networking services and cloud technologies. It also seems to be gaining more traction for embedded use-cases.

[PNG] [SVG] [Wordcloud of open answers]

You can scroll the chart to the right to see more domains. Note that the Automotive domain was not offered as a closed answer in the 2023 survey (it was merely entered through open answers), which might explain the large jump.

It is exciting to see the continued growth of professional Rust usage and the confidence so many users feel in its performance, control, security and safety, enjoyability, and more!

Challenges

As always, one of the main goals of the State of Rust survey is to shed light on challenges, concerns, and priorities on Rustaceans’ minds over the past year.

We have asked our users about aspects of Rust that limit their productivity. Perhaps unsurprisingly, slow compilation was at the top of the list, as it seems to be a perennial concern of Rust users. As always, there are efforts underway to improve the speed of the compiler, such as enabling the parallel frontend or switching to a faster linker by default. We invite you to test these improvements and let us know if you encounter any issues.

Other challenges included subpar support for debugging Rust and high disk usage of Rust compiler artifacts. On the other hand, most Rust users seem to be very happy with its runtime performance, the correctness and stability of the compiler and also Rust's documentation.

[PNG] [SVG] [Wordcloud of open answers]

In terms of specific unstable (or missing) features that Rust users want to be stabilized (or implemented), the most desired ones were async closures and if/let while chains. Well, we have good news! Async closures will be stabilized in the next version of Rust (1.85), and if/let while chains will hopefully follow soon after, once Edition 2024 is released (which will also happen in Rust 1.85).

Other coveted features are generators (both sync and async) and more powerful generic const expressions. You can follow the Rust Project Goals to track the progress of these (and other) features.

[PNG] [SVG] [Wordcloud of open answers]

In the open answers to this question, people were really helpful and tried hard to describe the most notable issues limiting their productivity. We have seen mentions of struggles with async programming (an all-time favourite), debuggability of errors (which people generally love, but they are not perfect for everyone) or Rust tooling being slow or resource intensive (rust-analyzer and rustfmt). Some users also want a better IDE story and improved interoperability with other languages.

This year, we have also included a new question about the speed of Rust's evolution. While most people seem to be content with the status quo, more than a quarter of people who responded to this question would like Rust to stabilize and/or add features more quickly, and only 7% of respondents would prefer Rust to slow down or completely stop adding new features.

[PNG] [SVG]

Interestingly, when we asked respondents about their main worries for the future of Rust, one of the top answers remained the worry that Rust will become too complex. This seems to be in contrast with the answers to the previous question. Perhaps Rust users still seem to consider the complexity of Rust to be manageable, but they worry that one day it might become too much.

We are happy to see that the amount of respondents concerned about Rust Project governance and lacking support of the Rust Foundation has dropped by about 6pp from 2023.

[PNG] [SVG] [Wordcloud of open answers]

Looking ahead

Each year, the results of the State of Rust survey help reveal the areas that need improvement in many areas across the Rust Project and ecosystem, as well as the aspects that are working well for our community.

If you have any suggestions for the Rust Annual survey, please let us know!

We are immensely grateful to those who participated in the 2024 State of Rust Survey and facilitated its creation. While there are always challenges associated with developing and maintaining a programming language, this year we were pleased to see a high level of survey participation and candid feedback that will truly help us make Rust work better for everyone.

If you’d like to dig into more details, we recommend you to browse through the full survey report.

Continue Reading…

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!

Continue Reading…

Rust Blog updated their profile.

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!

Continue Reading…

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 dynosaur1 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. ↩

Continue Reading…

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.

Continue Reading…

Announcing Rust 1.84.0

The Rust team is happy to announce a new version of Rust, 1.84.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.84.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.84.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.84.0 stable

Cargo considers Rust versions for dependency version selection

1.84.0 stabilizes the minimum supported Rust version (MSRV) aware resolver, which prefers dependency versions compatible with the project's declaredMSRV. With MSRV-aware version selection, the toil is reduced for maintainers to support older toolchains by not needing to manually select older versions for each dependency.

You can opt-in to the MSRV-aware resolver via .cargo/config.toml:

[resolver]
incompatible-rust-versions = "fallback"

Then when adding a dependency:

$ cargo add clap
    Updating crates.io index
warning: ignoring clap@4.5.23 (which requires rustc 1.74) to maintain demo's rust-version of 1.60
      Adding clap v4.0.32 to dependencies
    Updating crates.io index
     Locking 33 packages to latest Rust 1.60 compatible versions
      Adding clap v4.0.32 (available: v4.5.23, requires Rust 1.74)

When verifying the latest dependencies in CI, you can override this:

$ CARGO_RESOLVER_INCOMPATIBLE_RUST_VERSIONS=allow cargo update
    Updating crates.io index
     Locking 12 packages to latest compatible versions
    Updating clap v4.0.32 -> v4.5.23

You can also opt-in by setting package.resolver = "3" in the Cargo.toml manifest file though that will require raising your MSRV to 1.84. The new resolver will be enabled by default for projects using the 2024 edition (which will stabilize in 1.85).

This gives library authors more flexibility when deciding their policy on adopting new Rust toolchain features. Previously, a library adopting features from a new Rust toolchain would force downstream users of that library who have an older Rust version to either upgrade their toolchain or manually select an old version of the library compatible with their toolchain (and avoid running cargo update). Now, those users will be able to automatically use older library versions compatible with their older toolchain.

See the documentation for more considerations when deciding on an MSRV policy.

Migration to the new trait solver begins

The Rust compiler is in the process of moving to a new implementation for the trait solver. The next-generation trait solver is a reimplementation of a core component of Rust's type system. It is not only responsible for checking whether trait-bounds - e.g. Vec<T>: Clone - hold, but is also used by many other parts of the type system, such as normalization - figuring out the underlying type of <Vec<T> as IntoIterator>::Item - and equating types (checking whether T and U are the same).

In 1.84, the new solver is used for checking coherence of trait impls. At a high level, coherence is responsible for ensuring that there is at most one implementation of a trait for a given type while considering not yet written or visible code from other crates.

This stabilization fixes a few mostly theoretical correctness issues of the old implementation, resulting in potential "conflicting implementations of trait ..." errors that were not previously reported. We expect the affected patterns to be very rare based on evaluation of available code through Crater. The stabilization also improves our ability to prove that impls do not overlap, allowing more code to be written in some cases.

For more details, see a previous blog postand the stabilization report.

Strict provenance APIs

In Rust, pointers are not simply an "integer" or "address". For instance, a "use after free" is undefined behavior even if you "get lucky" and the freed memory gets reallocated before your read/write. As another example, writing through a pointer derived from an &i32 reference is undefined behavior, even if writing to the same address via a different pointer is legal. The underlying pattern here is that the way a pointer is computed matters, not just the address that results from this computation. For this reason, we say that pointers have provenance: to fully characterize pointer-related undefined behavior in Rust, we have to know not only the address the pointer points to, but also track which other pointer(s) it is "derived from".

Most of the time, programmers do not need to worry much about provenance, and it is very clear how a pointer got derived. However, when casting pointers to integers and back, the provenance of the resulting pointer is underspecified. With this release, Rust is adding a set of APIs that can in many cases replace the use of integer-pointer-casts, and therefore avoid the ambiguities inherent to such casts. In particular, the pattern of using the lowest bits of an aligned pointer to store extra information can now be implemented without ever casting a pointer to an integer or back. This makes the code easier to reason about, easier to analyze for the compiler, and also benefits tools likeMiri and architectures likeCHERI that aim to detect and diagnose pointer misuse.

For more details, see the standard library documentation on provenance.

Stabilized APIs

• Ipv6Addr::is_unique_local
• Ipv6Addr::is_unicast_link_local
• core::ptr::with_exposed_provenance
• core::ptr::with_exposed_provenance_mut
• ::addr
• ::expose_provenance
• ::with_addr
• ::map_addr
• ::isqrt
• ::checked_isqrt
• ::isqrt
• NonZero::isqrt
• core::ptr::without_provenance
• core::ptr::without_provenance_mut
• core::ptr::dangling
• core::ptr::dangling_mut
• Pin::as_deref_mut

These APIs are now stable in const contexts

• AtomicBool::from_ptr
• AtomicPtr::from_ptr
• AtomicU8::from_ptr
• AtomicU16::from_ptr
• AtomicU32::from_ptr
• AtomicU64::from_ptr
• AtomicUsize::from_ptr
• AtomicI8::from_ptr
• AtomicI16::from_ptr
• AtomicI32::from_ptr
• AtomicI64::from_ptr
• AtomicIsize::from_ptr
• ::is_null
• ::as_ref
• ::as_mut
• Pin::new
• Pin::new_unchecked
• Pin::get_ref
• Pin::into_ref
• Pin::get_mut
• Pin::get_unchecked_mut
• Pin::static_ref
• Pin::static_mut

Other changes

Check out everything that changed in Rust, Cargo, and Clippy.

Contributors to 1.84.0

Many people came together to create Rust 1.84.0. We couldn't have done it without all of you. Thanks!

Continue Reading…

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

Continue Reading…

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 the main 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!

Click here to read a summary of last year's survey findings.

Continue Reading…

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!

Continue Reading…

Rust 2024 call for testing

Rust 2024 call for testing

We've been hard at work on Rust 2024. We're thrilled about how it has turned out. It's going to be the largest edition since Rust 2015. 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.

As planned, we recently merged the feature-complete Rust 2024 edition to the release train for Rust 1.85. It has now entered nightly beta1.

You can help right now to make this edition a success by testing Rust 2024 on your own projects using nightly Rust. Migrating your projects to the new edition is straightforward and mostly automated. Here's how:

1. Install the most recent nightly with rustup update nightly.
2. In your project, run cargo +nightly fix --edition.
3. Edit Cargo.toml and change the edition field to say edition = "2024" and, if you have a rust-version specified, set rust-version = "1.85".
4. Run cargo +nightly check to verify your project now works in the new edition.
5. Run some tests, and try out the new features!

(More details on how to migrate can be found here and within each of the chapters describing the changes in Rust 2024.)

If you encounter any problems or see areas where we could make the experience better, tell us about it by filing an issue.

Coming next

Rust 2024 will enter the beta channel on 2025-01-09, and will be released to stable Rust with Rust 1.85 on 2025-02-20.

1. That is, it's still in nightly (not in the beta channel), but the edition items are frozen in a way similar to it being in the beta channel, and as with any beta, we'd like wide testing. ↩

Continue Reading…

The wasm32-wasip2 Target Has Reached Tier 2 Support

Introduction

In April of this year we posted an update about Rust's WASI targetsto the main Rust blog. In it we covered the rename of the wasm32-wasi target to wasm32-wasip1, and the introduction of the new wasm32-wasip2 target as a "tier 3" target. This meant that while the target was available as part ofrust-lang/rustc, it was not guaranteed to build. We're pleased to announce that this has changed in Rust 1.82.

For those unfamiliar with WebAssembly (Wasm) components and WASI 0.2, here is a quick, simplified primer:

• Wasm is a (virtual) instruction format for programs to be compiled into (think: x86).
• Wasm Components are a container format and type system that wrap Core Wasm instructions into typed, hermetic binaries and libraries (think: ELF).
• WASI is a reserved namespace for a collection of standardized Wasm component interfaces (think: POSIX header files).

For a more detailed explanation see the WASI 0.2 announcement post on the Bytecode Alliance blog.

What's new?

Starting Rust 1.82 (2024-10-17) the wasm32-wasip2 (WASI 0.2) target has reached tier-2 platform support in the Rust compiler. Among other things this now means it is guaranteed to build, and is now available to install via Rustup using the following command:

rustup target add wasm32-wasip2

Up until now Rust users writing Wasm Components would always have to rely on tools (such ascargo-component) which target the WASI 0.1 target (wasm32-wasip1) and package it into a WASI 0.2 Component via a post-processing step invoked. Now that wasm32-wasip2 is available to everyone via Rustup, tooling can begin to directly target WASI 0.2 without the need for additional post-processing.

What this also means is that ecosystem crates can begin targeting WASI 0.2 directly for platform-specific code. WASI 0.1 did not have support for sockets. Now that we have a stable tier 2 platform available, crate authors should be able to finally start writing WASI-compatible network code. To target WASI 0.2 from Rust, authors can use the following cfg attribute:

#[cfg(all(target_os = "wasi", target_env = "p2"))]
mod wasip2 {
    // items go here
}

To target the older WASI 0.1 target, Rust also accepts target_env = "p1".

Standard Library Support

The WASI 0.2 Rust target reaching tier 2 platform support is in a way just the beginning. means it's supported and stable. While the platform itself is now stable, support in the stdlib for WASI 0.2 APIs is still limited. While the WASI 0.2 specification specifies APIs for example for timers, files, and sockets - if you try and use the stdlib APIs for these today, you'll find they don't yet work.

We expect to gradually extend the Rust stdlib with support for WASI 0.2 APIs throughout the remainder of this year into the next. That work has already started, withrust-lang/rust#129638 adding native support for std::net in Rust 1.83. We expect more of these PRs to land through the remainder of the year.

Though this doesn't need to stop users from using WASI 0.2 today. The stdlib is great because it provides portable abstractions, usually built on top of an operating system's libc or equivalent. If you want to use WASI 0.2 APIs directly today, you can either use thewasi crate directly. Or generate your own WASI bindings from the WASI specification's interface types using wit-bindgen.

Conclusion

The wasm32-wasip2 target is now installable via Rustup. This makes it possible for the Rust compiler to directly compile to the Wasm Components format targeting the WASI 0.2 interfaces. There is now also a way for crates to compile add WASI 0.2 platform support by writing:

#[cfg(all(target_os = "wasi", target_env = "p2"))]
mod wasip2 {}

We're excited for Wasm Components and WASI 0.2 to have reached this milestone within the Rust project, and are excited to see what folks in the community will be building with it!

Continue Reading…