++ + + +**Generators.** Experimental support for an `iter!` macro has landed in nightly. This is intended for nightly-only experimentation and will still need an RFC before it can stabilize. Tracking issue is [rust-lang/rust#142269](https://github.com/rust-lang/rust/issues/142269). + +**Async book.** @nrc has been hard at work filling out the official Async Rust book, recently adding chapters on [concurrency primitives](https://rust-lang.github.io/async-book/part-guide/concurrency-primitives.html), structured concurrency, and pinning. + +**dynosaur.** A [dynosaur RFC](https://github.com/spastorino/dynosaur/issues/78) was opened describing what blanket impls we think the proc macro should generate for a trait, to make the trait usable as `impl Trait` in argument position in other traits. This is the last remaining open design question before we release dynosaur 0.3 as a candidate for 1.0. Please chime in on the RFC if you have thoughts. + + + ++ +
++ + + +Update! + +The all-hands has happened! + +More than 150 project members and invited guests attended, making this the largest in-person collaborative event in the history of the Rust project. + + + +On Wednesday, several Rust project members gave talks to other project members and (potential) contributors, as part of the "Rust Project Track" at the RustWeek conference. The recordings are available [on YouTube](https://www.youtube.com/playlist?list=PL8Q1w7Ff68DBJsobwUVTr_vbb2MbxisAF). ๐น + + + +On Thursday, we celebrated the 10 year birthday of Rust 1.0. With over 300 people, we celebrated, listened to speeches from various former and current team members and contributors, and watched the live [release of Rust 1.87.0](https://blog.rust-lang.org/2025/05/15/Rust-1.87.0/) on stage. + + + +On Friday and Saturday, the actual Rust All-Hands 2025 took place. For two full days spread over 10 different meeting rooms, both [pre-planned](https://docs.google.com/spreadsheets/d/1G07-f2pwAzEztZMpuxcCW3EWFS1pEX4ShNbsg91Qqjw/edit?gid=0#gid=0) and ad-hoc discussions took place on a very wide range of topics. Meeting notes have been collected in this Zulip topic: [#all-hands-2025 > Meeting notes!](https://rust-lang.zulipchat.com/#narrow/channel/486433-all-hands-2025/topic/Meeting.20notes!/with/518928628) + +Many many long standing issues have been unblocked. Many new ideas were discussed, both small and big. Conflicts were resolved. Plans were made. And many personal connections were formed and improved. โค + + + +I've collected feedback from the participants (67 of you replied so far), and the replies where overwhelmingly positive with an average score of 9.5/10. ๐ The vast majority would like this to be a yearly event. I've started working on making that happen! + ++ ++
+ +Thank you all for attending! See you all next year! ๐ + + + ++
+
+
+
+
+
+
+ +
+ + + +Update from our 2025-05-07 meeting ([full minutes](https://hackmd.io/@rust-lang-team/S1Y3l7Kxel)): + + - Enthusiasm and plans for RustWeek. + + - `arbitrary_self_types`: update from @dingxiangfei2009 at https://rust-lang.zulipchat.com/#narrow/channel/425075-rust-for-linux/topic/2025-05-07.20meeting/near/516734641 -- he plans to talk to types in order to find a solution. @davidtwco will ping @petrochenkov about `rustc_resolve`. + + - Sanitizer support and `#[sanitize(off)]`: discussed by lang at https://github.com/rust-lang/rust/pull/123617#issuecomment-2859621119. Discussion about allowing to disable particular sanitizers. Older concern from compiler at https://github.com/rust-lang/rust/pull/123617#issuecomment-2192330122. + + - `asm_const` with pointers support: lang talked about it -- lang will want an RFC: https://github.com/rust-lang/rust/issues/128464#issuecomment-2861515372. + + - ABI-modifying compiler flags: two MCPs filled: https://github.com/rust-lang/compiler-team/issues/868 (`-Zretpoline` and `-Zretpoline-external-thunk`) and https://github.com/rust-lang/compiler-team/issues/869 (`-Zharden-sls`). + + Implementation PR for `-Zindirect-branch-cs-prefix` at https://github.com/rust-lang/rust/pull/140740 that goes on top of https://github.com/rust-lang/rust/pull/135927. + + @davidtwco agreed there is likely no need for a separate MCP for this last one, i.e. it could go into the `-Zretpoline*` one. @azhogin pinged about this at https://github.com/rust-lang/rust/pull/135927#issuecomment-2859906060. + + - `--crate-attr`: @Mark-Simulacrum was pinged and he is OK to adopt the RFC (https://github.com/rust-lang/rfcs/pull/3791). + + + ++ + + + +Comment by @nikomatsakis posted on 2025-05-20:
+ + + +TL;DR: + +The primary focus for this year is compiled flags, and we are continuing to push on the various compiler flags and things that are needed to support building RFL on stable (e.g., RFC #3791 proposed adding `--crate-attr`, which permits injecting attributes into crates externally to allow the Kernel's build process to add things like `#![no_std]` so they don't have to be inserted manually into every file; MCPs for ABI flags like [`retpoline`](https://github.com/rust-lang/compiler-team/issues/868) and [`harden-sls`](https://github.com/rust-lang/compiler-team/issues/869) and [implementation of `-Zindirect-branch-cs-prefix`](https://github.com/rust-lang/rust/pull/140740)). A number of issues had minor design questions (how to manage clippy configuration; best approach for rustdoc tests) and we plan to use the RustWeek time to hash those out. + +We are also finishing up some of the work on language items. We have had two stabilizations of lang features needed by Rust for Linux ([naked functions](https://github.com/rust-lang/rust/pull/134213), [`asm_goto` syntax](https://blog.rust-lang.org/2025/05/15/Rust-1.87.0/#asm-jumps-to-rust-code)). The trickiest bit here is arbitrary self types, where we encountered a concern relating to pin and are still [discussing the best resolution](https://rust-lang.zulipchat.com/#narrow/channel/425075-rust-for-linux/topic/2025-05-07.20meeting/near/516734641). + + + + + ++ +
+ + + +And another round of updates. First of all, Google approved two GSoC projects for the summer, where @Sa4dUs will work on the autodiff frontend and @KMJ-007 will work on the backend. The frontend project is about improving our ABI handling to remove corner-cases around specific types that we currently can not differentiate. If time permits he might also get to re-model our frontend to lower our autodiff macro to a proper rustc intrinsic, which should allow us to simplify our logic a lot. +The backend project will look at how Enzyme uses TypeTrees, and create those during the lowering to LLVM-IR. This should allow autodiff to become more reliable, work on debug builds, and generally compile a lot faster. + + + + + ++ + + + +Comment by @ZuseZ4 posted on 2025-05-25:
+ + + +The last weeks were focused on enabling autodiff in a lot more locations, as well as doing a lot of CI and Cmake work to be able to ship it on nightly. At the same time, autodiff is also gaining increasingly more contributors. That should help a lot with the uptick in issues, which I expect once we enable autodiff in nightly builds. + +**Key developments:** +1. @Shourya742 added support for applying autodiff inside of `inherent impl blocks`. https://github.com/rust-lang/rust/pull/140104 +2. @haenoe added support for applying autodiff to generic functions. https://github.com/rust-lang/rust/pull/140049 +3. @Shourya742 added an optimization to inline the generated function, removing one layer of indirection. That should improve performance when differentiating tiny functions. https://github.com/rust-lang/rust/pull/139308 +4. @haenoe added support for applying autodiff to inner (nested) functions. https://github.com/rust-lang/rust/pull/138314 +5. I have found a bugfix for building rustc with both debug and autodiff enabled. This previously failed during bootstrap. This bugfix also solved the last remaining (compile time) performance regression of the autodiff feature. That means that if we now enable autodiff on nightly, it won't affect compile times for people not using it. https://github.com/rust-lang/rust/pull/140030 +6. After a hint from Onur I also fixed autodiff check builds:https://github.com/rust-lang/rust/pull/140000, which makes contributing to autodiff easier. +7. I ran countless experiments on improving and fixing Enzyme's CMake and merged a few PRs into Enzyme. We don't fully support the macos dist runners yet and some of my CMake improvements only live in our Enzyme fork and aren't accepted by upstream yet, but the CI is now able to run longer before failing with the next bug, which should hopefully be easy to fix. At least I already received a hint on how to solve it. +8. @Shourya742 also helped with an experiment on how to bundle Enzyme with the Rust compiler. We ended up selecting a different distribution path, but the PR was helpful to discuss solutions with Infra contributors. https://github.com/rust-lang/rust/pull/140244 +9. @Sa4dUs implemented a PR to split our `#[autodiff]` macro into `autodiff_forward` and `autodiff_reverse`. They behave quite differently in some ways that might surprise users, so I decided it's best for now to have them separated, which also will make teaching and documenting easier. https://github.com/rust-lang/rust/pull/140697 + +**Help Wanted:** +There are two or three smaller issues remaining to distribute Enzyme/autodiff. If anyone is open to help, either with bootstrap, CI, or CMake issues, I'd appreciate any support. Please feel free to ping me on Discord, Zulip, or in https://github.com/rust-lang/rust/pull/140064 to discuss what's left to do. + + +In general, we solved most of the distribution issues over the last weeks, and autodiff can now be applied to almost all functions. That's a pretty good base, so I will now start to look again more into the GPU support for rustc. + + + + ++ + + + +Comment by @ZuseZ4 posted on 2025-06-15:
+ + + +The last three weeks I had success in shifting away from autodiff, towards my other projects. + +**Key developments:** +1) I forgot to mention it in a previous update, but I have added support for sret (struct return) handling to std::autodiff, so we now can differentiate a lot more functions reliably. https://github.com/rust-lang/rust/pull/139465 + +2) I added more support for batched autodiff in: https://github.com/rust-lang/rust/pull/139351 + +3) I have started working on a std::batching PR, which just allows fusing multiple function calls into one. https://github.com/rust-lang/rust/pull/141637. I am still not fully sure on how to design the frontend, but in general it will allow Array-of-Struct and Struct-of-Array vectorization. Based on a popular feedback I received it's now also generating SIMD types. So you can write your function in a scalar way, and just use the macro to generate a vectorized version which accepts and generates SIMD types. + +4) My first PR to handle automatic data movement to and from a GPU is up! https://github.com/rust-lang/rust/pull/142097 It can handle data movements for almost arbitrary functions, as long as your function is named `kernel_{num}`, and each of your arguments is a pointer to exactly 256 f32 values. As the next step, I will probably work on the backend to generate the actual kernel launches, so people can run their Rust code on the GPU. Once I have that tested and working I will go back to develop a frontend, to remove the input type limitations and give users a way to manually schedule data transfers. The gpu/offload frontend will likely be very simple compared to my autodiff frontend, so I don't expect many complications and therefore leave it to the end. + + +**Help Wanted:** + +There is only really one issue left which I'd like to see fixed before enabling autodiff on nightly, and that is MacOS support. +Most of the MacOS CI already works, we can now build Enzyme, LLVM, and rustc, but later fail when we build Cranelift due to linker flag issues. The person who was looking into it got busy with other things, so I would really appreciate it if someone could pick it up! Otherwise I can also just start by shipping autodiff on Linux only, but given how close we are to MacOS support, I feel like it would be a shame. Since it's only an issue in CI, you don't need an own Mac to help with this. If anyeone has time, I'm happy to chat here [here](https://github.com/rust-lang/rust/issues/140137) or on Zulip/Discord. + + + ++ +
+ + + +Upps, giving another status update here: + +**Key developments**: Landed an extension of the alignment check to include (mutable) borrows in [rust#137940](https://github.com/rust-lang/rust/pull/137940). Working on the enums check (no draft PR yet). Hope to open a PR by mid next week. + +**Blockers**: None so far. + +**Help wanted**: Happy to join forces on general checks and for advice what other UB would be great to check!! :) + + + ++ +
+ + + +Monthly update! + +**Key developments:** + +- Documentation lints have been optimized greatly, giving us up to a 13.5% decrease in documentation-heavy crates. See https://github.com/rust-lang/rust-clippy/pull/14693 and https://github.com/rust-lang/rust-clippy/pull/14870 + +- The efforts on getting Clippy benchmarked on the official \@rust-timer bot account are getting started by the infra team. This allows us to do per-PR benchmarking instead of fixing performance problems ad-hoc. + +- We need to do further testing on the **early parallel lints effort**. While I have a working patch, no performance improvement has yet been proven. + +- Work on making an interface for a single-lint Clippy, for denoising benchmarks is getting in the works. + +**Blockers** +The query system not being parallelized. Currently working on a work-around but a parallel query system would make things a lot easier. + +**Help wanted:** +Help is appreciated in anything with the [`performance-project` label](https://github.com/rust-lang/rust-clippy/issues?q=is%3Aissue%20state%3Aopen%20label%3Aperformance-project) in the Clippy repository. + + + + + ++ +
+ + + +We should now be correctly deferring evaluation of type system constants making use of generic parameters or inference variables. There's also been some work to make our normalization infrastructure more term agnostic (i.e. work on both types and consts). Camelid's PR mentioned in the previous update has also made great progress. + + + ++ +
+ + + +Last week was the Rust All Hands. There were three days of discussions about interop at the all hands, led by @baumanj and including members from the Rust Project and C++ standards bodies as well as the developers of foundational Rust/C++ interop tools. The topics included + +* Comparing differing needs of interop across the industry +* Sharing the design philosophy and approach of different interop tools +* Brainstorming how to tackle common interop problems between the languages, like differences in integer types, memory/object models, and move semantics +* Discussing ways the Rust and C++ languages and toolchains can develop to make interop easier in the future + +Speaking for myself from the Rust Project side, it was a real pleasure to meet some of the faces from the C++ side! I look forward to working with them more in the future. + + + ++ +
+ + + +The talk went smoothly and was well received. I had several useful and interesting conversations at Rust Week about effort. That is all I have to report. + + + ++ +
+ + + +- Key developments: + - Moved crates to https://github.com/crate-ci/libtest2 +- Blockers +- Help wanted + + + ++ +
+ + + +We have reached an [agreement](https://rust-lang.zulipchat.com/#narrow/channel/508023-project-packages-as-namespaces/topic/Consensus.20on.20compiler.20implementation/with/522594925) on the compiler implementation, and will implement it in the next 2-3 weeks hopefully. + + + ++ +
+ + + +https://github.com/rust-lang/rust/pull/141754 has been opened to parse `impl` restrictions and lower them to `rustc_middle`. A separate pull request will be opened to enforce the restriction soon after that is merged. + + + ++ +
+ + + +Quick update, Data is currently being gathered (and has been for almost 2 weeks now) on docs.rs and I should have it uploaded and accessible on the PoC dashboard within the next week or two (depending on how long I want to let the data gather). + + + ++ + + + +Comment by @yaahc posted on 2025-06-03:
+ + + +Bigger Update, + +I've done the initial integration with the data gathered so far since rustweek. I have the data uploaded to the influxdb cloud instance managed by the infra team, I connected the infra team's grafana instance to said influxdb server and I imported my dashboards so we now have fancy graphs with real data on infra managed servers :tada: + + + + + +I'm now working with the infra team to see how we can open up access of the graphana dashboard so that anyone can go and poke around and look at the data. + +Another issue that came up is that the influxdb cloud serverless free instance that we're currently using has a mandatory max 30 day retention policy, so either I have to figure out a way to get that disabled on our instance or our data will get steadily deleted and will only be useful as a PoC demo dashboard for a short window of time. + + + ++ +
+ + + +We have triaged all major regressions discovered by the full crater run. While there are still some untriaged root regressions impacting a single crate, we've either fixed all major regressions or opened fixes to the affected crates in cases where the breakage is intended. We've started to track intended breakage in https://github.com/rust-lang/trait-system-refactor-initiative/issues/211. + +We've fixed quite a few additional issues encountered via crater: https://github.com/rust-lang/rust/pull/140672 https://github.com/rust-lang/rust/pull/140678 https://github.com/rust-lang/rust/pull/140707 https://github.com/rust-lang/rust/pull/140711 https://github.com/rust-lang/rust/pull/140712 https://github.com/rust-lang/rust/pull/140713 https://github.com/rust-lang/rust/pull/141125 https://github.com/rust-lang/rust/pull/141332 https://github.com/rust-lang/rust/pull/141333 https://github.com/rust-lang/rust/pull/141334 https://github.com/rust-lang/rust/pull/141347 https://github.com/rust-lang/rust/pull/141359. + +We are now tracking performance of some benchmarks with the new solver in our test suite and have started to optimize the new solver. Thank you @Kobzol for this! There are a lot of long-hanging fruit so we've made some large improvements already: https://github.com/rust-lang/rust/pull/141442 https://github.com/rust-lang/rust/pull/141500. There are also a bunch of additional improvements in-flight right now, e.g. https://github.com/rust-lang/rust/pull/141451. We still have a few crates which are *significantly* slower with the new solver, most notably `nalgebra` and `diesel`. I am confident we'll get the new solver a lot more competitive here over the next few months. + +Going forward, we will continue to improve the performance of the new solver. We will also finally work through our backlog of in-process changes and land the new opaque type handling. + + + + + ++ + + + +Comment by @lcnr posted on 2025-05-29:
+ + + +Ah, also @jackh726 continued to work on integrating the new solver in RustAnalyzer and it looks like we will be able to replace chalk in the near future. + + + ++ +
+ + + +Key developments: https://github.com/rust-lang/rust/issues/139368 was opened, which poses some possibly-relevant questions on the interaction between the `target_feature` attribute and traits. Otherwise, still trying to get a better understanding of the interaction between target feature and effects. + + + ++ +
+ + + +No updates on my side, but we may be going back to the original proposal (modulo syntax) with a syntax that is extensible to more opt-out marker effects without lots of repetition of the `const` keyword + + + ++ +
+ + + +This has been [approved as a GSoC project](https://blog.rust-lang.org/2025/05/08/gsoc-2025-selected-projects/#selected-projects). + + + ++ +
+ + + +Key Developments: A [PR](https://github.com/rust-lang/fls/pull/563) is ready for review and merging to update the FLS to be self-sufficient, not relying on external Ferrocene packages for building. This will give us more control of changes we would like to make to the document, including theming, logos, naming, etc. + +Next step: Make some modifications to the FLS content and have it published at https://rust-lang.github.io/fls + +Blockers: Potential blocker around the [(re)naming / rebranding of the FLS](https://rust-lang.zulipchat.com/#narrow/channel/399173-t-spec/topic/On.20renaming.20the.20FLS/with/521565495). + + + ++ +
+ + + +- @Jamesbarford has added the ability to write tests against the database to `rustc-perf` (rust-lang/rustc-perf#2119) +- @Jamesbarford has started to submit parts of rust-lang/rustc-perf#2081 in smaller chunks, with review feedback addressed, starting with rust-lang/rustc-perf#2134 (originally rust-lang/rustc-perf#2096) +- @Jamesbarford has prepared a [HackMD](https://hackmd.io/wq30YNEIQMSFLWWcWDSI9A) describing the design considerations involved in making rustc-perf support multiple collectors. + + + ++ + + + +Comment by @Jamesbarford posted on 2025-06-20:
+ + + +- @Kobzol & @Jamesbarford collaborated on finishing a workable draft for the new + architecture of the `rustc-perf` benchmarking; https://hackmd.io/wq30YNEIQMSFLWWcWDSI9A +- @Kobzol PR enabling backfilling of data, required for the new system design + https://github.com/rust-lang/rustc-perf/pull/2161 +- @Jamesbarford PR for creating a cron job and doing a first stage queue of + master commits; https://github.com/rust-lang/rustc-perf/pull/2163 +- @Jamesbarford PR for the collectors configuration, holding off merging for the + time being as we learn more about the system through building. + https://github.com/rust-lang/rustc-perf/pull/2157 +- @Kobzol PR allowing running the database tests on SQLite too; + https://github.com/rust-lang/rustc-perf/pull/2152 + + + + ++ +
+ + + +Here are the key developments for May, though there was a bit less time this month due to the All Hands. + +@amandasystems: A few more rounds of reviews were done on https://github.com/rust-lang/rust/pull/140466 (thanks to lcnr!), and most, if not all, of the feedback has been addressed already. Another PR was opened as a successor, containing another big chunk of work from the initial [PR #130227](https://github.com/rust-lang/rust/pull/130227): https://github.com/rust-lang/rust/pull/140737. + +@tage64: The work discussed in the previous updates has been extracted into a few PRs, mostly to do perf runs to be able to gauge the overhead in the in-progress implementation. First, an alternative implementation to [rustc's dense bitset](https://github.com/rust-lang/rust/pull/141325), which is used extensively in dataflow analyses such as the ones in the borrow checker, for example. Then, [a prototype of the algorithm](https://github.com/rust-lang/rust/pull/141326) discussed in prior updates, trying to make the location-sensitive constraints built lazily, as well as the loans in scope themselves. (And the union of these two in [#141583](https://github.com/rust-lang/rust/pull/)) + +@lqd: As discussed in the previous update, I've tried to see if we can limit scope here by evaluating the current algorithm a bit more: the expressiveness it allows, and where it fails. I've also evaluated all the open issues about NLL expressiveness that we hoped to fix, and see the ones we support now or could defer to future improvements. It seems _possible_. I've also started to have some idea of the work needed to make it more production-ready. That includes the experiments made with Tage above, but also trying to lower the total overhead by finding wins in NLLs, and here I e.g. [have some improvements in-flight](https://github.com/rust-lang/rust/pull/141667) for the dataflow analysis used in liveness. + +All Hands: we discussed with t-types the plan and in-progress PRs about opaque types, how they impact member constraints and in turn the constraint graph and SCCs. Some more work is needed here to ensure member constraints are correctly handled, even though they should only impact the SCCs and not the borrow checking algorithm per se (but there still are possible ambiguity issues if we don't take flow sensitivity into account here). + +(Fun and interesting aside: there's [an RFC](https://discourse.llvm.org/t/rfc-intra-procedural-lifetime-analysis-in-clang/86291) to add a polonius-like lifetime analysis to clang) + + + ++ +
+ + + +Key developments: +- rust-lang/rust#140035 has been merged + +Blockers: + +Help wanted: + + + + ++ +
+ + + +- We've resolved a handful of rounds of feedback on rust-lang/rust#137944 from @oli-obk, @lcnr and @fee1-dead; resolved issues from a crater run (bar one); and worked to decrease the performance regression. + - We've removed the constness parts of the patch to make it smaller and easier to review. Constness will come in a Part II. + - There's currently a -1% mean regression (min 0.1%, max 5.3%) that we're working to improve, but starting to run out of ideas. Regressions are just a consequence of the compiler having to prove more things with the addition of `MetaSized` bounds, rather than hot spots in newly introduced code. + - Given the large impact of the change, we ran a crater run and found three distinct issues, two have been fixed. The remaining issue is a overflow in a single niche crate which we're working out how we can resolve. + - We're largely just waiting on hearing from our reviewers what would be needed to see this change land. +- We've not made any changes to the Sized Hierarchy RFC, there's a small amount of discussion which will be responded to once the implementation has landed. +- We're working on changes to the SVE RFC which further clarifies that the language changes are decided by the Sized RFC and that the SVE RFC is only proposing the forever-unstable `repr(scalable)` attribute which are non-`const Sized` and lower to `vscale` in LLVM. + + + ++ + + + +Comment by @davidtwco posted on 2025-06-02:
+ + + +- rust-lang/rust#137944 is ready! It's in a t-types FCP to merge as there's a small unavoidable breakage (unless we wanted to wait for the new trait solver). + - Once this is merged, I'll work on a `#[rustc_no_implicit_bounds]` attribute for tests, testing whether `Deref::Target` can be relaxed, and Part II. +- I've still not made any changes to the Sized Hierarchy RFC, there's a small amount of discussion which will be responded to once the implementation has landed. + + + ++ +
+ + + +**Key developments:** No significant developments since [previous updates](https://github.com/rust-lang/rust-project-goals/issues/273#issuecomment-2815572055). + +**Blockers:** [Waiting](https://github.com/rust-lang/rfcs/pull/3458#issuecomment-2825837922) on lang team review. + + + ++ +