---
title: "Lang/RfL meeting 2025-07-30"
tags: ["T-lang", "design-meeting", "minutes"]
date: 2025-07-30
discussion: https://rust-lang.zulipchat.com/#narrow/channel/410673-t-lang.2Fmeetings/topic/RfL.20meeting.202025-07-30/
url: https://hackmd.io/Gw7rtJsqRUmWsGtSVnEvgA
---
# Lang/RfL meeting 2025-08-13

## Attendance

People:

Minutes: Tomas Sedovic

## Tracking

[Tracking issue](https://github.com/rust-lang/rust-project-goals/issues/116)

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

(feel free to add items here)

Xiang: Arbitrary self type: why was there a motivation for Deref becoming a subtrairt? Seems they're orthogonal. Turns out that was an unfortunate oversight. They didn't just think about real justification around that decision. I'd try to see if we could just work without a Deref and Receiver connection and keep them separate.

Assuming we still have a such a relation, I've posted a v2 of the RFC in the zulip chat. After this week I'd probably publish this as a PR.

TC: You and I talked about this. When Adrian did this, it was a simplification of the implementation. But maybe that's not needed? I've spent some time thinking on this and I agree that they're different kinds of things. The issue is writing out specific set of rules for method resolution if they differ. I don't see any immediate blockers. If you can show this in the experimental implementation, that would be great.

Tyler: My recollection is that started as not being a super trait relation and only within the last year we decided that they did need to be.

TC: It wasn't in the original RFC that they had a subtrait/supertrait relationship but there was a blanket impl that basically means the same thing. The proposal here was to have neither.

Josh: There was a proposed version before that that didn't necessarily do that. But it had some really complicated rules for how do you handle Deref vs. Receiver and how you did method resolution. Even if you are looking at the flow chart on how to resolve this it would be really complicated. So that was a part of what led to this. I'm not sure if there was another issue, but eliminating that whole branch of complexity.

TC: There was an entire separate axis of complexity that we pruned out of the RFC unrelated to this. I went looking and I couldn't find a lot of discusisons about complexity related to Deref/Receiver, rather than that other resolution rule we worked out. Maybe we're mixing it up with this other thing.

Josh: I don't think there is a fundamental property where you have this relationship to work. It's an open question whether you can have this and have a simple set of rules. I think it's worth an experiment. But the main concern would be the method resolution. And if that does end up being substantially more complex, that may end up being a blocker.

TC: Unfortunately, method resolution isn't simple right now, as we saw for unrelated reasons in the lang call today. It'll be important to write down the rules clearly for this.

Xiang: Seems like this would turn out to be a rule book on how method resolution works today and then see how it would change with an independent Receiver. Sounds like something we'd want to check into the dev guide and publish that.

Alice: Can you make `impl A { fn foo(self: B) }` be a method on `B`? <!-- I think? -->

Gary: The issue of not having Receiver and Deref related, now you have two-to-n ways to resolve the methods. It's an exponential explosion in the compiler.

TC: Yes, I had thought about exactly what Gary said, and it's why I wanted to see the proposal written down carefully. Is it that at every step down the chanin would you evaluate "do you have Deref or Receiver here, or both, and then you pick only one with some rule". Or is the idea that it could end up branching.

Xiang: I'll write that down. But I have a feeling that I could write down some simple rules for arbitrary self types or receiver type. I think can find something that's reasonable.

Tyler: We do have a project goal this cycle for making these types of trait hierarchies possible. The main motivation is about extending existing traits with super traits. We're actively devoting resources to this cyle.

Alice: Sometimes you want Deref but not Receiver. E.g. slice: do you want Self: Vec functions on slice? But I don't think you even want to implement both traits with both associated types. But people made arguments for Deref + !Receiver and !Deref + Receiver.

Josh: The only one that wouldn't work under the current proposal is Deref + !Receiver. Writing the slice/vec issue is something you could do today so we shouldn't necessarily stop you from doing that.

TC: There was a proposed usecase for them having separate associated types in the field projection proposal. I'd be interested in the thoughts of people here on that.

Gary: I don't necessarily think it's worth supporting that and making the language too complex.

TC: On first impression I hated it -- separating the traits like this -- but when I looked more carefully I hated it less. When you think about what Receiver and Deref mean in the language and how they impact method resolution, they are kind of different. And some of the confusion comes from conflating those two concepts. If you could unconflate them and articulate the method resolution rules, maybe that's workable. But that proposal needs to be written out clearly and talk about whether we're pruning the chain to avoid the exponentiality.

Gary: I think Deref and method resolutions work together. Where something can be called from a dyn trait is different whether they can be called from a method. Whether Receiver can prevent an object from being object safe -- that's different form calling a method on that object. Receiver doesn't give you more than the method resolution.

TC: Receiver defines a self type can be expressed. It has an effect on static semantics and which impls are looked at during the method resolution process.

Gary: Deref to me is just a sugar for method resolution. I think there's a different view on what deref actually means.

TC: I'd be interested to see your model written up.

Alice: Gary you spoke about receiver affecting the trait, that only works if you have derive(CoercePointee). Arbitrary self type does something else on its own.

Zulip discussion: https://rust-lang.zulipchat.com/#narrow/channel/213817-t-lang/topic/Consequences.20of.20making.20Deref.20a.20subtrait.20of.20Receiver

## Field projections: lang design meeting 2025-08-13

Happened [just before this meeting](https://rust-lang.zulipchat.com/#narrow/channel/410673-t-lang.2Fmeetings/topic/Design.20meeting.202025-08-13.3A.20Field.20Projections/).

Notes: https://hackmd.io/PgVxFwBDQlGXPGTQrI0i3A

Benno: importantly we had very positive vibe checks on the entire concept of field projections. We agreed on the usecases I put into the doc -- those should definitely be supported. We had interesting discussions on the design guidance section. We'll be moving forward with a lang experiment on field projections. Very successful meeting.

Tyler: The doc was good, the meeting went quite well. It laid out the space quite well, the lang team's response was enthusiastic. Reservations around syntax but it's not blocking anything. We're looking at things we could do in the compiler to reduce the syntax impact.

Alice: Is that going to be another dimension on deref chain?

## Updates from Miguel

Miguel Ojeda: Hi TC, Tomas,

* The -Zindirect-branch-cs-prefix PR was approved by David, so it should land soon: https://github.com/rust-lang/rust/pull/140740.
* I discovered a bug on the -Zregparm support which we will use for 32-bit x86: essentially, LLVM intrinsics, like memset, did not take into account the expected ABI change, and thus manifested in the kernel as e.g. derefs of the 0 or 1 address in certain places: https://github.com/Rust-for-Linux/linux/issues/78#issuecomment-3175358373. Trevor/Gary/Björn quickly noticed the LLVM IR did not have the relevant module flag that Clang passed (apart from the inreg on parameters). Trevor filled the issue on the Rust side: https://github.com/rust-lang/rust/issues/145271. Arthur Bied-Charreton created a PR to fix it, which should also be landing soon too: https://github.com/rust-lang/rust/pull/145309. When it does, we can re-test on the kernel side. (Thanks all!)
* I think Arthur may also add assembly tests for the other related flag, -Zreg-struct-return, since I noticed we didn't have any for these two flags, and I think it is important to have those and not only the LLVM IR level ones, like we do for other similar flags: https://github.com/rust-lang/rust/pull/145309#issuecomment-3182523749.

And a couple other updates for the minutes:

* -Zharden-sls and the sanitizers as target modifiers PRs, by Andrew, were both rebased: https://github.com/rust-lang/rust/pull/136597 and https://github.com/rust-lang/rust/pull/138736.
* The --crate-attr RFC was merged by Josh: https://github.com/rust-lang/rfcs/pull/3791.

And for the usual "kernel news" section that TC asks me about:

The Linux merge window has finished for this kernel cycle, which means new Rust features and code landed in v6.17-rc1, about ~8k lines of code this time around, which a fairly big jump like last time, for a total of ~47k lines. I will send the upgrades for the Rust and bindgen CIs as usual.

## Stabilize Arbitrary Self Types
[Tracking issue #44874](https://github.com/rust-lang/rust/issues/44874)

First up, we were deliberating, why we needed `Deref` to become subtrait of `Receiver`. There seems to be history, see [Zulip chat](https://rust-lang.zulipchat.com/#narrow/channel/213817-t-lang/topic/Consequences.20of.20making.20Deref.20a.20subtrait.20of.20Receiver) for the recount.

NOTE: This is being pursued via the "Supertrait associated items in subtrait impl" RFC.

Pre-RFC: https://hackmd.io/GONeg1UDQmWUoBvBqZ6yhw

Ding: I'me going to propose it and hope to have more lang discussion there.

Tyler: This fits into the project goal of evolving trait hierarchy. Taylor is going to champion this, did you talk to her?

Ding: I tagged her and Jules. I'll DM both of them. Alice has pointed outh there's a usecase for other kernel trait where trait implementations are mass generated by a macro and this would help too. The motivation is now added there too.

### RFC draft v2

[Link to v2 draft](https://hackmd.io/@rust-for-linux-/SJd7zyFDel)
This RFC alone has its own use case in RfL.

## Stabilize `derive(CoercePointee)`
[Tracking issue #123430](https://github.com/rust-lang/rust/issues/123430)

Stabilization PR: https://github.com/rust-lang/rust/pull/133820

Status: Blocked on `arbitrary_self_types`.

Also waiting on: [Do not materialise X in [X; 0] when X is unsizing a const PR#145277](https://github.com/rust-lang/rust/pull/145277)?

Ding: The PR is to address the one remaining concern. The arbitrary self type is blocking in the sense of feature utility.

Alice: In principle you could stabilize CoercePointee without arbitrary self type, but it would not be very useful. The bug is a lang bug so I think it maybe shouldn't block this?

TC: The situation is that there's not a pressing motivation to stabilize CoercePointee without arbitrary self types. And stabilizing one may lock us in ways we haven't thought about. We're treating them as coupled together until someone makes a case otherwise.

Alice: Last time I opened a reference PR. Seems like the Reference change was alerady approved by TC but the FCP is still open. https://github.com/rust-lang/rust/pull/136776

TC: We unblocked this on the Reference side. Thanks to Alice for a great PR. Everyone on Lang has done their job here -- we've all checked our boxes. What remains is types and we still have 2 concerns. What are the concerns?

Alice: Boxy said they wanted to write some FCP proposal. Should I wait/ping Boxy?

TC: And there's the second one about having a second look at doing a FCW.

TC: Have a discussion with Boxy on it. If you can reach out and report back in a couple weeks, that'd be good.

Tyler: On the question on forward compatibility warning: I asked for that originally. Eventually decided it may not be feasible. Having FCW should not block it from our side.

Alice: I was a bit surprised to see that one. We asked whether we can do a warning and each time they'd said no. I considered going to the Types team office hours but I was blocked on Tuesdays for the past two weeks.

## Support for pointers with `asm_const`
[Tracking issue #128464](https://github.com/rust-lang/rust/issues/128464)

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

Alice: It would be nice to get some feedback on it? T-Lang asked for it originally.

TC: It's on the lang radar but I've just skimmed it.

Tyler: Haven't looked at it yet.

Gary: for the implementation I have some issues on 32-bit x86. GCC supports the const ptr with "i" in asm but LLVM doesn't. Going to use an alternative way.

Alice: I think the implementation matches what's in the RFC than what the backend allows. In general, the expansion of this particular contstraint is pretty simple. Turns out understanding what that expansion means in inline assembly is a bit tricky. I wrote about it in the guide-level explanation.

TC: We should propose a design meeting fort this. It's obviously going to take an RFC read.

Alice: I that case I think the RFC itself is going to be the reading doc.

Tomas: I'll file an issue for this. (Update 2025-08-18 here's the design meeting issue: https://github.com/rust-lang/lang-team/issues/347)

## Field projections (2025H2 Goal)
https://rust-lang.github.io/rust-project-goals/2025h2/field-projections.html

Discussed above.

## In-place initialization (2025H2 Goal)
https://rust-lang.github.io/rust-project-goals/2025h2/in-place-initialization.html

Ding's experimental PR: https://github.com/rust-lang/rust/pull/142518

Ding: I attended the 2025-07-30 design meeting. We arrived at pivotting to a different approach. I still see some value in this experiment / language design. My question is: should we set aside time to discuss the requests with a smaller group? To settle on a final design.

Ding: I do have concerns about out pointers but I don't know how to formulate them in a way that we'd all agree on.

TC: Next step is probably you writing up a document that brings together your thoughts -- what you think is valuable there, what your concerns around out pointers are. It's probably going to take a number of documents to see this from different perspectives, pros/conts, feasibility.

Alice: Yosh and I talked today. Yosh argues that we can't really get around having to deprecate the existing Box::new, Vec::push. I also think the next step is people need to think more about all the solutions.

Tyler: The doc to the lang team covered. a lot of differevnt approaches. In my mind the leading approaches are Init and outptrs. And really dive into the benefits and drawbacks of each approach. Maybe these are just two different tools in our toolkit? Maybe they solve different sets of problems with some overlap. There's nothing in principle that says we can't have both.

Alice: One could be analogous to closures and the other to functions.

TC: There's also guaranteed move elision. That's the one where I could see us doing that and something else. If you can come up with a few simple rules, the guaranteed elision would "just work" in a lot of common cases, but it wouldn't solve everything, so we'd also need something else.

Tyler: I'd also love to see a doc that explores the ovelaps. A set of more specific design axioms might help. Maybe I'll collect some thoughts. TC and I talked and we found that deferred execution happening in a closure was a compelling design axiom.

Alice: I'll also need to think about this more deeply.

Tyler: I'll think on this more and write something down.

Ding: _note, there is a [blog post from Yoshua](https://blog.yoshuawuyts.com/placing-functions/)_

## cfg(no_fp_fmt_parse)
https://github.com/rust-lang/rust/pull/86048

Unstable config. Anything to track here? Is there a stabilization PR we're waiting for?

Alice: current status: unstable impl. People don't want to stabilize a cfg option in the standard library.

Tyler: Does it make sense to do this as a target variant? You'd create a target variant that gets rid of floating points. The standard library would have internal configs to enable/disable.

Alice: That makes sense to me.

Gary: We have another option to use soft float.

Alice: But the floating point format stuff is pretty big. We want to get rid of it.

## NUL-terminated file names with #[track_caller] aka `file_with_nul`
[Tracking issue](https://github.com/rust-lang/rust/issues/141727)

Waiting for someone to open stabilization PR?

Alice: I'm waiting for an underterminate amount of time before stabiliving it.

Tyler: I don't see a whole lot of risk / open design questions.

Alice: We've resolved those with the ACP.

Alice: We officially started using it in the upstream kernel as of last Monday.

## Compiler flags and features
https://rust-lang.github.io/rust-project-goals/2025h2/Rust-for-Linux-compiler.html