An Update on Rust's March Project Goals: What's the Progress So Far?

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. Flagship goals Bring the Async Rust experience closer to parity with sync Rust 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. What has happened? Generators. Initial implementation work has started on an iter! macro experiment in https://github.com/rust-lang/rust/pull/137725. Discussions have centered around whether the macro should accept blocks in addition to closures, whether thunk closures with an empty arguments list should implement IntoIterator, and whether blocks should evaluate to a type that is Iterator as well as IntoIterator. See the design meeting notes for more. dynosaur. We released dynosaur v0.2.0 with some critical bug fixes and one breaking change. We have several more breaking changes queued up for an 0.3 release line that we also use plan to use as a 1.0 candidate. Pin ergonomics. https://github.com/rust-lang/rust/pull/135733 landed to implement &pin const self and &pin mut self sugars as part of the ongoing pin ergonomics experiment. Another PR is open with an early implementation of applying this syntax to borrowing expressions. There has been some discussion within parts of the lang team on whether to prefer this &pin mut T syntax or &mut pin T, the latter of which applies equally well to Box but requires an edition. No detailed updates available. Organize Rust All-Hands 2025 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. What has happened? Invite more guests, after deciding on who else to invite. (To be discussed today in the council meeting.) Figure out if we can fund the travel+hotel costs for guests too. (To be discussed today in the council meeting.) Mara has asked all attendees for suggestions for guests to invite. Based on that, Mara has invited roughly 20 guests so far. Only two of them needed funding for their travel, which we can cover from the same travel budget. Open the call for proposals for talks for the Project Track (on wednesday) as part of the RustWeek conference. The Rust Project Track at RustWeek has been published: https://rustweek.org/schedule/wednesday/ This track is filled with talks that are relevant to folks attending the all-hands afterwards. 1 detailed update available. Comment by @m-ou-se posted on 2025-04-01: Invite more guests, after deciding on who else to invite. (To be discussed today in the council meeting.) Figure out if we can fund the travel+hotel costs for guests too. (To be discussed today in the council meeting.) I've asked all attendees for suggestions for guests to invite. Based on that, I've invited roughly 20 guests so far. Only two of them needed funding for their travel, which we can cover from the same travel budget. Stabilize tooling needed by Rust for Linux 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? Most of the major items are in an iteration phase. The rustdoc changes for exporting doctests are the furthest along, with a working prototype; the RFL project has been integrating that prototype and providing feedback. Clippy stabilization now has a pre-RFC and there is active iteration towards support for build-std. Other areas of progress: We have an open PR to stabilize -Zdwarf-version. The lang and types team have been discussing the best path forward to resolve #136702. This is a soundness concern that was raised around certain casts, specifically, casts from a type like *mut dyn Foo + '_ (with some lifetime) to *mut dyn Foo + 'static (with a static lifetime). Rust's defaulting rules mean that the latter is more commonly written with a defaulted lifetime, i.e., just *mut dyn Foo, which makes this an easy footgun. This kind of cast has always been dubious, as it disregards the lifetime in a rather subtle way, but when combined with arbitrary self types it permits users to disregard safety invariants making it hard to enforce soundness (see #136702 for details). The current proposal under discussion in #136776 is to make this sort of cast a hard error at least outside of an unsafe block; we evaluated the feasibility of doing a future-compatibility-warning and found it was infeasible. Crater runs suggest very limited fallout from this soundness fix but discussion continues about the best set of rules to adopt so as to balance minimizing fallout with overall language simplicity. 2 detailed updates available. Comment by @nikomatsakis posted on 2025-03-13: Update from our 2025-03-12 meeting (full minutes): RFL team requests someone to look at #138368 which is needed by kernel, @davidtwco to do so. -Zbinary-dep-info may not be needed; RFL may be able to emulate it. rustdoc changes for exporting doctests are being incorporated. @GuillaumeGomez is working on the kernel side of the feature too. @ojeda thinks it would be a good idea to do it in a way that does not tie both projects too much, so that rustdoc has more flexibility to change the output later on. Pre-RFC authored for clippy stabilization. Active iteration on the build-std design; feedback being provided by cargo team. @wesleywiser sent a PR to stabilize -Zdwarf-version. RfL doesn't use cfg(no_global_oom_handling) anymore. Soon, stable/LTS kernels that support several Rust versions will not use it either. Thus upstream Rust could potentially remove the cfg without breaking Linux, though other users like Windows may be still using it (#t-libs>no_global_oom_handling removal). Some discussion about best way forward for disabling orphan rule to allow experimentation with no firm conclusion. Comment by @nikomatsakis posted on 2025-03-26: Updates from today's meeting: Finalizing 2024h2 goals asm-goto is now stabilized! will be released in 1.87. asm-const has a preliminary impl, gcc support is needed. While not used in RFL, naked_asm is not on the list but it will be moving forward for stabilization. It suffers from the same LLVM bug as global_asm forgetting target feature flags. ABI-modifying compiler flags Andrew Zhogin has opened a draft PR (https://github.com/rust-lang/rust/pull/138736) following Alice's issue about which santisers should be modifiers (https://github.com/rust-lang/rust/issues/138453) Extract dependency information, configure no-std externally (-Zcrate-attr) We decided we don't need to be able to extract dependency information -Zcrate-attr has an RFC from jyn: https://github.com/rust-lang/rfcs/pull/3791 Rustdoc features to extract doc tests No update. Clippy configuration Pre-RFC was published but hasn't (to our knowledge) made progress. Would be good to sync up on next steps with @flip1995. Build-std No update. Progress will resume next week when the contributor working on this returns from holiday. -Zsanitize-kcfi-arity Added this as a new deliverable. These kind of "emerging codegen flag" requests can be expected from time to time. Notes available here and here. The PR has been reviewed and is unblocked to land. Goals looking for help Promoting Parallel Front End Help wanted: Help test the deadlock code in the issue list and try to reproduce the issues. If you'd like to help, please post in this goal's dedicated zulip topic. 1 detailed update available. Comment by @SparrowLii posted on 2025-03-18: Key developments: Several deadlock issue that remain for more than a year were resolved by #137731 The new test suit for parallel front end is being improved Blockers: null Help wanted: Help test the deadlock code in the issue list and try to reproduce the issue Stabilize public/private dependencies Help wanted: T-compiler people to work on the blocking issues #119428 and #71043. If you'd like to help, please post in this goal's dedicated zulip topic. 1 detailed update available. Comment by @epage posted on 2025-03-17: Key developments: @tgross35 got rust-lang/rust#135501 merged which improved which made progress on rust-lang/rust#119428, one of the two main blockers. In rust-lang/rust#119428, we've further discussed further designs and trade offs. Blockers: Further work on rust-lang/rust#119428 and rust-lang/rust#71043 Help wanted: T-compiler people to work on those above issues. Other goal updates "Stabilizable" prototype for expanded const generics 1 detailed update available. Comment by @BoxyUwU posted on 2025-03-17: camelids PR has been merged, we now correctly (to the best of my knowledge) lower const paths under mgca. I have a PR open to ensure that we handle evaluation of paths to consts with generics or inference variables correctly, and that we do not attempt to evaluate constants before they have been checked to be well formed. I'm also currently mentoring someone to implement proper handling of normalization of inherent associated constants under mgca. build-std 1 detailed update available. Comment by @davidtwco posted on 2025-03-03: A small update, @adamgemmell shared revisions to the aforementioned document, further feedback to which is being addressed. Continue resolving `cargo-semver-checks` blockers for merging into cargo Earlier this month, we completed one checkbox of the goal: #[doc(hidden)] in sealed trait analysis, live in cargo-semver-checks v0.40. We also made significant progress on type system modeling, which is part of two more checkboxes. We shipped method receiver types in our schema, enabling more than a dozen new lints. We have a draft schema for ?Sized bounds, and are putting the finishing touches on 'static and "outlives" bounds. More lints will follow here. We also have a draft schema for the new use<> precise capturing syntax. Additionally, cargo-semver-checks is participating in Google Summer of Code, so this month we had the privilege of merging many contributions from new contributors who are considering applying for GSoC with us! We're looking forward to this summer, and would like to wish the candidates good luck in the application process! 1 detailed update available. Comment by @obi1kenobi posted on 2025-03-08: Key developments: Sealed trait analysis correctly handles #[doc(hidden)] items. This completes one checkbox of this goal! We shipped a series of lints detecting breakage in generic types, lifetimes, and const generics. One of them has already caught accidental breakage in the real world! cargo-semver-checks v0.40, released today, includes a variety of improvements to sealed trait analysis. They can be summarized as "smarter, faster, more correct," and will have an immediate positive impact on popular crates such as diesel and zerocopy. While we already shipped a series of lints detecting generics-related breakage, more work is needed to complete that checkbox. This, and the "special cases like 'static and ?Sized", will be the focus of upcoming work. Declarative (`macro_rules!`) macro improvements No detailed updates available. Evaluate approaches for seamless interop between C++ and Rust 1 detailed update available. Comment by @tmandry posted on 2025-03-25: Since our last update, there has been talk of dedicating some time at the Rust All Hands for interop discussion; @baumanj and @tmandry are going to work on fleshing out an agenda. @cramertj and @tmandry brainstormed with @oli-obk (who was very helpful) about ways of supporting a more ambitious "template instantiation from Rust" goal, and this may get turned into a prototype at some point. Experiment with ergonomic ref-counting There is now an early prototype available that allows you to write x.use; if the type of X implements UseCloned, then this is equivalent to x.clone(), else it is equivalent to a move. This is not the desired end semantics in a few ways, just a step along the road. Nothing to see here (yet). 1 detailed update available. Comment by @nikomatsakis posted on 2025-03-17: Update: rust-lang/rust#134797 has landed. Semantics as implemented in the PR: Introduced a trait UseCloned implemented for Rc and Arc types. x.use checks whether x's type X implements the UseCloned trait; if so, then x.use is equivalent to x.clone(), otherwise it is a copy/move of x; use || ...x... closures act like move closures but respect the UseCloned trait, so they will either clone, copy, or move x as appropriate. Next steps: Modify codegen so that we guarantee that x.use will do a copy if X: Copy is true after monomorphization. Right now the desugaring to clone occurs before monomorphization and hence it will call the clone method even for those instances where X is a Copy type. Convert x.use to a move rather than a clone if this is a last-use. Make x equivalent to x.use but with an (allow-by-default) lint to signal that something special is happened. Notable decisions made and discussions: Opted to name the trait that controls whether x.use does a clone or a move UseCloned rather than Use. This is because the trait does not control whether or not you can use something but rather controls what happens when you do. Question was raised on Zulip as to whether x.use should auto-deref. After thinking it over, reached the conclusion that it should not, because x and x.use should eventually behave the same modulo lints, but that (as ever) a &T -> T coercion would be useful for ergonomic reasons. Expose experimental LLVM features for GPU offloading 1 detailed update available. Comment by @ZuseZ4 posted on 2025-03-25: I just noticed that I missed my February update, so I'll keep this update a bit more high-level, to not make it too long. Key developments: All key autodiff PRs got merged. So after building rust-lang/rust with the autodiff feature enabled, users can now use it, without the need for any custom fork. std::autodiff received the first PRs from new contributors, which have not been previously involved in rustc development! My plan is to grow a team to maintain this feature, so that's a great start. The PRs are here, here and here. Over time I hope to hand over increasingly larger issues. I received an offer to join the Rust compiler team, so now I can also officially review and approve PRs! For now I'll focus on reviewing PRs in the fields I'm most comfortable with, so autodiff, batching, and soon GPU offload. I implemented a standalone batching feature. It was a bit larger (~2k LoC) and needed some (back then unmerged) autodiff PRs, since they both use the same underlying Enzyme infrastructure. I therefore did not push for merging it. I recently implemented batching as part of the autodiff macro, for people who want to use both together. I subsequently split out a first set of code improvements and refactorings, which already got merged. The remaining autodiff feature PR is only 600 loc, so I'm currently cleaning it up for review. I spend time preparing an MCP to enable autodiff in CI (and therefore nightly). I also spend a lot of time discussing a potential MLIR backend for rustc. Please reach out if you want to be involved! **Help wanted: ** We want to support autodiff in lib builds, instead of only binaries. oli-obk and I recently figured out the underlying bug, and I started with a PR in https://github.com/rust-lang/rust/pull/137570. The problem is that autodiff assumes fat-lto builds, but lib builds compile some of the library code using thin-lto, even if users specify lto=fat in their Cargo.toml. We'd want to move every thing to fat-lto if we enable Autodiff as a temporary solution, and later move towards embed-bc as a longer-term solution. If you have some time to help please reach out! Some of us have already looked into it a little but got side-tracked, so it's better to talk first about which code to re-use, rather than starting from scratch. I also booked my RustWeek ticket, so I'm happy to talk about all types of Scientific Computing, HPC, ML, or cursed Rust(c) and LLVM internals! Please feel free to dm me if you're also going and want to meet. Extend pubgrub to match cargo's dependency resolution 1 detailed update available. Comment by @Eh2406 posted on 2025-03-14: Progress continues to be stalled by high priority tasks for $DAY_JOB. It continues to be unclear when the demands of work will allow me to return focus to this project. Externally Implementable Items No detailed updates available. Finish the libtest json output experiment 1 detailed update available. Comment by @epage posted on 2025-03-17: Key developments: Between tasks on #92, I've started to refresh myself on the libtest-next code base Blockers: Help wanted: Implement Open API Namespace Support No detailed updates available. Implement restrictions, prepare for stabilization No detailed updates available. Improve state machine codegen We've started work on implementing #[loop_match] on this branch. For the time being integer and enum patterns are supported. The benchmarks, are extremely encouraging, showing large improvements over the status quo, and significant improvements versus -Cllvm-args=-enable-dfa-jump-thread. Our next steps can be found in the todo file, and focus mostly on improving the code quality and robustness. 3 detailed updates available. Comment by @folkertdev posted on 2025-03-18: @traviscross how would we make progress on that? So far we've mostly been talking to @joshtriplett, under the assumption that a #[loop_match] attribute on loops combined with a #[const_continue] attribute on "jumps to the next iteration" will be acceptable as a language experiment. Our current implementation handles the following #![feature(loop_match)] enum State { A, B, } fn main() { let mut state = State::A; #[loop_match] 'outer: loop { state = 'blk: { match state { State::A => { #[const_continue] break 'blk State::B } State::B => break 'outer, } } } } Crucially, this does not add syntax, only the attributes and internal logic in MIR lowering for statically performing the pattern match to pick the right branch to jump to. The main challenge is then to implement this in the compiler itself, which we've been working on (I'll post our tl;dr update shortly) Comment by @folkertdev posted on 2025-03-18: Some benchmarks (as of march 18th) A benchmark of https://github.com/bjorn3/comrak/blob/loop_match_attr/autolink_email.rs, basically a big state machine that is a perfect fit for loop match Benchmark 1: ./autolink_email Time (mean ± σ): 1.126 s ± 0.012 s [User: 1.126 s, System: 0.000 s] Range (min … max): 1.105 s … 1.141 s 10 runs Benchmark 2: ./autolink_email_llvm_dfa Time (mean ± σ): 583.9 ms ± 6.9 ms [User: 581.8 ms, System: 2.0 ms] Range (min … max): 575.4 ms … 591.3 ms 10 runs Benchmark 3: ./autolink_email_loop_match Time (mean ± σ): 411.4 ms ± 8.8 ms [User: 410.1 ms, System: 1.3 ms] Range (min … max): 403.2 ms … 430.4 ms 10 runs Summary ./autolink_email_loop_match ran 1.42 ± 0.03 times faster than ./autolink_email_llvm_dfa 2.74 ± 0.07 times faster than ./autolink_email #[loop_match] beats the status quo, but also beats the llvm flag by a large margin. A benchmark of zlib decompression with chunks of 16 bytes (this makes the impact of loop_match more visible) Benchmark 1 (65 runs): target/release/examples/uncompress-baseline rs-chunked 4 measurement mean ± σ min … max outliers delta wall_time 77.7ms ± 3.04ms 74.6ms … 88.9ms 9 (14%) 0% peak_rss 24.1MB ± 64.6KB 24.0MB … 24.2MB 0 ( 0%) 0% cpu_cycles 303M ± 11.8M 293M … 348M 9 (14%) 0% instructions 833M ± 266 833M … 833M 0 ( 0%) 0% cache_references 3.62M ± 310K 3.19M … 4.93M 1 ( 2%) 0% cache_misses 209K ± 34.2K 143K … 325K 1 ( 2%) 0% branch_misses 4.09M ± 10.0K 4.08M … 4.13M 5 ( 8%) 0% Benchmark 2 (68 runs): target/release/examples/uncompress-llvm-dfa rs-chunked 4 measurement mean ± σ min … max outliers delta wall_time 74.0ms ± 3.24ms 70.6ms … 85.0ms 4 ( 6%) 🚀- 4.8% ± 1.4% peak_rss 24.1MB ± 27.1KB 24.0MB … 24.1MB 3 ( 4%) - 0.1% ± 0.1% cpu_cycles 287M ± 12.7M 277M … 330M 4 ( 6%) 🚀- 5.4% ± 1.4% instructions 797M ± 235 797M … 797M 0 ( 0%) 🚀- 4.3% ± 0.0% cache_references 3.56M ± 439K 3.08M … 5.93M 2 ( 3%) - 1.8% ± 3.6% cache_misses 144K ± 32.5K 83.7K … 249K 2 ( 3%) 🚀- 31.2% ± 5.4% branch_misses 4.09M ± 9.62K 4.07M … 4.12M 1 ( 1%) - 0.1% ± 0.1% Benchmark 3 (70 runs): target/release/examples/uncompress-loop-match rs-chunked 4 measurement mean ± σ min … max outliers delta wall_time 71.6ms ± 2.43ms 69.3ms … 78.8ms 6 ( 9%) 🚀- 7.8% ± 1.2% peak_rss 24.1MB ± 72.8KB 23.9MB … 24.2MB 20 (29%) - 0.0% ± 0.1% cpu_cycles 278M ± 9.59M 270M … 305M 7 (10%) 🚀- 8.5% ± 1.2% instructions 779M ± 277 779M … 779M 0 ( 0%) 🚀- 6.6% ± 0.0% cache_references 3.49M ± 270K 3.15M … 4.17M 4 ( 6%) 🚀- 3.8% ± 2.7% cache_misses 142K ± 25.6K 86.0K … 197K 0 ( 0%) 🚀- 32.0% ± 4.8% branch_misses 4.09M ± 7.83K 4.08M … 4.12M 1 ( 1%) + 0.0% ± 0.1% Benchmark 4 (69 runs): target/release/examples/uncompress-llvm-dfa-loop-match rs-chunked 4 measurement mean ± σ min … max outliers delta wall_time 72.8ms ± 2.57ms 69.7ms … 80.0ms 7 (10%) 🚀- 6.3% ± 1.2% peak_rss 24.1MB ± 35.1KB 23.9MB … 24.1MB 2 ( 3%) - 0.1% ± 0.1% cpu_cycles 281M ± 10.1M 269M … 312M 5 ( 7%) 🚀- 7.5% ± 1.2% instructions 778M ± 243 778M … 778M 0 ( 0%) 🚀- 6.7% ± 0.0% cache_references 3.45M ± 277K 2.95M … 4.14M 0 ( 0%) 🚀- 4.7% ± 2.7% cache_misses 176K ± 43.4K 106K … 301K 0 ( 0%) 🚀- 15.8% ± 6.3% branch_misses 4.16M ± 96.0K 4.08M … 4.37M 0 ( 0%) 💩+ 1.7% ± 0.6% The important points: loop-match is faster than llfm-dfa, and when combined performance is worse than when using loop-match on its own. Comment by @traviscross posted on 2025-03-18: Thanks for that update. Have reached out separately. Instrument the Rust standard library with safety contracts 1 detailed update available. Comment by @celinval posted on 2025-03-17: We have been able to merge the initial support for contracts in the Rust compiler under the contracts unstable feature. @tautschnig has created the first PR to incorporate contracts in the standard library and uncovered a few limitations that we've been working on. Making compiletest more maintainable: reworking directive handling 1 detailed update available. Comment by @jieyouxu posted on 2025-03-15: Update (2025-03-15): Doing a survey pass on compiletest to make sure I have the full picture. Metrics Initiative 1 detailed update available. Comment by @yaahc posted on 2025-03-03: After further review I've decided to limit scope initially and not get ahead of myself so I can make sure the schemas I'm working with can support the kind of queries and charts we're going to eventually want in the final version of the unstable feature usage metric. I'm hoping that by limiting scope I can have most of the items currently outlined in this project goal done ahead of schedule so I can move onto building the proper foundations based on the proof of concept and start to design more permanent components. As such I've opted for the following: minimal change to the current JSON format I need, which is including the timestamp Gain clarity on exactly what questions I should be answering with the unstable feature usage metrics, the desired graphs and tables, and how this influences what information I need to gather and how to construct the appropriate queries within graphana gathering a sample dataset from docs.rs rather than viewing it as the long term integration, since there are definitely some sampleset bias issues in that dataset from initial conversations with docs.rs Figure out proper hash/id to use in the metrics file names to avoid collisions with different conditional compilation variants of the same crate with different feature enabled. For the second item above I need to have more detailed conversations with both @rust-lang/libs-api and @rust-lang/lang Model coherence in a-mir-formality 1 detailed update available. Comment by @nikomatsakis posted on 2025-03-17: Update: @tiif has been working on integrating const-generic effects into a-mir-formality and making good progress. I have begun exploring integration of the MiniRust definition of MIR. This doesn't directly work towards the goal of modeling coherence but it will be needed for const generic work to be effective. I am considering some simplification and cleanup work as well. Next-generation trait solver 1 detailed update available. Comment by @lcnr posted on 2025-03-17: The two cycle handling PRs mentioned in the previous update have been merged, allowing nalgebra to compile with the new solver enabled. I have now started to work on opaque types in borrowck again. This is a quite involved issue and will likely take a few more weeks until it's fully implemented. Nightly support for ergonomic SIMD multiversioning 1 detailed update available. Comment by @veluca93 posted on 2025-03-17: Key developments: Started investigating how the proposed SIMD multiversioning options might fit in the context of the efforts for formalizing a Rust effect system Null and enum-discriminant runtime checks in debug builds No detailed updates available. Optimizing Clippy & linting 1 detailed update available. Comment by @blyxyas posted on 2025-03-17: Monthly update! https://github.com/rust-lang/rust-clippy/issues/13821 has been merged. This has successfully optimized the MSRV extraction from the source code. On the old MSRV extraction,Symbol::intern use was sky high being about 3.5 times higher than the rest of the compilation combined. Now, it's at normal levels. Note that Symbol::intern is a very expensive and locking function, so this is very notable. Thanks to @Alexendoo for this incredible work! As a general note on the month, I'd say that we've experimented a lot. Starting efforts on parallelizing the lint system. https://github.com/rust-lang/rust-clippy/issues/14423 Started taking a deeper look into our dependence on libLLVM.so and heavy relocation problems. I took a look into heap allocation optimization, seems that we are fine. For the moment, rust-clippy#14423 is the priority. Prepare const traits for stabilization 1 detailed update available. Comment by @oli-obk posted on 2025-03-20: I opened an RFC (https://github.com/rust-lang/rfcs/pull/3762) and we had a lang team meeting about it. Some design exploration and bikeshedding later we have settled on using (const)instead of ~const along with some more annotations for explicitness and some fewer annotations in other places. The RFC has been updated accordingly. There is still ongoing discussions about reintroducing the "fewer annotations" for redundancy and easier processing by humans. Prototype a new set of Cargo "plumbing" commands No detailed updates available. Publish first rust-lang-owned release of "FLS" 2 detailed updates available. Comment by @JoelMarcey posted on 2025-03-14: Key Developments: Working on a public announcement of Ferrous' contribution of the FLS. Goal is to have that released soon. Also working out the technical details of the contribution, particularly around how to initially integrate the FLS into the Project itself. Blockers: None yet. Comment by @JoelMarcey posted on 2025-04-01: Key Developments: Public announcement of the FLS donation to the Rust Project. Blockers: None Publish first version of StableMIR on crates.io 2 detailed updates available. Comment by @celinval posted on 2025-03-20: We have proposed a project idea to Google Summer of Code to implement the refactoring and infrastructure improvements needed for this project. I'm working on breaking down the work into smaller tasks so they can be implemented incrementally. Comment by @celinval posted on 2025-03-20: I am also happy to share that @makai410 is joining us in this effort! 🥳 Research: How to achieve safety when linking separately compiled code No detailed updates available. Run the 2025H1 project goal program 2 detailed updates available. Comment by @nikomatsakis posted on 2025-03-03: Update: February goal update has been posted. We made significant revisions to the way that goal updates are prepared. If you are a goal owner, it's worth reading the directions for how to report your status, especially the part about help wanted and summary comments. Comment by @nikomatsakis posted on 2025-03-17: Update: We sent out the first round of pings for the March update. The plan is to create the document on March 25th, so @rust-lang/goal-owners please get your updates in by then. Note that you can create a TL;DR comment if you want to add 2-3 bullet points that will be embedded directly into the final blog post. In terms of goal planning: @nandsh is planning to do a detailed retrospective on the goals program in conjunction with her research at CMU. Please reach out to her on Zulip (Nandini) if you are interested in participating. We are planning to overhaul the ping process as described in this hackmd. In short, pings will come on the 2nd/3rd Monday of the month. No pings will be sent if you've posted a comment that month. The blog post will be prepared on the 3rd Friday. We've been discussing how to structure 2025H2 goals and are thinking of making a few changes. We'll break out three categories of goals (Flagship / Core / Stretch), with "Core" goals being those deemed most important. We'll also have a 'pre-read' before the RFC opens with team leads to look for cross-team collaborative opportunities. At least that's the current plan. Rust Vision Document We drafted a Rust Vision Doc Action Plan. We expect to publish our announcement blog post by end of Month including a survey requesting volunteers to speak with us. We are also creating plans for interviews with company contacts, global community groups, and Rust maintainers. 1 detailed update available. Comment by @nikomatsakis posted on 2025-03-17: Update: I've asked @jackh726 to co-lead the team with me. Together we pulled together a Rust Vision Doc action plan. The plan begins by posting a blog post (draft available here) announcing the effort. We are coordinating with the Foundation to create a survey which will be linked from the blog post. The survey questions ask about user's experience but also look for volunteers we can speak with. We are pulling together the team that will perform the interviewing. We've been in touch with UX reseearchers who will brief us on some of the basics of UX research. We're finalizing team membership now plus the set of focus areas, we expect to cover at least users/companies, Rust project maintainers, and Rust global communities. See the Rust Vision Doc action plan for more details. rustc-perf improvements 1 detailed update available. Comment by @davidtwco posted on 2025-03-03: A small update, @Jamesbarford aligned with @kobzol on a high-level architecture and will begin fleshing out the details and making some small patches to rustc-perf to gain familiarity with the codebase. Scalable Polonius support on nightly 1 detailed update available. Comment by @lqd posted on 2025-03-24: Here are the key developments for this update. Amanda has continued on the placeholder removal task. In particular on the remaining issues with rewritten type tests. The in-progress work caused incorrect errors to be emitted under the rewrite scheme, and a new strategy to handle these was discussed. This has been implemented in the PR, and seems to work as hoped. So the PR should now be in a state that is ready for more in-depth review pass, and should hopefully land soon. Tage has started his master's thesis with a focus on the earliest parts of the borrow checking process, in order to experiment with graded borrow-checking, incrementalism, avoiding work that's not needed for loans that are not invalidated, and so on. A lot of great progress has been made on these parts already, and more are being discussed even in the later areas (live and active loans). I have focused on taking care of the remaining diagnostics and test failures of the location-sensitive analysis. For diagnostics in particular, the PRs mentioned in the previous updates have landed, and I've fixed a handful of NLL spans, all the remaining differences under the compare-mode, and blessed differences that were improvements. For the test failures, handling liveness differently in traversal fixed most of the remaining failures, while a couple are due to the friction with mid-points avoidance scheme. For these, we have a few different paths forward, but with different trade-offs and we'll be discussing and evaluation these in the very near future. Another two are still left to analyze in-depth to see what's going on. Our near future focus will be to continue down the path to correctness while also expanding test coverage that feels lacking in certain very niche areas, and that we want to improve. At the same time, we'll also work on a figuring out a better architecture to streamline the entire end-to-end process, to allow early outs, avoid work that is not needed, etc. Secure quorum-based cryptographic verification and mirroring for crates.io No detailed updates available. Stabilize cargo-script 1 detailed update available. Comment by @lqd posted on 2025-03-26: This project goal was actually carried over from 2024h2, in https://github.com/rust-lang/rust-project-goals/pull/294 SVE and SME on AArch64 2 detailed updates available. Comment by @davidtwco posted on 2025-03-03: A small update, we've opened a draft PR for the initial implementation of this - rust-lang/rust#137944. Otherwise, just continued to address feedback on the RFCs. Comment by @davidtwco posted on 2025-03-18: We've been resolving review feedback on the implementation of the Sized Hierarchy RFC on rust-lang/rust#137944. We're also working on reducing the performance regression in the PR, by avoiding unnecessary elaboration of sizedness supertraits and extending the existing Sized case in type_op_prove_predicate query's fast path. There's not been any changes to the RFC, there's minor feedback that has yet to be responded to, but it's otherwise just waiting on t-lang. We've been experimenting with rebasing rust-lang/rust#118917 on top of rust-lang/rust#137944 to confirm that const sizedness allows us to remove the type system exceptions that the SVE implementation previously relied on. We're happy to confirm that it does. Unsafe Fields No detailed updates available. Use annotate-snippets for rustc diagnostic output 1 detailed update available. Comment by @Muscraft posted on 2025-03-31: While my time was limited these past few months, lots of progress was made! I was able to align annotate-snippets internals with rustc's HumanEmitter and get the new API implemented. These changes have not been merged yet, but they can be found here. As part of this work, I got rustc using annotate-snippets as its only renderer. During all of this, I started working on making rustc use annotate-snippets as its only renderer, which turned out to be a huge benefit. I was able to get a feel for the new API while addressing rendering divergences. As of the time of writing, all but ~30 tests of the roughly 18,000 UI tests are passing. test result: FAILED. 18432 passed; 29 failed; 193 ignored; 0 measured; 0 filtered out; finished in 102.32s Most of the failing tests are caused by a few things: annotate-snippets right aligns numbers, whereas rustc left aligns annotate-snippets doesn't handle multiple suggestions for the same span very well Problems with handling FailureNote annotate-snippets doesn't currently support colored labels and titles, i.e., the magenta highlight rustc uses rustc wants to pass titles similar to error: internal compiler error[E0080], but annotate-snippets doesn't support that well differences in how rustc and annotate-snippets handle term width during tests When testing, rustc uses DEFAULT_COLUMN_WIDTH and does not subtract the code offset, while annotate-snippets does Slight differences in how "newline"/end of line highlighting is handled JSON output rendering contains color escapes By Rémy Rakic on behalf of Goals Team Also published here Photo by Dennis Mita on Unsplash 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 . slate of 40 project goals Flagship Goals tracking issue on the rust-project-goals repository Flagship goals Bring the Async Rust experience closer to parity with sync Rust Bring the Async Rust experience closer to parity with sync Rust Bring the Async Rust experience closer to parity with sync Rust 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. Why this goal? dynosaur 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. our plan async-trait Pin What has happened? Generators. Initial implementation work has started on an iter! macro experiment in https://github.com/rust-lang/rust/pull/137725 . Discussions have centered around whether the macro should accept blocks in addition to closures, whether thunk closures with an empty arguments list should implement IntoIterator , and whether blocks should evaluate to a type that is Iterator as well as IntoIterator . See the design meeting notes for more. What has happened? Generators. iter! https://github.com/rust-lang/rust/pull/137725 IntoIterator Iterator IntoIterator design meeting notes dynosaur. We released dynosaur v0.2.0 with some critical bug fixes and one breaking change. We have several more breaking changes queued up for an 0.3 release line that we also use plan to use as a 1.0 candidate. dynosaur. dynosaur v0.2.0 Pin ergonomics. https://github.com/rust-lang/rust/pull/135733 landed to implement &pin const self and &pin mut self sugars as part of the ongoing pin ergonomics experiment. Another PR is open with an early implementation of applying this syntax to borrowing expressions. There has been some discussion within parts of the lang team on whether to prefer this &pin mut T syntax or &mut pin T , the latter of which applies equally well to Box but requires an edition. Pin ergonomics. https://github.com/rust-lang/rust/pull/135733 &pin const self &pin mut self &pin mut T &mut pin T Box No detailed updates available. Organize Rust All-Hands 2025 Organize Rust All-Hands 2025 Organize Rust All-Hands 2025 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. Why this goal? creation of the Rust subteams there were 6 Rust teams with 24 people in total 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. RustWeek 2025 RustNL Rust Vision Doc What has happened? What has happened? Invite more guests, after deciding on who else to invite. (To be discussed today in the council meeting.) Figure out if we can fund the travel+hotel costs for guests too. (To be discussed today in the council meeting.) Invite more guests, after deciding on who else to invite. (To be discussed today in the council meeting.) Figure out if we can fund the travel+hotel costs for guests too. (To be discussed today in the council meeting.) Invite more guests, after deciding on who else to invite. (To be discussed today in the council meeting.) Figure out if we can fund the travel+hotel costs for guests too. (To be discussed today in the council meeting.) Mara has asked all attendees for suggestions for guests to invite. Based on that, Mara has invited roughly 20 guests so far. Only two of them needed funding for their travel, which we can cover from the same travel budget. Mara Mara Open the call for proposals for talks for the Project Track (on wednesday) as part of the RustWeek conference. Open the call for proposals for talks for the Project Track (on wednesday) as part of the RustWeek conference. Open the call for proposals for talks for the Project Track (on wednesday) as part of the RustWeek conference. The Rust Project Track at RustWeek has been published: https://rustweek.org/schedule/wednesday/ https://rustweek.org/schedule/wednesday/ This track is filled with talks that are relevant to folks attending the all-hands afterwards. 1 detailed update available. Comment by @m-ou-se posted on 2025-04-01: Comment by @m-ou-se posted on 2025-04-01: Invite more guests, after deciding on who else to invite. (To be discussed today in the council meeting.) Figure out if we can fund the travel+hotel costs for guests too. (To be discussed today in the council meeting.) I've asked all attendees for suggestions for guests to invite. Based on that, I've invited roughly 20 guests so far. Only two of them needed funding for their travel, which we can cover from the same travel budget. Invite more guests, after deciding on who else to invite. (To be discussed today in the council meeting.) Figure out if we can fund the travel+hotel costs for guests too. (To be discussed today in the council meeting.) Invite more guests, after deciding on who else to invite. (To be discussed today in the council meeting.) Figure out if we can fund the travel+hotel costs for guests too. (To be discussed today in the council meeting.) Invite more guests, after deciding on who else to invite. (To be discussed today in the council meeting.) Figure out if we can fund the travel+hotel costs for guests too. (To be discussed today in the council meeting.) I've asked all attendees for suggestions for guests to invite. Based on that, I've invited roughly 20 guests so far. Only two of them needed funding for their travel, which we can cover from the same travel budget. Stabilize tooling needed by Rust for Linux Stabilize tooling needed by Rust for Linux Stabilize tooling needed by Rust for Linux 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). Why this goal? experimental support for Rust development in the Linux kernel RFC #3716 build-std creating a stable way to rebuild core with specific compiler options What has happened? Most of the major items are in an iteration phase. The rustdoc changes for exporting doctests are the furthest along, with a working prototype; the RFL project has been integrating that prototype and providing feedback. Clippy stabilization now has a pre-RFC and there is active iteration towards support for build-std. What has happened? Other areas of progress: We have an open PR to stabilize -Zdwarf-version. The lang and types team have been discussing the best path forward to resolve #136702. This is a soundness concern that was raised around certain casts, specifically, casts from a type like *mut dyn Foo + '_ (with some lifetime) to *mut dyn Foo + 'static (with a static lifetime). Rust's defaulting rules mean that the latter is more commonly written with a defaulted lifetime, i.e., just *mut dyn Foo, which makes this an easy footgun. This kind of cast has always been dubious, as it disregards the lifetime in a rather subtle way, but when combined with arbitrary self types it permits users to disregard safety invariants making it hard to enforce soundness (see #136702 for details). The current proposal under discussion in #136776 is to make this sort of cast a hard error at least outside of an unsafe block; we evaluated the feasibility of doing a future-compatibility-warning and found it was infeasible. Crater runs suggest very limited fallout from this soundness fix but discussion continues about the best set of rules to adopt so as to balance minimizing fallout with overall language simplicity. We have an open PR to stabilize -Zdwarf-version . open PR -Zdwarf-version The lang and types team have been discussing the best path forward to resolve #136702 . This is a soundness concern that was raised around certain casts, specifically, casts from a type like *mut dyn Foo + '_ (with some lifetime) to *mut dyn Foo + 'static (with a static lifetime). Rust's defaulting rules mean that the latter is more commonly written with a defaulted lifetime, i.e., just *mut dyn Foo , which makes this an easy footgun. This kind of cast has always been dubious, as it disregards the lifetime in a rather subtle way, but when combined with arbitrary self types it permits users to disregard safety invariants making it hard to enforce soundness (see #136702 for details). The current proposal under discussion in #136776 is to make this sort of cast a hard error at least outside of an unsafe block; we evaluated the feasibility of doing a future-compatibility-warning and found it was infeasible. Crater runs suggest very limited fallout from this soundness fix but discussion continues about the best set of rules to adopt so as to balance minimizing fallout with overall language simplicity. #136702 *mut dyn Foo + '_ *mut dyn Foo + 'static *mut dyn Foo #136702 #136776 2 detailed updates available. Comment by @nikomatsakis posted on 2025-03-13: Comment by @nikomatsakis posted on 2025-03-13: Update from our 2025-03-12 meeting (full minutes): RFL team requests someone to look at #138368 which is needed by kernel, @davidtwco to do so. -Zbinary-dep-info may not be needed; RFL may be able to emulate it. rustdoc changes for exporting doctests are being incorporated. @GuillaumeGomez is working on the kernel side of the feature too. @ojeda thinks it would be a good idea to do it in a way that does not tie both projects too much, so that rustdoc has more flexibility to change the output later on. Pre-RFC authored for clippy stabilization. Active iteration on the build-std design; feedback being provided by cargo team. @wesleywiser sent a PR to stabilize -Zdwarf-version. RfL doesn't use cfg(no_global_oom_handling) anymore. Soon, stable/LTS kernels that support several Rust versions will not use it either. Thus upstream Rust could potentially remove the cfg without breaking Linux, though other users like Windows may be still using it (#t-libs>no_global_oom_handling removal). Some discussion about best way forward for disabling orphan rule to allow experimentation with no firm conclusion. Update from our 2025-03-12 meeting ( full minutes ): full minutes RFL team requests someone to look at #138368 which is needed by kernel, @davidtwco to do so. -Zbinary-dep-info may not be needed; RFL may be able to emulate it. rustdoc changes for exporting doctests are being incorporated. @GuillaumeGomez is working on the kernel side of the feature too. @ojeda thinks it would be a good idea to do it in a way that does not tie both projects too much, so that rustdoc has more flexibility to change the output later on. Pre-RFC authored for clippy stabilization. Active iteration on the build-std design; feedback being provided by cargo team. @wesleywiser sent a PR to stabilize -Zdwarf-version. RfL doesn't use cfg(no_global_oom_handling) anymore. Soon, stable/LTS kernels that support several Rust versions will not use it either. Thus upstream Rust could potentially remove the cfg without breaking Linux, though other users like Windows may be still using it (#t-libs>no_global_oom_handling removal). Some discussion about best way forward for disabling orphan rule to allow experimentation with no firm conclusion. RFL team requests someone to look at #138368 which is needed by kernel, @davidtwco to do so. #138368 @davidtwco -Zbinary-dep-info may not be needed; RFL may be able to emulate it. -Zbinary-dep-info rustdoc changes for exporting doctests are being incorporated. @GuillaumeGomez is working on the kernel side of the feature too. @ojeda thinks it would be a good idea to do it in a way that does not tie both projects too much, so that rustdoc has more flexibility to change the output later on. rustdoc @GuillaumeGomez @ojeda rustdoc Pre-RFC authored for clippy stabilization. Pre-RFC Active iteration on the build-std design; feedback being provided by cargo team. @wesleywiser sent a PR to stabilize -Zdwarf-version . @wesleywiser PR to stabilize -Zdwarf-version RfL doesn't use cfg(no_global_oom_handling) anymore. Soon, stable/LTS kernels that support several Rust versions will not use it either. Thus upstream Rust could potentially remove the cfg without breaking Linux, though other users like Windows may be still using it ( # t-libs>no_global_oom_handling removal ). cfg(no_global_oom_handling) cfg # t-libs>no_global_oom_handling removal t-libs>no_global_oom_handling removal Some discussion about best way forward for disabling orphan rule to allow experimentation with no firm conclusion. Comment by @nikomatsakis posted on 2025-03-26: Comment by @nikomatsakis posted on 2025-03-26: Updates from today's meeting: Finalizing 2024h2 goals asm-goto is now stabilized! will be released in 1.87. asm-const has a preliminary impl, gcc support is needed. While not used in RFL, naked_asm is not on the list but it will be moving forward for stabilization. It suffers from the same LLVM bug as global_asm forgetting target feature flags. ABI-modifying compiler flags Andrew Zhogin has opened a draft PR (https://github.com/rust-lang/rust/pull/138736) following Alice's issue about which santisers should be modifiers (https://github.com/rust-lang/rust/issues/138453) Extract dependency information, configure no-std externally (-Zcrate-attr) We decided we don't need to be able to extract dependency information -Zcrate-attr has an RFC from jyn: https://github.com/rust-lang/rfcs/pull/3791 Rustdoc features to extract doc tests No update. Clippy configuration Pre-RFC was published but hasn't (to our knowledge) made progress. Would be good to sync up on next steps with @flip1995. Build-std No update. Progress will resume next week when the contributor working on this returns from holiday. -Zsanitize-kcfi-arity Added this as a new deliverable. These kind of "emerging codegen flag" requests can be expected from time to time. Notes available here and here. The PR has been reviewed and is unblocked to land. Updates from today's meeting : today's meeting Finalizing 2024h2 goals asm-goto is now stabilized! will be released in 1.87. asm-const has a preliminary impl, gcc support is needed. While not used in RFL, naked_asm is not on the list but it will be moving forward for stabilization. It suffers from the same LLVM bug as global_asm forgetting target feature flags. asm-goto is now stabilized! will be released in 1.87. asm-const has a preliminary impl , gcc support is needed. preliminary impl While not used in RFL, naked_asm is not on the list but it will be moving forward for stabilization. It suffers from the same LLVM bug as global_asm forgetting target feature flags. naked_asm global_asm ABI-modifying compiler flags Andrew Zhogin has opened a draft PR (https://github.com/rust-lang/rust/pull/138736) following Alice's issue about which santisers should be modifiers (https://github.com/rust-lang/rust/issues/138453) Andrew Zhogin has opened a draft PR ( https://github.com/rust-lang/rust/pull/138736 ) following Alice's issue about which santisers should be modifiers ( https://github.com/rust-lang/rust/issues/138453 ) https://github.com/rust-lang/rust/pull/138736 https://github.com/rust-lang/rust/issues/138453 Extract dependency information, configure no-std externally (-Zcrate-attr) We decided we don't need to be able to extract dependency information -Zcrate-attr has an RFC from jyn: https://github.com/rust-lang/rfcs/pull/3791 We decided we don't need to be able to extract dependency information -Zcrate-attr has an RFC from jyn: https://github.com/rust-lang/rfcs/pull/3791 -Zcrate-attr https://github.com/rust-lang/rfcs/pull/3791 Rustdoc features to extract doc tests No update. No update. Clippy configuration Pre-RFC was published but hasn't (to our knowledge) made progress. Would be good to sync up on next steps with @flip1995. Pre-RFC was published but hasn't (to our knowledge) made progress. Would be good to sync up on next steps with @flip1995 . Pre-RFC @flip1995 Build-std Build-std No update. Progress will resume next week when the contributor working on this returns from holiday. No update. Progress will resume next week when the contributor working on this returns from holiday. -Zsanitize-kcfi-arity -Zsanitize-kcfi-arity Added this as a new deliverable. These kind of "emerging codegen flag" requests can be expected from time to time. Notes available here and here. The PR has been reviewed and is unblocked to land. Added this as a new deliverable. These kind of "emerging codegen flag" requests can be expected from time to time. Notes available here and here . here here The PR has been reviewed and is unblocked to land. Goals looking for help Promoting Parallel Front End Promoting Parallel Front End Promoting Parallel Front End Help wanted: Help test the deadlock code in the issue list and try to reproduce the issues. If you'd like to help, please post in this goal's dedicated zulip topic . Help wanted: issue list this goal's dedicated zulip topic 1 detailed update available. Comment by @SparrowLii posted on 2025-03-18: Comment by @SparrowLii posted on 2025-03-18: Key developments: Several deadlock issue that remain for more than a year were resolved by #137731 The new test suit for parallel front end is being improved Blockers: null Help wanted: Help test the deadlock code in the issue list and try to reproduce the issue Key developments: Several deadlock issue that remain for more than a year were resolved by #137731 The new test suit for parallel front end is being improved Blockers: null Help wanted: Help test the deadlock code in the issue list and try to reproduce the issue Key developments: Several deadlock issue that remain for more than a year were resolved by #137731 The new test suit for parallel front end is being improved Key developments: Blockers: null Blockers: Help wanted: Help test the deadlock code in the issue list and try to reproduce the issue Help wanted: issue list Stabilize public/private dependencies Stabilize public/private dependencies Stabilize public/private dependencies Help wanted: T-compiler people to work on the blocking issues #119428 and #71043 . If you'd like to help, please post in this goal's dedicated zulip topic . Help wanted: #119428 #71043 this goal's dedicated zulip topic 1 detailed update available. Comment by @epage posted on 2025-03-17: Comment by @epage posted on 2025-03-17: Key developments: @tgross35 got rust-lang/rust#135501 merged which improved which made progress on rust-lang/rust#119428, one of the two main blockers. In rust-lang/rust#119428, we've further discussed further designs and trade offs. Blockers: Further work on rust-lang/rust#119428 and rust-lang/rust#71043 Help wanted: T-compiler people to work on those above issues. Key developments: @tgross35 got rust-lang/rust#135501 merged which improved which made progress on rust-lang/rust#119428, one of the two main blockers. In rust-lang/rust#119428, we've further discussed further designs and trade offs. Blockers: Further work on rust-lang/rust#119428 and rust-lang/rust#71043 Help wanted: T-compiler people to work on those above issues. Key developments: @tgross35 got rust-lang/rust#135501 merged which improved which made progress on rust-lang/rust#119428, one of the two main blockers. In rust-lang/rust#119428, we've further discussed further designs and trade offs. Blockers: Further work on rust-lang/rust#119428 and rust-lang/rust#71043 Help wanted: T-compiler people to work on those above issues. Other goal updates "Stabilizable" prototype for expanded const generics "Stabilizable" prototype for expanded const generics "Stabilizable" prototype for expanded const generics 1 detailed update available. Comment by @BoxyUwU posted on 2025-03-17: Comment by @BoxyUwU posted on 2025-03-17: camelids PR has been merged, we now correctly (to the best of my knowledge) lower const paths under mgca. I have a PR open to ensure that we handle evaluation of paths to consts with generics or inference variables correctly, and that we do not attempt to evaluate constants before they have been checked to be well formed. I'm also currently mentoring someone to implement proper handling of normalization of inherent associated constants under mgca. camelids PR has been merged, we now correctly (to the best of my knowledge) lower const paths under mgca. I have a PR open to ensure that we handle evaluation of paths to consts with generics or inference variables correctly, and that we do not attempt to evaluate constants before they have been checked to be well formed. I'm also currently mentoring someone to implement proper handling of normalization of inherent associated constants under mgca. build-std build-std build-std 1 detailed update available. Comment by @davidtwco posted on 2025-03-03: Comment by @davidtwco posted on 2025-03-03: A small update, @adamgemmell shared revisions to the aforementioned document, further feedback to which is being addressed. A small update, @adamgemmell shared revisions to the aforementioned document , further feedback to which is being addressed. revisions to the aforementioned document Continue resolving `cargo-semver-checks` blockers for merging into cargo Continue resolving `cargo-semver-checks` blockers for merging into cargo Continue resolving `cargo-semver-checks` blockers for merging into cargo Earlier this month, we completed one checkbox of the goal: #[doc(hidden)] in sealed trait analysis, live in cargo-semver-checks v0.40. We also made significant progress on type system modeling, which is part of two more checkboxes. #[doc(hidden)] cargo-semver-checks We shipped method receiver types in our schema, enabling more than a dozen new lints. We have a draft schema for ?Sized bounds, and are putting the finishing touches on 'static and "outlives" bounds. More lints will follow here. We also have a draft schema for the new use<> precise capturing syntax. We shipped method receiver types in our schema, enabling more than a dozen new lints. We have a draft schema for ?Sized bounds, and are putting the finishing touches on 'static and "outlives" bounds. More lints will follow here. ?Sized 'static We also have a draft schema for the new use<> precise capturing syntax. use<> Additionally, cargo-semver-checks is participating in Google Summer of Code, so this month we had the privilege of merging many contributions from new contributors who are considering applying for GSoC with us! We're looking forward to this summer, and would like to wish the candidates good luck in the application process! cargo-semver-checks 1 detailed update available. Comment by @obi1kenobi posted on 2025-03-08: Comment by @obi1kenobi posted on 2025-03-08: Key developments: Sealed trait analysis correctly handles #[doc(hidden)] items. This completes one checkbox of this goal! We shipped a series of lints detecting breakage in generic types, lifetimes, and const generics. One of them has already caught accidental breakage in the real world! cargo-semver-checks v0.40, released today, includes a variety of improvements to sealed trait analysis. They can be summarized as "smarter, faster, more correct," and will have an immediate positive impact on popular crates such as diesel and zerocopy. While we already shipped a series of lints detecting generics-related breakage, more work is needed to complete that checkbox. This, and the "special cases like 'static and ?Sized", will be the focus of upcoming work. Key developments: Key developments: Sealed trait analysis correctly handles #[doc(hidden)] items. This completes one checkbox of this goal! We shipped a series of lints detecting breakage in generic types, lifetimes, and const generics. One of them has already caught accidental breakage in the real world! Sealed trait analysis correctly handles #[doc(hidden)] items. This completes one checkbox of this goal! #[doc(hidden)] We shipped a series of lints detecting breakage in generic types, lifetimes, and const generics. One of them has already caught accidental breakage in the real world! cargo-semver-checks v0.40, released today, includes a variety of improvements to sealed trait analysis. They can be summarized as "smarter, faster, more correct," and will have an immediate positive impact on popular crates such as diesel and zerocopy . cargo-semver-checks diesel zerocopy While we already shipped a series of lints detecting generics-related breakage, more work is needed to complete that checkbox. This, and the "special cases like 'static and ?Sized ", will be the focus of upcoming work. already shipped a series of lints 'static ?Sized Declarative (`macro_rules!`) macro improvements Declarative (`macro_rules!`) macro improvements Declarative (`macro_rules!`) macro improvements No detailed updates available. Evaluate approaches for seamless interop between C++ and Rust Evaluate approaches for seamless interop between C++ and Rust Evaluate approaches for seamless interop between C++ and Rust 1 detailed update available. Comment by @tmandry posted on 2025-03-25: Comment by @tmandry posted on 2025-03-25: Since our last update, there has been talk of dedicating some time at the Rust All Hands for interop discussion; @baumanj and @tmandry are going to work on fleshing out an agenda. @cramertj and @tmandry brainstormed with @oli-obk (who was very helpful) about ways of supporting a more ambitious "template instantiation from Rust" goal, and this may get turned into a prototype at some point. Since our last update, there has been talk of dedicating some time at the Rust All Hands for interop discussion; @baumanj and @tmandry are going to work on fleshing out an agenda. @cramertj and @tmandry brainstormed with @oli-obk (who was very helpful) about ways of supporting a more ambitious "template instantiation from Rust" goal, and this may get turned into a prototype at some point. Experiment with ergonomic ref-counting Experiment with ergonomic ref-counting Experiment with ergonomic ref-counting There is now an early prototype available that allows you to write x.use ; if the type of X implements UseCloned , then this is equivalent to x.clone() , else it is equivalent to a move. This is not the desired end semantics in a few ways, just a step along the road. Nothing to see here (yet). x.use X UseCloned x.clone() 1 detailed update available. Comment by @nikomatsakis posted on 2025-03-17: Comment by @nikomatsakis posted on 2025-03-17: Update: rust-lang/rust#134797 has landed. Semantics as implemented in the PR: Introduced a trait UseCloned implemented for Rc and Arc types. x.use checks whether x's type X implements the UseCloned trait; if so, then x.use is equivalent to x.clone(), otherwise it is a copy/move of x; use || ...x... closures act like move closures but respect the UseCloned trait, so they will either clone, copy, or move x as appropriate. Next steps: Modify codegen so that we guarantee that x.use will do a copy if X: Copy is true after monomorphization. Right now the desugaring to clone occurs before monomorphization and hence it will call the clone method even for those instances where X is a Copy type. Convert x.use to a move rather than a clone if this is a last-use. Make x equivalent to x.use but with an (allow-by-default) lint to signal that something special is happened. Notable decisions made and discussions: Opted to name the trait that controls whether x.use does a clone or a move UseCloned rather than Use. This is because the trait does not control whether or not you can use something but rather controls what happens when you do. Question was raised on Zulip as to whether x.use should auto-deref. After thinking it over, reached the conclusion that it should not, because x and x.use should eventually behave the same modulo lints, but that (as ever) a &T -> T coercion would be useful for ergonomic reasons. Update: rust-lang/rust#134797 has landed. Semantics as implemented in the PR: Introduced a trait UseCloned implemented for Rc and Arc types. x.use checks whether x's type X implements the UseCloned trait; if so, then x.use is equivalent to x.clone(), otherwise it is a copy/move of x; use || ...x... closures act like move closures but respect the UseCloned trait, so they will either clone, copy, or move x as appropriate. Introduced a trait UseCloned implemented for Rc and Arc types. UseCloned Rc Arc x.use checks whether x 's type X implements the UseCloned trait; if so, then x.use is equivalent to x.clone() , otherwise it is a copy/move of x ; x.use x X UseCloned x.use x.clone() x use || ...x... closures act like move closures but respect the UseCloned trait, so they will either clone , copy, or move x as appropriate. use || ...x... move UseCloned clone x Next steps: Modify codegen so that we guarantee that x.use will do a copy if X: Copy is true after monomorphization. Right now the desugaring to clone occurs before monomorphization and hence it will call the clone method even for those instances where X is a Copy type. Convert x.use to a move rather than a clone if this is a last-use. Make x equivalent to x.use but with an (allow-by-default) lint to signal that something special is happened. Modify codegen so that we guarantee that x.use will do a copy if X: Copy is true after monomorphization. Right now the desugaring to clone occurs before monomorphization and hence it will call the clone method even for those instances where X is a Copy type. x.use X: Copy clone clone X Copy Convert x.use to a move rather than a clone if this is a last-use. x.use Make x equivalent to x.use but with an (allow-by-default) lint to signal that something special is happened. x x.use Notable decisions made and discussions: Opted to name the trait that controls whether x.use does a clone or a move UseCloned rather than Use. This is because the trait does not control whether or not you can use something but rather controls what happens when you do. Question was raised on Zulip as to whether x.use should auto-deref. After thinking it over, reached the conclusion that it should not, because x and x.use should eventually behave the same modulo lints, but that (as ever) a &T -> T coercion would be useful for ergonomic reasons. Opted to name the trait that controls whether x.use does a clone or a move UseCloned rather than Use . This is because the trait does not control whether or not you can use something but rather controls what happens when you do. x.use UseCloned Use Question was raised on Zulip as to whether x.use should auto-deref. After thinking it over, reached the conclusion that it should not , because x and x.use should eventually behave the same modulo lints, but that (as ever) a &T -> T coercion would be useful for ergonomic reasons. Question was raised on Zulip x.use it should not x x.use &T -> T Expose experimental LLVM features for GPU offloading Expose experimental LLVM features for GPU offloading Expose experimental LLVM features for GPU offloading 1 detailed update available. Comment by @ZuseZ4 posted on 2025-03-25: Comment by @ZuseZ4 posted on 2025-03-25: I just noticed that I missed my February update, so I'll keep this update a bit more high-level, to not make it too long. Key developments: All key autodiff PRs got merged. So after building rust-lang/rust with the autodiff feature enabled, users can now use it, without the need for any custom fork. std::autodiff received the first PRs from new contributors, which have not been previously involved in rustc development! My plan is to grow a team to maintain this feature, so that's a great start. The PRs are here, here and here. Over time I hope to hand over increasingly larger issues. I received an offer to join the Rust compiler team, so now I can also officially review and approve PRs! For now I'll focus on reviewing PRs in the fields I'm most comfortable with, so autodiff, batching, and soon GPU offload. I implemented a standalone batching feature. It was a bit larger (~2k LoC) and needed some (back then unmerged) autodiff PRs, since they both use the same underlying Enzyme infrastructure. I therefore did not push for merging it. I recently implemented batching as part of the autodiff macro, for people who want to use both together. I subsequently split out a first set of code improvements and refactorings, which already got merged. The remaining autodiff feature PR is only 600 loc, so I'm currently cleaning it up for review. I spend time preparing an MCP to enable autodiff in CI (and therefore nightly). I also spend a lot of time discussing a potential MLIR backend for rustc. Please reach out if you want to be involved! **Help wanted: ** We want to support autodiff in lib builds, instead of only binaries. oli-obk and I recently figured out the underlying bug, and I started with a PR in https://github.com/rust-lang/rust/pull/137570. The problem is that autodiff assumes fat-lto builds, but lib builds compile some of the library code using thin-lto, even if users specify lto=fat in their Cargo.toml. We'd want to move every thing to fat-lto if we enable Autodiff as a temporary solution, and later move towards embed-bc as a longer-term solution. If you have some time to help please reach out! Some of us have already looked into it a little but got side-tracked, so it's better to talk first about which code to re-use, rather than starting from scratch. I also booked my RustWeek ticket, so I'm happy to talk about all types of Scientific Computing, HPC, ML, or cursed Rust(c) and LLVM internals! Please feel free to dm me if you're also going and want to meet. I just noticed that I missed my February update, so I'll keep this update a bit more high-level, to not make it too long. Key developments: Key developments: All key autodiff PRs got merged. So after building rust-lang/rust with the autodiff feature enabled, users can now use it, without the need for any custom fork. std::autodiff received the first PRs from new contributors, which have not been previously involved in rustc development! My plan is to grow a team to maintain this feature, so that's a great start. The PRs are here, here and here. Over time I hope to hand over increasingly larger issues. I received an offer to join the Rust compiler team, so now I can also officially review and approve PRs! For now I'll focus on reviewing PRs in the fields I'm most comfortable with, so autodiff, batching, and soon GPU offload. I implemented a standalone batching feature. It was a bit larger (~2k LoC) and needed some (back then unmerged) autodiff PRs, since they both use the same underlying Enzyme infrastructure. I therefore did not push for merging it. I recently implemented batching as part of the autodiff macro, for people who want to use both together. I subsequently split out a first set of code improvements and refactorings, which already got merged. The remaining autodiff feature PR is only 600 loc, so I'm currently cleaning it up for review. I spend time preparing an MCP to enable autodiff in CI (and therefore nightly). I also spend a lot of time discussing a potential MLIR backend for rustc. Please reach out if you want to be involved! All key autodiff PRs got merged. So after building rust-lang/rust with the autodiff feature enabled, users can now use it, without the need for any custom fork. rust-lang/rust std::autodiff received the first PRs from new contributors, which have not been previously involved in rustc development! My plan is to grow a team to maintain this feature, so that's a great start. The PRs are here , here and here . Over time I hope to hand over increasingly larger issues. here here here I received an offer to join the Rust compiler team, so now I can also officially review and approve PRs! For now I'll focus on reviewing PRs in the fields I'm most comfortable with, so autodiff, batching, and soon GPU offload. I implemented a standalone batching feature. It was a bit larger (~2k LoC) and needed some (back then unmerged) autodiff PRs, since they both use the same underlying Enzyme infrastructure. I therefore did not push for merging it. I recently implemented batching as part of the autodiff macro, for people who want to use both together. I subsequently split out a first set of code improvements and refactorings, which already got merged . The remaining autodiff feature PR is only 600 loc, so I'm currently cleaning it up for review. got merged PR I spend time preparing an MCP to enable autodiff in CI (and therefore nightly). I also spend a lot of time discussing a potential MLIR backend for rustc. Please reach out if you want to be involved! **Help wanted: ** We want to support autodiff in lib builds, instead of only binaries. oli-obk and I recently figured out the underlying bug, and I started with a PR in https://github.com/rust-lang/rust/pull/137570. The problem is that autodiff assumes fat-lto builds, but lib builds compile some of the library code using thin-lto, even if users specify lto=fat in their Cargo.toml. We'd want to move every thing to fat-lto if we enable Autodiff as a temporary solution, and later move towards embed-bc as a longer-term solution. If you have some time to help please reach out! Some of us have already looked into it a little but got side-tracked, so it's better to talk first about which code to re-use, rather than starting from scratch. lto=fat I also booked my RustWeek ticket, so I'm happy to talk about all types of Scientific Computing, HPC, ML, or cursed Rust(c) and LLVM internals! Please feel free to dm me if you're also going and want to meet. Extend pubgrub to match cargo's dependency resolution Extend pubgrub to match cargo's dependency resolution Extend pubgrub to match cargo's dependency resolution 1 detailed update available. Comment by @Eh2406 posted on 2025-03-14: Comment by @Eh2406 posted on 2025-03-14: Progress continues to be stalled by high priority tasks for $DAY_JOB. It continues to be unclear when the demands of work will allow me to return focus to this project. Progress continues to be stalled by high priority tasks for $DAY_JOB. It continues to be unclear when the demands of work will allow me to return focus to this project. Externally Implementable Items Externally Implementable Items Externally Implementable Items No detailed updates available. Finish the libtest json output experiment Finish the libtest json output experiment Finish the libtest json output experiment 1 detailed update available. Comment by @epage posted on 2025-03-17: Comment by @epage posted on 2025-03-17: Key developments: Between tasks on #92, I've started to refresh myself on the libtest-next code base Blockers: Help wanted: Key developments: Between tasks on #92, I've started to refresh myself on the libtest-next code base Blockers: Help wanted: Key developments: Between tasks on #92, I've started to refresh myself on the libtest-next code base Between tasks on #92, I've started to refresh myself on the libtest-next code base Between tasks on #92, I've started to refresh myself on the libtest-next code base Blockers: Help wanted: Implement Open API Namespace Support Implement Open API Namespace Support Implement Open API Namespace Support No detailed updates available. Implement restrictions, prepare for stabilization Implement restrictions, prepare for stabilization Implement restrictions, prepare for stabilization No detailed updates available. Improve state machine codegen Improve state machine codegen Improve state machine codegen We've started work on implementing #[loop_match] on this branch . For the time being integer and enum patterns are supported. The benchmarks , are extremely encouraging, showing large improvements over the status quo, and significant improvements versus -Cllvm-args=-enable-dfa-jump-thread . #[loop_match] this branch benchmarks -Cllvm-args=-enable-dfa-jump-thread Our next steps can be found in the todo file , and focus mostly on improving the code quality and robustness. todo file 3 detailed updates available. Comment by @folkertdev posted on 2025-03-18: Comment by @folkertdev posted on 2025-03-18: @traviscross how would we make progress on that? So far we've mostly been talking to @joshtriplett, under the assumption that a #[loop_match] attribute on loops combined with a #[const_continue] attribute on "jumps to the next iteration" will be acceptable as a language experiment. Our current implementation handles the following #![feature(loop_match)] enum State { A, B, } fn main() { let mut state = State::A; #[loop_match] 'outer: loop { state = 'blk: { match state { State::A => { #[const_continue] break 'blk State::B } State::B => break 'outer, } } } } Crucially, this does not add syntax, only the attributes and internal logic in MIR lowering for statically performing the pattern match to pick the right branch to jump to. The main challenge is then to implement this in the compiler itself, which we've been working on (I'll post our tl;dr update shortly) @traviscross how would we make progress on that? So far we've mostly been talking to @joshtriplett, under the assumption that a #[loop_match] attribute on loops combined with a #[const_continue] attribute on "jumps to the next iteration" will be acceptable as a language experiment. #[loop_match] #[const_continue] Our current implementation handles the following #![feature(loop_match)] enum State { A, B, } fn main() { let mut state = State::A; #[loop_match] 'outer: loop { state = 'blk: { match state { State::A => { #[const_continue] break 'blk State::B } State::B => break 'outer, } } } } #![feature(loop_match)] enum State { A, B, } fn main() { let mut state = State::A; #[loop_match] 'outer: loop { state = 'blk: { match state { State::A => { #[const_continue] break 'blk State::B } State::B => break 'outer, } } } } Crucially, this does not add syntax, only the attributes and internal logic in MIR lowering for statically performing the pattern match to pick the right branch to jump to. The main challenge is then to implement this in the compiler itself, which we've been working on (I'll post our tl;dr update shortly) Comment by @folkertdev posted on 2025-03-18: Comment by @folkertdev posted on 2025-03-18: Some benchmarks (as of march 18th) A benchmark of https://github.com/bjorn3/comrak/blob/loop_match_attr/autolink_email.rs, basically a big state machine that is a perfect fit for loop match Benchmark 1: ./autolink_email Time (mean ± σ): 1.126 s ± 0.012 s [User: 1.126 s, System: 0.000 s] Range (min … max): 1.105 s … 1.141 s 10 runs Benchmark 2: ./autolink_email_llvm_dfa Time (mean ± σ): 583.9 ms ± 6.9 ms [User: 581.8 ms, System: 2.0 ms] Range (min … max): 575.4 ms … 591.3 ms 10 runs Benchmark 3: ./autolink_email_loop_match Time (mean ± σ): 411.4 ms ± 8.8 ms [User: 410.1 ms, System: 1.3 ms] Range (min … max): 403.2 ms … 430.4 ms 10 runs Summary ./autolink_email_loop_match ran 1.42 ± 0.03 times faster than ./autolink_email_llvm_dfa 2.74 ± 0.07 times faster than ./autolink_email #[loop_match] beats the status quo, but also beats the llvm flag by a large margin. Some benchmarks (as of march 18th) A benchmark of https://github.com/bjorn3/comrak/blob/loop_match_attr/autolink_email.rs, basically a big state machine that is a perfect fit for loop match Benchmark 1: ./autolink_email Time (mean ± σ): 1.126 s ± 0.012 s [User: 1.126 s, System: 0.000 s] Range (min … max): 1.105 s … 1.141 s 10 runs Benchmark 2: ./autolink_email_llvm_dfa Time (mean ± σ): 583.9 ms ± 6.9 ms [User: 581.8 ms, System: 2.0 ms] Range (min … max): 575.4 ms … 591.3 ms 10 runs Benchmark 3: ./autolink_email_loop_match Time (mean ± σ): 411.4 ms ± 8.8 ms [User: 410.1 ms, System: 1.3 ms] Range (min … max): 403.2 ms … 430.4 ms 10 runs Summary ./autolink_email_loop_match ran 1.42 ± 0.03 times faster than ./autolink_email_llvm_dfa 2.74 ± 0.07 times faster than ./autolink_email Benchmark 1: ./autolink_email Time (mean ± σ): 1.126 s ± 0.012 s [User: 1.126 s, System: 0.000 s] Range (min … max): 1.105 s … 1.141 s 10 runs Benchmark 2: ./autolink_email_llvm_dfa Time (mean ± σ): 583.9 ms ± 6.9 ms [User: 581.8 ms, System: 2.0 ms] Range (min … max): 575.4 ms … 591.3 ms 10 runs Benchmark 3: ./autolink_email_loop_match Time (mean ± σ): 411.4 ms ± 8.8 ms [User: 410.1 ms, System: 1.3 ms] Range (min … max): 403.2 ms … 430.4 ms 10 runs Summary ./autolink_email_loop_match ran 1.42 ± 0.03 times faster than ./autolink_email_llvm_dfa 2.74 ± 0.07 times faster than ./autolink_email #[loop_match] beats the status quo, but also beats the llvm flag by a large margin. #[loop_match] A benchmark of zlib decompression with chunks of 16 bytes (this makes the impact of loop_match more visible) Benchmark 1 (65 runs): target/release/examples/uncompress-baseline rs-chunked 4 measurement mean ± σ min … max outliers delta wall_time 77.7ms ± 3.04ms 74.6ms … 88.9ms 9 (14%) 0% peak_rss 24.1MB ± 64.6KB 24.0MB … 24.2MB 0 ( 0%) 0% cpu_cycles 303M ± 11.8M 293M … 348M 9 (14%) 0% instructions 833M ± 266 833M … 833M 0 ( 0%) 0% cache_references 3.62M ± 310K 3.19M … 4.93M 1 ( 2%) 0% cache_misses 209K ± 34.2K 143K … 325K 1 ( 2%) 0% branch_misses 4.09M ± 10.0K 4.08M … 4.13M 5 ( 8%) 0% Benchmark 2 (68 runs): target/release/examples/uncompress-llvm-dfa rs-chunked 4 measurement mean ± σ min … max outliers delta wall_time 74.0ms ± 3.24ms 70.6ms … 85.0ms 4 ( 6%) 🚀- 4.8% ± 1.4% peak_rss 24.1MB ± 27.1KB 24.0MB … 24.1MB 3 ( 4%) - 0.1% ± 0.1% cpu_cycles 287M ± 12.7M 277M … 330M 4 ( 6%) 🚀- 5.4% ± 1.4% instructions 797M ± 235 797M … 797M 0 ( 0%) 🚀- 4.3% ± 0.0% cache_references 3.56M ± 439K 3.08M … 5.93M 2 ( 3%) - 1.8% ± 3.6% cache_misses 144K ± 32.5K 83.7K … 249K 2 ( 3%) 🚀- 31.2% ± 5.4% branch_misses 4.09M ± 9.62K 4.07M … 4.12M 1 ( 1%) - 0.1% ± 0.1% Benchmark 3 (70 runs): target/release/examples/uncompress-loop-match rs-chunked 4 measurement mean ± σ min … max outliers delta wall_time 71.6ms ± 2.43ms 69.3ms … 78.8ms 6 ( 9%) 🚀- 7.8% ± 1.2% peak_rss 24.1MB ± 72.8KB 23.9MB … 24.2MB 20 (29%) - 0.0% ± 0.1% cpu_cycles 278M ± 9.59M 270M … 305M 7 (10%) 🚀- 8.5% ± 1.2% instructions 779M ± 277 779M … 779M 0 ( 0%) 🚀- 6.6% ± 0.0% cache_references 3.49M ± 270K 3.15M … 4.17M 4 ( 6%) 🚀- 3.8% ± 2.7% cache_misses 142K ± 25.6K 86.0K … 197K 0 ( 0%) 🚀- 32.0% ± 4.8% branch_misses 4.09M ± 7.83K 4.08M … 4.12M 1 ( 1%) + 0.0% ± 0.1% Benchmark 4 (69 runs): target/release/examples/uncompress-llvm-dfa-loop-match rs-chunked 4 measurement mean ± σ min … max outliers delta wall_time 72.8ms ± 2.57ms 69.7ms … 80.0ms 7 (10%) 🚀- 6.3% ± 1.2% peak_rss 24.1MB ± 35.1KB 23.9MB … 24.1MB 2 ( 3%) - 0.1% ± 0.1% cpu_cycles 281M ± 10.1M 269M … 312M 5 ( 7%) 🚀- 7.5% ± 1.2% instructions 778M ± 243 778M … 778M 0 ( 0%) 🚀- 6.7% ± 0.0% cache_references 3.45M ± 277K 2.95M … 4.14M 0 ( 0%) 🚀- 4.7% ± 2.7% cache_misses 176K ± 43.4K 106K … 301K 0 ( 0%) 🚀- 15.8% ± 6.3% branch_misses 4.16M ± 96.0K 4.08M … 4.37M 0 ( 0%) 💩+ 1.7% ± 0.6% The important points: loop-match is faster than llfm-dfa, and when combined performance is worse than when using loop-match on its own. A benchmark of zlib decompression with chunks of 16 bytes (this makes the impact of loop_match more visible) loop_match Benchmark 1 (65 runs): target/release/examples/uncompress-baseline rs-chunked 4 measurement mean ± σ min … max outliers delta wall_time 77.7ms ± 3.04ms 74.6ms … 88.9ms 9 (14%) 0% peak_rss 24.1MB ± 64.6KB 24.0MB … 24.2MB 0 ( 0%) 0% cpu_cycles 303M ± 11.8M 293M … 348M 9 (14%) 0% instructions 833M ± 266 833M … 833M 0 ( 0%) 0% cache_references 3.62M ± 310K 3.19M … 4.93M 1 ( 2%) 0% cache_misses 209K ± 34.2K 143K … 325K 1 ( 2%) 0% branch_misses 4.09M ± 10.0K 4.08M … 4.13M 5 ( 8%) 0% Benchmark 2 (68 runs): target/release/examples/uncompress-llvm-dfa rs-chunked 4 measurement mean ± σ min … max outliers delta wall_time 74.0ms ± 3.24ms 70.6ms … 85.0ms 4 ( 6%) 🚀- 4.8% ± 1.4% peak_rss 24.1MB ± 27.1KB 24.0MB … 24.1MB 3 ( 4%) - 0.1% ± 0.1% cpu_cycles 287M ± 12.7M 277M … 330M 4 ( 6%) 🚀- 5.4% ± 1.4% instructions 797M ± 235 797M … 797M 0 ( 0%) 🚀- 4.3% ± 0.0% cache_references 3.56M ± 439K 3.08M … 5.93M 2 ( 3%) - 1.8% ± 3.6% cache_misses 144K ± 32.5K 83.7K … 249K 2 ( 3%) 🚀- 31.2% ± 5.4% branch_misses 4.09M ± 9.62K 4.07M … 4.12M 1 ( 1%) - 0.1% ± 0.1% Benchmark 3 (70 runs): target/release/examples/uncompress-loop-match rs-chunked 4 measurement mean ± σ min … max outliers delta wall_time 71.6ms ± 2.43ms 69.3ms … 78.8ms 6 ( 9%) 🚀- 7.8% ± 1.2% peak_rss 24.1MB ± 72.8KB 23.9MB … 24.2MB 20 (29%) - 0.0% ± 0.1% cpu_cycles 278M ± 9.59M 270M … 305M 7 (10%) 🚀- 8.5% ± 1.2% instructions 779M ± 277 779M … 779M 0 ( 0%) 🚀- 6.6% ± 0.0% cache_references 3.49M ± 270K 3.15M … 4.17M 4 ( 6%) 🚀- 3.8% ± 2.7% cache_misses 142K ± 25.6K 86.0K … 197K 0 ( 0%) 🚀- 32.0% ± 4.8% branch_misses 4.09M ± 7.83K 4.08M … 4.12M 1 ( 1%) + 0.0% ± 0.1% Benchmark 4 (69 runs): target/release/examples/uncompress-llvm-dfa-loop-match rs-chunked 4 measurement mean ± σ min … max outliers delta wall_time 72.8ms ± 2.57ms 69.7ms … 80.0ms 7 (10%) 🚀- 6.3% ± 1.2% peak_rss 24.1MB ± 35.1KB 23.9MB … 24.1MB 2 ( 3%) - 0.1% ± 0.1% cpu_cycles 281M ± 10.1M 269M … 312M 5 ( 7%) 🚀- 7.5% ± 1.2% instructions 778M ± 243 778M … 778M 0 ( 0%) 🚀- 6.7% ± 0.0% cache_references 3.45M ± 277K 2.95M … 4.14M 0 ( 0%) 🚀- 4.7% ± 2.7% cache_misses 176K ± 43.4K 106K … 301K 0 ( 0%) 🚀- 15.8% ± 6.3% branch_misses 4.16M ± 96.0K 4.08M … 4.37M 0 ( 0%) 💩+ 1.7% ± 0.6% Benchmark 1 (65 runs): target/release/examples/uncompress-baseline rs-chunked 4 measurement mean ± σ min … max outliers delta wall_time 77.7ms ± 3.04ms 74.6ms … 88.9ms 9 (14%) 0% peak_rss 24.1MB ± 64.6KB 24.0MB … 24.2MB 0 ( 0%) 0% cpu_cycles 303M ± 11.8M 293M … 348M 9 (14%) 0% instructions 833M ± 266 833M … 833M 0 ( 0%) 0% cache_references 3.62M ± 310K 3.19M … 4.93M 1 ( 2%) 0% cache_misses 209K ± 34.2K 143K … 325K 1 ( 2%) 0% branch_misses 4.09M ± 10.0K 4.08M … 4.13M 5 ( 8%) 0% Benchmark 2 (68 runs): target/release/examples/uncompress-llvm-dfa rs-chunked 4 measurement mean ± σ min … max outliers delta wall_time 74.0ms ± 3.24ms 70.6ms … 85.0ms 4 ( 6%) 🚀- 4.8% ± 1.4% peak_rss 24.1MB ± 27.1KB 24.0MB … 24.1MB 3 ( 4%) - 0.1% ± 0.1% cpu_cycles 287M ± 12.7M 277M … 330M 4 ( 6%) 🚀- 5.4% ± 1.4% instructions 797M ± 235 797M … 797M 0 ( 0%) 🚀- 4.3% ± 0.0% cache_references 3.56M ± 439K 3.08M … 5.93M 2 ( 3%) - 1.8% ± 3.6% cache_misses 144K ± 32.5K 83.7K … 249K 2 ( 3%) 🚀- 31.2% ± 5.4% branch_misses 4.09M ± 9.62K 4.07M … 4.12M 1 ( 1%) - 0.1% ± 0.1% Benchmark 3 (70 runs): target/release/examples/uncompress-loop-match rs-chunked 4 measurement mean ± σ min … max outliers delta wall_time 71.6ms ± 2.43ms 69.3ms … 78.8ms 6 ( 9%) 🚀- 7.8% ± 1.2% peak_rss 24.1MB ± 72.8KB 23.9MB … 24.2MB 20 (29%) - 0.0% ± 0.1% cpu_cycles 278M ± 9.59M 270M … 305M 7 (10%) 🚀- 8.5% ± 1.2% instructions 779M ± 277 779M … 779M 0 ( 0%) 🚀- 6.6% ± 0.0% cache_references 3.49M ± 270K 3.15M … 4.17M 4 ( 6%) 🚀- 3.8% ± 2.7% cache_misses 142K ± 25.6K 86.0K … 197K 0 ( 0%) 🚀- 32.0% ± 4.8% branch_misses 4.09M ± 7.83K 4.08M … 4.12M 1 ( 1%) + 0.0% ± 0.1% Benchmark 4 (69 runs): target/release/examples/uncompress-llvm-dfa-loop-match rs-chunked 4 measurement mean ± σ min … max outliers delta wall_time 72.8ms ± 2.57ms 69.7ms … 80.0ms 7 (10%) 🚀- 6.3% ± 1.2% peak_rss 24.1MB ± 35.1KB 23.9MB … 24.1MB 2 ( 3%) - 0.1% ± 0.1% cpu_cycles 281M ± 10.1M 269M … 312M 5 ( 7%) 🚀- 7.5% ± 1.2% instructions 778M ± 243 778M … 778M 0 ( 0%) 🚀- 6.7% ± 0.0% cache_references 3.45M ± 277K 2.95M … 4.14M 0 ( 0%) 🚀- 4.7% ± 2.7% cache_misses 176K ± 43.4K 106K … 301K 0 ( 0%) 🚀- 15.8% ± 6.3% branch_misses 4.16M ± 96.0K 4.08M … 4.37M 0 ( 0%) 💩+ 1.7% ± 0.6% The important points: loop-match is faster than llfm-dfa , and when combined performance is worse than when using loop-match on its own. loop-match llfm-dfa loop-match Comment by @traviscross posted on 2025-03-18: Comment by @traviscross posted on 2025-03-18: Thanks for that update. Have reached out separately. Thanks for that update. Have reached out separately. Instrument the Rust standard library with safety contracts Instrument the Rust standard library with safety contracts Instrument the Rust standard library with safety contracts 1 detailed update available. Comment by @celinval posted on 2025-03-17: Comment by @celinval posted on 2025-03-17: We have been able to merge the initial support for contracts in the Rust compiler under the contracts unstable feature. @tautschnig has created the first PR to incorporate contracts in the standard library and uncovered a few limitations that we've been working on. We have been able to merge the initial support for contracts in the Rust compiler under the contracts unstable feature. @tautschnig has created the first PR to incorporate contracts in the standard library and uncovered a few limitations that we've been working on. contracts Making compiletest more maintainable: reworking directive handling Making compiletest more maintainable: reworking directive handling Making compiletest more maintainable: reworking directive handling 1 detailed update available. Comment by @jieyouxu posted on 2025-03-15: Comment by @jieyouxu posted on 2025-03-15: Update (2025-03-15): Doing a survey pass on compiletest to make sure I have the full picture. Update (2025-03-15): Doing a survey pass on compiletest to make sure I have the full picture. Doing a survey pass on compiletest to make sure I have the full picture. Metrics Initiative Metrics Initiative Metrics Initiative 1 detailed update available. Comment by @yaahc posted on 2025-03-03: Comment by @yaahc posted on 2025-03-03: After further review I've decided to limit scope initially and not get ahead of myself so I can make sure the schemas I'm working with can support the kind of queries and charts we're going to eventually want in the final version of the unstable feature usage metric. I'm hoping that by limiting scope I can have most of the items currently outlined in this project goal done ahead of schedule so I can move onto building the proper foundations based on the proof of concept and start to design more permanent components. As such I've opted for the following: minimal change to the current JSON format I need, which is including the timestamp Gain clarity on exactly what questions I should be answering with the unstable feature usage metrics, the desired graphs and tables, and how this influences what information I need to gather and how to construct the appropriate queries within graphana gathering a sample dataset from docs.rs rather than viewing it as the long term integration, since there are definitely some sampleset bias issues in that dataset from initial conversations with docs.rs Figure out proper hash/id to use in the metrics file names to avoid collisions with different conditional compilation variants of the same crate with different feature enabled. For the second item above I need to have more detailed conversations with both @rust-lang/libs-api and @rust-lang/lang After further review I've decided to limit scope initially and not get ahead of myself so I can make sure the schemas I'm working with can support the kind of queries and charts we're going to eventually want in the final version of the unstable feature usage metric. I'm hoping that by limiting scope I can have most of the items currently outlined in this project goal done ahead of schedule so I can move onto building the proper foundations based on the proof of concept and start to design more permanent components. As such I've opted for the following: minimal change to the current JSON format I need, which is including the timestamp Gain clarity on exactly what questions I should be answering with the unstable feature usage metrics, the desired graphs and tables, and how this influences what information I need to gather and how to construct the appropriate queries within graphana gathering a sample dataset from docs.rs rather than viewing it as the long term integration, since there are definitely some sampleset bias issues in that dataset from initial conversations with docs.rs Figure out proper hash/id to use in the metrics file names to avoid collisions with different conditional compilation variants of the same crate with different feature enabled. minimal change to the current JSON format I need, which is including the timestamp Gain clarity on exactly what questions I should be answering with the unstable feature usage metrics, the desired graphs and tables, and how this influences what information I need to gather and how to construct the appropriate queries within graphana gathering a sample dataset from docs.rs rather than viewing it as the long term integration, since there are definitely some sampleset bias issues in that dataset from initial conversations with docs.rs Figure out proper hash/id to use in the metrics file names to avoid collisions with different conditional compilation variants of the same crate with different feature enabled. Figure out proper hash/id to use in the metrics file names to avoid collisions with different conditional compilation variants of the same crate with different feature enabled. Figure out proper hash/id to use in the metrics file names to avoid collisions with different conditional compilation variants of the same crate with different feature enabled. For the second item above I need to have more detailed conversations with both @rust-lang/libs-api and @rust-lang/lang Model coherence in a-mir-formality Model coherence in a-mir-formality Model coherence in a-mir-formality 1 detailed update available. Comment by @nikomatsakis posted on 2025-03-17: Comment by @nikomatsakis posted on 2025-03-17: Update: @tiif has been working on integrating const-generic effects into a-mir-formality and making good progress. I have begun exploring integration of the MiniRust definition of MIR. This doesn't directly work towards the goal of modeling coherence but it will be needed for const generic work to be effective. I am considering some simplification and cleanup work as well. Update: @tiif has been working on integrating const-generic effects into a-mir-formality and making good progress. I have begun exploring integration of the MiniRust definition of MIR. This doesn't directly work towards the goal of modeling coherence but it will be needed for const generic work to be effective. MiniRust I am considering some simplification and cleanup work as well. Next-generation trait solver Next-generation trait solver Next-generation trait solver 1 detailed update available. Comment by @lcnr posted on 2025-03-17: Comment by @lcnr posted on 2025-03-17: The two cycle handling PRs mentioned in the previous update have been merged, allowing nalgebra to compile with the new solver enabled. I have now started to work on opaque types in borrowck again. This is a quite involved issue and will likely take a few more weeks until it's fully implemented. The two cycle handling PRs mentioned in the previous update have been merged, allowing nalgebra to compile with the new solver enabled. I have now started to work on opaque types in borrowck again. This is a quite involved issue and will likely take a few more weeks until it's fully implemented. nalgebra Nightly support for ergonomic SIMD multiversioning Nightly support for ergonomic SIMD multiversioning Nightly support for ergonomic SIMD multiversioning 1 detailed update available. Comment by @veluca93 posted on 2025-03-17: Comment by @veluca93 posted on 2025-03-17: Key developments: Started investigating how the proposed SIMD multiversioning options might fit in the context of the efforts for formalizing a Rust effect system Key developments: Started investigating how the proposed SIMD multiversioning options might fit in the context of the efforts for formalizing a Rust effect system Null and enum-discriminant runtime checks in debug builds Null and enum-discriminant runtime checks in debug builds Null and enum-discriminant runtime checks in debug builds No detailed updates available. Optimizing Clippy & linting Optimizing Clippy & linting Optimizing Clippy & linting 1 detailed update available. Comment by @blyxyas posted on 2025-03-17: Comment by @blyxyas posted on 2025-03-17: Monthly update! https://github.com/rust-lang/rust-clippy/issues/13821 has been merged. This has successfully optimized the MSRV extraction from the source code. On the old MSRV extraction,Symbol::intern use was sky high being about 3.5 times higher than the rest of the compilation combined. Now, it's at normal levels. Note that Symbol::intern is a very expensive and locking function, so this is very notable. Thanks to @Alexendoo for this incredible work! As a general note on the month, I'd say that we've experimented a lot. Starting efforts on parallelizing the lint system. https://github.com/rust-lang/rust-clippy/issues/14423 Started taking a deeper look into our dependence on libLLVM.so and heavy relocation problems. I took a look into heap allocation optimization, seems that we are fine. For the moment, rust-clippy#14423 is the priority. Monthly update! https://github.com/rust-lang/rust-clippy/issues/13821 has been merged. This has successfully optimized the MSRV extraction from the source code. https://github.com/rust-lang/rust-clippy/issues/13821 has been merged. This has successfully optimized the MSRV extraction from the source code. On the old MSRV extraction, Symbol::intern use was sky high being about 3.5 times higher than the rest of the compilation combined. Now, it's at normal levels. Note that Symbol::intern is a very expensive and locking function, so this is very notable. Thanks to @Alexendoo for this incredible work! Symbol::intern Symbol::intern As a general note on the month, I'd say that we've experimented a lot. Starting efforts on parallelizing the lint system. https://github.com/rust-lang/rust-clippy/issues/14423 Started taking a deeper look into our dependence on libLLVM.so and heavy relocation problems. I took a look into heap allocation optimization, seems that we are fine. For the moment, rust-clippy#14423 is the priority. Starting efforts on parallelizing the lint system. https://github.com/rust-lang/rust-clippy/issues/14423 Started taking a deeper look into our dependence on libLLVM.so and heavy relocation problems. libLLVM.so I took a look into heap allocation optimization, seems that we are fine. For the moment, rust-clippy#14423 is the priority. Prepare const traits for stabilization Prepare const traits for stabilization Prepare const traits for stabilization 1 detailed update available. Comment by @oli-obk posted on 2025-03-20: Comment by @oli-obk posted on 2025-03-20: I opened an RFC (https://github.com/rust-lang/rfcs/pull/3762) and we had a lang team meeting about it. Some design exploration and bikeshedding later we have settled on using (const)instead of ~const along with some more annotations for explicitness and some fewer annotations in other places. The RFC has been updated accordingly. There is still ongoing discussions about reintroducing the "fewer annotations" for redundancy and easier processing by humans. I opened an RFC (https://github.com/rust-lang/rfcs/pull/3762) and we had a lang team meeting about it. Some design exploration and bikeshedding later we have settled on using (const)instead of ~const along with some more annotations for explicitness and some fewer annotations in other places. The RFC has been updated accordingly. There is still ongoing discussions about reintroducing the "fewer annotations" for redundancy and easier processing by humans. Prototype a new set of Cargo "plumbing" commands Prototype a new set of Cargo "plumbing" commands Prototype a new set of Cargo "plumbing" commands No detailed updates available. Publish first rust-lang-owned release of "FLS" Publish first rust-lang-owned release of "FLS" Publish first rust-lang-owned release of "FLS" 2 detailed updates available. Comment by @JoelMarcey posted on 2025-03-14: Comment by @JoelMarcey posted on 2025-03-14: Key Developments: Working on a public announcement of Ferrous' contribution of the FLS. Goal is to have that released soon. Also working out the technical details of the contribution, particularly around how to initially integrate the FLS into the Project itself. Blockers: None yet. Key Developments: Working on a public announcement of Ferrous' contribution of the FLS. Goal is to have that released soon. Also working out the technical details of the contribution, particularly around how to initially integrate the FLS into the Project itself. Blockers: None yet. Comment by @JoelMarcey posted on 2025-04-01: Comment by @JoelMarcey posted on 2025-04-01: Key Developments: Public announcement of the FLS donation to the Rust Project. Blockers: None Key Developments: Public announcement of the FLS donation to the Rust Project . announcement Project Blockers: None Publish first version of StableMIR on crates.io Publish first version of StableMIR on crates.io Publish first version of StableMIR on crates.io 2 detailed updates available. Comment by @celinval posted on 2025-03-20: Comment by @celinval posted on 2025-03-20: We have proposed a project idea to Google Summer of Code to implement the refactoring and infrastructure improvements needed for this project. I'm working on breaking down the work into smaller tasks so they can be implemented incrementally. We have proposed a project idea to Google Summer of Code to implement the refactoring and infrastructure improvements needed for this project. I'm working on breaking down the work into smaller tasks so they can be implemented incrementally. Comment by @celinval posted on 2025-03-20: Comment by @celinval posted on 2025-03-20: I am also happy to share that @makai410 is joining us in this effort! 🥳 I am also happy to share that @makai410 is joining us in this effort! 🥳 Research: How to achieve safety when linking separately compiled code Research: How to achieve safety when linking separately compiled code Research: How to achieve safety when linking separately compiled code No detailed updates available. Run the 2025H1 project goal program Run the 2025H1 project goal program Run the 2025H1 project goal program 2 detailed updates available. Comment by @nikomatsakis posted on 2025-03-03: Comment by @nikomatsakis posted on 2025-03-03: Update: February goal update has been posted. We made significant revisions to the way that goal updates are prepared. If you are a goal owner, it's worth reading the directions for how to report your status, especially the part about help wanted and summary comments. Update: February goal update has been posted . We made significant revisions to the way that goal updates are prepared. If you are a goal owner, it's worth reading the directions for how to report your status , especially the part about help wanted and summary comments. has been posted how to report your status help wanted summary Comment by @nikomatsakis posted on 2025-03-17: Comment by @nikomatsakis posted on 2025-03-17: Update: We sent out the first round of pings for the March update. The plan is to create the document on March 25th, so @rust-lang/goal-owners please get your updates in by then. Note that you can create a TL;DR comment if you want to add 2-3 bullet points that will be embedded directly into the final blog post. In terms of goal planning: @nandsh is planning to do a detailed retrospective on the goals program in conjunction with her research at CMU. Please reach out to her on Zulip (Nandini) if you are interested in participating. We are planning to overhaul the ping process as described in this hackmd. In short, pings will come on the 2nd/3rd Monday of the month. No pings will be sent if you've posted a comment that month. The blog post will be prepared on the 3rd Friday. We've been discussing how to structure 2025H2 goals and are thinking of making a few changes. We'll break out three categories of goals (Flagship / Core / Stretch), with "Core" goals being those deemed most important. We'll also have a 'pre-read' before the RFC opens with team leads to look for cross-team collaborative opportunities. At least that's the current plan. Update: We sent out the first round of pings for the March update. The plan is to create the document on March 25th , so @rust-lang/goal-owners please get your updates in by then. Note that you can create a TL;DR comment if you want to add 2-3 bullet points that will be embedded directly into the final blog post. March 25th TL;DR comment In terms of goal planning: @nandsh is planning to do a detailed retrospective on the goals program in conjunction with her research at CMU. Please reach out to her on Zulip (Nandini) if you are interested in participating. We are planning to overhaul the ping process as described in this hackmd. In short, pings will come on the 2nd/3rd Monday of the month. No pings will be sent if you've posted a comment that month. The blog post will be prepared on the 3rd Friday. We've been discussing how to structure 2025H2 goals and are thinking of making a few changes. We'll break out three categories of goals (Flagship / Core / Stretch), with "Core" goals being those deemed most important. We'll also have a 'pre-read' before the RFC opens with team leads to look for cross-team collaborative opportunities. At least that's the current plan. @nandsh is planning to do a detailed retrospective on the goals program in conjunction with her research at CMU. Please reach out to her on Zulip ( Nandini ) if you are interested in participating. Nandini We are planning to overhaul the ping process as described in this hackmd . In short, pings will come on the 2nd/3rd Monday of the month. No pings will be sent if you've posted a comment that month. The blog post will be prepared on the 3rd Friday. described in this hackmd We've been discussing how to structure 2025H2 goals and are thinking of making a few changes. We'll break out three categories of goals (Flagship / Core / Stretch), with "Core" goals being those deemed most important. We'll also have a 'pre-read' before the RFC opens with team leads to look for cross-team collaborative opportunities. At least that's the current plan. current Rust Vision Document Rust Vision Document Rust Vision Document We drafted a Rust Vision Doc Action Plan. We expect to publish our announcement blog post by end of Month including a survey requesting volunteers to speak with us. We are also creating plans for interviews with company contacts, global community groups, and Rust maintainers. We drafted a Rust Vision Doc Action Plan . Rust Vision Doc Action Plan We expect to publish our announcement blog post by end of Month including a survey requesting volunteers to speak with us. We are also creating plans for interviews with company contacts, global community groups, and Rust maintainers. 1 detailed update available. Comment by @nikomatsakis posted on 2025-03-17: Comment by @nikomatsakis posted on 2025-03-17: Update: I've asked @jackh726 to co-lead the team with me. Together we pulled together a Rust Vision Doc action plan. The plan begins by posting a blog post (draft available here) announcing the effort. We are coordinating with the Foundation to create a survey which will be linked from the blog post. The survey questions ask about user's experience but also look for volunteers we can speak with. We are pulling together the team that will perform the interviewing. We've been in touch with UX reseearchers who will brief us on some of the basics of UX research. We're finalizing team membership now plus the set of focus areas, we expect to cover at least users/companies, Rust project maintainers, and Rust global communities. See the Rust Vision Doc action plan for more details. Update: I've asked @jackh726 to co-lead the team with me. Together we pulled together a Rust Vision Doc action plan . Rust Vision Doc action plan The plan begins by posting a blog post ( draft available here ) announcing the effort. We are coordinating with the Foundation to create a survey which will be linked from the blog post. The survey questions ask about user's experience but also look for volunteers we can speak with. draft available here survey questions We are pulling together the team that will perform the interviewing. We've been in touch with UX reseearchers who will brief us on some of the basics of UX research. We're finalizing team membership now plus the set of focus areas, we expect to cover at least users/companies, Rust project maintainers, and Rust global communities. See the Rust Vision Doc action plan for more details. Rust Vision Doc action plan rustc-perf improvements rustc-perf improvements rustc-perf improvements 1 detailed update available. Comment by @davidtwco posted on 2025-03-03: Comment by @davidtwco posted on 2025-03-03: A small update, @Jamesbarford aligned with @kobzol on a high-level architecture and will begin fleshing out the details and making some small patches to rustc-perf to gain familiarity with the codebase. A small update, @Jamesbarford aligned with @kobzol on a high-level architecture and will begin fleshing out the details and making some small patches to rustc-perf to gain familiarity with the codebase. Scalable Polonius support on nightly Scalable Polonius support on nightly Scalable Polonius support on nightly 1 detailed update available. Comment by @lqd posted on 2025-03-24: Comment by @lqd posted on 2025-03-24: Here are the key developments for this update. Amanda has continued on the placeholder removal task. In particular on the remaining issues with rewritten type tests. The in-progress work caused incorrect errors to be emitted under the rewrite scheme, and a new strategy to handle these was discussed. This has been implemented in the PR, and seems to work as hoped. So the PR should now be in a state that is ready for more in-depth review pass, and should hopefully land soon. Tage has started his master's thesis with a focus on the earliest parts of the borrow checking process, in order to experiment with graded borrow-checking, incrementalism, avoiding work that's not needed for loans that are not invalidated, and so on. A lot of great progress has been made on these parts already, and more are being discussed even in the later areas (live and active loans). I have focused on taking care of the remaining diagnostics and test failures of the location-sensitive analysis. For diagnostics in particular, the PRs mentioned in the previous updates have landed, and I've fixed a handful of NLL spans, all the remaining differences under the compare-mode, and blessed differences that were improvements. For the test failures, handling liveness differently in traversal fixed most of the remaining failures, while a couple are due to the friction with mid-points avoidance scheme. For these, we have a few different paths forward, but with different trade-offs and we'll be discussing and evaluation these in the very near future. Another two are still left to analyze in-depth to see what's going on. Our near future focus will be to continue down the path to correctness while also expanding test coverage that feels lacking in certain very niche areas, and that we want to improve. At the same time, we'll also work on a figuring out a better architecture to streamline the entire end-to-end process, to allow early outs, avoid work that is not needed, etc. Here are the key developments for this update. Amanda has continued on the placeholder removal task. In particular on the remaining issues with rewritten type tests. The in-progress work caused incorrect errors to be emitted under the rewrite scheme, and a new strategy to handle these was discussed. This has been implemented in the PR, and seems to work as hoped. So the PR should now be in a state that is ready for more in-depth review pass, and should hopefully land soon. Tage has started his master's thesis with a focus on the earliest parts of the borrow checking process, in order to experiment with graded borrow-checking, incrementalism, avoiding work that's not needed for loans that are not invalidated, and so on. A lot of great progress has been made on these parts already, and more are being discussed even in the later areas (live and active loans). I have focused on taking care of the remaining diagnostics and test failures of the location-sensitive analysis. For diagnostics in particular, the PRs mentioned in the previous updates have landed, and I've fixed a handful of NLL spans, all the remaining differences under the compare-mode, and blessed differences that were improvements. For the test failures, handling liveness differently in traversal fixed most of the remaining failures, while a couple are due to the friction with mid-points avoidance scheme. For these, we have a few different paths forward, but with different trade-offs and we'll be discussing and evaluation these in the very near future. Another two are still left to analyze in-depth to see what's going on. Our near future focus will be to continue down the path to correctness while also expanding test coverage that feels lacking in certain very niche areas, and that we want to improve. At the same time, we'll also work on a figuring out a better architecture to streamline the entire end-to-end process, to allow early outs, avoid work that is not needed, etc. Secure quorum-based cryptographic verification and mirroring for crates.io Secure quorum-based cryptographic verification and mirroring for crates.io Secure quorum-based cryptographic verification and mirroring for crates.io No detailed updates available. Stabilize cargo-script Stabilize cargo-script Stabilize cargo-script 1 detailed update available. Comment by @lqd posted on 2025-03-26: Comment by @lqd posted on 2025-03-26: This project goal was actually carried over from 2024h2, in https://github.com/rust-lang/rust-project-goals/pull/294 This project goal was actually carried over from 2024h2, in https://github.com/rust-lang/rust-project-goals/pull/294 SVE and SME on AArch64 SVE and SME on AArch64 SVE and SME on AArch64 2 detailed updates available. Comment by @davidtwco posted on 2025-03-03: Comment by @davidtwco posted on 2025-03-03: A small update, we've opened a draft PR for the initial implementation of this - rust-lang/rust#137944. Otherwise, just continued to address feedback on the RFCs. A small update, we've opened a draft PR for the initial implementation of this - rust-lang/rust#137944. Otherwise, just continued to address feedback on the RFCs. Comment by @davidtwco posted on 2025-03-18: Comment by @davidtwco posted on 2025-03-18: We've been resolving review feedback on the implementation of the Sized Hierarchy RFC on rust-lang/rust#137944. We're also working on reducing the performance regression in the PR, by avoiding unnecessary elaboration of sizedness supertraits and extending the existing Sized case in type_op_prove_predicate query's fast path. There's not been any changes to the RFC, there's minor feedback that has yet to be responded to, but it's otherwise just waiting on t-lang. We've been experimenting with rebasing rust-lang/rust#118917 on top of rust-lang/rust#137944 to confirm that const sizedness allows us to remove the type system exceptions that the SVE implementation previously relied on. We're happy to confirm that it does. We've been resolving review feedback on the implementation of the Sized Hierarchy RFC on rust-lang/rust#137944. We're also working on reducing the performance regression in the PR, by avoiding unnecessary elaboration of sizedness supertraits and extending the existing Sized case in type_op_prove_predicate query's fast path. There's not been any changes to the RFC, there's minor feedback that has yet to be responded to, but it's otherwise just waiting on t-lang. We've been experimenting with rebasing rust-lang/rust#118917 on top of rust-lang/rust#137944 to confirm that const sizedness allows us to remove the type system exceptions that the SVE implementation previously relied on. We're happy to confirm that it does. We've been resolving review feedback on the implementation of the Sized Hierarchy RFC on rust-lang/rust#137944. We're also working on reducing the performance regression in the PR, by avoiding unnecessary elaboration of sizedness supertraits and extending the existing Sized case in type_op_prove_predicate query's fast path. Sized type_op_prove_predicate There's not been any changes to the RFC, there's minor feedback that has yet to be responded to, but it's otherwise just waiting on t-lang. We've been experimenting with rebasing rust-lang/rust#118917 on top of rust-lang/rust#137944 to confirm that const sizedness allows us to remove the type system exceptions that the SVE implementation previously relied on. We're happy to confirm that it does. Unsafe Fields Unsafe Fields Unsafe Fields No detailed updates available. Use annotate-snippets for rustc diagnostic output Use annotate-snippets for rustc diagnostic output Use annotate-snippets for rustc diagnostic output 1 detailed update available. Comment by @Muscraft posted on 2025-03-31: Comment by @Muscraft posted on 2025-03-31: While my time was limited these past few months, lots of progress was made! I was able to align annotate-snippets internals with rustc's HumanEmitter and get the new API implemented. These changes have not been merged yet, but they can be found here. As part of this work, I got rustc using annotate-snippets as its only renderer. During all of this, I started working on making rustc use annotate-snippets as its only renderer, which turned out to be a huge benefit. I was able to get a feel for the new API while addressing rendering divergences. As of the time of writing, all but ~30 tests of the roughly 18,000 UI tests are passing. test result: FAILED. 18432 passed; 29 failed; 193 ignored; 0 measured; 0 filtered out; finished in 102.32s Most of the failing tests are caused by a few things: annotate-snippets right aligns numbers, whereas rustc left aligns annotate-snippets doesn't handle multiple suggestions for the same span very well Problems with handling FailureNote annotate-snippets doesn't currently support colored labels and titles, i.e., the magenta highlight rustc uses rustc wants to pass titles similar to error: internal compiler error[E0080], but annotate-snippets doesn't support that well differences in how rustc and annotate-snippets handle term width during tests When testing, rustc uses DEFAULT_COLUMN_WIDTH and does not subtract the code offset, while annotate-snippets does Slight differences in how "newline"/end of line highlighting is handled JSON output rendering contains color escapes While my time was limited these past few months, lots of progress was made! I was able to align annotate-snippets internals with rustc 's HumanEmitter and get the new API implemented. These changes have not been merged yet, but they can be found here . As part of this work, I got rustc using annotate-snippets as its only renderer. During all of this, I started working on making rustc use annotate-snippets as its only renderer, which turned out to be a huge benefit. I was able to get a feel for the new API while addressing rendering divergences. As of the time of writing, all but ~30 tests of the roughly 18,000 UI tests are passing. annotate-snippets rustc HumanEmitter they can be found here rustc annotate-snippets rustc annotate-snippets test result: FAILED. 18432 passed; 29 failed; 193 ignored; 0 measured; 0 filtered out; finished in 102.32s test result: FAILED. 18432 passed; 29 failed; 193 ignored; 0 measured; 0 filtered out; finished in 102.32s Most of the failing tests are caused by a few things: annotate-snippets right aligns numbers, whereas rustc left aligns annotate-snippets doesn't handle multiple suggestions for the same span very well Problems with handling FailureNote annotate-snippets doesn't currently support colored labels and titles, i.e., the magenta highlight rustc uses rustc wants to pass titles similar to error: internal compiler error[E0080], but annotate-snippets doesn't support that well differences in how rustc and annotate-snippets handle term width during tests When testing, rustc uses DEFAULT_COLUMN_WIDTH and does not subtract the code offset, while annotate-snippets does Slight differences in how "newline"/end of line highlighting is handled JSON output rendering contains color escapes annotate-snippets right aligns numbers, whereas rustc left aligns annotate-snippets rustc annotate-snippets doesn't handle multiple suggestions for the same span very well annotate-snippets Problems with handling FailureNote FailureNote annotate-snippets doesn't currently support colored labels and titles, i.e., the magenta highlight rustc uses annotate-snippets rustc rustc wants to pass titles similar to error: internal compiler error[E0080] , but annotate-snippets doesn't support that well rustc error: internal compiler error[E0080] annotate-snippets differences in how rustc and annotate-snippets handle term width during tests When testing, rustc uses DEFAULT_COLUMN_WIDTH and does not subtract the code offset, while annotate-snippets does rustc annotate-snippets When testing, rustc uses DEFAULT_COLUMN_WIDTH and does not subtract the code offset, while annotate-snippets does When testing, rustc uses DEFAULT_COLUMN_WIDTH and does not subtract the code offset, while annotate-snippets does rustc DEFAULT_COLUMN_WIDTH annotate-snippets Slight differences in how "newline"/end of line highlighting is handled JSON output rendering contains color escapes By Rémy Rakic on behalf of Goals Team By Rémy Rakic on behalf of Goals Team Goals Team Goals Team Also published here Also published here here Photo by Dennis Mita on Unsplash Photo by Dennis Mita on Unsplash Dennis Mita Unsplash