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

## Attendance

People: Alice Ryhl, Benno Lossi, Tyler Mandry, Josh, Xiang/Ding, Gary Guo, Wesley Wiser, Miguel, TC

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

Miguel:

- https://github.com/rust-lang/rust/pull/140740
Add -Zindirect-branch-cs-prefix
landed already

- https://github.com/rust-lang/rust/pull/145309
Fix -Zregparm for LLVM builtins)
also landed

- https://github.com/rust-lang/rust/pull/136597
-Zharden-sls
ready for reviews

- https://github.com/rust-lang/rust/pull/138736
Sanitizers target modificators
close to land

- https://github.com/rust-lang/rust/pull/145382
Add assembly test for -Zreg-struct-return option
Trevor approved, should be good

Josh: if we're adding the logig for reg structure anywhere, is that something we're already using for the RUst ABI?

Gary: Rust ABI will have special logic if the type can be fit into two registers. Otherwise it will use the default for the platform.

Josh: So you don't think theer's any case weher the reg struct return will do something moer effecieant than the rust abi. We can change the Rust ABI so if there's anything more efficient we could do, we can change the Rust ABI.

Gary: Looks like it's quite efficient already but I'll investigate and let you know.

Gary: An example of Rust ABI passing by memory and reg-struct-return passing by register: https://godbolt.org/z/e1a3xhPGb -- more than 2 scalars that it doesn't make it to a scalar pair.

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

[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

Q: Where have we landed on `Deref`/`Receiver`?

Ding: I am finalising the separation of Deref and Receiver trait by introducing the Receiver side change. I need a bit more time to test and explore the consequences. I am aiming at posting the PR by end of the week.

Ding: I posted a write up today on what's happening with the arbitrary self types. Splitting of the traints is a strentgthening fo the featuer. We'd allow more ways to resolve the method probing. I have confidence I can continue with the experiment in that way. I view it as a pure extension of the feature.

TC: I appreciate the write up and you taking the time to properly describe the current behavior. The proposal splitting the traits I find pretty compelling. I like your analysis on it. The observation about how the `Receiver` chain is always a postfix of the `Deref` chain at every step of the process solves many concerns. I'm curious to see this implemented so we can poke at it. I'm excited that if this works out we can stabilize arbitrary self types without having to first solve trait migrations.

Ding: A [write-up](https://hackmd.io/@rust-for-linux-/rySktshdex) is covering the existing probing procedure. I intend to publish into the reference, too.

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

Ding: I've recevied comments on the [RFC #3851](https://github.com/rust-lang/rfcs/pull/3851). I'll respond to the comments and if there's anything else about the Trait Evolution RFC I'll bring it up in the lang channel. If I hit a wall, I'll reach out to you Alice. But first I need to formulate what Taylor really wants out of it.

Tyler: We had a design meeting on this topic. There's some discussion of being to implement Ord and get everything else for free. I think it's not a requirement for MVP of the feature but whether we can extend it in the future.

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

Design meeting: https://github.com/rust-lang/lang-team/issues/347
- Meeting waiting to be scheduled on Lang side

TC: We have conferences on the way, we're backed up on our triage. We could slot this as the next design meeting in the calendar: 2025-10-08.

Alice: For the in-place initialization meeting I asked for two meetings and the slots are filling up quickly.

Tyler: We're filling up at least half of our slots and we're mostly scheduled for non-project goals.

Alice: The second meeting would be near of the goal period.

Tyler: I think we should manage them all of them.

TC: Also if we get backed up on our nomianted queue we'll have to start postponing them.

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

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

Experimental implementation of field reflection in my repo: https://github.com/BennoLossin/rust/tree/field-projections

Ding & I have been working together and managed to get this simple code to compile:

#![allow(incomplete_features, dead_code)]
#![feature(field_projections)]

use std::field::{Field, UnalignedField, field_of};
use std::mem::offset_of;
use std::ptr;

struct Foo {
    x: usize,
}

pub fn project_ref<F: Field>(r: &F::Base) -> &F::Type
where
    F::Type: Sized,
{
    unsafe { &*ptr::from_ref(r).byte_add(F::OFFSET).cast() }
}

fn main() {
    let x = Foo { x: 42 };
    let _: &usize = project_ref::<field_of!(Foo, x)>(&x);
}

There still are several `todo!` and `// TODO` left throughout the code, but after some cleanups I will post a PR

Benno: We can use the field_of macro and have a basic field projection. This will enable us some more experimentation before we do more borrow checker changes. This is a great starting point. Where's a lot of todo! in the code, Ding has been very helpful.

When I clean those up I'll post the PR.

Tyler: I've been working with Benno trying to burn down soem of the open questions and that's been very productive.

## 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
- Current status?

Ding: It's going stale. I wanted to pick it up right after the initial arbitrary self type PR. I'd like to talk about teh design space here. It would be hard for the implementation to continue with the Init trait not having a stable design in the first place. Is there an opportunity to discuss this?

Alice: Maybe you and I should have a call about that.

Ding: I tried to start a doc but I never got to the writing. There's way too many materials to read.

Benno: Feel free to include me if you want.

(notes from last time) Tyler was going think and write something down (design axioms, guaranteed move elision, other proposals).

Tyler: I didn't get to do anything concrete. Maybe Alice and I could brainstorm about that.

Alice: That's a really good idea, we should set up a call as well.

## cfg(no_fp_fmt_parse)
https://github.com/rust-lang/rust/pull/86048
- Anything new happening on the stabilization front?

Miguel: We were discussing how we can make core smaller for the kernel. So we thought we could add cfg to cut certain things. One of them was this flag. We had the ideas to cut things and we've submitted at least one more PR. What happened was that people didn't want a lot of cfgs added. Back then the Libs team said they don't want to add too many cfgs because testing them is hard.

It depends on the cfg, some are harder than others. This one may be worth it but the other ones were too small to consider. Instead of this, we could find the things we'd cut down behing a single feature but that's very Linux specific.

TODO: Tomas to set up discussion with Libs-API

Alice: This removes one thing from core, but other things (e.g. on 32-bit ARM we don't have 64bit/64bit division (or it's really slow and people want you to discourage you), similar with 128 integers, Kernel folks don't want floats at all). There's some potential to say: should targets say "we don't have floats".

Miguel: We could have targets that could use floats in particular cases and forbid it in most places. Back then we removed the Rc type.

Alice: There's also the atomics.

Miguel: Yeah. There's also unicode.

Gary: Atomics aren't issue in terms of code size because they're all inline methods. There's no cost in having it. The other ones have code size impacts.

Miguel: the other cfgs were in alloc. We don't care about those -- we use our own alloc nowadays. There's also the 128bit integers -- those would probably be useful.

It's not critical, there are more important things to discuss.

Tyler: What would it look like if you were designing it. Would you have true core and then a sort of a-la-carte things you'd add? OR something wheer you'd selectively turn off featuress.

Miguel: Initially, the cfg route seemed the easier. But recently, someone brought up the question why can't remove more from Rust. More and more, I'd expect to mix and match. But it would be better if we had our own smaller core.

Miguel: there are two ways: removing thing. And the other would be having a tiny core that we could use build-std to build and we'd customize and implement things in the kernel.

Gary: If we go that route we need coherency domains to be able to implement traits and inherent methods on these tiny-core types.

Alice: Another suggestion I've heard is the idea of using target modifiers. A target could decide that floats don't exist and we could expose that as a compiler flag. And similarly, the signedness of `c_char` -- it should be unsigned.

Alice: C actually has a flag to set signedness for char.

Josh: Various C compilers has these flags but not all of them.

Tyler: We seem to be circling around a set of features that would meet your usecase: target modifiers / lightweight ways of changing the signedness of char, a set of features you could set when you're building core with build-std, coherence. Is there anything missing from that lisst?

Miguel: no_panic suport. If we had our own core, we could experiment more easily witth core that doesn't support any panics at all.

Tyler: Instead of panic = immediate abort, it would be panic = compiler error.

Miguel: yeah. The other one the builtin arithmetic operators on being able to customize (instead of the overflow / panic)it would be nice to have a middleground wheer it wraps and also calls a custom function provided for us - where we could panic or or report or do whatever. This is what Linux normally does on a panic. Mara was working on that (it was planned as a several step process), but I don't know the latest status of that.

Tomas: TODO check with Mara.

Tomas: TODO Collect these examples and write it up.

Benno: We also have custom formatting to be able to print CString. We've wrapped the formatting machinery with our own. It would be great if people could not use the standard formatting machinery and use ours instead.

Josh: The formatting args thing I wonder how that coudl be solved with appropriate Display impls.

Alice: We've tried to add our own Display and you wouldn't let us to do that.

Josh: We can't add that to the standard library. But you control your standard library.

Benno: We don't own the cstr type.

Josh: So what you're saying orphan rule. You could always use the unstable option that makes core alloc and std part of one coherence domain. So our core and your std would be the same domain.

Alice: we also want to remove debug impls for pointers.

Miguel: We want the the all the options in the kernel to print differnt things. But we also want to forbid pritting the pointer value becaues that leaks addresses and has security implication. We want to disable the default behaviour. AND be explicit about this.

Josh: Didn't recent kernel make it so %p can't print an unmasked pointer?

Miguel: That maybe happened a while ago?

Josh: I think we finally got around to doing it recently.

Gary: The flag Josh mentioned doesn't exist, a flag rustc_allow_incoherent_impl exists but it allows adding inherent method implementations only.

Tyler: We're looking for someone to go ahead and implement that in the compiler.

Miguel: there's a third that a PR that broke rust CI. It's all good now but it's been working well. The bot works, it all works as intended.

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

[Stabilization PR](https://github.com/rust-lang/rust/pull/145664)

Discussed at Libs-API meeting yesterday (2025-08-26). Restarted FCP with the suggestion to use `file_as_c_str` as the name. Currently awaiting Libs-API checkboxes

Alice: I went ahead and submitted the pull request to rename it.

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