From 2a5092cce2977595fcdf045baab08ffd76ff98d1 Mon Sep 17 00:00:00 2001 From: Tomas Sedovic Date: Wed, 5 Nov 2025 14:55:06 +0100 Subject: [PATCH] Add the 2025 October project goals update --- content/Project-Goals-2025-October-Update.md | 2642 ++++++++++++++++++ 1 file changed, 2642 insertions(+) create mode 100644 content/Project-Goals-2025-October-Update.md diff --git a/content/Project-Goals-2025-October-Update.md b/content/Project-Goals-2025-October-Update.md new file mode 100644 index 000000000..be8e4263c --- /dev/null +++ b/content/Project-Goals-2025-October-Update.md @@ -0,0 +1,2642 @@ ++++ +path = "9999/12/31/project-goals-update-october-2025" +title = "Project goals update — October 2025" +authors = ["Tomas Sedovic"] + +[extra] +team = "the Goals team" +team_url = "https://rust-lang.org/governance/teams/launching-pad/#team-goals" ++++ + +The Rust project is currently working towards a [slate of 41 project goals](https://rust-lang.github.io/rust-project-goals/2025h2/goals.html), with 13 of them designated as [Flagship Goals](https://rust-lang.github.io/rust-project-goals/2025h2/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 + + +### "Beyond the `&`" + +
+ + +
+Continue Experimentation with Pin Ergonomics (rust-lang/rust-project-goals#389) +
+ + + + + + + + + + + + + + + + + + + + +
Progress +
Point of contact

Frank King

+
Champions

compiler (Oliver Scherer), lang (TC)

+
Task owners

Frank King

+
+ + + + + + +
+ +

1 detailed update available.

+ + +
+
+Comment by @frank-king posted on 2025-10-22: +
+

Status update:

+

Regarding the TODO list in the next 6 months, here is the current status:

+

Introduce &pin mut|const place borrowing syntax

+
    +
  • [x] parsing: #135731, merged.
    • +
  • [ ] lowering and borrowck: not started yet.
    • +
+

I've got some primitive ideas about borrowck, and I probably need to confirm with someone who is familiar with MIR/borrowck before starting to implement.

+

A pinned borrow consists two MIR statements:

+
    +
  1. a borrow statement that creates the mutable reference,
    2. +
  2. and an adt aggregate statement that put the mutable reference into the Pin struct.
    3. +
+

I may have to add a new borrow kind so that pinned borrows can be recognized. Then traverse the dataflow graph to make sure that pinned places cannot been moved.

+

Pattern matching of &pin mut|const T types

+

In the past few months, I have struggled with the !Unpin stuffs (the original design sketch Alternative A), trying implementing it, refactoring, discussing on zulips, and was constantly confused; luckily, we have finally reached a new agreement of the Alternative B version.

+
    +
  • [ ] #139751 under review (reimplemented regarding Alternative B).
    • +
+

Support drop(&pin mut self) for structurally pinned types

+
    +
  • [ ] adding a new Drop::pin_drop(&pin mut self) method: draft PR #144537
    • +
+

Supporting both Drop::drop(&mut self) and Drop::drop(&pin mut self) seems to introduce method-overloading to Rust, which I think might need some more general ways to handle (maybe by a rustc attribute?). So instead, I'd like to implemenent this via a new method Drop::pin_drop(&pin mut self) first.

+

Introduce &pin pat pattern syntax

+

Not started yet (I'd prefer doing that when pattern matching of &pin mut|const T types is ready).

+

Support &pin mut|const T -> &|&mut T coercion (requires T: Unpin of &pin mut T -> &mut T)

+

Not started yet. (It's quite independent, probably someone else can help with it)

+

Support auto borrowing of &pin mut|const place in method calls with &pin mut|const self receivers

+

Seems to be handled by Autoreborrow traits?

+ +
+
+
+
+ +
+
+ + +
+Design a language feature to solve Field Projections (rust-lang/rust-project-goals#390) +
+ + + + + + + + + + + + + + + + + + + + +
Progress +
Point of contact

Benno Lossin

+
Champions

lang (Tyler Mandry)

+
Task owners

Benno Lossin

+
+ + +
+TL;DR.

There have been lots of internal developments since the last update:

+ +

Next Steps:

+
    +
  • we're still planning to merge https://github.com/rust-lang/rust/pull/146307, after I have updated it with the new FRT logic and it has been reviewed
    • +
  • once that PR lands, I plan to update the library experiment to use the experimental FRTs
    • +
  • then the testing using that library can begin in the Linux kernel and other projects (this is where anyone interested in trying field projections can help out!)
    • +
+ +
+ + + + +
+ +

4 detailed updates available.

+ + +
+
+Comment by @BennoLossin posted on 2025-10-23: +
+

Decomposing Projections

+

A chained projection operation should naturally decompose, so foo.[Ber Clausen][].[Baz Shkara][] should be the same as writing (foo.[Ber Clausen][]).[Baz Shkara][]. Until now, the different parenthesizing would have allowed different outcomes. This behavior is confusing and also makes many implementation details more complicated than they need to be.

+

Field Representing Types

+

Since projections now decompose, we have no need from a design perspective for multi-level FRTs. So field_of!(Foo, bar.baz) is no longer required to work. Thus we have decided to restrict FRTs to only a single field and get rid of the path. This simplifies the implementation in the compiler and also avoids certain difficult questions such as the locality of FRTs (if we had a path, we would have to walk the path and it is local, if all structs included in the path are local). Now with only a single field, the FRT is local if the struct is.

+

We also discovered that it is a good idea to make FRTs inhabited (they still are ZSTs), since then it allows the following pattern to work:

+
fn project_free_standing<F: Field>(_: Field, r: &F::Base) -> &F::Type { ... }
+
+// can now call the function without turbofish:
+let my_field = project_free_standing(field_of!(MyStruct, my_field), &my_struct);
+
+

FRTs via const Generics

+

We also spent some time thinking about const generics and FRTs on zulip:

+ +

In short, this won't be happening any time soon. However, it could be a future implementation of the field_of! macro depending on how reflection through const generics evolves (but also only in the far-ish future).

+ +
+
+
+Comment by @BennoLossin posted on 2025-10-23: +
+

Single Project Operator & Trait via Exclusive Decay

+

It would be great if we only had to add a single operator and trait and could obtain the same features as we have with two. The current reason for having two operators is to allow both shared and exclusive projections. If we could have another operation that decays an exclusive reference (or custom, exclusive smart-pointer type) into a shared reference (or the custom, shared version of the smart pointer). This decay operation would need borrow checker support in order to have simultaneous projections of one field exclusively and another field shared (and possibly multiple times).

+

This goes into a similar direction as the reborrowing project goal https://github.com/rust-lang/rust-project-goals/issues/399, however, it needs extra borrow checker support.

+
fn add(x: cell::RefMut<'_, i32>, step: i32) {
+    *x = *x + step;
+}
+
+struct Point {
+    x: i32,
+    y: i32,
+}
+
+fn example(p: cell::RefMut<'_, Point>) {
+    let y: cell::Ref<'_, i32> = coerce_shared!(p.[@y][]);
+    let y2 = coerce_shared!(p.[@y][]); // can project twice if both are coerced
+    add(p.[Devon Peticolas][], *y);
+    add(p.[Devon Peticolas][], *y2);
+    assert_eq!(*y, *y2); // can still use them afterwards
+}
+
+

Problems:

+
    +
  • explicit syntax is annoying for these "coercions", but
    • +
  • we cannot make this implicit: +
      +
    • if this were an implicit operation, only the borrow checker would know when one had to coerce,
      • +
    • this operation is allowed to change the type,
      • +
    • this results in borrow check backfeeding into typecheck, which is not possible or at least extremely difficult
      • +
    +
    • +
+

Syntax

+

Not much movement here, it depends on the question discussed in the previous section, since if we only have one operator, we could choose .@, -> or ~; if we have to have two, then we need additional syntax to differentiate them.

+ +
+
+
+Comment by @BennoLossin posted on 2025-10-23: +
+

Simplifying the Project trait

+

There have been some developments in pin ergonomics https://github.com/rust-lang/rust/issues/130494: "alternative B" is now the main approach which means that Pin<&mut T> has linear projections, which means that it doesn't change its output type depending on the concrete field (really depending on the field, not only its type). So it falls into the general projection pattern Pin<&mut Struct> -> Pin<&mut Field> which means that Pin doesn't need any where clauses when implementing Project.

+

Additionally we have found out that RCU also doesn't need where clauses, as we can also make its projections linear by introducing a MutexRef<'_, T> smart pointer that always allows projections and only has special behavior for T = Rcu<U>. Discussed on zulip after this message.

+

For this reason we can get rid of the generic argument to Project and mandate that all types that support projections support them for all fields. So the new Project trait looks like this:

+
// still need a common super trait for `Project` & `ProjectMut`
+pub trait Projectable {
+    type Target: ?Sized;
+}
+
+pub unsafe trait Project: Projectable {
+    type Output<F: Field<Base = Self::Target>>;
+
+    unsafe fn project<F: Field<Base = Self::Target>>(
+        this: *const Self,
+    ) -> Self::Output<F>;
+}
+
+

Are FRTs even necessary?

+

With this change we can also think about getting rid of FRTs entirely. For example we could have the following Project trait:

+
pub unsafe trait Project: Projectable {
+    type Output<F>;
+
+    unsafe fn project<const OFFSET: usize, F>(
+        this: *const Self,
+    ) -> Self::Output<F>;
+}
+
+

There are other applications for FRTs that are very useful for Rust-for-Linux. For example, storing field information for intrusive data structures directly in that structure as a generic.

+ +

More concretely, in the kernel there are workqueues that allow you to run code in parallel to the currently running thread. In order to insert an item into a workqueue, an intrusive linked list is used. However, we need to be able to insert the same item into multiple lists. This is done by storing multiple instances of the Work struct. Its definition is:

+
pub struct Work<T, const ID: u64> { ... }
+
+

Where the ID generic must be unique inside of the struct.

+
struct MyDriver {
+    data: Arc<MyData>,
+    main_work: Work<Self, 0>,
+    aux_work: Work<Self, 1>,
+    // more fields ...
+}
+
+// Then you call a macro to implement the unsafe `HasWork` trait safely.
+// It asserts that there is a field of type `Work<MyDriver, 0>` at the given field
+// (and also exposes its offset).
+impl_has_work!(impl HasWork<MyDriver, 0> for MyDriver { self.main_work });
+impl_has_work!(impl HasWork<MyDriver, 1> for MyDriver { self.aux_work });
+
+// Then you implement `WorkItem` twice:
+
+impl WorkItem<0> for MyDriver {
+    type Pointer = Arc<Self>;
+    
+    fn run(this: Self::Pointer) {
+        println!("doing the main work here");
+    }
+}
+
+impl WorkItem<1> for MyDriver {
+    type Pointer = Arc<Self>;
+    
+    fn run(this: Self::Pointer) {
+        println!("doing the aux work here");
+    }
+}
+
+// And finally you can call `enqueue` on a `Queue`:
+
+let my_driver = Arc::new(MyDriver::new());
+let queue: &'static Queue = kernel::workqueue::system_highpri();
+queue.enqueue::<_, 0>(my_driver.clone()).expect("my_driver is not yet enqueued for id 0");
+
+// there are different queues
+let queue = kernel::workqueue::system_long();
+queue.enqueue::<_, 1>(my_driver.clone()).expect("my_driver is not yet enqueued for id 1");
+
+// cannot insert multiple times:
+assert!(queue.enqueue::<_, 1>(my_driver.clone()).is_err());
+
+

FRTs could be used instead of this id, making the definition be Work<F: Field> (also merging the T parameter).

+
struct MyDriver {
+    data: Arc<MyData>,
+    main_work: Work<field_of!(Self, main_work)>,
+    aux_work: Work<field_of!(Self, aux_work)>,
+    // more fields ...
+}
+
+impl WorkItem<field_of!(MyDriver, main_work)> for MyDriver {
+    type Pointer = Arc<Self>;
+    
+    fn run(this: Self::Pointer) {
+        println!("doing the main work here");
+    }
+}
+
+impl WorkItem<field_of!(MyDriver, aux_work)> for MyDriver {
+    type Pointer = Arc<Self>;
+    
+    fn run(this: Self::Pointer) {
+        println!("doing the aux work here");
+    }
+}
+
+let my_driver = Arc::new(MyDriver::new());
+let queue: &'static Queue = kernel::workqueue::system_highpri();
+queue
+    .enqueue(my_driver.clone(), field_of!(MyDriver, main_work))
+    //                          ^ using Gary's idea to avoid turbofish
+    .expect("my_driver is not yet enqueued for main_work");
+
+let queue = kernel::workqueue::system_long();
+queue
+    .enqueue(my_driver.clone(), field_of!(MyDriver, aux_work))
+    .expect("my_driver is not yet enqueued for aux_work");
+
+assert!(queue.enqueue(my_driver.clone(), field_of!(MyDriver, aux_work)).is_err());
+
+

This makes it overall a lot more readable (by providing sensible names instead of magic numbers), and maintainable (we can add a new variant without worrying about which IDs are unused). It also avoids the unsafe HasWork trait and the need to write the impl_has_work! macro for each Work field.

+ +

I still think that having FRTs is going to be the right call for field projections as well, so I'm going to keep their experiment going. However, we should fully explore their necessity and rationale for a future RFC.

+ +
+
+
+Comment by @BennoLossin posted on 2025-10-23: +
+

Making Project::project safe

+

In the current proposal the Project::project function is unsafe, because it takes a raw pointer as an argument. This is pretty unusual for an operator trait (it would be the first). Tyler Mandry thought about a way of making it safe by introducing "partial struct types". This new type is spelled Struct.F where F is an FRT of that struct. It's like Struct, but with the restriction that only the field represented by F can be accessed. So for example &Struct.F would point to Struct, but only allow one to read that single field. This way we could design the Project trait in a safe manner:

+
// governs conversion of `Self` to `Narrowed<F>` & replaces Projectable
+pub unsafe trait NarrowPointee {
+    type Target;
+
+    type Narrowed<F: Field<Base = Self::Target>>;
+}
+
+pub trait Project: NarrowPointee {
+    type Output<F: Field<Base = Self::Type>>;
+
+    fn project(narrowed: Self::Narrowed<F>) -> Self::Output<F>;
+}
+
+

The NarrowPointee trait allows a type to declare that it supports conversions of its Target type to Target.F. For example, we would implement it for RefMut like this:

+
unsafe impl<'a, T> NarrowPointee for RefMut<'a, T> {
+    type Target = T;
+    type Narrowed<F: Field<Base = T>> = RefMut<'a, T.F>;
+}
+
+

Then we can make the narrowing a builtin operation in the compiler that gets prepended on the actual coercion operation.

+

However, this "partial struct type" has a fatal flaw that Oliver Scherer found (edit by oli: it was actually boxy who found it): it conflicts with mem::swap, if Struct.F has the same layout as Struct, then writing to such a variable will overwrite all bytes, thus also overwriting field that aren't F. Even if we make an exception for these types and moves/copies, this wouldn't work, as a user today can rely on the fact that they write size_of::<T>() bytes to a *mut T and thus have a valid value of that type at that location. Tyler Mandry suggested we make it !Sized and even !MetaSized to prevent overwriting values of that type (maybe the Overwrite trait could come in handy here as well). But this might make "partial struct types" too weak to be truly useful. Additionally this poses many more questions that we haven't yet tackled.

+ +
+
+
+
+ +
+
+ + +
+Reborrow traits (rust-lang/rust-project-goals#399) +
+ + + + + + + + + + + + + + + + + + + + +
Progress +
Point of contact

Aapo Alasuutari

+
Champions

compiler (Oliver Scherer), lang (Tyler Mandry)

+
Task owners

Aapo Alasuutari

+
+ + + + + + +
+ +

1 detailed update available.

+ + +
+
+Comment by @aapoalas posted on 2025-10-22: +
+

Initial implementation of a Reborrow trait for types with only lifetimes with exclusive reference semantics is working but not yet upstreamed not in review. CoerceShared implementation is not yet started.

+

Proper composable implementation will likely require a different tactic than the current one. Safety and validity checks are currently absent as well and will require more work.

+ +
+
+
+
+ +
+ + +### "Flexible, fast(er) compilation" + +
+ + +
+build-std (rust-lang/rust-project-goals#274) +
+ + + + + + + + + + + + + + + + + + + + +
Progress +
Point of contact

David Wood

+
Champions

cargo (Eric Huss), compiler (David Wood), libs (Amanieu d'Antras)

+
Task owners

Adam Gemmell, David Wood

+
+ + + + + + +
+ +

1 detailed update available.

+ + +
+
+Comment by @davidtwco posted on 2025-10-31: +
+

We've now opened our first batch of RFCs: rust-lang/rfcs#3873, rust-lang/rfcs#3874 and rust-lang/rfcs#3875

+ +
+
+
+
+ +
+
+ + +
+Production-ready cranelift backend (rust-lang/rust-project-goals#397) +
+ + + + + + + + + + + + + + + + + + + + +
Progress +
Point of contact

Folkert de Vries

+
Champions

compiler (bjorn3)

+
Task owners

bjorn3, Folkert de Vries, [Trifecta Tech Foundation]

+
+ + + + + + +
+ +No detailed updates available. + +
+ +
+
+ + +
+Promoting Parallel Front End (rust-lang/rust-project-goals#121) +
+ + + + + + + + + + + + + + + + +
Progress +
Point of contact

Sparrow Li

+
Task owners

Sparrow Li

+
+ + + + + + +
+ +No detailed updates available. + +
+ +
+
+ + +
+Relink don't Rebuild (rust-lang/rust-project-goals#400) +
+ + + + + + + + + + + + + + + + + + + + +
Progress +
Point of contact

Jane Lusby

+
Champions

cargo (Weihang Lo), compiler (Oliver Scherer)

+
Task owners

Ally Sommers, Piotr Osiewicz

+
+ + + + + + +
+ +No detailed updates available. + +
+ +
+ + +### "Higher-level Rust" + +
+ + +
+Ergonomic ref-counting: RFC decision and preview (rust-lang/rust-project-goals#107) +
+ + + + + + + + + + + + + + + + + + + + +
Progress +
Point of contact

Niko Matsakis

+
Champions

compiler (Santiago Pastorino), lang (Niko Matsakis)

+
Task owners

Niko Matsakis, Santiago Pastorino

+
+ + + + + + +
+ +

3 detailed updates available.

+ + +
+
+Comment by @nikomatsakis posted on 2025-10-07: +
+

I posted this blog post that proposes that we ought to name the trait Handle and define it as a trait where clone produces an "entangled" value -- i.e., a second handle to the same underlying value.

+

Before that, there's been a LOT of conversation that hasn't made its way onto this tracking issue. Trying to fix that! Here is a brief summary, in any case:

+ +

RFC #3680: https://github.com/rust-lang/rfcs/pull/3680

+ +
+
+
+Comment by @nikomatsakis posted on 2025-10-09: +
+

I wrote up a brief summary of my current thoughts on Zulip; I plan to move this content into a series of blog posts, but I figured it was worth laying it out here too for those watching this space:

+
+

09:11 +(1) I don't think clones/handles are categorically different when it comes to how much you want to see them made explicit; some applications want them both to be explicit, some want them automatic, some will want a mix -- and possibly other kinds of categorizations.

+

09:11 +(2) But I do think that if you are making everything explicit, it's useful to see the difference between a general purpose clone and a handle.

+

09:12 +(3) I also think there are many classes of software where there is value in having everything explicit -- and that those classes are often the ones most in Rust's "sweet spot". So we should make sure that it's possible to have everything be explicit ergonomically.

+

09:12 +(4) This does not imply that we can't make automatic clones/handles possible too -- it is just that we should treat both use cases (explicit and automatic) as first-class in importance.

+

09:13 +(5) Right now I'm focused on the explicit case. I think this is what the use-use-everywhere was about, though I prefer a different proposal now -- basically just making handle and clone methods understood and specially handled by the compiler for optimization and desugaring purposes. There are pros and cons to that, obviously, and that's what I plan to write-up in more detail.

+

09:14 +(6) On a related note, I think we also need explicit closure captures, which is a whole interesting design space. I don't personally find it "sufficient" for the "fully explicit" case but I could understand why others might think it is, and it's probably a good step to take.

+

09:15 +(7) I go back and forth on profiles -- basically a fancy name for lint-groups based on application domain -- and whether I think we should go that direction, but I think that if we were going to go automatic, that's the way I would do it: i.e., the compiler will automatically insert calls to clone and handle, but it will lint when it does so; the lint can by deny-by-default at first but applications could opt into allow for either or both.

+

I previously wanted allow-by-default but I've decided this is a silly hill to die on, and it's probably better to move in smaller increments.

+
+ +
+
+
+Comment by @nikomatsakis posted on 2025-10-22: +
+

Update:

+

There has been more discussion about the Handle trait on Zulip and elsewhere. Some of the notable comments:

+
    +
  • Downsides of the current name: it's a noun, which doesn't follow Rust naming convention, and the verb handle is very generic and could mean many things.
    • +
  • Alternative names proposed: Entangle/entangle or entangled, Share/share, Alias/alias, or Retain/retain. if we want to seriously hardcore on the science names -- Mitose/mitose or Fission/fission.
    • +
  • There has been some criticism pointing out that focusing on handles means that other types which might be "cheaply cloneable" don't qualify.
    • +
+

For now I will go on using the term Handle, but I agree with the critique that it should be a verb, and currently prefer Alias/alias as an alternative.

+
+

I'm continuing to work my way through the backlog of blog posts about the conversations from Rustconf. The purposes of these blog posts is not just to socialize the ideas more broadly but also to help myself think through them. Here is the latest post:

+

https://smallcultfollowing.com/babysteps/blog/2025/10/13/ergonomic-explicit-handles/

+

The point of this post is to argue that, whatever else we do, Rust should have a way to create handles/clones (and closures that work with them) which is at once explicit and ergonomic.

+

To give a preview of my current thinking, I am working now on the next post which will discuss how we should add an explicit capture clause syntax. This is somewhat orthogonal but not really, in that an explicit syntax would make closures that clone more ergonomic (but only mildly). I don't have a proposal I fully like for this syntax though and there are a lot of interesting questions to work out. As a strawperson, though, you might imagine [this older proposal I wrote up](https://hackmd.io/Niko Matsakis/SyI0eMFXO?type=view), which would mean something like this:

+
let actor1 = async move(reply_tx.handle()) {
+    reply_tx.send(...);
+};
+let actor2 = async move(reply_tx.handle()) {
+    reply_tx.send(...);
+};
+
+

This is an improvement on

+
let actor1 = {
+    let reply_tx = reply_tx.handle();
+    async move(reply_tx.handle()) {
+        reply_tx.send(...);
+    }
+};
+
+

but only mildly.

+

The next post I intend to write would be a variant on "use, use everywhere" that recommends method call syntax and permitting the compiler to elide handle/clone calls, so that the example becomes

+
let actor1 = async move {
+    reply_tx.handle().send(...);
+    //       -------- due to optimizations, this would capture the handle creation to happen only when future is *created*
+};
+
+

This would mean that cloning of strings and things might benefit from the same behavior:

+
let actor1 = async move {
+    reply_tx.handle().send(some_id.clone());
+    //                     -------- the `some_id.clone()` would occur at future creation time
+};
+
+

The rationable that got me here is (a) minimizing perceived complexity and focusing on muscle memory (just add .clone() or .handle() to fix use-after-move errors, no matter when/where they occur). The cost of course is that (a) Handle/Clone become very special; and (b) it blurs the lines on when code execution occurs. Despite the .handle() occurring inside the future (resp. closure) body, it actually executes when the future (resp. closure) is created in this case (in other cases, such as a closure that implements Fn or FnMut and hence executes more than once, it might occur during each execution as well).

+ +
+
+
+
+ +
+
+ + +
+Stabilize cargo-script (rust-lang/rust-project-goals#119) +
+ + + + + + + + + + + + + + + + + + + + +
Progress +
Point of contact

Ed Page

+
Champions

cargo (Ed Page), lang (Josh Triplett), lang-docs (Josh Triplett)

+
Task owners

Ed Page

+
+ + + + + + +
+ +No detailed updates available. + +
+ +
+ + +### "Unblocking dormant traits" + +
+ + +
+Evolving trait hierarchies (rust-lang/rust-project-goals#393) +
+ + + + + + + + + + + + + + + + + + + + +
Progress +
Point of contact

Taylor Cramer

+
Champions

lang (Taylor Cramer), types (Oliver Scherer)

+
Task owners

Taylor Cramer, Taylor Cramer & others

+
+ + + + + + +
+ +No detailed updates available. + +
+ +
+
+ + +
+In-place initialization (rust-lang/rust-project-goals#395) +
+ + + + + + + + + + + + + + + + + + + + +
Progress +
Point of contact

Alice Ryhl

+
Champions

lang (Taylor Cramer)

+
Task owners

Benno Lossin, Alice Ryhl, Michael Goulet, Taylor Cramer, Josh Triplett, Gary Guo, Yoshua Wuyts

+
+ + + + + + +
+ +

1 detailed update available.

+ + +
+
+Comment by @Darksonn posted on 2025-10-22: +
+

This is our first update we’re posting for the in-place init work. Overall things are progressing well, with lively discussion happening on the newly minted t-lang/in-place-init Zulip channel. Here are the highlights since the lang team design meeting at the end of July:

+ + +
+
+
+
+ +
+
+ + +
+Next-generation trait solver (rust-lang/rust-project-goals#113) +
+ + + + + + + + + + + + + + + + + + + + +
Progress +
Point of contact

lcnr

+
Champions

types (lcnr)

+
Task owners

Boxy, Michael Goulet, lcnr

+
+ + + + + + +
+ +

1 detailed update available.

+ + +
+
+Comment by @lcnr posted on 2025-10-23: +
+

Since the last update we've fixed the hang in rayon in https://github.com/rust-lang/rust/pull/144991 and https://github.com/rust-lang/rust/pull/144732 which relied on https://github.com/rust-lang/rust/pull/143054 https://github.com/rust-lang/rust/pull/144955 https://github.com/rust-lang/rust/pull/144405 https://github.com/rust-lang/rust/pull/145706. This introduced some search graph bugs which we fixed in https://github.com/rust-lang/rust/pull/147061 https://github.com/rust-lang/rust/pull/147266.

+

We're mostly done with the opaque type support now. Doing so required a lot of quite involved changes:

+
    +
  • https://github.com/rust-lang/rust/pull/145244 non-defining uses in borrowck
    • +
  • https://github.com/rust-lang/rust/pull/145925 non-defining uses in borrowck closure support
    • +
  • https://github.com/rust-lang/rust/pull/145711 non-defining uses in hir typeck
    • +
  • https://github.com/rust-lang/rust/pull/140375 eagerly compute sub_unification_table again
    • +
  • https://github.com/rust-lang/rust/pull/146329 item bounds
    • +
  • https://github.com/rust-lang/rust/pull/145993 function calls
    • +
  • https://github.com/rust-lang/rust/pull/146885 method selection
    • +
  • https://github.com/rust-lang/rust/pull/147249 fallback
    • +
+

We also fixed some additional self-contained issues and perf improvements: https://github.com/rust-lang/rust/pull/146725 https://github.com/rust-lang/rust/pull/147138 https://github.com/rust-lang/rust/pull/147152 https://github.com/rust-lang/rust/pull/145713 https://github.com/rust-lang/rust/pull/145951

+

We have also migrated rust-analyzer to entirely use the new solver instead of chalk. This required a large effort mainly by Jack Huey Chayim Refael Friedman and Shoyu Vanilla. That's some really impressive work on their end 🎉 See this list of merged PRs for an overview of what this required on the r-a side. Chayim Refael Friedman also landed some changes to the trait solver itself to simplify the integration: https://github.com/rust-lang/rust/pull/145377 https://github.com/rust-lang/rust/pull/146111 https://github.com/rust-lang/rust/pull/147723 https://github.com/rust-lang/rust/pull/146182.

+

We're still tracking the remaining issues in https://github.com/orgs/rust-lang/projects/61/views/1. Most of these issues are comparatively simple and I expect us to fix most of them over the next few months, getting us close to stabilization. We're currently doing another crater triage which may surface a few more issues.

+ +
+
+
+
+ +
+
+ + +
+Stabilizable Polonius support on nightly (rust-lang/rust-project-goals#118) +
+ + + + + + + + + + + + + + + + + + + + +
Progress +
Point of contact

Rémy Rakic

+
Champions

types (Jack Huey)

+
Task owners

Amanda Stjerna, Rémy Rakic, Niko Matsakis

+
+ + + + + + +
+ +

1 detailed update available.

+ + +
+
+Comment by @lqd posted on 2025-10-22: +
+

Here's another summary of the most interesting developments since the last update:

+
    +
  • reviews and updates have been done on the polonius alpha, and it has since landed
    • +
  • the last 2 trivial diagnostics failures were fixed
    • +
  • we've done perf runs, crater runs, completed gathering stats on crates.io for avg and outliers in CFG sizes, locals, loan and region counts, dataflow framework behavior on unexpected graph shapes and bitset invalidations
    • +
  • I worked on dataflow for borrowck: single pass analyses on acyclic CFGs, dataflow analyses on SCCs for cyclic CFGs
    • +
  • some more pieces of amanda's SCC rework have landed, with lcnr's help
    • +
  • lcnr's opaque type rework, borrowcking of nested items, and so on, also fixed some issues we mentioned in previous updates with member constraints for computing when loans are going out of scope
    • +
  • we also studied recent papers in flow-sensitive pointer analysis
    • +
  • I also started the loans-in-scope algorithm rework, and also have reachability acceleration with the CFG SCCs
    • +
  • the last 2 actual failures in the UI tests are soundness issues, related to liveness of captured regions for opaque types: some regions that should be live are not, which were done to help with precise capture and limit the impact of capturing unused regions that cannot be actually used in the hidden type. The unsoundness should not be observable with NLLs, but polonius alpha relies on liveness to propagate loans throughout the CFG: these dead regions prevent detecting some error-causing loan invalidations. The easiest fix would cause breakage in code that's now accepted. niko, jack and I have another possible solution and I'm trying to implement it now
    • +
+ +
+
+
+
+ +
+ + +## Goals looking for help + + +## Other goal updates + +
+ + +
+Add a team charter for rustdoc team (rust-lang/rust-project-goals#387) +
+ + + + + + + + + + + + + + + + +
Progress +
Point of contact

Guillaume Gomez

+
Champions

rustdoc (Guillaume Gomez)

+
+ + + + + + +
+ +No detailed updates available. + +
+ +
+
+ + +
+Borrow checking in a-mir-formality (rust-lang/rust-project-goals#122) +
+ + + + + + + + + + + + + + + + + + + + +
Progress +
Point of contact

Niko Matsakis

+
Champions

types (Niko Matsakis)

+
Task owners

Niko Matsakis, tiif

+
+ + + + + + +
+ +No detailed updates available. + +
+ +
+
+ + +
+C++/Rust Interop Problem Space Mapping (rust-lang/rust-project-goals#388) +
+ + + + + + + + + + + + + + + + + + + + +
Progress +
Point of contact

Jon Bauman

+
Champions

compiler (Oliver Scherer), lang (Tyler Mandry), libs (David Tolnay)

+
Task owners

Jon Bauman

+
+ + + + + + +
+ +No detailed updates available. + +
+ +
+
+ + +
+Comprehensive niche checks for Rust (rust-lang/rust-project-goals#262) +
+ + + + + + + + + + + + + + + + + + + + +
Progress +
Point of contact

Bastian Kersting

+
Champions

compiler (Ben Kimock), opsem (Ben Kimock)

+
Task owners

Bastian Kersting], Jakob Koschel

+
+ + + + + + +
+ +No detailed updates available. + +
+ +
+
+ + +
+Const Generics (rust-lang/rust-project-goals#100) +
+ + + + + + + + + + + + + + + + + + + + +
Progress +
Point of contact

Boxy

+
Champions

lang (Niko Matsakis)

+
Task owners

Boxy, Noah Lev

+
+ + + + + + +
+ +

1 detailed update available.

+ + +
+
+Comment by @nikomatsakis posted on 2025-10-22: +
+

We had a design meeting on 2025-09-10, minutes available here, aiming at these questions:

+
+

There are a few concrete things I would like to get out of this meeting, listed sequentially in order of most to least important:

+
    +
  1. Would you be comfortable stabilizing the initial ADTs-only extensions? +
      +
    • This would be properly RFC'd before stabilization, this ask is just a "vibe check".
      • +
    +
    2. +
  2. Are you interested in seeing Per-Value Rejection for enums with undesirable variants?
    3. +
  3. How do you feel about the idea of Lossy Conversion as an approach in general, what about specifically for the References and Raw Pointers extensions?
    4. +
  4. How do you feel about the idea of dropping the One Equality ideal in general, what about specifically for -0.0 vs +0.0, what about specifically for NaN values?
    5. +
+
+

The vibe checks on the first one were as follows:

+
+

Vibe check

+

The main ask:

+
+

Would you be comfortable stabilizing the initial ADTs-only extensions?

+
+

(plus the other ones)

+

nikomatsakis

+

I am +1 on working incrementally and focusing first on ADTs. I am supportive of stabilization overall but I don't feel like we've "nailed" the way to talk or think about these things. So I guess my "vibe" is +1 but if this doc were turned into an RFC kind of "as is" I would probably wind up -1 on the RFC, I think more work is needed (in some sense, the question is, "what is the name of the opt-in trait and why is it named that"). This space is complex and I think we have to do better at helping people understand the fine-grained distinctions between runtime values, const-eval values, and type-safe values.

+

Niko: if we add some sort of derive of a trait name, how much value are we getting from the derive, what should the trait be named?

+

tmandry

+

I think we'll learn the most by stabilizing ADTs in a forward compatible way (including an opt-in) now. So +1 from me on the proposed design.

+

It's worth noting that this is a feature that interacts with many other features, and we will be considering extensions to the MVP for the foreseeable future. To some extent the lang team has committed to this already but we should know what we're signing ourselves up for.

+

scottmcm

+

scottmcm: concern over the private fields restriction (see question below), but otherwise for the top ask, yes happy to just do "simple" types (no floats, no cells, no references, etc).

+

TC

+

As Niko said, +1 on working incrementally, and I too am supportive overall.

+

As a vibe, per-value rejection seems fairly OK to me in that we decided to do value-based reasoning for other const checks. It occurs to me there's some parallel with that.

+

https://github.com/rust-lang/rust/pull/119044

+

As for the opt-in on types, I see the logic. I do have reservations about adding too many opt-ins to the language, and so I'm curious about whether this can be safely removed.

+

Regarding floats, I see the question on these as related to our decision about how to handle padding in structs. If it makes sense to normalize or otherwise treat -0.0 and +0.0 as the same, then it'd also make sense in my view to normalize or otherwise treat two structs with the same values but different padding (or where only one has initialized padding) as the same.

+
+ +
+
+
+
+ +
+
+ + +
+Continue resolving `cargo-semver-checks` blockers for merging into cargo (rust-lang/rust-project-goals#104) +
+ + + + + + + + + + + + + + + + + + + + +
Progress +
Point of contact

Predrag Gruevski

+
Champions

cargo (Ed Page), rustdoc (Alona Enraght-Moony)

+
Task owners

Predrag Gruevski

+
+ + + + + + +
+ +No detailed updates available. + +
+ +
+
+ + +
+Develop the capabilities to keep the FLS up to date (rust-lang/rust-project-goals#391) +
+ + + + + + + + + + + + + + + + + + + + +
Progress +
Point of contact

Pete LeVasseur

+
Champions

bootstrap (Jakub Beránek), lang (Niko Matsakis), spec (Pete LeVasseur)

+
Task owners

Pete LeVasseur, Contributors from Ferrous Systems and others TBD, t-spec and contributors from Ferrous Systems

+
+ + + + + + +
+ +

2 detailed updates available.

+ + +
+
+Comment by @nikomatsakis posted on 2025-10-22: +
+

After much discussion, we have decided to charter this team as a t-spec subteam. Pete LeVasseur and I are working to make that happen now.

+ +
+
+
+Comment by @nikomatsakis posted on 2025-10-22: +
+

PR with charters:

+

https://github.com/rust-lang/team/pull/2028

+ +
+
+
+
+ +
+
+ + +
+Emit Retags in Codegen (rust-lang/rust-project-goals#392) +
+ + + + + + + + + + + + + + + + + + + + +
Progress +
Point of contact

Ian McCormack

+
Champions

compiler (Ralf Jung), opsem (Ralf Jung)

+
Task owners

Ian McCormack

+
+ + + + + + +
+ +

1 detailed update available.

+ + +
+
+Comment by @icmccorm posted on 2025-10-25: +
+

Here's our first status update!

+
    +
  • +

    We've been experimenting with a few different ways of emitting retags in codegen, as well as a few different forms that retags should take at this level. We think we've settled on a set of changes that's worth sending out to the community for feedback, likely as a pre-RFC. You can expect more engagement from us on this level in the next couple of weeks.

    +
    • +
  • +

    We've used these changes to create an initial working prototype for BorrowSanitizer that supports finding Tree Borrows violations in tiny, single-threaded Rust programs. We're working on getting Miri's test suite ported over to confirm that everything is working correctly and that we've quashed any false positives or false negatives.

    +
    • +
  • +

    This coming Monday, I'll be presenting on BorrowSanitizer and this project goal at the Workshop on Supporting Memory Safety in LLVM. Please reach out if you're attending and would like to chat more in person!

    +
    • +
+ +
+
+
+
+ +
+
+ + +
+Expand the Rust Reference to specify more aspects of the Rust language (rust-lang/rust-project-goals#394) +
+ + + + + + + + + + + + + + + + + + + + +
Progress +
Point of contact

Josh Triplett

+
Champions

lang-docs (Josh Triplett), spec (Josh Triplett)

+
Task owners

Amanieu d'Antras, Guillaume Gomez, Jack Huey, Josh Triplett, lcnr, Mara Bos, Vadim Petrochenkov, Jane Lusby

+
+ + + + + + +
+ +

1 detailed update available.

+ + +
+
+Comment by @joshtriplett posted on 2025-10-22: +
+

The work on this goal has led to many ongoing discussions on the current status of the Reference. Those discussions are still in progress.

+

Meanwhile, many people working on this goal have successfully written outlines or draft chapters, at various stages of completeness. There's a broken-out status report at https://github.com/rust-lang/project-goal-reference-expansion/issues/11 .

+ +
+
+
+
+ +
+
+ + +
+Finish the libtest json output experiment (rust-lang/rust-project-goals#255) +
+ + + + + + + + + + + + + + + + + + + + +
Progress +
Point of contact

Ed Page

+
Champions

cargo (Ed Page)

+
Task owners

Ed Page

+
+ + + + + + +
+ +No detailed updates available. + +
+ +
+
+ + +
+Finish the std::offload module (rust-lang/rust-project-goals#109) +
+ + + + + + + + + + + + + + + + + + + + +
Progress +
Point of contact

Manuel Drehwald

+
Champions

compiler (Manuel Drehwald), lang (TC)

+
Task owners

Manuel Drehwald, LLVM offload/GPU contributors

+
+ + + + + + +
+ +

1 detailed update available.

+ + +
+
+Comment by @ZuseZ4 posted on 2025-10-22: +
+

A longer update of the changes over the fall. We had two gsoc contributors and a lot of smaller improvements for std::autodiff. The first two improvements were already mentioned as draft PRs in the previous update, but got merged since. I also upstreamed more std::offload changes.

+
    +
  1. Marcelo Domínguez refactored the autodiff frontend to be a proper rustc intrinsic, rather than just hackend into the frontend like I first implemented it. This already solved multiple open issues, reduced the code size, and made it generally easier to maintain going forward.
    2. +
  2. Karan Janthe upstreamed a first implementation of "TypeTrees", which lowers rust type and layout information to Enzyme, our autodiff backend. This makes it more likely that you won't see compilation failures with the error message "Can not deduce type of ". We might refine in the future what information exactly we lower.
    3. +
  3. Karan Janthe made sure that std::autodiff has support for f16 and and f128 types.
    4. +
  4. One more of my offload PRs landed. I also figured out why the LLVM-IR generated by the std::offload code needed some manual adjustments in the past. We were inconsistent when communicating with LLVM's offload module, about whether we'd want a magic, extra, dyn_ptr argument, that enables kernels to use some extra features. We don't use these features yet, but for consistency we now always generate and expect the extra pointer. The bugfix is currently under review, once it lands upstream, rustc is able to run code on GPUs (still with a little help of clang).
    5. +
  5. Marcelo Domínguez refactored my offload frontend, again introducing a proper rustc intrinsic. That code will still need to go through review, but once it lands it will get us a lot closer to a usable frontend. He also started to generate type information for our offload backend to know how many bytes to copy to and from the devices. This is a very simplified version of our autodiff typetrees.
    6. +
  6. At RustChinaConf, I was lucky to run into the wild linker author David Lattimore, which helped me to create a draft PR that can dlopen Enzyme at runtime. This means we could ship it via rustup for people interested in std::autodiff, and don't have to link it in at build time, which would increase binary size even for those users that are not interested in it. There are some open issues, so please reach out if you have time to get the PR ready!
    7. +
  7. @sgasho spend a lot of time trying to get Rust into the Enzyme CI. Unfortunately that is a tricky process due to Enzyme's CI requirements, so it's not merged yet.
    8. +
  8. I tried to simplify building std::autodiff by marking it as compatible with download-llvm-ci. Building LLVM from source was previously the by far slowest part of building rustc with autodiff, so this has a large potential. Unfortunately the CI experiments revealed some issues around this setting. We think we know why Enzyme's Cmake causes issues here and are working on a fix to make it more reliable.
    9. +
  9. Osama Abdelkader and bjorn3 looked into automatically enabling fat-lto when autodiff is enabled. In the past, forgetting to enable fat-lto resulted in incorrect (zero) derivatives. The first approach unfortunately wasn't able to cover all cases, so we need to see whether we can handle it nicely. If that turns out to be too complicated, we will revert it and instead "just" provide a nice error message, rather than returning incorrect derivatives.
    10. +
+

All-in-all I spend a lot more time on infra (dlopen, cmake, download-llvm-ci, ...) then I'd like, but on the happy side there are only so many features left that I want to support here so there is an end in sight. +I am also about to give a tech-talk at the upcoming LLVM dev meeting about safe GPU programming in Rust.

+ +
+
+
+
+ +
+
+ + +
+Getting Rust for Linux into stable Rust: compiler features (rust-lang/rust-project-goals#407) +
+ + + + + + + + + + + + + + + + + + + + +
Progress +
Point of contact

Tomas Sedovic

+
Champions

compiler (Wesley Wiser)

+
Task owners

(depending on the flag)

+
+ + + + + + +
+ +

3 detailed updates available.

+ + +
+
+Comment by @tomassedovic posted on 2025-10-09: +
+

I've updated the top-level description to show everything we're tracking here (please let me know if anything's missing or incorrect!).

+ +
+
+
+Comment by @tomassedovic posted on 2025-10-10: +
+
    +
  • [merged] Sanitizers target modificators / https://github.com/rust-lang/rust/pull/138736
    • +
  • [merged] Add assembly test for -Zreg-struct-return option / https://github.com/rust-lang/rust/pull/145382
    • +
  • [merged] CI: rfl: move job forward to Linux v6.17-rc5 to remove temporary commits / https://github.com/rust-lang/rust/pull/146368
    • +
  • -Zharden-sls / https://github.com/rust-lang/rust/pull/136597 +
      +
    • Waiting on review
      • +
    +
    • +
  • #![register_tool] / https://github.com/rust-lang/rust/issues/66079 +
      +
    • Waiting on https://github.com/rust-lang/rfcs/pull/3808
      • +
    +
    • +
  • -Zno-jump-tables / https://github.com/rust-lang/rust/pull/145974 +
      +
    • Active FCP, waiting on 2 check boxes
      • +
    +
    • +
+ +
+
+
+Comment by @tomassedovic posted on 2025-10-24: +
+

-Cunsigned-char

+

We've discussed adding an option analogous to -funsigned-char in GCC and Clang, that would allow you to set whether std::ffi::c_char is represented by i8 or u8. Right now, this is platform-specific and should map onto whatever char is in C on the same platform. However, Linux explicitly sets char to be unsigned and then our Rust code conflicts with that. And isn this case the sign is significant.

+

Rust for Linux works around this this with their rust::ffi module, but now that they've switched to the standard library's CStr type, they're running into it again with the as_ptr method.

+

Tyler mentioned https://docs.rs/ffi_11/latest/ffi_11/ which preserves the char / signed char / unsigned char distinction.

+

Grouping target modifier flags

+

The proposed unsigned-char option is essentially a target modifier. We have several more of these (e.g. llvm-args, no-redzone) in the Rust compiler and Josh suggested we distinguish them somehow. E.g. by giving them the same prefix or possibly creating a new config option (right now we have -C and -Z, maybe we could add -T for target modifiers) so they're distinct from the e.g. the codegen options.

+

Josh started a Zulip thread here: https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Grouping.20target.20modifier.20options.3F/with/546524232

+

#![register_tool] / rust#66079 / RFC#3808

+

Tyler looked at the RFC. The Crubit team started using register_tool but then moved to using an attribute instead. He proposed we could do something similar here, although it would require a new feature and RFC.

+

The team was open to seeing how it would work.

+ +
+
+
+
+ +
+
+ + +
+Getting Rust for Linux into stable Rust: language features (rust-lang/rust-project-goals#116) +
+ + + + + + + + + + + + + + + + + + + + +
Progress +
Point of contact

Tomas Sedovic

+
Champions

lang (Josh Triplett), lang-docs (TC)

+
Task owners

Ding Xiang Fei

+
+ + + + + + +
+ +

3 detailed updates available.

+ + +
+
+Comment by @tomassedovic posted on 2025-10-09: +
+

I've updated the top-level description to show everything we're tracking here (please let me know if anything's missing or incorrect!).

+ +
+
+
+Comment by @tomassedovic posted on 2025-10-10: +
+

Deref/Receiver

+
    +
  • Ding Xiang Fei keeps updating the PR: https://github.com/rust-lang/rust/pull/146095
    • +
  • They're also working on a document to explain the consequences of this split
    • +
+

Arbitrary Self Types

+
    +
  • https://github.com/rust-lang/rust/issues/44874
    • +
  • Waiting on the Deref/Receiver work, no updates
    • +
+

derive(CoercePointee)

+
    +
  • https://github.com/rust-lang/rust/pull/133820
    • +
  • Waiting on Arbitrary self types
    • +
+

Pass pointers to const in asm! blocks

+
    +
  • RFC: https://github.com/rust-lang/rfcs/pull/3848
    • +
  • The Lang team went through the RFC with Alice Ryhl on 2025-10-08 and it's in FCP now
    • +
+

Field projections

+
    +
  • Benno Lossin opened a PR here: https://github.com/rust-lang/rust/pull/146307
    • +
  • Being reviewed by the compiler folks
    • +
+

Providing \0 terminated file names with #[track_caller]

+
    +
  • The feature has been implemented and stabilized with file_as_c_str as the method name: https://github.com/rust-lang/rust/pull/145664
    • +
+

Supertrait auto impl RFC

+
    +
  • Ding Xiang Fei opened the RFC and works with the reviewers: https://github.com/rust-lang/rfcs/pull/3851
    • +
+

Other

+
    +
  • Miguel Ojeda spoke to Linus about rustfmt and they came to agreement.
    • +
+ +
+
+
+Comment by @tomassedovic posted on 2025-10-24: +
+

Layout of core::any::TypeId

+

Danilo asked about the layout of TypeId -- specifically its size and whether they can rely on it because they want to store it in a C struct. The struct's size is currently 16 bytes, but that's an implementation detail.

+

As a vibe check, Josh Triplett and Tyler Mandry were open to guaranteeing that it's going to be at most 16 bytes, but they wanted to reserve the option to reduce the size at some point. The next step is to have the full Lang and Libs teams discuss the proposal.

+

Danilo will open a PR to get that discussion started.

+

rustfmt

+

Miguel brought up the "trailing empty comment" workaround for the formatting issue that made the rounds on the Linux kernel a few weeks ago. The kernel style places each import on a single line:

+
    use crate::{
+        fmt,
+        page::AsPageIter,
+    };
+
+

rustfmt compresses this to:

+
    use crate::{fmt, page::AsPageIter};
+
+

The workaround is to put an empty trailing comment at the end

+
    use crate::{
+        fmt,
+        page::AsPageIter, //
+    };
+
+

This was deemed acceptable (for the time being) and merged into the mainline kernel: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4a9cb2eecc78fa9d388481762dd798fa770e1971

+

Miguel is in contact with rustfmt to support this behaviour without a workaround.

+

// PANIC: ... comments / clippy#15895

+

This is a proposal to add a lint that would require a PANIC comment (modeled after the SAFETY comment) to explain the circumstances during which the code will or won't panic.

+

Alejandra González was open to the suggestion and Henry Barker stepped up to implement it.

+

Deref/Receiver

+

During the experimentation work, Ding ran into an issue with overlapping impls (that was present even with #[unstable_feature_bound(..)]). We ran out of time but we'll discuss this offline and return to it at the next meeting.

+ +
+
+
+
+ +
+
+ + +
+Implement Open API Namespace Support (rust-lang/rust-project-goals#256) +
+ + + + + + + + + + + + + + + + + + + + +
Progress +
Point of contact

Help Wanted

+
Champions

cargo (Ed Page), compiler (b-naber), crates-io (Carol Nichols)

+
Task owners

b-naber, Ed Page

+
+ + + + + + +
+ +No detailed updates available. + +
+ +
+
+ + +
+MIR move elimination (rust-lang/rust-project-goals#396) +
+ + + + + + + + + + + + + + + + + + + + +
Progress +
Point of contact

Amanieu d'Antras

+
Champions

lang (Amanieu d'Antras)

+
Task owners

Amanieu d'Antras

+
+ + + + + + +
+ +No detailed updates available. + +
+ +
+
+ + +
+Prototype a new set of Cargo "plumbing" commands (rust-lang/rust-project-goals#264) +
+ + + + + + + + + + + + + + + + +
Progress +
Point of contact

Help Wanted

+
Task owners

Help wanted, Ed Page

+
+ + + + + + +
+ +No detailed updates available. + +
+ +
+
+ + +
+Prototype Cargo build analysis (rust-lang/rust-project-goals#398) +
+ + + + + + + + + + + + + + + + + + + + +
Progress +
Point of contact

Weihang Lo

+
Champions

cargo (Weihang Lo)

+
Task owners

Help wanted Weihang Lo, Weihang Lo

+
+ + + + + + +
+ +

1 detailed update available.

+ + +
+
+Comment by @weihanglo posted on 2025-10-04: +
+

Cargo tracking issue: https://github.com/rust-lang/cargo/issues/15844. +The first implementation was https://github.com/rust-lang/cargo/pull/15845 in August that added build.analysis.enabled = true to unconditionally generate timing HTML. Further implementations tasks is listed in https://github.com/rust-lang/cargo/issues/15844#issuecomment-3192779748.

+

Haven't yet got any progress in September.

+ +
+
+
+
+ +
+
+ + +
+reflection and comptime (rust-lang/rust-project-goals#406) +
+ + + + + + + + + + + + + + + + + + + + +
Progress +
Point of contact

Oliver Scherer

+
Champions

compiler (Oliver Scherer), lang (Scott McMurray), libs (Josh Triplett)

+
Task owners

oli-obk

+
+ + + + + + +
+ +

1 detailed update available.

+ + +
+
+Comment by @oli-obk posted on 2025-10-22: +
+

I implemented an initial MVP supporting only tuples and primitives (tho those are just opaque things you can't interact with further), and getting offsets for the tuple fields as well as the size of the tuple: https://github.com/rust-lang/rust/pull/146923

+

There are two designs of how to expose this from a libs perspective, but after a sync meeting with scottmcm yesterday we came to the conclusion that neither is objectively better at this stage so we're just going to go with the nice end-user UX version for now. For details see the PR description.

+

Once the MVP lands, I will mentor various interested contributors who will keep adding fields to the Type struct and variants the TypeKind enum.

+

The next major step is restricting what information you can get from structs outside of the current module or crate. We want to honor visibility, so an initial step would be to just never show private fields, but we want to explore allowing private fields to be shown either just within the current module or via some opt-in marker trait

+ +
+
+
+
+ +
+
+ + +
+Rework Cargo Build Dir Layout (rust-lang/rust-project-goals#401) +
+ + + + + + + + + + + + + + + + + + + + +
Progress +
Point of contact

Ross Sullivan

+
Champions

cargo (Weihang Lo)

+
Task owners

Ross Sullivan

+
+ + + + + + +
+ +

1 detailed update available.

+ + +
+
+Comment by @ranger-ross posted on 2025-10-06: +
+

Status update October 6, 2025

+

The build-dir was split out of target-dir as part of https://github.com/rust-lang/cargo/issues/14125 and scheduled for stabilization in Rust 1.91.0. 🎉

+

Before re-organizing the build-dir layout we wanted to improve the existing layout tests to make sure we do not make any unexpected changes. This testing harness improvement was merged in https://github.com/rust-lang/cargo/pull/15874.

+

The initial build-dir layout reorganization PR has been posted https://github.com/rust-lang/cargo/pull/15947 and discussion/reviews are under way.

+ +
+
+
+
+ +
+
+ + +
+Run more tests for GCC backend in the Rust's CI (rust-lang/rust-project-goals#402) +
+ + + + + + + + + + + + + + + + + + + + +
Progress +
Point of contact

Guillaume Gomez

+
Champions

compiler (Wesley Wiser), infra (Marco Ieni)

+
Task owners

Guillaume Gomez

+
+ + + + + + +
+ +No detailed updates available. + +
+ +
+
+ + +
+Rust Stabilization of MemorySanitizer and ThreadSanitizer Support (rust-lang/rust-project-goals#403) +
+ + + + + + + + + + + + + + + + +
Progress +
Point of contact

Jakob Koschel

+
Task owners

[Bastian Kersting](https://github.com/1c3t3a), [Jakob Koschel](https://github.com/jakos-sec)

+
+ + + + + + +
+ +No detailed updates available. + +
+ +
+
+ + +
+Rust Vision Document (rust-lang/rust-project-goals#269) +
+ + + + + + + + + + + + + + + + +
Progress +
Point of contact

Niko Matsakis

+
Task owners

vision team

+
+ + + + + + +
+ +

1 detailed update available.

+ + +
+
+Comment by @jackh726 posted on 2025-10-22: +
+

Update:

+

Niko and I gave a talk at RustConf 2025 (and I represented that talk at RustChinaConf 2025) where we gave an update on this (and some intermediate insights).

+

We have started to seriously plan the shape of the final doc. We have some "blind spots" that we'd like to cover before finishing up, but overall we're feeling close to the finish line on interviews.

+ +
+
+
+
+ +
+
+ + +
+rustc-perf improvements (rust-lang/rust-project-goals#275) +
+ + + + + + + + + + + + + + + + + + + + +
Progress +
Point of contact

James

+
Champions

compiler (David Wood), infra (Jakub Beránek)

+
Task owners

James, Jakub Beránek, David Wood

+
+ + + + + + +
+ +

1 detailed update available.

+ + +
+
+Comment by @Kobzol posted on 2025-10-21: +
+

We moved forward with the implementation, and the new job queue system is now being tested in production on a single test pull request. Most things seem to be working, but there are a few things to iron out and some profiling to be done. I expect that within a few weeks we could be ready to switch to the new system fully in production.

+ +
+
+
+
+ +
+
+ + +
+Stabilize public/private dependencies (rust-lang/rust-project-goals#272) +
+ + + + + + + + + + + + + + + + + + + + +
Progress +
Point of contact

Help Wanted

+
Champions

cargo (Ed Page)

+
Task owners

Help wanted, Ed Page

+
+ + + + + + +
+ +No detailed updates available. + +
+ +
+
+ + +
+Stabilize rustdoc `doc_cfg` feature (rust-lang/rust-project-goals#404) +
+ + + + + + + + + + + + + + + + + + + + +
Progress +
Point of contact

Guillaume Gomez

+
Champions

rustdoc (Guillaume Gomez)

+
Task owners

Guillaume Gomez

+
+ + + + + + +
+ +No detailed updates available. + +
+ +
+
+ + +
+SVE and SME on AArch64 (rust-lang/rust-project-goals#270) +
+ + + + + + + + + + + + + + + + + + + + +
Progress +
Point of contact

David Wood

+
Champions

compiler (David Wood), lang (Niko Matsakis), libs (Amanieu d'Antras)

+
Task owners

David Wood

+
+ + + + + + +
+ +

1 detailed update available.

+ + +
+
+Comment by @nikomatsakis posted on 2025-10-22: +
+

Sized hierarchy

+

The focus right now is on the "non-const" parts of the proposal, as the "const" parts are blocked on the new trait solver (https://github.com/rust-lang/rust-project-goals/issues/113). Now that the types team FCP https://github.com/rust-lang/rust/pull/144064 has completed, work can proceed to land the implementation PRs. David Wood plans to split the RFC to separate out the "non-const" parts of the proposal so it can move independently, which will enable extern types.

+

To that end, there are three interesting T-lang design questions to be considered.

+

Naming of the traits

+

The RFC currently proposes the following names

+
    +
  • Sized
    • +
  • MetaSized
    • +
  • PointeeSized
    • +
+

However, these names do not follow the "best practice" of naming the trait after the capability that it provides. As champion Niko is recommending we shift to the following names:

+
    +
  • Sized -- should righly be called SizeOf, but oh well, not worth changing.
    • +
  • SizeOfVal -- named after the method size_of_val that you get access to.
    • +
  • Pointee -- the only thing you can do is point at it.
    • +
+

The last trait name is already used by the (unstable) std::ptr::Pointee trait. We do not want to have these literally be the same trait because that trait adds a Metadata associated type which would be backwards incompatible; if existing code uses T::Metadata to mean <T as SomeOtherTrait>::Metadata, it could introduce ambiguity if now T: Pointee due to defaults. My proposal is to rename std::ptr::Pointee to std::ptr::PointeeMetadata for now, since that trait is unstable and the design remains under some discussion. The two traits could either be merged eventually or remain separate.

+

Note that PointeeMetadata would be implemented automatically by the compiler for anything that implements Pointee.

+

Syntax opt-in

+

The RFC proposes that an explicit bound like T: MetaSized disabled the default T: Sized bound. However, this gives no signal that this trait bound is "special" or different than any other trait bound. Naming conventions can help here, signalling to users that these are special traits, but that leads to constraints on naming and may not scale as we consider using this mechanism to relax other defaults as proposed in my recent blog post. One idea is to use some form of syntax, so that T: MetaSized is just a regular bound, but (for example) T: =MetaSized indicates that this bound "disables" the default Sized bound. This gives users some signal that something special is going on. This = syntax is borrowing from semver constraints, although it's not a precise match (it does not mean that T: Sized doesn't hold, after all). Other proposals would be some other sigil (T: ?MetaSized, but it means "opt out from the traits above you"; T: #MetaSized, ...) or a keyword (no idea).

+

To help us get a feel for it, I'll use T: =Foo throughout this post.

+

Implicit trait supertrait bounds, edition interaction

+

In Rust 2024, a trait is implicitly ?Sized which gets mapped to =SizeOfVal:

+
trait Marker {} // cannot be implemented by extern types
+
+

This is not desirable but changing it would be backwards incompatible if traits have default methods that take advantage of this bound:

+
trait NotQuiteMarker {
+    fn dummy(&self) {
+        let s = size_of_val(self);
+    }
+}
+
+

We need to decide how to handle this. Options are

+
    +
  • Just change it, breakage will be small (have to test that).
    • +
  • Default to =SizeOfVal but let users explicitly write =Pointee if they want that. Bad because all traits will be incompatible with extern types.
    • +
  • Default to =SizeOfVal only if defaulted methods are present. Bad because it's a backwards incompatible change to add a defaulted method now.
    • +
  • Default to =Pointee but add where Self: =SizeOfVal implicitly to defaulted methods. Now it's not backwards incompatible to add a new defaulted method, but it is backwards incompatible to change an existing method to have a default.
    • +
+

If we go with one of the latter options, Niko proposes that we should relax this in the next Edition (Rust 2026?) so that the default becomes Pointee (or maybe not even that, if we can).

+

Relaxing associated type bounds

+

Under the RFC, existing ?Sized bounds would be equivalent to =SizeOfVal. This is mostly fine but will cause problems in (at least) two specific cases: closure bounds and the Deref trait. For closures, we can adjust the bound since the associated type is unstable and due to the peculiarities of our Fn() -> T syntax. Failure to adjust the Deref bound in particular would prohibit the use of Rc<E> where E is an extern type, etc.

+

For deref bounds, David Wood is preparing a PR that simply changes the bound in a backwards incompatible way to assess breakage on crater. There is some chance the breakage will be small.

+

If the breakage proves problematic, or if we find other traits that need to be relaxed in a similar fashion, we do have the option of:

+
    +
  • In Rust 2024, T: Deref becomes equivalent to T: Deref<Target: SizeOfVal> unless written like T: Deref<Target: =Pointee>. We add that annotation throughout stdlib.
    • +
  • In Rust 202X, we change the default, so that T: Deref does not add any special bounds, and existing Rust 2024 T: Deref is rewritten to T: Deref<Target: SizeOfVal> as needed.
    • +
+

Other notes

+

One topic that came up in discussion is that we may eventually wish to add a level "below" Pointee, perhaps Value, that signifies webassembly external values which cannot be pointed at. That is not currently under consideration but should be backwards compatible.

+ +
+
+
+
+ +
+
+ + +
+Type System Documentation (rust-lang/rust-project-goals#405) +
+ + + + + + + + + + + + + + + + + + + + +
Progress +
Point of contact

Boxy

+
Champions

types (Boxy)

+
Task owners

Boxy, lcnr

+
+ + + + + + +
+ +No detailed updates available. + +
+ +
+
+ + +
+Unsafe Fields (rust-lang/rust-project-goals#273) +
+ + + + + + + + + + + + + + + + + + + + +
Progress +
Point of contact

Jack Wrenn

+
Champions

compiler (Jack Wrenn), lang (Scott McMurray)

+
Task owners

Jacob Pratt, Jack Wrenn, Luca Versari

+
+ + + + + + +
+ +No detailed updates available. + +
+ +