---
title: "Lang/RfL meeting 2025-12-03"
tags: ["T-lang", "design-meeting", "minutes"]
date: 2025-12-03
discussion: https://rust-lang.zulipchat.com/#narrow/channel/410673-t-lang.2Fmeetings/topic/RfL.20meeting.202025-12-03/with/561692086
url: https://hackmd.io/1_duOCDkQvmzxSQ1Zh7-Gg
---

# Lang/RfL meeting 2025-12-03

## Attendance

People: Josh Triplett, Ding, Nadrieril, Tomas Sedovic, TC, Wesley Wiser, Miguel Ojeda, Gary Guo,

Driver: Tomas
Notes: Tomas

## Tracking

[RfL lang features tracking issue](https://github.com/rust-lang/rust-project-goals/issues/116)
[RfL compiler features tracking issue](https://github.com/rust-lang/rust-project-goals/issues/407)
[Rust unstable features needed for the kernel](https://github.com/Rust-for-Linux/linux/issues/2)
[Rust wanted features from RfL](https://github.com/Rust-for-Linux/linux/issues/354)

### Project Goals

* Lang features: https://rust-lang.github.io/rust-project-goals/2025h2/Rust-for-Linux-language.html
* Compiler features: https://rust-lang.github.io/rust-project-goals/2025h2/Rust-for-Linux-compiler.html
* In-place initialization: https://rust-lang.github.io/rust-project-goals/2025h2/in-place-initialization.html
* Field projections: https://rust-lang.github.io/rust-project-goals/2025h2/field-projections.html

## Announcements or custom items

### Project goals in 2026

Tomas: I've been going through all the active goals. As far as I see, we'd like to continue all four goals we have in 2026. Is that correct?

### Giving update at the conference

Miguel: I'll be giving a usual update for Rust for Linux at the conference. I've reached out to folks who might have something to say. If anyone from the Rust Project have an update they want to highlight, let me know.

Miguel: For Lang and Compiler, I'd highlight features we got that's either done or close to done. If there's anything you think I should mention, please talk to me.

## Compiler features

* `-Zharden-sls` / https://github.com/rust-lang/rust/pull/136597
* Waiting for review
* Wesley is looking at this right now
* `#![register_tool]` / https://github.com/rust-lang/rust/issues/66079
* Last time: Tyler was going to propose adding the namespaced tool attrs as a "future possibility" in the RFC and then FCPing it
* Tyler: No updates; I am still planning this after fully reviewing the RFC again. Some other things like maintainer support took precedence since the last meeting.
* Updates/blockers on any other features?

Tomas TODO: add all the compiler features listed in the goal/tracking issue here so we can look at them all.

## Lang features

#### `Deref` / `Receiver`

https://rust-lang.zulipchat.com/#narrow/channel/522311-t-lang.2Fcustom-refs/topic/Consequences.20of.20making.20Deref.20a.20subtrait.20of.20Receiver/with/547014978

Current status / updates? / Anything to discuss?

Ding: I am still writing the reference on method receiver. I will edit a little bit and put up a PR after LPC. On the chain splitting proposal, we are still trying to get endorsement in general. In conjunction, supertrait auto-impl lang experiment is kind of underway as our insurance.

Ding: Tyler and I talked a week+ ago, the vibe is that the idea is not well-proliferated. They're not convinced aobut whether the split is a good way to go. I'm still writing the method probing section inthe Reference to clear things up a bit.

Ding: On the optimization side, I'm still working on it. Taking a different apporach to make the optimization work. I'd say the text would be only available after the FCP.

#### [RFC #3851: Supertrait Auto-impl](https://github.com/rust-lang/rfcs/pull/3851)

Ding addressed obi1kenobi's request on SemVer compatibility

Ding's update from yesterday:

> I forgot to mention that we would like to support higher-kinded superbounds, too. The text is now updated with the extension. Extensions in the text would be rolled out gradually as the feature is developed.

Anything to discuss?

Ding: I think lcnr@'s example on conflicting `auto impl` items give a strong reason not to perform automatic `impl` conflicts. I will try to convince cramertj@ and tmandry@. [Implementation](https://github.com/rust-lang/rust/pull/149335) has started, we have a [tracking issue](https://github.com/rust-lang/rust/issues/149556) and I am receiving reviews.

Ding: Tyler mentioned it'd be a great to have that as an insurance.

Josh: We had recently talk with Tyler and Amanieu: we brought this to the Types team. And talked about how this should work and how we want it to work. There's an experiment going on. And we want this for the standard library to make some of the Write traits more usable. Types is evaluating that and looking at it. In addition to the lang experiement, we might now have more thorough evaluation and backing from the Types folks on how this should work.

Josh: This will include some edge cases on multiple auto-impl traits. We're looking to add a feature for having that work on adding a precedence of one over the other. This is preliminary, types will let us know.

Ding: I wasn't aware of this and I was waiting on Taylor's response. Should I continue to drive the implementation?

Josh: You should absolutely continue to drive it. I don't know if you've heard from Taylor lately, but she's not been around much lately.

TC: We've just appointed Tyler Mandry as the new champion.

Josh: He's going to start championing and liaisoning the experiemnet. Please reach otu to Tyler. And I expect you'll be getting more support from the Types team so if you have any corner cases, please reach out to them with Tyler.

Josh: There are three lang features that kind of overlap here: auto-impl trait, inside that an associated type whose type is an impl trait (opaque associated type inside aouto-impl) and low precedence mechanism.

### Arbitrary Self Types
[Arbitrary Self Types: Tracking issue #44874](https://github.com/rust-lang/rust/issues/44874)
- Waiting on the Deref/Receiver

Current status / updates? / Anything to discuss?

Ding: nothing at the moment.

### `derive(CoercePointee)`
[derive(CoercePointee) Tracking issue #123430](https://github.com/rust-lang/rust/issues/123430)
- Stabilization PR: https://github.com/rust-lang/rust/pull/133820
- Waiting on Arbitrary self types

Current status / updates? / Anything to discuss?

Ding: There was a PR about dispatch from dyn. But hasn't moved, is anyone looking at it?

Ding: I still need to answer a question here: https://github.com/rust-lang/rust/pull/149068#issuecomment-3583544237

### In-place initialization

Goal tracking issue: https://github.com/rust-lang/rust-project-goals/issues/395

Current status / updates? / Anything to discuss?

Ding: I'll prepare to prepare some material for a discussion at LPC on how we arrived to our proposal to hear from the audience to corver the surface syntax of it. I'll meet with Tyler again to check the gut feelings about the feature. Whether we can make a plan to write a series of RFCs. It's growing quite large.

Ding: The placing function and guaranteed return value placement are superceded by outpointer and placing function and Bennos' proposal would be the most user friendly interface that could be built on top of the uniint pointer. The guaranteed value placement is something that's still useful to the compiler in places where placement is possible. We're still waiting for Olivier's final text on that.

And Nadri's proposal for places that could model that too.

Tomas: How are we looking with all the different proposals? Are there signs of converging on the ultimate solution?

Nadri: I feel it's converging but slowly. We're started to get a feel of what the final solution needs to be, we're getting constrains on the solutions but it still needs time.

### Field projections

https://rust-lang.github.io/rust-project-goals/2025h2/field-projections.html

Goal tracking issue: https://github.com/rust-lang/rust-project-goals/issues/390

Feature tracking issue: https://github.com/rust-lang/rust/issues/145383

Field representing types (FRT) PR: https://github.com/rust-lang/rust/pull/146307.

Current status / updates? / Anything to discuss?

Nadri: Benno is working on this masters thesis. My proposal has been selected at least for the user-facing bits. My feeling is it's getting fleshed out into something fulfilling a lot of goals. It's a huge undertaking. I'm looking forward to syncing with Benno.

Miguel: The scope is quite wide if I understood it.

Nadri: And even the minimum thing is quite large. But now I'm getting to think about minute details which is a good sign.

## Other topics

Miguel: Talked to Guillaume about beta-backporting https://github.com/rust-lang/rust/pull/148068 since otherwise we would need one more kernel workaround for the upcoming 1.92. He went ahead and nominated it, and it is getting merge now: https://github.com/rust-lang/rust/pull/149572

***

Gary: I've started implementation of the asm const pointer.

***

Jesung found a breakage in Rust Analyzer that affected the kernel due to `-Zcrate-attr` and started to look into it and we already got a response from the RA folks.

https://rust-lang.zulipchat.com/#narrow/channel/185405-t-compiler.2Frust-analyzer/topic/Primitive.20type.20inherent.20method.20lookup.20fails/near/561607963

***

Ding: We have improvements on tooling: rust-binden PR is open to refine the types being reported. That impacts kernel as well as my day job. It is here: https://github.com/rust-lang/rust-bindgen/pull/3323

Miguel: Thanks, that's really good.

Ding: Can we get some capacity from the Rust bindgen to look at it?

Miguel: I'm in contact with Emilio Cobos Álvarez (@emilio), we can ping him for things that are important. Jon who works on bindgen also repliet.

Ding: I'd also keep the discussion to improve bindgen -- we're using it a lot and as we add support for cryptographic and tls features, it'll become even more important.

Miguel: There's also a desire for when we could skip bindgen to import headers from rustc into C files.

***

Miguel: there's no change on the rustfmt work. They're worknig through the backlog to go through before looking at the comma thing.

Miguel: `--emit=noreturn`

Miguel: We need this for the object tool (`objtool`) that we use in the kernel to analyse the object files. It would be great to discuss this at some point. (TODO Tomas add to the compiler list)

Gary: This is important for the C side. But in Rust with the type system it's harder to make this mistake. I'd suggest for objtool to maybe ignore Rust functions. I see little value in having this check embedded in the objtool.

Miguel: objtool analyses the raw object file, it has no view into the source code. It checks things are correct on the structure/assembly level.

Josh: objtool is the thing that checks for "do you have code that runs at runtime that calls things that are in the init section" and things like that.

Miguel: It also checks the CFI stuff.

Gary: emit=noreturn sounds like too specific. Having just noreturn wouldn't be valuable.

Miguel: But the CFI check did find issues for us

Gary: CFI sure, but something like noreturn doesn't seem that useful to me.

Miguel: this is a list of features, plus it has a lot of undocumented ones:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/objtool/Documentation/objtool.txt

Miguel: these are all the checks I have to maintain manually:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/objtool/check.c#n186

Miguel: we're currently checking all the Rust object files. If it's not too complex for the Rust compiler, it would be worth it.

Gary: Dwarf already has this information. Using gimli you can get this information with a few lines of code.

Miguel: The problem in the kernel is objtool works even for things without debug information.

Gary: maybe we could say all Rust builds should have dwarf enabled. A lot of distros will have it anyway. I think the PTF is generated from dwarf too. So generating it anyway and have objtool get noreturn information from there wouldn't be too bad. But that's a feature that would need to be added to objtool. It might be a big ask to ask the compiler to support a feature that's only for us and can be implemented elsewhere.

Miguel: If it's not a big maintenance burden, it could be something permanently unstable that's only for rust for linux.

Tomas: how does it square with the desire to build on stable Rust?

Miguel: We have the unstable compiler for now and objtool is running by linux on everything.

***

Miguel: Guillaume is looking at the hidden private items in the generated rustdoc. The idea is for projects like the kernel to toggle to show them.