Rust Blog

Announcing rustup 1.29.3

2026-11-03T00:00:00+00:00

The rustup team has published a new point release of rustup, 1.29.3.

Rustup is the recommended tool to install Rust, a programming language that empowers everyone to build reliable and efficient software.

What's new in rustup 1.29.3

This new patch release has fixed some minor regressions over the previous one:

Fixed "Illegal instruction" error on certain x86_64 CPUs without SSE4.1. pr#5162
Fixed "lock() not supported" error on Solaris. pr#5167

Further details are available in the changelog!

How to update

If you have a previous version of rustup installed, getting the new one is as easy as stopping any programs which may be using rustup (e.g. closing your IDE) and running:

$ rustup self update

Rustup will also automatically update itself at the end of a normal toolchain update:

$ rustup update

For this particular release, if you have encountered any issues during self-update, you may try to update rustup manually by following the steps below:

Download the corresponding rustup-init binary for your platform.
Make double sure that no other rustup processes are running.
Replace your existing rustup binary with the downloaded rustup-init renamed to rustup.
- As a reminder, this binary is often located at $HOME/.cargo/bin/rustup, or $CARGO_HOME/bin/rustup if you have overridden the $CARGO_HOME environment variable.

If you don't have it already, you can get rustup from the appropriate page on our website.

Rustup's documentation is also available in the rustup book.

Caveats

Rustup releases can come with problems not caused by rustup itself but just due to having a new release.

In particular, anti-malware scanners might block rustup or stop it from creating or copying files, especially when installing rust-docs which contains many small files.

Issues like this should be automatically resolved in a few weeks when the anti-malware scanners are updated to be aware of the new rustup release.

Thanks

Thanks again to all the contributors who made this rustup release possible!

How to fund Rust contributors

2026-10-26T00:00:00+00:00

TLDR:

To fund general maintenance, donate to the Rust Foundation Maintainers Fund or sponsor the RustNL Maintainers Team

To fund specific features and improvements, sponsor fundable Rust Project Goals

To fund individual contributors, donate to their GitHub Sponsors accounts

There is always so much to do in the Rust Project! New features to implement, bugs to fix, performance optimizations to make, issues to triage… It takes a lot of work to keep our high bar of quality while also shipping new features and improvements. And the workload keeps increasing with the continuous growth of Rust adoption.

As is unfortunately common in open source projects, a large fraction of that work is currently done by volunteers. That causes various issues, such as people burning out or complex features taking many years to ship.

Unsurprisingly, one of the best ways to help improve that is to get more people who work on Rust funded! This year, several funding initiatives started ramping up, and we already experience many positive effects. They helped us improve the maintenance status of critical Rust projects and make significant progress on several long-awaited features, such as allocators, the never type, the next trait solver or the Polonius borrow checker. However, only a fraction of people working on Rust are currently funded for their work.

We know that there are Rust users, both individuals and companies, who would like to help improve Rust by funding it, but it might not always be obvious how exactly to do that. This post thus provides suggestions on how you can support the development of Rust in three ways.

If you're unsure which option fits, or would like to discuss funding on behalf of your company, please contact the Funding team.

Fund general maintenance

Maintenance is a continuous process required to keep Rust (or any software project for that matter) working. It consists of two main activities. The first is general housekeeping, such as ensuring that Continuous Integration works, dependencies are kept up-to-date and issues, bugs and security incidents are promptly triaged and resolved. The second is performing refactorings and code reviews, which ensures that the codebase will be able to evolve and continuously ship new features, without accruing extensive technical debt.

Having quality maintenance is crucial for the long-term health of Rust, yet it is typically very difficult to find funding for it; funders often want to sponsor specific new features, rather than just "keeping the lights on". However, without sufficient maintenance, it becomes much more difficult, and much slower, to ship new features. Improving the maintenance of Rust thus also helps us ship features and improvements faster, though the effects are sometimes only observable over longer periods of time.

Funding maintenance is a great choice if you want to let us decide how best to improve Rust. The Rust Funding team continuously looks for Rust teams and projects that require help with their maintenance efforts, and allocates available funds to Rust maintainers who could help improve the situation.

To fund Rust maintainers, consider donating to the Rust Foundation Maintainers Fund or sponsoring the RustNL Maintainers Team.

Fund specific features and improvements

There are always many Rust improvements and new features that are in progress. We track some of those initiatives through Rust Project Goals. Each Goal describes a specific improvement to Rust: what it is, who is going to develop and drive it forward and which Rust teams are willing to help reviewing and maintaining it.

Some of those Goals are looking for funding. Either to help their owner dedicate time and focus to push the given feature forward, or to fund maintainers who will perform refactorings necessary to unblock that feature and review its implementation. Often funding is required for both. When a Goal is properly funded, the probability that it will achieve its milestones is much higher, which then translates in the given improvement being shipped sooner to Rust users.

Funding Project Goals is a great choice if you want to help push forward specific Rust features or Rust toolchain improvements that will benefit you or your company.

To fund contributors working on Project Goals, consider taking a look at Goals that need funding and reaching out to their funding contact. If in doubt how to proceed, reach out to the Rust Funding team.

Fund individual contributors

There are hundreds of people in the Rust Project who continuously work on improving Rust. Some of them have personal fundraising profiles (e.g. on GitHub Sponsors), which allows you to support them directly.

There might be various reasons for supporting a specific person. Maybe they are maintaining a crate that you love to use, maybe you like reading their blog posts, or maybe you are simply a fan of the work that they do. Whatever the reason, we are sure that they would appreciate your support!

Funding individual contributors is a great choice if you want to directly support Rust contributors whose work you appreciate.

To fund individual Rust contributors, check out their GitHub profile or personal website to see what options there are for supporting them. You can also examine our list of Rust Project members who can be supported through GitHub Sponsors^[1].

Conclusion

We hope that this post is useful to anyone who would potentially like to invest funds into making Rust better. You can also find a shortened version of the "how to fund Rust guide" at the Funding page of the Rust website, or check out a RustConf 2026 talk by Niko Matsakis about how Project Goals and their funding works.

If you are a company looking to fund the development of Rust, consider joining the Rust Commercial Network. Joining the network is free, and Rust Foundation membership is not required. It can help you find opportunities for funding improvements in specific areas related to Rust usage (e.g. user interfaces, language interop, supply chain security, etc.) and collaborate on funding Rust development with other companies.

There are of course other ways of helping Rust other than donating funds. For example, you can check out Project Goals that are looking for contributors or more generally check our contributor onboarding guide. Companies can also help by giving employees paid time to contribute upstream, or by hiring Rust contributors to do that work. One possible model is the Engineer in Residence role, that was recently established in the Rust Foundation.

Note that this list is not exhaustive; there are some Project members who accept donations through GitHub Sponsors (or another fundraising platform), but did not opt into being listed on this page. ↩

Announcing rustup 1.29.2

2026-10-20T00:00:00+00:00

The rustup team is happy to announce the release of rustup version 1.29.2.

Rustup is the recommended tool to install Rust, a programming language that empowers everyone to build reliable and efficient software.

What's new in rustup 1.29.2

This is a small release which only updates the rustls-webpki and webpki-root-certs dependencies to address the problematic eMudhra intermediate certificates issue described in CVE-2026-111943.

How to update

If you have a previous version of rustup installed, getting the new one is as easy as stopping any programs which may be using rustup (e.g. closing your IDE) and running:

$ rustup self update

Rustup will also automatically update itself at the end of a normal toolchain update:

$ rustup update

If you don't have it already, you can get rustup from the appropriate page on our website.

Rustup's documentation is also available in the rustup book.

Caveats

Rustup releases can come with problems not caused by rustup itself but just due to having a new release.

In particular, anti-malware scanners might block rustup or stop it from creating or copying files, especially when installing rust-docs which contains many small files.

Issues like this should be automatically resolved in a few weeks when the anti-malware scanners are updated to be aware of the new rustup release.

Thanks

Thanks again to all the contributors who made this rustup release possible!

Announcing Rust 1.99.1

2026-10-15T00:00:00+00:00

The Rust team has published a new point release of Rust, 1.99.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.99.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.99.1

Rust 1.99.1 fixes the following regressions from prior releases:

Missing symbol wcslen: Some Rust targets were getting link errors for missing wcslen, and that function is now present in Rust's compiler-builtins library as a fallback.

The LLVM loop-idiom-wcslen pass may introduce calls to wcslen as an optimization, and some Rust targets did not have that function readily available in libc or elsewhere. The UEFI targets in particular were broken for any project using std, as some of these calls were introduced in the precompiled standard library, but the issue was also reproducible for similar user code patterns.
Miscompilation of FFI bool return values on x86_64: Rust functions returning bool through FFI could leave bits 1-7 of the return register unspecified, causing callers to observe raw values other than 0 or 1. This return type is now marked for zero-extension again, as required by the ABI.
rust-lld failed to load libLLVM on macOS: This linker could fail to run if the compiler was invoked without the rustup proxy, as there was no direct setting for the appropriate library search path. Now rust-lld is built with an rpath entry for the directory containing libLLVM.dylib.

If you'd like to help us out by testing future releases, you might consider using the beta (rustup default beta) and nightly (rustup default nightly) channels locally and in your CI. Please report any bugs you might come across!

Contributors to 1.99.1

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

Demoting i686 Windows targets to std-only

2026-10-02T00:00:00+00:00

With Rust 1.100.0, the following changes to 32-bit Windows targets will happen:

i686-pc-windows-msvc Tier 1 with host tools target will be demoted to Tier 1 without host tools.
i686-pc-windows-gnu Tier 2 with host tools target will be demoted to Tier 2 without host tools.

Builds of the standard library will continue to be distributed, but host tools such as the compiler will be no longer available. i686-pc-windows-msvc as a Tier 1 target still undergoes CI testing.

To build 32-bit Windows binaries, cross-compiling from a still-supported host toolchain (such as a 64-bit Windows ones) will be required from now on.

Background

Desktop and Server 32-bit only x86 CPUs are no longer sold for over 15 years, and general 32-bit Windows support has ended in October 2025. This means that the development platforms these targets are meant for hardly exist these days, and even if they do exist they typically aren't capable enough for development.

Even on the modern x86_64 hardware, building i686 Windows toolchains has proven to be problematic. We have encountered compiler binaries crashing when built with the i686 MSVC target, and the GNU C++ toolchain failing with OOMs during LLVM build.

Considering all these things, cross-compiling these targets from a better supported one is what we have found to be the best solution forward. As part of that, we stopped producing host tools for these targets. For the time being, the prebuilt standard library is still available, and in case of i686-pc-windows-msvc still tested on CI.

What Changes?

After Rust 1.100, it will no longer be possible to install toolchains on 32-bit Windows hosts. We recommend cross-compiling from a still-supported host (such as a 64-bit Windows toolchain) instead. Other 32-bit platforms are not impacted by this change.

For more details about these demotions, see RFC 3999 for i686-pc-windows-msvc demotion, and MCP 1020 for i686-pc-windows-gnu demotion.

Announcing Rust 1.99.0

2026-10-01T00:00:00+00:00

The Rust team is happy to announce a new version of Rust, 1.99.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.99.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.99.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.99.0 stable

extern "C" variadics

Rust 1.99.0 stabilizes defining C-ABI variadic functions with "C" and "C-unwind" ABIs. Variadic functions defined this way use a variable argument list (...) and accept an arbitrary number of arguments. Rust could already call externally-defined variadic functions (e.g., libc::printf). With Rust 1.99, these functions can now be written in Rust itself:

/// SAFETY: must be called with (at least) 2 i32 arguments.
unsafe extern "C" fn sum(mut args: ...) -> i32 {
    // SAFETY: guaranteed by the caller.
    let a = unsafe { args.next_arg::<i32>() };
    let b = unsafe { args.next_arg::<i32>() };
    a + b
}

fn foo() -> i32 {
    unsafe { sum(0i32, 2i32) }
}

The type of ... is VaList, which is ABI-compatible with the C va_list type across targets. What types can be read from a VaList is guarded by the VaArgSafe trait.

For more details on c-variadic functions, see the Reference. This release also stabilizes support for defining naked variadic functions with non-"C" ABIs, which must be written via inline assembly.

Layout information from raw pointers

This release settles the safety requirements for retrieving the size and alignment on raw pointers to both Sized (trivially safe, already possible on stable) and non-Sized types.

This is done by stabilizing three functions:

Layout::for_value_raw
mem::size_of_val_raw
mem::align_of_val_raw

Recommend against round-trip unleaking after `Box::leak`

While there are no changes to the language semantics in Rust 1.99, we have updated the documentation on Box::leak to recommend against patterns that later deallocate that memory. This was done because such code was found to have problematic interactions with current and future potential compiler optimizations, and is especially problematic with the upcoming stabilization of custom allocators. Instead, Box::into_non_null or Box::into_raw should be preferred.

This guidance also applies to other leak functions in the standard library.

Stabilized APIs

IntoIterator for Box<[T; N]>
IntoIterator for &Box<[T; N]>
IntoIterator for &mut Box<[T; N]>
VecDeque::retain_back
core::ffi::VaList
Box::into_non_null
Box::from_non_null
Vec::into_parts
Vec::from_parts
core::mem::size_of_val_raw
core::mem::align_of_val_raw
core::alloc::Layout::for_value_raw
String::from_utf8_lossy_owned
string::FromUtf8Error::into_utf8_lossy
FusedIterator for StepBy<I>
std::fs::set_times
std::fs::set_times_nofollow

Other changes

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

Contributors to 1.99.0

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

Announcing a Maintainer in Residence: Scott Schafer for the Cargo team

2026-09-22T00:00:00+00:00

At the end of August, we announced our first Maintainers in Residence, Rust Project contributors who are funded for their upstream contributions and maintenance work from the Rust Foundation Maintainers Fund (RFMF). Since then, the Rust Leadership Council has dedicated more funds from its Project Priorities budget to RFMF, and together with AWS also providing additional funds, this allowed us to open a new full-time Maintainer in Residence (MiR) position to support the Cargo team. We would like to thank the Rust Leadership Council, AWS, and also the Rust Foundation for providing us with this opportunity! If you would like to help us hire more maintainers to improve Rust, consider donating to RFMF.

This post explains why we chose to support the Cargo team specifically, and introduces Scott Schafer, the new Cargo Maintainer in Residence.

Why Cargo?

The new MiR full-time position is dedicated to helping with the maintenance of Cargo, our build system and package manager. The Cargo project is deeply involved in many new Rust features, improvements, and Project Goals. Combined with its cross-cutting nature, where it has to support many different use-cases and integrate with several other tools, it takes a lot of work just to keep up with its maintenance needs, let alone support so many feature requests and proposed changes.

Because of that, the Cargo team has sometimes struggled with meeting its maintenance demands. You might remember that for several years, it actually held a feature freeze, to reduce Cargo's internal tech debt, perform necessary refactorings, go through the issue and pull request backlog, and come up with scalable internal development and design processes, so that they could eventually go back to even thinking about adding new features.

Recently, some changes occurred within the team, which made it more difficult for them to meet their maintenance baseline. Some members of the team left, while others lost their dedicated funding for working on Cargo maintenance and had to scale down their involvement. The Funding team thus considered it very important to support this team, given that we had an opportunity to do so. And thus we decided to hire a full-time maintainer to work on Cargo for (at least) the next 12 months.

Even though we know that a single full-time maintainer will not completely solve the maintenance struggles of the Cargo team, we hope that it will improve the situation, and provide a bit of a relief for the team.

Introducing Scott Schafer

We are very happy to welcome Scott Schafer (@muscraft) into the Maintainer in Residence role! Scott has joined the Cargo team three years ago, and apart from working on Cargo, he is also the lead of the Rust Docker team, which prepares official Docker images for every Rust version.

Apart from working on general maintenance of Cargo, Scott has implemented Cargo's Workspace inheritance feature, and has also spearheaded a complex multi-year effort to switch the rendering of diagnostics in the Rust compiler to use the annotate-snippets crate. This effort has been completed in the Rust 1.93.0 release. Thanks to it, the same diagnostics interface can now be shared between the compiler and Cargo (and also other tools), which amongst other things unblocked further development of the Cargo linting system, which has now been stabilized and will ship in the Rust 1.100.0 release.

Everyone we talked about was very excited about Scott becoming a Cargo Maintainer in Residence, and we share that feeling. We wish Scott all the best in his new role, and we are very happy that we can support his maintenance work.

Here is what Scott thinks about it:

I am incredibly excited to work on Cargo full-time! There have been so many things that I wish I could've worked on over the years, that I will now be able to get to. I hope that my efforts will bring Cargo into a more maintainable state.

Conclusion

We are incredibly happy that we keep getting more funds for the Rust Foundation Maintainers Fund, which allows us to support Rust Project contributors. The funding team will be working with the supported maintainers, and also the funders, to ensure that they are all happy with the arrangement, so that we can secure stable funding for Rust maintenance for years to come.

If you would like to help us support more Rust maintainers, consider donating to RFMF!

GitHub Actions leaking secrets when Miri output is cached

2026-09-21T00:00:00+00:00

The Rust Security Response Team was notified that Miri stores all environment variables to target/, allowing secrets to persist in caches.

While not necessary a vulnerability in and of itself, when paired with GitHub Actions caching behavior, it is possible for this to expose secrets to PRs.

Overview

GitHub Actions makes it possible to cache directories between runs. Typical setups allow CI runs on main (and other branches) to write to cache, and PRs can only read from cache (preventing cache poisoning). Rust projects tend to speed up CI by caching binaries built by cargo install and sometimes the contents of target/.

PR CI can be triggered by anyone who can open PRs on your repository. GitHub requires maintainer approval for the first PR, but future PRs will rerun CI on every push. Anyone who has previously landed a change can trigger a CI run extracting information from cached target/ and then cover their tracks by pushing a second commit to the PR.

GitHub sometimes hides overwritten commits in its UI, making this kind of attack harder to detect. CI run logs and overwritten commits are also deleted after a few months.

When cargo miri is invoked, Miri needs to retain build-relevant environment variables between runs^[1]. The current code to do so achieves this by storing all environment variables to target/. This, of course, persists when target/ is cached.

If your environment contained secrets, these can now be accessed by PRs via the cache.

Our fix

Our short term fix for this is to make Miri only preserve CARGO_* environment variables (excepting CARGO_*_TOKEN) and OUT_DIR. In the longer term, Miri and cargo may figure out better ways to inform Miri of the relevant list of environment variables. Note that this patch may not be available on nightly yet.

We also performed an ecosystem scan of GitHub repositories and identified 1 repository with this issue and 7 repositories that do not appear to be vulnerable but should be cautious anyway. We have reached out to those maintainers.

Am I affected?

It is likely that our scan was imperfect, so we recommend you check your own GitHub Actions setups if you run Miri.

You are vulnerable if:

You run cargo miri in CI
The step that runs cargo miri has access to secrets as an environment variable:
- By being passed in to the step itself as an environment variable
- By being set in env for the workflow
- By being passed in to a previous step that persists it in the environment somehow
The workflow being used caches the target directory, usually done via actions/cache or swatinem/rust-cache
The cache is accessible to PRs (common and often the intended use case)

Possible quick fixes include:

Disabling cache for that job.
Scoping secrets to steps in that job that do not call Miri.
Temporarily disabling Miri.

Once done, please clear the cache. Consider rotating any secrets that might have leaked.

The Miri release in the upcoming nightly (2026-09-22) will no longer have this problem.

Even if you do not run Miri, ensure jobs that can write to public caches do not have access to secrets. Many tools do not have special handling for secrets, and assume the entire environment can be written to the filesystem.

Threat model

We consider it bad practice to have a cache that can easily be tainted by secrets.

If caching target/, it is worth making sure that the inputs to processes that create target/ (anything invoking cargo) do not have secrets available. It is generally rare for standard cargo build/test subcommands to need any secrets or tokens^[2], so this is mostly a matter of being careful about having secrets exposed as environment variables to the entire job.

Cargo/Miri/Rust does not guarantee that environment variables will be safe from being copied into target/. While we are treating this as a security issue and patching it out of an abundance of caution, this is not something you should rely on in general. Beyond official Rust tooling, it is possible for build scripts to be doing things that lead to the environment being stored in compilation artifacts.

Acknowledgements

Thanks to Predrag Gruevski of OpenAI for reporting this issue to us. Furthermore, the ecosystem scan was performed using Codex access and credits donated by OpenAI, which we also thank them for.

Issue triage and remediation was performed by Manish Goregaokar, Ralf Jung, Ben Kimock, Weihang Lo, Jacob Finkelman, Walter Pearce, Josh Stone, and Mark Rousskov.

Miri is invoked multiple times by cargo miri for complicated reasons ↩
In theory it could come up with build scripts reading from the network ↩

Be alert: targeted attacks on prominent Rustaceans

2026-09-17T00:00:00+00:00

We believe that there is an ongoing campaign targeting rust-lang members and owners of popular crates that is attempting to compromise devices and accounts in order to use them to publish malware.

What we've seen

A video call is set up for something positive — maybe for a job, maybe for a project, maybe for a contract opportunity — and then that's used as a vector to either get the target to install something on their computer (such as a purportedly missing audio codec) or execute another command (for example, via putting a command on the clipboard).

These attackers are setting up new but legitimate seeming company profiles, including plausible LinkedIn presences, in order to pass cursory inspection.

A previous attack of this form targeted many prominent Rust developers in June, and, last month, the arrayref crate was briefly compromised through similar attacks. At this moment we do not know if these are all a part of the same campaign.

This attack style is known to be used by the DPRK, and has been seen outside of the Rust community as well.

What you can do

Please take extra care in the near term. Be appropriately suspicious of cold outreaches, and ensure that any calls you have with new people are on platforms you trust — ideally, try to be the one who sets up the call on a platform you already use.

Please also re-check that your accounts look normal: MFA enabled, no unexpected logins on platforms that can track that, and so on.

If you have any concerns about your accounts, please reach out to help@crates.io (for crates.io account concerns) and/or security@rust-lang.org (for any other concerns). We're very happy to help.

Rust debugging survey 2026 results

2026-09-07T00:00:00+00:00

One of the biggest challenges Rust developers report in our annual surveys is a subpar debugging experience. So, back in February, we ran our first Rust Debugging Survey, in the hopes of identifying how Rust developers are using debuggers and what problems they are facing when doing so. We received over 2,300 responses, and we'd like to thank everyone who took the time to participate in the survey!

In this report, we'll go over some of the results of the survey. If you'd like, you can also check out the complete results of the survey.

If you'd like to skip ahead to any particular section, you can do so with this index:

Who Uses Debuggers?
How Are Debuggers Used?
Challenges
Debugger Visualizers
Closing Remarks

Who Uses Debuggers?

The first step to making sense of the survey results is understanding who took the survey. We asked respondents to rate their Rust expertise, from "Never used it" to "Advanced". Over 80% reported themselves as "Advanced" or "Intermediate", split roughly evenly between the two:

[PNG] [SVG]

We also asked respondents if they currently use or have used debuggers in Rust. Over 46% said they currently do, with the remaining responses split between "have in the past" and "never have". That means that over half of respondents do not currently use a debugger for Rust!

[PNG] [SVG]

Categorized by expertise, the responses reveal that roughly half of "beginners" have never used debuggers in Rust! On the other hand, nearly half of "advanced users" currently do use debuggers in Rust:

[PNG] [SVG]

For respondents who indicated they had previously used Rust but no longer did, we asked if challenges with debugging support were why they stopped. For nearly 3%, the answer was "yes", with an additional 24% reporting debugging issues as being partially responsible (though mind the small response count; most respondents were active users of Rust):

[PNG] [SVG]

How Are Debuggers Used?

Knowing what debuggers developers are using and how is another important part of understanding the challenges they face. To this end, we asked respondents how they were debugging their programs. Unsurprisingly, most developers make use of print debugging and the dbg! macro. Excluding those, using lldb inside an IDE was the most popular choice, followed by gdb on the command line:

[PNG] [SVG]

We can get a more detailed breakdown of these results if we include the operating system on which the respondents use a given debugging approach. We examine this from two different angles. The first angle being, "On operating system X, what percent of responses are using debugger Y?". Print debugging and the dbg! macro are consistently the top two yet again, but looking beyond that, things get more interesting. On Linux, using gdb on the command line was the most popular choice by a thin margin, beating lldb in an IDE by only 0.4%. On Windows, Windows Subsystem for Linux (WSL), and macOS, lldb in an IDE was the top pick by at least 6%, making it a very popular choice in general. On Windows, the three least popular choices were the command line debuggers (gdb CLI, lldb CLI, and BugStalker), and on both Windows and macOS the third most popular pick was, "I don't know". Those who were debugging on operating systems not listed (Other) most frequently used some kind of special embedded debugger or gdb:

[PNG] [SVG]

The other angle we can look at these responses from is, "For users of debugger X, what percent of responses are using it on operating system Y?". For most debuggers, Linux makes up the largest portion of uses, ranging from about 45% to about 77%, followed by Windows, then macOS. The most notable exceptions are WinDbg and the Visual Studio debugger, which are primarily used on Windows, and lldb, which is used more on macOS than Windows in an IDE and on the command line:

[PNG] [SVG]

To the 6 respondents who use WinDbg on Linux: we wish you luck!

As for how people actually use their debugger of choice, the aggregate results are not particularly surprising. Roughly 87% of users are using debuggers for stepping line-by-line through programs and a little over half of users are using debuggers to obtain stack traces from hung/crashed processes. Only a quarter of the respondents use a debugger to debug async code. That might be partially caused by the async Rust debugging experience being clumsy and incomplete, or it could just be that users aren't writing much async code:

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

If we break these results down by expertise, we can learn a bit more about usage patterns. As users become more experienced with Rust, their use of debuggers for learning purposes decreases, and they get more stack traces from crashed processes:

[PNG] [SVG]

The final bit of insight into how Rustaceans use debuggers is if they are debugging programs that use Rust alongside other programming languages. For 44% of respondents, the answer is "yes", which is a pretty high number!

As for which languages those are, C dominates the scene at a little over 70%, followed by C++ at about 43% and Python at about 20%:

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

Challenges

Instead of diving right into asking, "what problems do you face when using debuggers?", or something to that effect, we first asked respondents why they decide against using debuggers whenever they do, including for reasons that aren't necessarily "problems with debuggers".

The most commonly reported reason was that it was easier or faster to use logs or print debugging to solve problems, reported by a little over 81% of respondents. This could partially be explained by the open responses, which featured complaints that debuggers were too difficult to set up and/or use (especially on Windows, when dealing with Web Assembly, or in embedded contexts) and sentiment suggesting that small and/or simple problems just don't really need a debugger. It does leave one wondering if the user experience could be made convenient enough to dethrone print debugging, but it seems hard to beat something so intuitive. This is followed by roughly 37% of respondents who write code that Just Works. Fair enough. After that, about 26% of respondents indicated that they've decided not to use debuggers in situations where the language features they were working with had poor support. This is slightly more than issues with standard library types, at about 22%, which is slightly more than issues with external library types, at about 20%:

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

As stepping through code was anticipated to be one of the most common uses for debuggers, we directly asked respondents if they faced any issues when doing so. A little over 51% of respondents said they did! Of those who reported that they experienced issues stepping through code, we asked when they were experiencing issues. Async code was the most common case reported at slightly over 28%, followed by code involving macros at about 23%. The least common case reported was code involving function pointers, at almost 6%:

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

We also directly asked respondents which types in the standard library were hard to work with, if any. This was an open-response question, and reading through the responses, some particularly common complaints were with enums and collections, particularly std::collections::HashMap and std::vec::Vec. This is also visible in the word cloud in the full report.

We asked respondents to indicate which pain points, if any, they have encountered when using debuggers with Rust. At slightly over 74%, poor representation of values was the most common pain point by a decent margin, followed by being unable to print variables at just over 55%:

[PNG] [SVG]

Debugger Visualizers

We asked respondents to indicate if they were library authors, and if so, if they were aware of and using the debugger_visualizer attribute. Nearly 62% of respondents indicated that they were library authors who were not aware of this attribute:

[PNG] [SVG]

For those who indicated that they were library authors who knew about the attribute but did not use it, we also asked why. This represented a much smaller fraction of respondents, so keep that in mind! That said, half of these library authors indicated that they didn't have the time to maintain visualizer attributes, and just under half indicated they didn't know how to write visualizer scripts:

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

For those of you who have been reading this section asking yourself what the debugger_visualizer attribute is, you can read up on it in The Rust Reference: Debugger Attributes. The quick explanation is that the debugger_visualizer attribute can be applied to modules or the crate root to embed files in the debug information which improve the display of values with certain debuggers. The two currently supported file types are Natvis files, used by Microsoft debuggers such as WinDbg, and GDB "pretty printers", which are structured Python scripts used by GDB.

Closing Remarks

Thanks to your participation in this survey, we've gained some great insights about how Rustaceans are using debuggers and what issues they are facing. For example, knowing that such a high number of users are dealing with poor representation of values pairs well with knowing which standard library types are causing issues, knowing that many library authors haven't heard of the debugger_visualizer attribute, and knowing that many of those who have but don't use it either don't know how or don't have time to maintain visualizer scripts.

Looking to the future, the survey results have suggested that there are a few notable ways we could most significantly improve the debugging experience in Rust, such as:

Fixing the way enums are represented by debuggers so they show actual variants
Fixing the way collections (such as HashMap) are represented by debuggers so they show their contents, rather than their implementation details
Fixing the way string types (such as String and CString) are represented by debuggers so they render as text, rather than their implementation details
Improving the async debugging experience, particularly with stack traces
Improving stepping through certain state machines (such as iterators and Futures)
Providing documentation on basic set up and use of some common debuggers

A common suggestion that could resolve those first three points is to use the Debug implementation of types to display them in debuggers. There are challenges to that approach, such as the fact that the Debug implementation is not present in the final binary unless it is actually used somewhere in the program, but it isn't impossible. Notably, this is already supported by the BugStalker debugger (given the same condition that the Debug implementation must actually be used), which some of you first heard about from the survey! It also appears to have some support for async, with plans to expand.

One notable way the debugger experience is currently being improved is through the ongoing Google Summer of Code project improving how we test debug info and visualizer scripts, making it easier to maintain and improve our own visualizer scripts and general compatibility with visualizer scripts without silent breakage or regressions.

Once again, we'd like to thank everyone who took the time to participate in the survey!

Rust Blog

Announcing rustup 1.29.3

What's new in rustup 1.29.3

How to update

Caveats

Thanks

How to fund Rust contributors

Fund general maintenance

Fund specific features and improvements

Fund individual contributors

Conclusion

Announcing rustup 1.29.2

What's new in rustup 1.29.2

How to update

Caveats

Thanks

Announcing Rust 1.99.1

What's in 1.99.1

Contributors to 1.99.1

Demoting i686 Windows targets to std-only

Background

What Changes?

Announcing Rust 1.99.0

What's in 1.99.0 stable

extern "C" variadics

Layout information from raw pointers

Recommend against round-trip unleaking after Box::leak

Stabilized APIs

Other changes

Contributors to 1.99.0

Announcing a Maintainer in Residence: Scott Schafer for the Cargo team

Why Cargo?

Introducing Scott Schafer

Conclusion

GitHub Actions leaking secrets when Miri output is cached

Overview

Our fix

Am I affected?

Threat model

Acknowledgements

Be alert: targeted attacks on prominent Rustaceans

What we've seen

What you can do

Rust debugging survey 2026 results

Who Uses Debuggers?

How Are Debuggers Used?

Challenges

Debugger Visualizers

Closing Remarks

Recommend against round-trip unleaking after `Box::leak`