The Rust Project is currently working towards a slate of 40 project goals, with 3 of them designated 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.

This is the final update for the first half of 2025. We’re in the process of selecting goals for the second half of the year.

Here are the goals that are currently proposed for 2025H2.

Flagship goals

Why this goal? This work continues our drive to improve support for async programming in Rust. In 2024H2 we stabilized async closures; explored the generator design space; and began work on the dynosaur crate, an experimental proc-macro to provide dynamic dispatch for async functions in traits. In 2025H1 our plan is to deliver (1) improved support for async-fn-in-traits, completely subsuming the functionality of the async-trait crate; (2) progress towards sync and async generators, simplifying the creation of iterators and async data streams; (3) and improve the ergonomics of Pin, making lower-level async coding more approachable. These items together start to unblock the creation of the next generation of async libraries in the wider ecosystem, as progress there has been blocked on a stable solution for async traits and streams.

H1 Recap from @tmandry:

What went well: This cycle we saw significant progress in a few areas:

• We had productive conversations with the language team on generators, and landed an experimental implementation for a builtin iter! macro that implements unpinned generators.
• We shipped async closures and the new lifetime capture rules as part of Rust 2024.
• We developed a proc macro, dynosaur, that can be used to support async fn together with dyn Trait.
• We landed an early-stage experiment to support async Drop in the compiler.
• We landed an experimental implementation of autoreborrowing for pinned references, along with a number of other improvements for pin ergonomics. What didn’t: In some areas, we didn’t make as much progress as we hoped. In retrospect, the scope of this goal was too large for one person to manage. With flagship project goals, there this a desire to paint a grand vision that I think would be better served by another mechanism without a time bound on it. I’ve been calling this a “north star”.

In some cases, like RTN, progress has been by technical debt in the Rust compiler’s type system. For that there is an ongoing project goal to replace the trait solver with a next-generation version. Finally, on the design front, progress is sometimes slowed by uncertainty and disagreement around the future of pinning in the Rust language.

Looking forward: My takeaway from this is that in the next project goals cycle, we should focus on answering more fundamental questions of Rust’s evolution. These should reduce uncertainty and pave the way for us to unblock major features for async in future cycles. For example, how far we can push pin ergonomics? What approach should we take for in-place initialization, and can it support async fn in dyn Trait? How will we support evolving trait hierarchies in a general way that allows us to support the Tower “middleware” pattern with async fn?

I’m excited by the lineup of goals we have for this next cycle. See you on the other side!

2 detailed updates available. Comment by @tmandry posted on 2025-07-17:

dynosaur v0.3 has been released. This release contains some breaking changes in preparation for an upcoming 1.0 release. See the linked release notes for more details.

Comment by @tmandry posted on 2025-07-30:

H1 Recap

What went well: This cycle we saw significant progress in a few areas:

• We had productive conversations with the language team on generators, and landed an experimental implementation for a builtin iter! macro that implements unpinned generators.
• We shipped async closures and the new lifetime capture rules as part of Rust 2024.
• We developed a proc macro, dynosaur, that can be used to support async fn together with dyn Trait.
• We landed an early-stage experiment to support async Drop in the compiler.
• We landed an experimental implementation of autoreborrowing for pinned references, along with a number of other improvements for pin ergonomics. What didn’t: In some areas, we didn’t make as much progress as we hoped. In retrospect, the scope of this goal was too large for one person to manage. With flagship project goals, there this a desire to paint a grand vision that I think would be better served by another mechanism without a time bound on it. I’ve been calling this a “north star”.

In some cases, like RTN, progress has been by technical debt in the Rust compiler’s type system. For that there is an ongoing project goal to replace the trait solver with a next-generation version. Finally, on the design front, progress is sometimes slowed by uncertainty and disagreement around the future of pinning in the Rust language.

Looking forward: My takeaway from this is that in the next project goals cycle, we should focus on answering more fundamental questions of Rust’s evolution. These should reduce uncertainty and pave the way for us to unblock major features for async in future cycles. For example, how far we can push pin ergonomics? What approach should we take for in-place initialization, and can it support async fn in dyn Trait? How will we support evolving trait hierarchies in a general way that allows us to support the Tower “middleware” pattern with async fn?

I’m excited by the lineup of goals we have for this next cycle. See you on the other side!

Why this goal? May 15, 2025 marks the 10-year anniversary of Rust’s 1.0 release; it also marks 10 years since the creation of the Rust subteams. At the time there were 6 Rust teams with 24 people in total. There are now 57 teams with 166 people. In-person All Hands meetings are an effective way to help these maintainers get to know one another with high-bandwidth discussions. This year, the Rust Project will be coming together for RustWeek 2025, a joint event organized with RustNL. Participating project teams will use the time to share knowledge, make plans, or just get to know one another better. One particular goal for the All Hands is reviewing a draft of the Rust Vision Doc, a document that aims to take stock of where Rust is and lay out high-level goals for the next few years.

Why this goal? This goal continues our work from 2024H2 in supporting the experimental support for Rust development in the Linux kernel. Whereas in 2024H2 we were focused on stabilizing required language features, our focus in 2025H1 is stabilizing compiler flags and tooling options. We will (1) implement RFC #3716 which lays out a design for ABI-modifying flags; (2) take the first step towards stabilizing build-std by creating a stable way to rebuild core with specific compiler options; (3) extending rustdoc, clippy, and the compiler with features that extract metadata for integration into other build systems (in this case, the kernel’s build system).

What has happened?

• Ding opened a PR#142518 that implements the in-place initialization experiment.
• Ding is working on an experimental implementation (PR#143527) for arbitrary_self_types.
• Ding opened a PR to Clang (a C frontend for LLVM): Queries on GCC-style inline assembly statements and got it merged.
• @ojeda opened two Rust for Linux goals for the next period:
• https://github.com/rust-lang/rust-project-goals/pull/347
• https://github.com/rust-lang/rust-project-goals/pull/346 2 detailed updates available. Comment by @tomassedovic posted on 2025-07-07:

In-place initialization

Ding opened a PR#142518 that implements the in-place initialization experiment.

arbitrary_self_types

Ding is working on an experimental implementation (PR#143527).

Queries on GCC-style inline assembly statements:

Ding opened a PR to Clang (a C frontend for LLVM): https://github.com/llvm/llvm-project/pull/143424 and got it merged.

This is part of the LLVM/Clang issues the Rust for Linux project needs: https://github.com/Rust-for-Linux/linux/issues/1132.

-Zindirect-branch-cs-prefix:

We’ve discussed whether this needs to be a separate target feature vs. a modifier on the existing retpoline one. Josh argued that since having this enabled without retpoline doesn’t make sense, it should be a modifier. On the other hand, Miguel mentioned that it would be clearer on the user’s side (easier to map the names from GCC and Clang to rustc when they’re the same and see that we’re enabling the same thing in Rust and Linux kernel’s Makefiles).

It seems that -Cmin-function-alignment will be another similar case.

Ultimately, this is a compiler question and should be resolved here: https://github.com/rust-lang/rust/pull/140740

The Rust for Linux team was asked to submit a new MCP (Major Change Proposal) for the -Zindirect-branch-cs-prefix flag. @ojeda opened it here: https://github.com/rust-lang/compiler-team/issues/899 and it’s now been accepted.

Stabilizing AddressSanitizer and LeakSanitizer:

• https://github.com/rust-lang/rust/pull/123617
• https://github.com/rust-lang/rust/pull/142681 In light of the newly-proposed #[sanitize(xyz = "on|off")] syntax, we’ve discussed whether it makes sense to add a shorthand to enable/disable all of them at once (e.g. #[sanitize(all = "on|off")]). The experience from the field suggests that this is rarely something people do.

We’ve also discussed what values should the options have (e.g. "yes"/"no" vs. "on"/"off" or true/false). No strong preferences, but in case of an error, the compiler should suggest the correct value to use.

P.S.: There will be a Lang design meeting regarding in-place initialization on Wednesday 2025-07-30: https://github.com/rust-lang/lang-team/issues/332.

Comment by @tomassedovic posted on 2025-07-18:

2025H2 Goals

@ojeda proposed two goals to move the effort forward: one for the language and the other for the compiler.

• https://github.com/rust-lang/rust-project-goals/pull/347
• https://github.com/rust-lang/rust-project-goals/pull/346

Ongoing work updates

@dingxiangfei2009 drafted a Pre-RFC for the supertrait-item-in-subtrait-impl work. Need to add two modifications to the RFC to incorporate t-lang requests.

Goals looking for help

Help wanted: Help test the deadlock code in the issue list and try to reproduce the issue

1 detailed update available. Comment by @SparrowLii posted on 2025-07-11:

• Key developments: We bring rustc-rayon in rustc’s working tree, the PR that fixes several deadlock issues has been merged.
• Blockers: null
• Help wanted: Help test the deadlock code in the issue list and try to reproduce the issue

Help wanted: this project goal needs a compiler developer to move forward.

3 detailed updates available. Comment by @epage posted on 2025-07-10:

Help wanted: this project goal needs a compiler developer to move forward.

Comment by @sladyn98 posted on 2025-07-11:

@epage hey i would like to help contribute with this, if you could probably mentor me in the right direction, i could learn and ramp up and move this forward, i could start with some tasks, scope them out into small bite sized chunks and contribute

Comment by @epage posted on 2025-07-11:

This is mostly in the compiler atm and I’m not in a position to mentor or review compiler changes; my first compiler PR is being merged right now. I’m mostly on this from the Cargo side and overall coordination.

Help wanted: I’ll be working towards verifying rustfmt, rust-analyzer, and other tooling support and will be needing at least reviews from people, if not some mentorship.

1 detailed update available. Comment by @epage posted on 2025-07-10:

Key developments:

• @epage is shifting attention back to this now that toml v0.9 is out
• -Zunpretty support is being added in rust-lang/rust#143708 Blockers

Help wanted

• I’ll be working towards verifying rustfmt, rust-analyzer, and other tooling support and will be needing at least reviews from people, if not some mentorship.

Other goal updates

1 detailed update available. Comment by @BoxyUwU posted on 2025-07-25:

Not much to say since the last update- I have been focused on other areas of const generics and I believe camelid has been relatively busy with other things too. I intend for the next const generics project goal to be more broadly scoped than just min_generic_const_args so that other const generics work can be given a summary here :)

• Discussed the latest round of feedback on the pre-RFC, the most significant of which is that the scope of the RFC is almost certainly too large for an MVP.
• @davidtwco presented a reformulation of the plan which focuses on the core components of build-std and leaves more features for future extensions after a minimal MVP:
• Stage 1a: Introduce manual controls for enabling the build-std behavior in Cargo.
• Stage 1b: Introduce Cargo syntax to declare explicit dependencies on core, alloc and std crates.
• This stage enables the use of Tier 3 targets on stable Rust and allows the ecosystem to start transitioning to explicit dependencies on the standard library.
• This stage would be considered the minimal MVP.
• Stage 2: Teach Cargo to build std with different codegen/target modifier options.
• This stage allows the standard library to be compiled with custom codegen options.
• Stage 3: Enable automatic standard library rebuilds.
• This stage focuses on making build-std behave ergonomically and naturally without users having to manually ask for the standard library to be built.
• General consensus was reached that this plan feels viable. @davidtwco will write the Stage 1a/b RFC.
• Submitted a 2025H2 goal proposal 2 detailed updates available. Comment by @wesleywiser posted on 2025-07-22:

• Updates from our biweekly sync call:
  • Discussed the latest round of feedback on the pre-RFC, the most significant of which is that the scope of the RFC is almost certainly too large for an MVP.
  • @davidtwco presented a reformulation of the plan which focuses on the core components of build-std and leaves more features for future extensions after a minimal MVP:
    • Stage 1a: Introduce manual controls for enabling the build-std behavior in Cargo.
    • Stage 1b: Introduce Cargo syntax to declare explicit dependencies on core, alloc and std crates.
      • This stage enables the use of Tier 3 targets on stable Rust and allows the ecosystem to start transitioning to explicit dependencies on the standard library.
      • This stage would be considered the minimal MVP.
    • Stage 2: Teach Cargo to build std with different codegen/target modifier options.
      • This stage allows the standard library to be compiled with custom codegen options.
    • Stage 3: Enable automatic standard library rebuilds.
      • This stage focuses on making build-std behave ergonomically and naturally without users having to manually ask for the standard library to be built.
  • General consensus was reached that this plan feels viable. @davidtwco will write the Stage 1a/b RFC.
  • Some discussion on various threads from the previous RFC draft.

Comment by @wesleywiser posted on 2025-07-28:

Continuing the build-std work has been submitted as a Project Goal for 2025H2: https://rust-lang.github.io/rust-project-goals/2025h2/build-std.html

Belated update for May and June: RustWeek was extremely productive! It was great to sit down in a room with all the stakeholders and talk about what it would take to get cross-crate linting working reliably at scale.

As a result of this work we identified a lot of previously-unknown blockers, as well as some paths forward. More work remains, but it’s nice that we now have a much better idea of what that work should look like.

TL;DR:

• ?Sized linting is blocked since it requires additional data in rustdoc JSON.
• Currently we get information on the syntactic presence of ?Sized. But another bound might be implying Sized, which makes ?Sized not true overall.
• Failing to account for this would mean we get both false negatives and false positives. This is effectively a dual of the the “implied bounds” issue in the previous post.
• Cross-crate linting has had some positive movement, and some additional blockers identified.
• docs.rs has begun hosting rustdoc JSON, allowing us to use it as a cache to avoid rebuilding rustdoc JSON in cross-crate linting scenarios where those builds could get expensive.
• We need a way to determine which features in dependencies are active (recursively) given a set of features active in the the top crate, so we know how to generate accurate rustdoc JSON. That information is not currently available via the lockfile or any cargo interface.
• We need to work with the rustdoc and cargo teams to make it possible to use rmeta files to correctly combine data across crates. This has many moving parts and will take time to get right, but based on in-person conversations at RustWeek we all agreed was the best and most reliable path forward.
• Other improvements to cargo-semver-checks are ongoing: a full set of #[target_feature] lints ships in the next release, and two folks participating in Google Summer of Code have begun contributing to cargo-semver-checks already! While the targets for the 2025H1 goals proved a bit too ambitious to hit in this timeline, I’m looking forward to continuing my work on the goal in the 2025H2 period!

1 detailed update available. Comment by @obi1kenobi posted on 2025-07-04:

Belated update for May and June: RustWeek was extremely productive! It was great to sit down in a room with all the stakeholders and talk about what it would take to get cross-crate linting working reliably at scale.

As a result of this work we identified a lot of previously-unknown blockers, as well as some paths forward. More work remains, but it’s nice that we now have a much better idea of what that work should look like.

TL;DR:

• ?Sized linting is blocked since it requires additional data in rustdoc JSON.
  • Currently we get information on the syntactic presence of ?Sized. But another bound might be implying Sized, which makes ?Sized not true overall.
  • Failing to account for this would mean we get both false negatives and false positives. This is effectively a dual of the the “implied bounds” issue in the previous post.
• Cross-crate linting has had some positive movement, and some additional blockers identified.
  • docs.rs has begun hosting rustdoc JSON, allowing us to use it as a cache to avoid rebuilding rustdoc JSON in cross-crate linting scenarios where those builds could get expensive.
  • We need a way to determine which features in dependencies are active (recursively) given a set of features active in the the top crate, so we know how to generate accurate rustdoc JSON. That information is not currently available via the lockfile or any cargo interface.
  • We need to work with the rustdoc and cargo teams to make it possible to use rmeta files to correctly combine data across crates. This has many moving parts and will take time to get right, but based on in-person conversations at RustWeek we all agreed was the best and most reliable path forward.
• Other improvements to cargo-semver-checks are ongoing: a full set of #[target_feature] lints ships in the next release, and two folks participating in Google Summer of Code have begun contributing to cargo-semver-checks already! While the targets for the 2025H1 goals proved a bit too ambitious to hit in this timeline, I’m looking forward to continuing my work on the goal in the 2025H2 period!

Current status:

• @joshtriplett authored RFCs for both attribute macros and derive macros.
• After some further iteration with the lang team, both RFCs were accepted and merged.
• @joshtriplett, @eholk, and @vincenzopalazzo did some successful group-spelunking into the implementation of macros in rustc.
• @joshtriplett rewrote the macro_rules! parser, which enabled future extensibility and resulted in better error messages. This then enabled several follow-up refactors and simplifications.
• @joshtriplett wrote a PR implementing attribute macros. 2 detailed updates available. Comment by @joshtriplett posted on 2025-07-21:

Current status:

• @joshtriplett authored RFCs for both attribute macros and derive macros. Both were accepted and merged.
• @joshtriplett, @eholk, and @vincenzopalazzo did some successful group-spelunking into the implementation of macros in rustc.
• @joshtriplett rewrote the macro_rules! parser, which enabled future extensibility and resulted in better error messages. This then enabled several follow-up refactors and simplifications.
• @joshtriplett wrote a PR implementing attribute macros (review in progress).

Comment by @joshtriplett posted on 2025-07-29:

Update: Implementation PR for attribute macros is up.

Recap by @tmandry:

This project goals cycle was important for C++ interop. With the language team we established that we should evolve Rust to enable a first-class C++ interop story, making rich and automatic bindings possible between the two languages. At the Rust All Hands, people from across the industry met to describe their needs to each other, what is working for them, and what isn’t. This process of discovery has led to a lot of insight into where we can make progress now and ideas for what it will take to really “solve” interop.

One thing I think we can say with certainty is that interop is a vast problem space, and that any two groups who want interop are very likely to have different specific needs. I’m excited about the project goal proposal by @baumanj to begin mapping this problem space out in the open, so that as we refer to problems we can better understand where our needs overlap and diverge.

Despite the diversity of needs, we’ve noticed that there is quite a bit of overlap when it comes to language evolution. This includes many features requested by Rust for Linux, a flagship customer of the Rust Project. In retrospect, this is not surprising: Rust for Linux needs fine-grained interop with C APIs, which is roughly a subset of the needs for interop with C++ APIs. Often the need runs deeper than interop, and is more about supporting patterns in Rust that existing systems languages already support as a first-class feature.

I’m looking forward to tackling areas where we can “extend the fundamentals” of Rust in a way that makes these, and other use cases, possible. This includes H2 project goal proposals like pin ergonomics, reborrowing, field projections, and in-place initialization.

Thanks to everyone who contributed to the discussions this past cycle. Looking forward to seeing you in the next one!

2 detailed updates available. Comment by @tmandry posted on 2025-07-29:

Ahead of the all hands, @cramertj and @tmandry collaborated on a prototype called ecdysis that explored the viability of instantiating types “on-demand” in the Rust compiler. These types are intended to look like C++ template instantiations. The prototype was a success in that it made the direction look viable and also surfaced some foundational work that needs to happen in the compiler first. That said, continuing to pursue it is not the highest priority for either of us at the moment.

Many thanks to @oli-obk for their advice and pointers.

Comment by @tmandry posted on 2025-07-29:

Recap

This project goals cycle was important for C++ interop. With the language team we established that we should evolve Rust to enable a first-class C++ interop story, making rich and automatic bindings possible between the two languages. At the Rust All Hands, people from across the industry met to describe their needs to each other, what is working for them, and what isn’t. This process of discovery has led to a lot of insight into where we can make progress now and ideas for what it will take to really “solve” interop.

One thing I think we can say with certainty is that interop is a vast problem space, and that any two groups who want interop are very likely to have different specific needs. I’m excited about the project goal proposal by @baumanj to begin mapping this problem space out in the open, so that as we refer to problems we can better understand where our needs overlap and diverge.

Despite the diversity of needs, we’ve noticed that there is quite a bit of overlap when it comes to language evolution. This includes many features requested by Rust for Linux, a flagship customer of the Rust Project. In retrospect, this is not surprising: Rust for Linux needs fine-grained interop with C APIs, which is roughly a subset of the needs for interop with C++ APIs. Often the need runs deeper than interop, and is more about supporting patterns in Rust that existing systems languages already support as a first-class feature.

I’m looking forward to tackling areas where we can “extend the fundamentals” of Rust in a way that makes these, and other use cases, possible. This includes H2 project goal proposals like pin ergonomics, reborrowing, field projections, and in-place initialization.

Thanks to everyone who contributed to the discussions this past cycle. Looking forward to seeing you in the next one!

1 detailed update available. Comment by @spastorino posted on 2025-06-30:

We’re currently working on the last-use optimization. We’ve the liveness analysis needed implemented and we need to extensively test it.

@ZuseZ4:

The last update for this project-goal period! I have continued to work on the gpu support, while our two Rust/LLVM autodiff gsoc students made great progress with their corresponding projects.

Key developments:

My memory-movement PR got reviewed and after a few iterations landed in nightly. That means you now don’t even have to build your own rustc to move data to and from a GPU (with the limitations mentioned in my previous post). As part of my PR, I also updated the rustc-dev-guide: https://rustc-dev-guide.rust-lang.org/offload/installation.html. 1. Now that the host (CPU) code landed, I looked into compiling rust kernels to GPUs. When experimenting with the amdgcn target for rustc I noticed a regression, due to which all examples for that target failed. I submitted a small patch to fix it. It landed a few days ago, and prevents rustc from generating f128 types on AMD GPUs: https://github.com/rust-lang/rust/pull/144383. 1. I looked into HIP and OpenMP (managed/kernel-mode) examples to see what’s needed to launch the kernels. I should already have most of the code upstream, since it landed as part of my host PR, so I think I should soon be able to add the remaining glue code to start running Rust code on GPUs. https://github.com/rust-lang/rust/pull/142696. 1. The main PR of @KMJ-007 is up, to start generating typetrees for Enzyme, the backend of our std::autodiff module. Enzyme sometimes wants more information about a type than it can get from LLVM, so it either needs to deduce it (slow), or it will fail to compile (bad). In the future we hope to lower MIR information to Enzyme, and this is the first step for it. I just submitted the first round of reviews: https://github.com/rust-lang/rust/pull/142640 1. The main PR of @Sa4dUs is up, it replaces my historically grown middle-end with a proper rustc-autodiff-intrinsic. This allows us to remove a few hacks and thus makes it easier to maintain. It will also handle more corner-cases, and reduces the amount of autodiff related code in rustc by ~400 lines. I also gave it a first review pass. I also submitted an updated project-goal to finish the std::offload module, to the point where we can write an interesting amount of kernels in pure (nightly) Rust and launch them to GPUs. All new project goals are supposed to have “champions” from the teams they are related to, which in the case of my autodiff/batching/offload work would be t-compiler and t-lang (see Niko’s blog post for more details). Since I joined the compiler team a while ago I can now champion for it myself on the compiler side, and @traviscross volunteered to continue the support on the language side, thank you!

1 detailed update available. Comment by @ZuseZ4 posted on 2025-07-30:

The last update for this project-goal period! I have continued to work on the gpu support, while our two Rust/LLVM autodiff gsoc students made great progress with their corresponding projects.

Key developments:

My memory-movement PR got reviewed and after a few iterations landed in nightly. That means you can now don’t even have to build your own rustc to move data to and from a GPU (with the limitations mentioned in my previous post). As part of my PR, I also updated the rustc-dev-guide: https://rustc-dev-guide.rust-lang.org/offload/installation.html 1. Now that the host (CPU) code landed, I looked into compiling rust kernels to GPUs. When experimenting with the amdgcn target for rustc I noticed a regression, due to which all examples for that target failed. I submitted a small patch to fix it. It landed a few days ago, and prevents rustc from generating f128 types on AMD GPUs: https://github.com/rust-lang/rust/pull/144383 1. I looked into HIP and OpenMP (managed/kernel-mode) examples to see what’s needed to launch the kernels. I should already have most of the code upstream, since it landed as part of my host PR, so I think I should soon be able to add the remaining glue code to start running Rust code on GPUs. https://github.com/rust-lang/rust/pull/142696. 1. The main PR of @KMJ-007 is up, to start generating typetrees for Enzyme, the backend of our std::autodiff module. Enzyme sometimes wants more information about a type than it can get from LLVM, so it either needs to deduce it (slow), or it will fail to compile (bad). In the future we hope to lower MIR information to Enzyme, and this is the first step for it. I just submitted the first round of reviews: https://github.com/rust-lang/rust/pull/142640 1. The main PR of @Sa4dUs is up, it replaces my historically grown middle-end with a proper rustc-autodiff-intrinsic. This allows us to remove a few hacks and thus makes it easier to maintain. It will also handle more corner-cases, and reduces the amount of autodiff related code in rustc by ~400 lines. I also gave it a first review pass. I also submitted an updated project-goal to finish the std::offload module, to the point where we can write an interesting amount of kernels in pure (nightly) Rust and launch them to GPUs. All new project goals are supposed to have “champions” from the teams they are related to, which in the case of my autodiff/batching/offload work would be t-compiler and t-lang (see Niko’s blog post for more details). Since I joined the compiler team a while ago I can now champion for it myself on the compiler side, and @traviscross volunteered to continue the support on the language side, thank you!

2 detailed updates available. @Eh2406:

My time at Amazon is coming to an end. They supported the very successful effort with the 2024h2 goal, and encouraged me to propose the 2025h1 goal that is now wrapping up. Unfortunately other work efforts led to the very limited progress on the 2025h1 goal. I do not know what comes next, but it definitely involves taking time to relax and recover. Recovering involves rediscovering the joy in the work that I love. And, I have a deep passion for this problem. I hope to make some time to work on this. But, relaxing requires reducing the commitments I have made to others and the associated stress. So I will not promise progress, nor will I renew the goal for 2025h2.

Comment by @Eh2406 posted on 2025-07-02:

My time at Amazon is coming to an end. They supported the very successful effort with the 2024h2 goal, and encouraged me to propose the 2025h1 goal that is now wrapping up. Unfortunately other work efforts led to the very limited progress on the 2025h1 goal. I do not know what comes next, but it definitely involves taking time to relax and recover. Recovering involves rediscovering the joy in the work that I love. And, I have a deep passion for this problem. I hope to make some time to work on this. But, relaxing requires reducing the commitments I have made to others and the associated stress. So I will not promise progress, nor will I renew the goal for 2025h2.

Comment by @tomassedovic posted on 2025-07-25:

Thank you for everything Jacob and good luck!

As the 2025 H1 period is coming to an end and we’re focusing on the goals for the second half of the year, we will close this issue by the end of this month (July 2025).

If you or someone else out there is working on this and has updates to share, please add them as a comment here by 2025-07-29 so they can be included in the final blog post.

Even after the issue is closed, the work here can be picked up – we’ll just no longer track it as part of the 2025H1 goals effort.

2 detailed updates available. Comment by @epage posted on 2025-07-10:

Key developments:

Blockers

• Staffing wise, attention was taken by toml v0.9 and now cargo-script Help wanted

• Help in writing out the end-user API on top of the raw harness

Comment by @epage posted on 2025-07-28:

Key developments:

• https://github.com/assert-rs/libtest2/pull/94
• https://github.com/assert-rs/libtest2/pull/99
• https://github.com/assert-rs/libtest2/pull/100

1 detailed update available. Comment by @b-naber posted on 2025-07-28:

Chiming in for @epage here since further progress is still blocked on the compiler implementation. Unfortunately things have been moving more slowly than I had initially hoped. We have been doing some refactoring (https://github.com/rust-lang/rust/pull/142547 and https://github.com/rust-lang/rust/pull/144131) that allow us to introduce a new Scope for namespaced crates inside name resolution. There’s a draft PR (https://github.com/rust-lang/rust/pull/140271) that should be straightforward to adapt to the refactoring.

2 detailed updates available. Comment by @celinval posted on 2025-07-03:

Unfortunately, we didn’t make much progress since April except for a very useful discussion during Rust all hands. A few notes can be found here: https://hackmd.io/@qnR1-HVLRx-dekU5dvtvkw/SyUuR6SZgx. We’re still waiting for the design discussion meeting with the compiler team.

Comment by @celinval posted on 2025-07-25:

@dawidl022 is working as part of GSoC to improve contracts implementation under @tautschnig mentorship. Additionally, @tautschnig and @carolynzech are working on porting contracts from https://github.com/model-checking/verify-rust-std to the Rust repo.

1 detailed update available. Comment by @yaahc posted on 2025-07-11:

No update for this month beyond the previous finalish update. I still intend to publish the json->influxdb conversion code

2 detailed updates available. Comment by @lcnr posted on 2025-07-14:

We - or well, overwhelmingly @compiler-errors - continued to make performance improvements to the new solver over the last month: https://github.com/rust-lang/rust/pull/142802 https://github.com/rust-lang/rust/pull/142732 https://github.com/rust-lang/rust/pull/142317 https://github.com/rust-lang/rust/pull/142316 https://github.com/rust-lang/rust/pull/142223 https://github.com/rust-lang/rust/pull/142090 https://github.com/rust-lang/rust/pull/142088 https://github.com/rust-lang/rust/pull/142085 https://github.com/rust-lang/rust/pull/141927 https://github.com/rust-lang/rust/pull/141581 https://github.com/rust-lang/rust/pull/141451. nalgebra is currently 70% slower than with the old solver implementation and we seem to be about 30-50% slower in most normal crates.

I’ve been working on strengthening the search graph to avoid the hang in rayon and https://github.com/rust-lang/trait-system-refactor-initiative/issues/210 in a principled way. This has been more challenging than expected and will take at least another week to get done.

Comment by @lcnr posted on 2025-07-29:

Since the last update @compiler-errors landed two additional perf optimizations: https://github.com/rust-lang/rust/pull/143500 https://github.com/rust-lang/rust/pull/143309.

I am still working on the hang in rayon and https://github.com/rust-lang/trait-system-refactor-initiative/issues/210. I’ve ended up having to change the invariants of the type system to support a fast paths based on structural identity, e.g. quickly proving T: Trait<'a> via a T: Trait<'a> where-bound, in https://github.com/rust-lang/rust/pull/144405. Changing this invariant requires some additional work in HIR typeck, so I am currently reducing the perf impact of that change.

With this I can then land the actual fast paths which fix both rayon and similar hangs due to a large number of where-bounds. This should also be done soon. I will then go back to implement the new opaque type handling approach as that’s the only remaining issue before we can call for testing.

1 detailed update available. Comment by @veluca93 posted on 2025-07-10:

Key developments: https://github.com/rust-lang/rust/issues/143352 proposes an experimental feature to investigate an effect-based approach to integrate generics and target features, effectively giving ways to have different monomorphizations of a function have different target features.

1 detailed update available. Comment by @1c3t3a posted on 2025-07-25:

Key developments: Landed the enum discriminant check and enabled it for transmutes to enums for now (this is not so powerful), currently extending it to union reads and pointer reads.

Blockers: question of how to insert a check if we already observe UB (e.g. the enum is only represented by an i1 in LLVM IR). This is to be addressed by the next project goal: https://rust-lang.github.io/rust-project-goals/2025h2/comprehensive-niche-checks.html.

@blyxyas:

Final monthly update!

Even more optimizations have been achieved on the documentation lints front. https://github.com/rust-lang/rust-clippy/pull/15030 (-6.7% on bumpalo).

The 3rd heaviest function was optimized away by 99.75%, along with the strlen_on_c_strings lint. This gives us about a 15% optimization on tokio. https://github.com/rust-lang/rust-clippy/pull/15043.

As a minor improvement, we now instantiate a lot less types on unit_return_expecting_ord (89% less calls in some benchmarks). This saves us a lot of locks on the type interner. As a final update to the project goal, I’d like to say a little bit more:

I’m very happy with how this project goal has turned out. We’ve seen improvements in the 35-60% range for your real world projects and while I couldn’t deliver the two objectives the project goal promised because of an excess in ambition, I still don’t think that these are too far-fetched by any means.

As some specific examples, you can now witness a 38% performance improvements in analyzing Cargo, and a 61% in analyzing Tokio!

Much more to come, and thanks for sticking by while we make Clippy a better project, with better developer experience. Have a great week, and I hope that you can enjoy all the performance improvements that we’ve delivered across this project goal.

1 detailed update available. Comment by @blyxyas posted on 2025-06-27:

Final monthly update!

Even more optimizations have been achieved on the documentation lints front. https://github.com/rust-lang/rust-clippy/pull/15030. (-6.7% on bumpalo).

The 3rd heaviest function was optimized away by 99.75%, along with the strlen_on_c_strings lint. This gives us about a 15% optimization on tokio. https://github.com/rust-lang/rust-clippy/pull/15043

As a minor improvement, we now instantiate a lot less types on unit_return_expecting_ord (89% less calls in some benchmarks). This saves us a lot of locks on the type interner. As a final update to the project goal, I’d like to say a little bit more:

I’m very happy with how this project goal has turned out. We’ve seen improvements in the 35-60% range for your real world projects and while I couldn’t deliver the two objectives the project goal promised because of an excess in ambition, I still don’t think that these are too far-fetched by any means.

As some specific examples, you can now witness a 38% performance improvements in analyzing Cargo, and a 61% in analyzing Tokio!

Much more to come, and thanks for sticking by while we make Clippy a better project, with better developer experience. Have a great week, and I hope that you can enjoy all the performance improvements that we’ve delivered across this project goal.

@oli-obk:

The following contributors have made many libcore traits const:

• @Daniel-Aaron-Bloom
• @estebank
• @Randl
• @SciMind2460 @fee1-dead has also updated the syntax to allow for const trait Trait {} declarations instead of #[const_trait] trait Trait {}.