From 00ead23cc2f9c064739c0e1297ec9166432ecad4 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?R=C3=A9my=20Rakic?= Date: Wed, 21 May 2025 19:23:29 +0000 Subject: [PATCH 01/10] import generated blog post template --- content/Project-Goals-2025-April-Update.md | 1496 ++++++++++++++++++++ 1 file changed, 1496 insertions(+) create mode 100644 content/Project-Goals-2025-April-Update.md diff --git a/content/Project-Goals-2025-April-Update.md b/content/Project-Goals-2025-April-Update.md new file mode 100644 index 000000000..54ee31f97 --- /dev/null +++ b/content/Project-Goals-2025-April-Update.md @@ -0,0 +1,1496 @@ ++++ +path = "9999/12/31/april-project-goals-update" +title = "April Project Goals Update" +authors = ["Rémy Rakic"] + +[extra] +team = "the Goals team" +team_url = "https://www.rust-lang.org/governance/teams/launching-pad#team-goals" ++++ + +The Rust project is currently working towards a [slate of 40 project goals](https://rust-lang.github.io/rust-project-goals/2025h1/goals.html), with 3 of them designated as [Flagship Goals](https://rust-lang.github.io/rust-project-goals/2025h1/goals.html#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](https://github.com/rust-lang/rust-project-goals/issues?q=is%3Aissue%20state%3Aopen%20label%3AC-tracking-issue). + +## 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](https://rust-lang.github.io/rust-project-goals/2025h1/async.html) is to deliver (1) improved support for async-fn-in-traits, completely subsuming the functionality of the [`async-trait` crate](https://crates.io/crates/async-trait); (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?** + + + + +
+1 detailed update available. + + + + + + +Comment by @tmandry posted on 2025-05-20:
+ +
+ + + +**Async fn in traits.** An FCP proposal to stabilize return type notation was started in https://github.com/rust-lang/rust/pull/138424. However, it is currently blocked on concerns that stabilizing it now will make it more difficult to ship Rust's next-generation trait solver. + +**Async fn in dyn trait.** There have been discussions around next steps to support this in the language. More experimentation is needed, along with an initial RFC. + +**dynosaur.** More breaking changes have landed and we expect to release v0.3 soon. + + + +
+ +
+ + + +
+
+
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](https://internals.rust-lang.org/t/announcing-the-subteams/2042). At the time [there were 6 Rust teams with 24 people in total](http://web.archive.org/web/20150517235608/http://www.rust-lang.org/team.html). 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](https://2025.rustweek.org), a joint event organized with [RustNL](https://2025.rustweek.org/about/). 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](./rust-vision-doc.md), 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?** + + + + +
+3 detailed updates available. + + + + + + +Comment by @m-ou-se posted on 2025-04-23:
+ +
+ + + +Update: + +Below is the preliminary schedule for the "pre all hands" and all hands: + +![Image](https://github.com/user-attachments/assets/9dd9aa14-1b37-478b-9071-3865ebac3994) + +![Image](https://github.com/user-attachments/assets/4849caa8-c7af-4a9e-b1ee-75c1fafc7a6c) + +![Image](https://github.com/user-attachments/assets/5888677e-3319-453c-9758-f8014954ebe6) + +The last day has a lot of empty slots for now. I'm still working on filling those, but I'll leave a few empty slots to allow for flexibility during the event itself. + + + +
+ + + + +Comment by @m-ou-se posted on 2025-04-23:
+ +
+ + + +I published our covid policy: https://rustweek.org/covid-policy-all-hands-and-unconf/ + +And got us a ton of covid self-tests and Aranet4 CO₂ sensors: + +![Image](https://github.com/user-attachments/assets/09f53af5-785b-4871-b7be-06f58b1b786d) +![Image](https://github.com/user-attachments/assets/fdd79c8f-94bb-40b2-9cf9-ab949ebeb4e8) + + + +
+ + + + +Comment by @m-ou-se posted on 2025-04-23:
+ +
+ + + +For remote attendance, I got us a bunch of Jabra Speak2 75 conferencing speaker-microphones. They are battery powered and work out-of-the-box both over USB and Bluetooth on any platform. + +I'll put them near the entrance for anyone to borrow for any of the meeting rooms. + +![Image](https://github.com/user-attachments/assets/1669b50d-a60c-4ba0-8e82-9f403820d0a7) + + + +
+ +
+ + + +
+
+
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][RFL.com]. 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`](https://doc.rust-lang.org/cargo/reference/unstable.html#build-std) by [creating a stable way to rebuild core with specific compiler options](https://rust-lang.github.io/rust-project-goals/2025h1/build-std.html); (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). + +[RFC #3716]: https://github.com/rust-lang/rfcs/pull/3716 +[RFL.com]: https://rust-for-linux.com/ +[RFL#2]: https://github.com/Rust-for-Linux/linux/issues/2 + +**What has happened?** 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). + + + + +
+3 detailed updates available. + + + + + + +Comment by @ojeda posted on 2025-05-20:
+ +
+ + + +Update from our 2025-04-09 meeting ([full minutes](https://hackmd.io/@rust-lang-team/rkqdLEER1l)): + + - Some progress on `arbitrary_self_types`. In particular, decided to do with respect to pin and other related cases. + + - `asm_goto` is solved, apart from output operands. For `asm_const`, https://github.com/rust-lang/rust/pull/138618 is nominated. + + - ABI-modifying compiler flags: some PRs waiting review, e.g. https://github.com/rust-lang/rust/pull/138736. + + - `--crate-attr` RFC is up: https://github.com/rust-lang/rfcs/pull/3791. + + - `-Zsanitize-kcfi-arity`'s implementation PR got merged: https://github.com/rust-lang/rust/pull/138368. If all is good from the Linux side, a stabilization PR will be sent. + + - CFI `core::fmt` issue: https://github.com/rust-lang/rust/issues/115199. + + - Discussion around `bindgen`, `repr(align)` and packed types. RFC nominated for lang discussion: https://github.com/rust-lang/rfcs/pull/3718#issuecomment-2790654254. + + + +
+ + + + +Comment by @ojeda posted on 2025-05-20:
+ +
+ + + +Update from our 2025-04-23 meeting ([full minutes](https://hackmd.io/@rust-lang-team/BJZ69jLkgx)): + + - Naked functions were stabilized, which could see some use in the kernel. + + - Lang discussed `#[repr(align)]` (the kernel is interested in, at least, the global one, i.e. `-Zmin-function-alignment=N`). + + - `asm_const`: @nbdd0121 will reply on the latest review comments in the implementation PR: https://github.com/rust-lang/rust/issues/128464. + + - `--crate-attr`: the author of the RFC (https://github.com/rust-lang/rfcs/pull/3791) is looking for a new owner. The RFC is in proposed FCP. Small updates to the text may be needed. Otherwise compiler probably wants to merge it. @Mark-Simulacrum to be pinged. + + - Clippy configuration etc.: @flip1995 will be at RustWeek, the plan is to discuss it there. + + - `rustdoc` extract doctests: @GuillaumeGomez and @ojeda plan to discuss it at RustWeek. + + - `-Zsanitize-kcfi-arity`: waiting on the kernel side (`tc-build` support sent). + + - CFI `core::fmt` issue: PR submitted: https://github.com/rust-lang/rust/pull/139632. + + + +
+ + + + +Comment by @ojeda posted on 2025-05-20:
+ +
+ + + +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). + + + +
+ +
+ + + + +## Goals looking for help + + +## Other goal updates + +
+
"Stabilizable" prototype for expanded const generics
+
+
+
+ + + + + + + +
+1 detailed update available. + + + + + + +Comment by @BoxyUwU posted on 2025-04-30:
+ +
+ + + +I've a PR open to make resolving inherent assoc terms in item signatures not result in query cycles, this will be necessary for uses of inherent assoc consts in the type system under mgca. camelid is currently working on representing const items as aliases to type system consts rather than bodies like they currently are, this is necessary to implement normalization of const const aliases under mgca, it will also allow us to implement the core mgca check of const aliases in the type system being equal to valid const arguments, and also we'll be able to split out a full gca feature gate *without* that restriction. + +The PR mentioned in the previous update to handle const aliases with inference variables correctly has turned into a bit of a rabbit hole. It turned out that there were *stable* issues around const evaluation and illformed constants resulting in ICEs so I've wound up trying to get those fixed and have been writing up a document explaining justification for a breaking change there. + + + +
+ +
+ + +
+
build-std
+
+
+
+ + + + + + + +
+1 detailed update available. + + + + + + +Comment by @davidtwco posted on 2025-05-07:
+ +
+ + + +- We've started a regular biweekly sync call with upstream stakeholders in build-std from the lang, compiler and cargo teams where we discuss aspects of our tentative design or clarify constraints. +- @adamgemmell has continued to draft our proposal for build-std, which we're discussing in our regular sync calls. +- We're hosting a session at the All Hands next week to discuss build-std. + + + +
+ +
+ + +
+
Continue resolving `cargo-semver-checks` blockers for merging into cargo
+
+
+
+ + + + + + + +
+1 detailed update available. + + + + + + +Comment by @obi1kenobi posted on 2025-05-03:
+ +
+ + + +We encountered some speedbumps this month. + +TL;DR: +- While working on `'static` and "outlives" bounds, we discovered Rust's ability to _imply_ bounds that are not stated explicitly at the definition site. +- Implied bounds are load-bearing for SemVer; failure to take them into account will produce _both_ false-positives _and_ false-negatives. +- While technical limitations make it infeasible for `cargo-semver-checks` to correctly deduce implied bounds, `rustc` has this capability internally. +- We have [asked the rustdoc team](https://rust-lang.zulipchat.com/#narrow/channel/266220-t-rustdoc/topic/Show.20implied.20bounds.20in.20rustdoc.20JSON/near/515146429) to expose implied bounds in rustdoc JSON by using those `rustc` internal APIs. + +There are some good news as well, though! While looking at the `#[target_feature]` attribute: +- We discovered previously-undocumented SemVer hazards. +- We [discovered a case of unsoundness](https://github.com/rust-lang/rust/issues/139368) when that attribute is used on trait methods. +- With the help of contributors and the rustdoc team, rustdoc JSON began including additional information that will help future `cargo-semver-checks` versions catch those SemVer hazards. + + + +
+ +
+ + +
+
Declarative (`macro_rules!`) macro improvements
+
+
+
+ + + + + + + + + +
+No detailed updates available. +
+ + +
+
Evaluate approaches for seamless interop between C++ and Rust
+
+
+
+ + + + + + + + + +
+No detailed updates available. +
+ + +
+
Experiment with ergonomic ref-counting
+
+
+
+ + + + + + + +
+2 detailed updates available. + + + + + + +Comment by @nikomatsakis posted on 2025-04-08:
+ +
+ + + +In reviewing https://github.com/rust-lang/rust/pull/138628, we realized that the tests were not behaving as expected because they were running in Rust 2015 which had distinct capture rules. My [suggestion](https://github.com/rust-lang/rust/pull/138628#pullrequestreview-2750344682) was to limit the `use` keyword (or at least use closures...) to Rust 2021 so as to avoid having to think about how it interacts with earlier capture rules (as well as potential migrations). I believe this follows from the Edition axiom that [Editions are meant to be adopted](https://rust-lang.github.io/rfcs/3085-edition-2021.html#editions-are-meant-to-be-adopted). + +There is an interesting tension with [Rust should feel like one language](https://rust-lang.github.io/rfcs/3085-edition-2021.html#rust-should-feel-like-one-language). My feeling is that there is a missing tenet: the reason we do editions and not fine-grained features is because we wish to avoid combianotoric explosion, where odd combinations of features can lead to untested scenarios. But that is exactly what would be happening here if we allow `use` on older editions. So I think the rule should be that you make new features available on older editions *up until the point where they interact with something that changed* -- in this case, `use` closures interact with the closure capture rules which changed in Rust 2021, so we should limit this feature to Rust 2021 and newer. + +Put another way, you should never have to go back and modify an edition migration to work differently. That suggestions you are attempting to push the feature too far back. + + + +
+ + + + +Comment by @spastorino posted on 2025-04-30:
+ +
+ + + +We've modified codegen so that we guarantee that `x.use` will do a copy if `X: Copy` is true after monomorphization. Before this change the desugaring to `clone` occured only before monomorphization and hence it would call the `clone` method even for those instances where `X` is a `Copy` type. So with this modification we avoid such situation. + +We are not working on convert `x.use` to a move rather than a clone if this is a last-use. + + + +
+ +
+ + +
+
Expose experimental LLVM features for GPU offloading
+
+
+
+ + + + + + + + + +
+No detailed updates available. +
+ + +
+
Extend pubgrub to match cargo's dependency resolution
+
+
+
+ + + + + + + +
+1 detailed update available. + + + + + + +Comment by @Eh2406 posted on 2025-05-03:
+ +
+ + + +I will be giving [a talk at Rust-Week](https://rustweek.org/talks/jacob/) about the history that brought us to this project/goal. Aside from preparing for that talk I have not had time for this effort. + + + +
+ +
+ + +
+
Externally Implementable Items
+
+
+
+ + + + + + + + + +
+No detailed updates available. +
+ + +
+
Finish the libtest json output experiment
+
+
+
+ + + + + + + +
+1 detailed update available. + + + + + + +Comment by @epage posted on 2025-04-30:
+ +
+ + + +- Key developments: + - Continued efforts to clean up the existing code + - t-testing-devex has been working out where the crates should live in preparation for publishing them ([#t-testing-devex > crate ownership @ 💬](https://rust-lang.zulipchat.com/#narrow/channel/404371-t-testing-devex/topic/crate.20ownership/near/513724212)) + - Looking to build on the work done for `test-r` and `rustest` crates as they align with the long term vision +- Blockers: +- Help wanted: + + + +
+ +
+ + +
+
Implement Open API Namespace Support
+
+
+
+ + + + + + + +
+1 detailed update available. + + + + + + +Comment by @eholk posted on 2025-04-30:
+ +
+ + + +@b-naber and I have been working on the rustc side of the implementation for this feature. + +I merged https://github.com/rust-lang/rust/pull/139647, which adds the unstables `-Z namespaced-crates` option to the compiler and enables parsing of externs like `--extern foo::bar=libbar.rlib`. @b-naber has led the resolver changes and has a draft PR up at https://github.com/rust-lang/rust/pull/140271. + +The implementation work has raised some [new concerns](https://github.com/rust-lang/rust/issues/122349#issuecomment-2832241624) about the overall direction, so work is ongoing to resolve those while continuing to make progress in the meantime. + + + +
+ +
+ + +
+
Implement restrictions, prepare for stabilization
+
+
+
+ + + + + + + + + +
+No detailed updates available. +
+ + +
+
Improve state machine codegen
+
+
+
+ + + + + + + + + +
+No detailed updates available. +
+ + +
+
Instrument the Rust standard library with safety contracts
+
+
+
+ + + + + + + +
+1 detailed update available. + + + + + + +Comment by @celinval posted on 2025-04-30:
+ +
+ + + +We fixed issue https://github.com/rust-lang/rust/issues/136925 that was blocking contract annotations on constant functions, which unblocks the initial PR to add some contract annotations in the standard library (https://github.com/rust-lang/rust/pull/136578). The PR currently triggers a CI failure which we are investigating. + + + +
+ +
+ + +
+
Making compiletest more maintainable: reworking directive handling
+
+
+
+ + + + + + + +
+1 detailed update available. + + + + + + +Comment by @jieyouxu posted on 2025-05-01:
+ +
+ + + +Update (2025-05-01): + +- Not much updates, recent compiletest changes were surrounding error annotation strictness/canonicalization and landing a new executor that doesn't depend on libtest, and I've mostly been involved in reviewing those. +- Next planned changes are first to introduce some discipline into compiletest's error handling and contributor-facing diagnostics, because configuration and directive handling currently still has a ton of random panics all over the place. + + + +
+ +
+ + +
+
Metrics Initiative
+
+
+
+ + + + + + + +
+2 detailed updates available. + + + + + + +Comment by @yaahc posted on 2025-04-16:
+ +
+ + + +Small progress update: + +following the plan mentioned above plus some extra bits, I've implemented the following changes + +* changed the json output to include the timestamp +* changed the file naming to ensure uniqueness and not overwrite metrics for the same crate when built with different configurations + * previously I was piggybacking on the hash used to name artifacts in the `.cargo` or `build` directories, which in the compiler is known as `extra_filename` and is configured by cargo, but it turns out this doesn't guarantee uniqueness + * I've replaced this with the ["Strict Version Hash"](https://rustc-dev-guide.rust-lang.org/backend/libs-and-metadata.html?highlight=stable%20version%20hash#strict-version-hash) (SVH) + * Doing so introduced an ICE when compiling some crates with incremental compilation enabled. I've since resolved this in https://github.com/rust-lang/rust/pull/139502 and tested this version against the top 100 crates in the ecosystem and their dependencies to verify its working +* I've been working with the infra team and they've setup a cloud instance of influxdb 3.0 and grafana, influxdb is setup, grafana in progress +* I met with both libs and lang to discuss their needs related to the unstable feature usage metrics and metrics in general + +Next Steps: +* I've got everything setup for the docs.rs team to start gathering a sample dataset for which I will then upload to the server the infra team setup +* update locally hosted PoC impl to work with recent changes to metrics files and naming and validate that it's working as expected +* work on the queries for the grafana instance to setup a graph per feature showing usage over time + * probably going to create fake usage data to with for this +* on the side I'm also looking into how much work it would be to track relative usage of various library APIs under a single feature flag (e.g. https://github.com/rust-lang/rust/issues/139911 tracking the specific functions used) +* develop a better understanding of the expected cost of running an influxdb server + + + +
+ + + + +Comment by @yaahc posted on 2025-04-22:
+ +
+ + + +posting this here so I can link to it in other places, I've setup the basic usage over time chart using some synthesized data that just emulates quadraticly (is that a word?) increasing feature usage for my given feature over the course of a week (the generated data starts at 0 usages per day and ends at 1000 usages per day). This chart counts the usage over each day long period and charts those counts over a week. The dip at the end is the difference between when I generated the data, after which there is zero usage data, and when I queried it. + +With this I should be ready to just upload the data once we've gathered it from docs.rs, all I need to do is polish and export the dashboards I've made from grafana to the rust-lang grafana instance, connect that instance to the rust-lang influxdb instance, and upload the data to influxdb once we've gathered it. + +![Image](https://github.com/user-attachments/assets/4d3db7cf-04bc-400c-8791-ac10c402ccdf) + + + +
+ +
+ + +
+
Model coherence in a-mir-formality
+
+
+
+ + + + + + + + + +
+No detailed updates available. +
+ + +
+
Next-generation trait solver
+
+
+
+ + + + + + + +
+1 detailed update available. + + + + + + +Comment by @lcnr posted on 2025-05-01:
+ +
+ + + +We've made a lot of progress over the last 1.5 months. My change to opaque types in borrowck is pretty much done now: https://github.com/rust-lang/rust/pull/139587. It still needs some cleanup and an FCP to actually merge. We've already merged multiple cleanups on the way here. + +We then started to test crater with the `-Znext-solver=globally`. @compiler-errors and me encountered and merged the fixes for 13 issues since then: https://github.com/rust-lang/rust/pull/139791 https://github.com/rust-lang/rust/pull/139798 https://github.com/rust-lang/rust/pull/140236 https://github.com/rust-lang/rust/pull/139900 https://github.com/rust-lang/rust/pull/139828 https://github.com/rust-lang/rust/pull/139774 https://github.com/rust-lang/rust/pull/139762 https://github.com/rust-lang/rust/pull/139789 https://github.com/rust-lang/rust/pull/138845 https://github.com/rust-lang/rust/pull/140306 https://github.com/rust-lang/rust/pull/140305 https://github.com/rust-lang/rust/pull/140276 https://github.com/rust-lang/rust/pull/140302. @Nadrieril was also helpful by minimizing an encountered issue. + +With these improvements and multiple in-flight changes we're now at significantly less than 100 remaining regressions in the top 10000 crates and have started the first complete crater run today. We are using a single PR for all crater runs. Check out https://github.com/rust-lang/rust/pull/133502 for the current status and the stack of in-flight changes. + + + +
+ +
+ + +
+
Nightly support for ergonomic SIMD multiversioning
+
+
+
+ + + + + + + +
+1 detailed update available. + + + + + + +Comment by @veluca93 posted on 2025-04-30:
+ +
+ + + +Key developments: nothing substantial. + + + +
+ +
+ + +
+
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-04-29:
+ +
+ + + +Monthly update! + +- In [the last monthly update](https://github.com/rust-lang/rust-project-goals/issues/114#issuecomment-2730435572) we saw the impact that [interning symbols](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/symbol/struct.Symbol.html#method.intern) had on the program's performance. An effort to minimize this via a pre-interning symbol mechanism has been implemented in https://github.com/rust-lang/rust-clippy/pull/14650 and https://github.com/rust-lang/rust/pull/138682 + +- We're phasing out the old ["str path"](https://doc.rust-lang.org/nightly/nightly-rustc/clippy_utils/fn.match_def_path.html) infrastructure into a new lazy alternative. https://github.com/rust-lang/rust-clippy/pull/14705 + +- We're currently in the effort to optimize some documentation lints that took up to 15% of the Clippy runtime (depending on how much documentation for each line of code you had.) See https://github.com/rust-lang/rust-clippy/pull/14693 + +- We've also been experimenting with lots of new possibilities, mainly on parallel lints. Althought they currently are not performance improvements, there are some great hope put into them. + +- Memory consumption and branch mispredictions are being monitored, they do not seem out of the ordinary. + +- Monitoring cache misses and references, turns out that about 31% of cache references (792m found) are cache misses (253m found) in some benchmarks. We will check what's behind those numbers and if they can be improved. + +This has been a great month for performance! + + + +
+ +
+ + +
+
Prepare const traits for stabilization
+
+
+
+ + + + + + + +
+1 detailed update available. + + + + + + +Comment by @oli-obk posted on 2025-04-30:
+ +
+ + + +No updates + + + +
+ +
+ + +
+
Promoting Parallel Front End
+
+
+
+ + + + + + + + + +
+No detailed updates available. +
+ + +
+
Prototype a new set of Cargo "plumbing" commands
+
+
+
+ + + + + + + +
+3 detailed updates available. + + + + + + +Comment by @epage posted on 2025-04-30:
+ +
+ + + +- Key developments: + - The [cargo-plumbing repo](https://github.com/crate-ci/cargo-plumbing) was created to serve as the central place for collaboration on this effort + - @ashiskumarnaik posted crate-ci/cargo-plumbing#5 for the first plumbing command +- Blockers: +- Help wanted: + + + + + +
+ + + + +Comment by @ojuschugh1 posted on 2025-05-05:
+ +
+ + + +Hi @epage , I am interested in working on this project. If you are still looking for someone. + + + +
+ + + + +Comment by @epage posted on 2025-05-05:
+ +
+ + + +@ojuschugh1 iirc there is a GSoC proposal for this and we are waiting to hear whether it was accepted. If it was, it would likely involve coordinating with them on tasks. + + + +
+ +
+ + +
+
Publish first rust-lang-owned release of "FLS"
+
+
+
+ + + + + + + +
+1 detailed update available. + + + + + + +Comment by @JoelMarcey posted on 2025-05-02:
+ +
+ + + +Key Developments: The FLS repo has officially been transferred from Ferrous to the Rust Project. https://github.com/rust-lang/fls is now live. + +Next step: Integrate the FLS with the Rust build system in order to support publishing within project processes. + +Blockers: None yet. The build system integration could create some support requests, however. + + + +
+ +
+ + +
+
Publish first version of StableMIR on crates.io
+
+
+
+ + + + + + + +
+1 detailed update available. + + + + + + +Comment by @celinval posted on 2025-04-30:
+ +
+ + + +We have started the refactoring. @makai410 has moved all the existing code into a single crate and they have started moving things around. + + + +
+ +
+ + +
+
Research: How to achieve safety when linking separately compiled code
+
+
+
+ + + + + + + + + +
+No detailed updates available. +
+ + +
+
Run the 2025H1 project goal program
+
+
+
+ + + + + + + + + +
+No detailed updates available. +
+ + +
+
Rust Vision Document
+
+
+
+ + + + + + + + + +
+No detailed updates available. +
+ + +
+
rustc-perf improvements
+
+
+
+ + + + + + + +
+1 detailed update available. + + + + + + +Comment by @davidtwco posted on 2025-05-07:
+ +
+ + + +- @Jamesbarford has been working with @Kobzol to implement a database-backed job queueing mechanism, which will better scale to support multiple collectors and ends up being the key part of rustc-perf needing adapted to support multiple collectors. +- @Jamesbarford has also upstreamed tests for the existing queue ordering (rust-lang/rustc-perf#2072). + + + +
+ +
+ + +
+
Scalable Polonius support on nightly
+
+
+
+ + + + + + + +
+1 detailed update available. + + + + + + +Comment by @lqd posted on 2025-05-05:
+ +
+ + + +Here are the key developments for the month of April + +- @amandasystems + - extracted a handful of PRs out of the gigantic placeholder rewrite PR, to make it easier to review and land + - https://github.com/rust-lang/rust/pull/139960, https://github.com/rust-lang/rust/pull/139965, and https://github.com/rust-lang/rust/pull/140466 +- Tage + - continued experimenting and making progress with the early phase of the process, and making building constraints, and traversing them per loan, lazy + - started extracting some of that work for discussion, review, PRs, as well as writing reports for his masters thesis +- @lqd + - continued on improving the algorithm. We're now at a point where we have an approximation of the datalog algorithm, which handles our UI tests -- except one where control flow in a loop connects to regions that are live before and after the loop: this causes a false positive that our datalog implementation used to accept (via a more comprehensive but slower approach). + - we're currently discussing whether we can cut scope *here*, as this formulation accepts NLL problem case 3. We'll need to evaluate what limits this formulation imposes on expressiveness outside NLL problem case 3 and streaming iterators -- and whether it indeed has an easier path to becoming production ready. We'll also still try to see if it's possible to still improve the algorithm and avoid emitting errors on [issue 46589](https://github.com/rust-lang/rust/issues/46589), since we initially hoped to fix this one as well. + + + +
+ +
+ + +
+
Secure quorum-based cryptographic verification and mirroring for crates.io
+
+
+
+ + + + + + + + + +
+No detailed updates available. +
+ + +
+
Stabilize cargo-script
+
+
+
+ + + + + + + +
+1 detailed update available. + + + + + + +Comment by @epage posted on 2025-04-30:
+ +
+ + + +Key developments: +- @fee1-dead posted rust-lang/rust#140035 for compiler support for frontmatters (which supersedes rust-lang/rust#137193) + +Blockers: + +Help wanted: + + + +
+ +
+ + +
+
Stabilize public/private dependencies
+
+
+
+ + + + + + + + + +
+No detailed updates available. +
+ + +
+
SVE and SME on AArch64
+
+
+
+ + + + + + + +
+1 detailed update available. + + + + + + +Comment by @davidtwco posted on 2025-05-07:
+ +
+ + + +- 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. + + + +
+ +
+ + +
+
Unsafe Fields
+
+
+
+ + + + + + + +
+1 detailed update available. + + + + + + +Comment by @jswrenn posted on 2025-04-18:
+ +
+ + + +**Key developments:** After the last lang team meeting, Ralf observed that the additive/subtractive dichotomy (and its attendant design concerns w.r.t. `Drop`) could be sidestepped, since a field type *already* cannot be put into an unsound-to-drop state without unsafe code. With this observation, we can reduce field safety tooling to two rules: + +1. a field should be marked unsafe if it carries a safety invariant (of any kind) +2. a field marked `unsafe` is unsafe to use + +The RFC now reflects this design and has more or less reached a fixed point. Ongoing discussion on the RFC is now mostly limited to weighing this design against a proposed alternative that mixes syntactically knobs and wrapper types. The RFC would benefit from formal review by @rust-lang/lang. + + + +
+ +
+ + +
+
Use annotate-snippets for rustc diagnostic output
+
+
+
+ + + + + + + + + +
+No detailed updates available. +
+ + From 7187713e37c39e6082aba8f4fbce6d0e350a89df Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?R=C3=A9my=20Rakic?= Date: Wed, 21 May 2025 19:26:57 +0000 Subject: [PATCH 02/10] make async goal update the TL;DR --- content/Project-Goals-2025-April-Update.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/content/Project-Goals-2025-April-Update.md b/content/Project-Goals-2025-April-Update.md index 54ee31f97..a0066ff4b 100644 --- a/content/Project-Goals-2025-April-Update.md +++ b/content/Project-Goals-2025-April-Update.md @@ -23,6 +23,12 @@ The Rust project is currently working towards a [slate of 40 project goals](http **What has happened?** +**Async fn in traits.** An FCP proposal to stabilize return type notation was started in . However, it is currently blocked on concerns that stabilizing it now will make it more difficult to ship Rust's next-generation trait solver. + +**Async fn in dyn trait.** There have been discussions around next steps to support this in the language. More experimentation is needed, along with an initial RFC. + +**dynosaur.** More breaking changes have landed and we expect to release v0.3 soon. + From e3ee560a069fce9bd1e8f6653dc737df38795476 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?R=C3=A9my=20Rakic?= Date: Wed, 21 May 2025 19:32:29 +0000 Subject: [PATCH 03/10] summarize all hands updates as TL;DR --- content/Project-Goals-2025-April-Update.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/Project-Goals-2025-April-Update.md b/content/Project-Goals-2025-April-Update.md index a0066ff4b..d7664dce5 100644 --- a/content/Project-Goals-2025-April-Update.md +++ b/content/Project-Goals-2025-April-Update.md @@ -70,7 +70,7 @@ The Rust project is currently working towards a [slate of 40 project goals](http **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](https://internals.rust-lang.org/t/announcing-the-subteams/2042). At the time [there were 6 Rust teams with 24 people in total](http://web.archive.org/web/20150517235608/http://www.rust-lang.org/team.html). 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](https://2025.rustweek.org), a joint event organized with [RustNL](https://2025.rustweek.org/about/). 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](./rust-vision-doc.md), 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?** +**What has happened?** Things have been progressing smoothly. The work to prepare the schedule for the "pre all hands" and all hands has started with the teams. The COVID policy has been posted. Self-tests and CO₂ sensors have been received, as well as speaker-microphones to allow for remote participation. From f2fcb243c97a7e72feb04e815a44fe9961a79050 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?R=C3=A9my=20Rakic?= Date: Wed, 21 May 2025 19:49:04 +0000 Subject: [PATCH 04/10] fix goals looking for help section --- content/Project-Goals-2025-April-Update.md | 34 +++++++++++++++++++++- 1 file changed, 33 insertions(+), 1 deletion(-) diff --git a/content/Project-Goals-2025-April-Update.md b/content/Project-Goals-2025-April-Update.md index d7664dce5..b3c679b63 100644 --- a/content/Project-Goals-2025-April-Update.md +++ b/content/Project-Goals-2025-April-Update.md @@ -268,10 +268,42 @@ Update from our 2025-05-07 meeting ([full minutes](https://hackmd.io/@rust-lang- - +
## Goals looking for help +
+ +
+
+
+ + + + + +*Help wanted:* Help test the deadlock code in the [issue list](https://github.com/rust-lang/rust/labels/WG-compiler-parallel) and try to reproduce the issues. If you'd like to help, please post in [this goal's dedicated zulip topic](https://rust-lang.zulipchat.com/#narrow/channel/435869-project-goals/topic/Promoting.20Parallel.20Front.20End.20.28goals.23121.29/with/506292058). + + + + + +
+
+ +
+
+
+ + + + + +*Help wanted:* T-compiler people to work on the blocking issues [#119428](https://github.com/rust-lang/rust/issues/119428) and [#71043](https://github.com/rust-lang/rust/issues/71043). If you'd like to help, please post in [this goal's dedicated zulip topic](https://rust-lang.zulipchat.com/#narrow/channel/435869-project-goals/topic/Stabilize.20public.2Fprivate.20dependencies.20.28goals.23272.29). + + + + ## Other goal updates From d696bd56604b7fab475c7c13cf0b18e082319659 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?R=C3=A9my=20Rakic?= Date: Wed, 21 May 2025 19:50:53 +0000 Subject: [PATCH 05/10] fix RFL section about naked functions --- content/Project-Goals-2025-April-Update.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/Project-Goals-2025-April-Update.md b/content/Project-Goals-2025-April-Update.md index b3c679b63..be6c4b893 100644 --- a/content/Project-Goals-2025-April-Update.md +++ b/content/Project-Goals-2025-April-Update.md @@ -164,7 +164,7 @@ I'll put them near the entrance for anyone to borrow for any of the meeting room **What has happened?** 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). +We are also finishing up some of the work on language items. We have had one stabilization of lang features needed by Rust for Linux ([`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). From b943dea69401c5738a4958751b275f27a4571901 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?R=C3=A9my=20Rakic?= Date: Wed, 21 May 2025 20:02:28 +0000 Subject: [PATCH 06/10] remove May update from RFL section --- content/Project-Goals-2025-April-Update.md | 33 +--------------------- 1 file changed, 1 insertion(+), 32 deletions(-) diff --git a/content/Project-Goals-2025-April-Update.md b/content/Project-Goals-2025-April-Update.md index be6c4b893..526e709f9 100644 --- a/content/Project-Goals-2025-April-Update.md +++ b/content/Project-Goals-2025-April-Update.md @@ -170,7 +170,7 @@ We are also finishing up some of the work on language items. We have had one sta
-3 detailed updates available. +2 detailed updates available. @@ -234,37 +234,6 @@ Update from our 2025-04-23 meeting ([full minutes](https://hackmd.io/@rust-lang- - - - -Comment by @ojeda posted on 2025-05-20:
- -
- - - -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). - - - -
-
From 5a0a123224a2d07f676cccee420e2059838b4426 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?R=C3=A9my=20Rakic?= Date: Wed, 21 May 2025 20:13:56 +0000 Subject: [PATCH 07/10] linkify --- content/Project-Goals-2025-April-Update.md | 52 +++++++++++----------- 1 file changed, 27 insertions(+), 25 deletions(-) diff --git a/content/Project-Goals-2025-April-Update.md b/content/Project-Goals-2025-April-Update.md index 526e709f9..d79272672 100644 --- a/content/Project-Goals-2025-April-Update.md +++ b/content/Project-Goals-2025-April-Update.md @@ -46,7 +46,7 @@ The Rust project is currently working towards a [slate of 40 project goals](http -**Async fn in traits.** An FCP proposal to stabilize return type notation was started in https://github.com/rust-lang/rust/pull/138424. However, it is currently blocked on concerns that stabilizing it now will make it more difficult to ship Rust's next-generation trait solver. +**Async fn in traits.** An FCP proposal to stabilize return type notation was started in . However, it is currently blocked on concerns that stabilizing it now will make it more difficult to ship Rust's next-generation trait solver. **Async fn in dyn trait.** There have been discussions around next steps to support this in the language. More experimentation is needed, along with an initial RFC. @@ -114,7 +114,7 @@ The last day has a lot of empty slots for now. I'm still working on filling thos -I published our covid policy: https://rustweek.org/covid-policy-all-hands-and-unconf/ +I published our covid policy: And got us a ton of covid self-tests and Aranet4 CO₂ sensors: @@ -162,10 +162,12 @@ I'll put them near the entrance for anyone to borrow for any of the meeting room [RFL.com]: https://rust-for-linux.com/ [RFL#2]: https://github.com/Rust-for-Linux/linux/issues/2 -**What has happened?** 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. +**What has happened?** 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 one stabilization of lang features needed by Rust for Linux ([`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). +[RFC #3791]: https://github.com/rust-lang/rfcs/pull/3791 + @@ -187,17 +189,17 @@ Update from our 2025-04-09 meeting ([full minutes](https://hackmd.io/@rust-lang- - Some progress on `arbitrary_self_types`. In particular, decided to do with respect to pin and other related cases. - - `asm_goto` is solved, apart from output operands. For `asm_const`, https://github.com/rust-lang/rust/pull/138618 is nominated. + - `asm_goto` is solved, apart from output operands. For `asm_const`, is nominated. - - ABI-modifying compiler flags: some PRs waiting review, e.g. https://github.com/rust-lang/rust/pull/138736. + - ABI-modifying compiler flags: some PRs waiting review, e.g. . - - `--crate-attr` RFC is up: https://github.com/rust-lang/rfcs/pull/3791. + - `--crate-attr` RFC is up: . - - `-Zsanitize-kcfi-arity`'s implementation PR got merged: https://github.com/rust-lang/rust/pull/138368. If all is good from the Linux side, a stabilization PR will be sent. + - `-Zsanitize-kcfi-arity`'s implementation PR got merged: . If all is good from the Linux side, a stabilization PR will be sent. - - CFI `core::fmt` issue: https://github.com/rust-lang/rust/issues/115199. + - CFI `core::fmt` issue: . - - Discussion around `bindgen`, `repr(align)` and packed types. RFC nominated for lang discussion: https://github.com/rust-lang/rfcs/pull/3718#issuecomment-2790654254. + - Discussion around `bindgen`, `repr(align)` and packed types. RFC nominated for lang discussion: . @@ -218,9 +220,9 @@ Update from our 2025-04-23 meeting ([full minutes](https://hackmd.io/@rust-lang- - Lang discussed `#[repr(align)]` (the kernel is interested in, at least, the global one, i.e. `-Zmin-function-alignment=N`). - - `asm_const`: @nbdd0121 will reply on the latest review comments in the implementation PR: https://github.com/rust-lang/rust/issues/128464. + - `asm_const`: @nbdd0121 will reply on the latest review comments in the implementation PR: . - - `--crate-attr`: the author of the RFC (https://github.com/rust-lang/rfcs/pull/3791) is looking for a new owner. The RFC is in proposed FCP. Small updates to the text may be needed. Otherwise compiler probably wants to merge it. @Mark-Simulacrum to be pinged. + - `--crate-attr`: the author of the RFC () is looking for a new owner. The RFC is in proposed FCP. Small updates to the text may be needed. Otherwise compiler probably wants to merge it. @Mark-Simulacrum to be pinged. - Clippy configuration etc.: @flip1995 will be at RustWeek, the plan is to discuss it there. @@ -228,7 +230,7 @@ Update from our 2025-04-23 meeting ([full minutes](https://hackmd.io/@rust-lang- - `-Zsanitize-kcfi-arity`: waiting on the kernel side (`tc-build` support sent). - - CFI `core::fmt` issue: PR submitted: https://github.com/rust-lang/rust/pull/139632. + - CFI `core::fmt` issue: PR submitted: . @@ -460,7 +462,7 @@ There are some good news as well, though! While looking at the `#[target_feature -In reviewing https://github.com/rust-lang/rust/pull/138628, we realized that the tests were not behaving as expected because they were running in Rust 2015 which had distinct capture rules. My [suggestion](https://github.com/rust-lang/rust/pull/138628#pullrequestreview-2750344682) was to limit the `use` keyword (or at least use closures...) to Rust 2021 so as to avoid having to think about how it interacts with earlier capture rules (as well as potential migrations). I believe this follows from the Edition axiom that [Editions are meant to be adopted](https://rust-lang.github.io/rfcs/3085-edition-2021.html#editions-are-meant-to-be-adopted). +In reviewing , we realized that the tests were not behaving as expected because they were running in Rust 2015 which had distinct capture rules. My [suggestion](https://github.com/rust-lang/rust/pull/138628#pullrequestreview-2750344682) was to limit the `use` keyword (or at least use closures...) to Rust 2021 so as to avoid having to think about how it interacts with earlier capture rules (as well as potential migrations). I believe this follows from the Edition axiom that [Editions are meant to be adopted](https://rust-lang.github.io/rfcs/3085-edition-2021.html#editions-are-meant-to-be-adopted). There is an interesting tension with [Rust should feel like one language](https://rust-lang.github.io/rfcs/3085-edition-2021.html#rust-should-feel-like-one-language). My feeling is that there is a missing tenet: the reason we do editions and not fine-grained features is because we wish to avoid combianotoric explosion, where odd combinations of features can lead to untested scenarios. But that is exactly what would be happening here if we allow `use` on older editions. So I think the rule should be that you make new features available on older editions *up until the point where they interact with something that changed* -- in this case, `use` closures interact with the closure capture rules which changed in Rust 2021, so we should limit this feature to Rust 2021 and newer. @@ -631,7 +633,7 @@ I will be giving [a talk at Rust-Week](https://rustweek.org/talks/jacob/) about @b-naber and I have been working on the rustc side of the implementation for this feature. -I merged https://github.com/rust-lang/rust/pull/139647, which adds the unstables `-Z namespaced-crates` option to the compiler and enables parsing of externs like `--extern foo::bar=libbar.rlib`. @b-naber has led the resolver changes and has a draft PR up at https://github.com/rust-lang/rust/pull/140271. +I merged , which adds the unstables `-Z namespaced-crates` option to the compiler and enables parsing of externs like `--extern foo::bar=libbar.rlib`. @b-naber has led the resolver changes and has a draft PR up at . The implementation work has raised some [new concerns](https://github.com/rust-lang/rust/issues/122349#issuecomment-2832241624) about the overall direction, so work is ongoing to resolve those while continuing to make progress in the meantime. @@ -706,7 +708,7 @@ The implementation work has raised some [new concerns](https://github.com/rust-l -We fixed issue https://github.com/rust-lang/rust/issues/136925 that was blocking contract annotations on constant functions, which unblocks the initial PR to add some contract annotations in the standard library (https://github.com/rust-lang/rust/pull/136578). The PR currently triggers a CI failure which we are investigating. +We fixed issue that was blocking contract annotations on constant functions, which unblocks the initial PR to add some contract annotations in the standard library (). The PR currently triggers a CI failure which we are investigating. @@ -787,7 +789,7 @@ following the plan mentioned above plus some extra bits, I've implemented the fo * changed the file naming to ensure uniqueness and not overwrite metrics for the same crate when built with different configurations * previously I was piggybacking on the hash used to name artifacts in the `.cargo` or `build` directories, which in the compiler is known as `extra_filename` and is configured by cargo, but it turns out this doesn't guarantee uniqueness * I've replaced this with the ["Strict Version Hash"](https://rustc-dev-guide.rust-lang.org/backend/libs-and-metadata.html?highlight=stable%20version%20hash#strict-version-hash) (SVH) - * Doing so introduced an ICE when compiling some crates with incremental compilation enabled. I've since resolved this in https://github.com/rust-lang/rust/pull/139502 and tested this version against the top 100 crates in the ecosystem and their dependencies to verify its working + * Doing so introduced an ICE when compiling some crates with incremental compilation enabled. I've since resolved this in and tested this version against the top 100 crates in the ecosystem and their dependencies to verify its working * I've been working with the infra team and they've setup a cloud instance of influxdb 3.0 and grafana, influxdb is setup, grafana in progress * I met with both libs and lang to discuss their needs related to the unstable feature usage metrics and metrics in general @@ -796,7 +798,7 @@ Next Steps: * update locally hosted PoC impl to work with recent changes to metrics files and naming and validate that it's working as expected * work on the queries for the grafana instance to setup a graph per feature showing usage over time * probably going to create fake usage data to with for this -* on the side I'm also looking into how much work it would be to track relative usage of various library APIs under a single feature flag (e.g. https://github.com/rust-lang/rust/issues/139911 tracking the specific functions used) +* on the side I'm also looking into how much work it would be to track relative usage of various library APIs under a single feature flag (e.g. tracking the specific functions used) * develop a better understanding of the expected cost of running an influxdb server @@ -870,11 +872,11 @@ With this I should be ready to just upload the data once we've gathered it from -We've made a lot of progress over the last 1.5 months. My change to opaque types in borrowck is pretty much done now: https://github.com/rust-lang/rust/pull/139587. It still needs some cleanup and an FCP to actually merge. We've already merged multiple cleanups on the way here. +We've made a lot of progress over the last 1.5 months. My change to opaque types in borrowck is pretty much done now: . It still needs some cleanup and an FCP to actually merge. We've already merged multiple cleanups on the way here. -We then started to test crater with the `-Znext-solver=globally`. @compiler-errors and me encountered and merged the fixes for 13 issues since then: https://github.com/rust-lang/rust/pull/139791 https://github.com/rust-lang/rust/pull/139798 https://github.com/rust-lang/rust/pull/140236 https://github.com/rust-lang/rust/pull/139900 https://github.com/rust-lang/rust/pull/139828 https://github.com/rust-lang/rust/pull/139774 https://github.com/rust-lang/rust/pull/139762 https://github.com/rust-lang/rust/pull/139789 https://github.com/rust-lang/rust/pull/138845 https://github.com/rust-lang/rust/pull/140306 https://github.com/rust-lang/rust/pull/140305 https://github.com/rust-lang/rust/pull/140276 https://github.com/rust-lang/rust/pull/140302. @Nadrieril was also helpful by minimizing an encountered issue. +We then started to test crater with the `-Znext-solver=globally`. @compiler-errors and me encountered and merged the fixes for 13 issues since then: . @Nadrieril was also helpful by minimizing an encountered issue. -With these improvements and multiple in-flight changes we're now at significantly less than 100 remaining regressions in the top 10000 crates and have started the first complete crater run today. We are using a single PR for all crater runs. Check out https://github.com/rust-lang/rust/pull/133502 for the current status and the stack of in-flight changes. +With these improvements and multiple in-flight changes we're now at significantly less than 100 remaining regressions in the top 10000 crates and have started the first complete crater run today. We are using a single PR for all crater runs. Check out for the current status and the stack of in-flight changes. @@ -965,11 +967,11 @@ Key developments: nothing substantial. Monthly update! -- In [the last monthly update](https://github.com/rust-lang/rust-project-goals/issues/114#issuecomment-2730435572) we saw the impact that [interning symbols](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/symbol/struct.Symbol.html#method.intern) had on the program's performance. An effort to minimize this via a pre-interning symbol mechanism has been implemented in https://github.com/rust-lang/rust-clippy/pull/14650 and https://github.com/rust-lang/rust/pull/138682 +- In [the last monthly update](https://github.com/rust-lang/rust-project-goals/issues/114#issuecomment-2730435572) we saw the impact that [interning symbols](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/symbol/struct.Symbol.html#method.intern) had on the program's performance. An effort to minimize this via a pre-interning symbol mechanism has been implemented in and -- We're phasing out the old ["str path"](https://doc.rust-lang.org/nightly/nightly-rustc/clippy_utils/fn.match_def_path.html) infrastructure into a new lazy alternative. https://github.com/rust-lang/rust-clippy/pull/14705 +- We're phasing out the old ["str path"](https://doc.rust-lang.org/nightly/nightly-rustc/clippy_utils/fn.match_def_path.html) infrastructure into a new lazy alternative. -- We're currently in the effort to optimize some documentation lints that took up to 15% of the Clippy runtime (depending on how much documentation for each line of code you had.) See https://github.com/rust-lang/rust-clippy/pull/14693 +- We're currently in the effort to optimize some documentation lints that took up to 15% of the Clippy runtime (depending on how much documentation for each line of code you had.) See - We've also been experimenting with lots of new possibilities, mainly on parallel lints. Althought they currently are not performance improvements, there are some great hope put into them. @@ -1137,7 +1139,7 @@ Hi @epage , I am interested in working on this project. If you are still lookin -Key Developments: The FLS repo has officially been transferred from Ferrous to the Rust Project. https://github.com/rust-lang/fls is now live. +Key Developments: The FLS repo has officially been transferred from Ferrous to the Rust Project. is now live. Next step: Integrate the FLS with the Rust build system in order to support publishing within project processes. @@ -1308,7 +1310,7 @@ Here are the key developments for the month of April - @amandasystems - extracted a handful of PRs out of the gigantic placeholder rewrite PR, to make it easier to review and land - - https://github.com/rust-lang/rust/pull/139960, https://github.com/rust-lang/rust/pull/139965, and https://github.com/rust-lang/rust/pull/140466 + - , , and - Tage - continued experimenting and making progress with the early phase of the process, and making building constraints, and traversing them per loan, lazy - started extracting some of that work for discussion, review, PRs, as well as writing reports for his masters thesis From 7e5c614b8d04528bbac5c95efe73075c0eabdb28 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?R=C3=A9my=20Rakic?= Date: Thu, 22 May 2025 17:54:39 +0200 Subject: [PATCH 08/10] Update content/Project-Goals-2025-April-Update.md Co-authored-by: apiraino --- content/Project-Goals-2025-April-Update.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/Project-Goals-2025-April-Update.md b/content/Project-Goals-2025-April-Update.md index d79272672..a80586c54 100644 --- a/content/Project-Goals-2025-April-Update.md +++ b/content/Project-Goals-2025-April-Update.md @@ -481,7 +481,7 @@ Put another way, you should never have to go back and modify an edition migratio -We've modified codegen so that we guarantee that `x.use` will do a copy if `X: Copy` is true after monomorphization. Before this change the desugaring to `clone` occured only before monomorphization and hence it would call the `clone` method even for those instances where `X` is a `Copy` type. So with this modification we avoid such situation. +We've modified codegen so that we guarantee that `x.use` will do a copy if `X: Copy` is true after monomorphization. Before this change the desugaring to `clone` occurred only before monomorphization and hence it would call the `clone` method even for those instances where `X` is a `Copy` type. So with this modification we avoid such situation. We are not working on convert `x.use` to a move rather than a clone if this is a last-use. From 4b6919163da4a36411b8230b256303b9dbe35df8 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?R=C3=A9my=20Rakic?= Date: Thu, 22 May 2025 17:54:55 +0200 Subject: [PATCH 09/10] Update content/Project-Goals-2025-April-Update.md Co-authored-by: apiraino --- content/Project-Goals-2025-April-Update.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/Project-Goals-2025-April-Update.md b/content/Project-Goals-2025-April-Update.md index a80586c54..04c760041 100644 --- a/content/Project-Goals-2025-April-Update.md +++ b/content/Project-Goals-2025-April-Update.md @@ -973,7 +973,7 @@ Monthly update! - We're currently in the effort to optimize some documentation lints that took up to 15% of the Clippy runtime (depending on how much documentation for each line of code you had.) See -- We've also been experimenting with lots of new possibilities, mainly on parallel lints. Althought they currently are not performance improvements, there are some great hope put into them. +- We've also been experimenting with lots of new possibilities, mainly on parallel lints. Although they currently are not performance improvements, there are some great hope put into them. - Memory consumption and branch mispredictions are being monitored, they do not seem out of the ordinary. From 40dc890c4116b14f244b4c3fa9d7927a9432849f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?R=C3=A9my=20Rakic?= Date: Mon, 26 May 2025 09:06:46 +0000 Subject: [PATCH 10/10] set publication date --- content/Project-Goals-2025-April-Update.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/Project-Goals-2025-April-Update.md b/content/Project-Goals-2025-April-Update.md index 04c760041..194486a51 100644 --- a/content/Project-Goals-2025-April-Update.md +++ b/content/Project-Goals-2025-April-Update.md @@ -1,5 +1,5 @@ +++ -path = "9999/12/31/april-project-goals-update" +path = "2025/05/26/april-project-goals-update" title = "April Project Goals Update" authors = ["Rémy Rakic"]