---
title: "Lang/RfL meeting 2025-11-05"
tags: ["T-lang", "design-meeting", "minutes"]
date: 2025-11-05
discussion: https://rust-lang.zulipchat.com/#narrow/channel/410673-t-lang.2Fmeetings/topic/RfL.20meeting.202025-11-05/with/553894436
url: https://hackmd.io/YrqLUjjRQZGfimvv9lj3Bw
---
# Lang/RfL meeting 2025-11-05

## Attendance

People: Alejandra, Alice, Benno, Ding, Boqun, Miguel, Ramon, TC, Josh

Driver: Tomas Sedovic
Notes: Tomas Sedovic

## 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)

### 2025H2 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

## Announcements or custom items

(please add your items here)

## LWN articles

* [Gccrs after libcore](https://lwn.net/SubscriberLink/1040197/0733825193ca1f04/)
* [Git considers SHA-256, Rust, LLMs, and more](https://lwn.net/SubscriberLink/1042172/c7e1cdef4a518cc3/)
* [DebugFS on Rust](https://lwn.net/SubscriberLink/1041095/2ef0281b0fec4d9d/)

## Compiler features

* -Zharden-sls / https://github.com/rust-lang/rust/pull/136597
* Reviewed, *waiting on author* (Wesley left a request: https://github.com/rust-lang/rust/pull/136597#discussion_r2426704113).
* TC: you might ask petrochenkov (TODO Tomas)
* `#![register_tool]` / https://github.com/rust-lang/rust/issues/66079
* Waiting on [RFC#3808](https://github.com/rust-lang/rfcs/pull/3808)
* Gary's not here to discuss, but the question is, do we want register_tool or go with Tyler's idea?
* -Zno-jump-tables / https://github.com/rust-lang/rust/pull/145974
* Merged as of couple days ago \o/, planned to ship in Rust 1.93.0
* The kernel about to land the support for the new name (landed during the meeting, in fact).
* Anything else?

## 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

Ding: I pasted my thougts aobut why we have strong tendency to see the split. There's been a discussion on how to interpret the traits. I'm still looking for further comments on that. If the lang team wants to put something for everyone to read, I'm thinking of adding a second RFC patch.

Ding: The experiment with both variants of arbitrary self types have the new feature gate in the PR. We have new reviews coming in. Jack has a question about the expansion of the search space that I need to respond to. The amount of work is comparable.

TC: Rather than an RFC, the most useful next step would be to write the Reference PR. That would help to make it clear how we're representing this model in terms of the language. If you can specify the behavior in writing the Reference language, that should make the RFC easier. Hopefully we can find a really clear way of presenting the model.

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

Ding: I am receiving reviews on [#146095](https://github.com/rust-lang/rust/pull/146095). I still owe Jack an answer as to the search space, and I will explain that the search space on existing types with `Deref::Target == Receiver::Target` should invoke the same amount of work, after introduction of the caching.

[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

theemathas opened an issue [`derive(CoercePointee)` accepts `?Sized + Sized` #148399](https://github.com/rust-lang/rust/issues/148399)
- Doesn't seem to be a problem, conversation moved to having a deny-by-default lint for `T: ?Sized`

Alice: There's no problem, that's just an error that arguably should be a lint. Even if you do this, you don't end up with something bad.

[Forbid freely casting lifetime bounds of dyn-types
](https://github.com/rust-lang/rust/pull/136776) bugfix
- Fixes: [arbitrary_self_types + derive_coerce_pointee allows calling methods whose where clauses are violated](https://github.com/rust-lang/rust/issues/136702)
- Passed FCP, ongoing discussion

Alice: This is also one of the blockers for `derive(CoercePointee)` alongside arbitrary self types. Someone noticed it didn't actually applied in all cases. The next step is the PR needs to be updated and we need to do another crater run.

#### [RFC #3851: Supertrait Auto-impl](https://github.com/rust-lang/rfcs/pull/3851)
- obi1kenobi requests more detailed consideration for semver impact edge cases: https://github.com/rust-lang/rfcs/pull/3851#discussion_r2430827437

Current status?
Ding: I am still in implementation phase of the RFC. Working on the parser and the HIR interface for it. Trying to ship it in smaller chunks. As for obi1kenobi, I am working on a full section dedicated to the important questions raised and hopefully I will get the satisfying answers.

Ding: The difficulty is writing out examples for all of the cases highilghted. That's taking time.

#### [RFC #3848: Pass pointers to `const` in assembly](https://github.com/rust-lang/rfcs/pull/3848)

Finished FCP, will be merged soon. Next steps?

Tracking issue: https://github.com/rust-lang/rfcs/pull/3848

TODO: Tomas to look at the full process for merging RFCs (look at the Forge?)

Note: Gary has an implementation PR here: https://github.com/rust-lang/rust/pull/138618

Ralf proposed this diff to the RFC: https://github.com/rust-lang/rfcs/pull/3848#discussion_r2275839654

#### Field projections (2025H2 Goal)

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.

NOTE: Benno posted very detailed updates to the goal tracking issue: https://github.com/rust-lang/rust-project-goals/issues/390#issuecomment-3438476150

Benno: Tyler and I have a weekly meeting and we go through different design ideas there. Making the information known to the people following along is useful. And linking the comments to the zulip discussion is helpful as well.

Benno: We went through a lot of different things. E.g. moving projections, owned references, discussing `DerefMove`. Talking about having a single `Project` trait that would make things easier to document.

Benno: There's a zulip thread about virtual places:

https://rust-lang.zulipchat.com/#narrow/channel/522311-t-lang.2Fcustom-refs/topic/Field.20projections.20and.20places/with/553831123

we could have virtual places. Similar to field projections but do it in a slightly different way. That could be combined with the field projections and end up with something broader than initially intended.

let mut x = MyPtr::new(Struct { .. });

// currently not allowed, since this desugars to two deref calls
let a = &mut x.a;
let b = &mut x.b;

// with places proposal we'd also allow
let c = &mut x.a.c;
let d = &mut x.a.d;

Miguel: How is this related to the partial struct references?

Benno: Using field projections you can implement those yourself using unsafe. Tyler's idea was to make the projection safe:

https://github.com/rust-lang/rust-project-goals/issues/390#issuecomment-3438584812

Benno: They don't work with how Rust types work normally. You're allowed to copy Rust types byte by byte. The partial struct type would have the same layout as the struct type itself. But you wouldn't be able to access the rest of the bytes and therefore wouldn't be able to move the struct.

Benno: In a different discussion we talked about move constructors. With that we could make these partial struct types work.

TC: How does this interacts with the opsem? When you take a reference, that counts as a read of everything accessible behind the reference. How it would that interact with the partial struct type and padding of the struct?

Benno: One way would be just reading the field. You're only able to access the field of the type, you can't go back. It'd be similar to having just the reference of the field.

Alice: Having a reference doesn't imply a read if there's an UnsafeCell.

TC: Agreed.

Alice: You have something similar with Pin. They have to opt out from these reference rules. So it seems like a familiar territory.

Josh: That seems reasonable.

TC: We could come up with a set of rules. We'd have to carefully define them.

Josh: I meant that too: we could define the rules.

Benno: I haven't finished the Field Representing Types PR. Now that we're doing multiple projections, I'm more sceptical of the FRT. I'll have to talk with Tyler about the best way forward. We're still in the design territory. I'll sync up with Yosh and Nadrieril. We haven't had owned references on our radar for a long time and now it's something that could be useful. I have an idea for an additional projection kind (copy projections) that work on `Copy` structs. Those could work on `ArcRef`.

## Other topics

Alice: Matt Mauer has an idea of inlining C code into Rust code. Theres' a middle ground between "do nothing" and "full LTO". Take all the static inline functions you have in your C code and generate header functions (we already do that). You compile that down to LLVM bitcode (instead of an object file). And there's a tool called llvm-link that can merge them toghether and it lets you treat everything in the second bitcode file as a static inlined function. And Matt said that rustc has multiple passes where we could pass the bitcode into. I think that would make it really easy to inline certain functions into Rust code without going full LTO. Have a flag you pass to rustc with the bitcode.

Josh: That sounds deeply impressive. You're moving this into LLVM-based inlining. That sounds awesome.

Alice: I think anyone doing FFI could benefit from this. It seems like an obvious fit with bindgen.

Boqun: https://lore.kernel.org/rust-for-linux/[e-mail]/ This is what we're trying to do currently (without Matt's idea). But I think Matthew's idea is much better than this.

Alice: https://android-review.googlesource.com/c/kernel/common/+/3811945 this is a modification on what Boqun said above that still uses llvm-link

Alice: and this is the zulip thread Matt opened about this idea: https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/pre-MCP.20vibe.20check.3A.20-Zinternalize-bitcode/near/546294314

Boqun: Could/should this be a Rust project goal for the next period?

Miguel: I think that's a good idea.