---
title: "Lang/RfL meeting 2026-03-25"
tags: ["T-lang", "design-meeting", "minutes"]
date: 2026-03-25
discussion:
url: https://hackmd.io/RsnVqqb0Qh2BhMW2g9Elew
---

# Lang/RfL meeting 2026-03-25

## Attendance

People: Alice Ryhl, Boxy, Tomas Sedovic, Mukesh Kumar Chaurasiya, Boqun Feng, Benno Lossin, Paul Murphy, Josh Triplett, Miguel Ojeda, Xiangfei Ding, 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)
[Rust wanted features](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

(please add topics here)

### Const generics (Boxy)

Boxy: I have a [document that discusses where const generics can get](https://hackmd.io/o7aNy5EgSROfSlA_eAdHxg?view#Slightly-Sparkly-Future-for-Const-Generics) to implemnation-wise. I want to see what you actually need.

Alice: The most interesting use case is motivated by not wanting to panic. (Panics might cause your computer to stop.) We want to have things like bounded integers that have a maximum value that's a const generic. We use this for bitfields etc. where the bound generic is a power of two. We want to be able to do arithmetic on it (e.g integer with three bits shift by two bits).

Boqun: https://hackmd.io/NmCuEB9ISFGfj2cbTUvFBQ <- this is a list of examples we have

Boxy: Is it all integer operations you want to statically guarantee won't panic?

Alice: We do this on specific integers, when we do arithmetic on it we want the maximum to

Boqun: Alice can you show the bounded integer example?

Alice: This is the bounded integer type: https://rust.docs.kernel.org/next/kernel/num/bounded/struct.Bounded.html

Alice: The `Bounded` type is a bounded integer and `N` is the number of bits. We have a method `shr` (shift right) you're shifting by another const. You have `Bounded<10>`, you want to shift-right by `2`, and they're both compile-time constants, I want to get `Bounded<8>`.

Josh: Do you have some samples of how this is used in practice in the kernel?

Alice: It's used for the bitfeield register access.

Miguel: https://lore.kernel.org/rust-for-linux/[e-mail]/

Josh: It feels it would be worth mentioning that peopel were asking for bit-width integers as a type. You could think of a `u10` as a `u16` as a pattern type with `3-16`? If you're just adding two `u10` you can say it's wrapping or say the result must fit into `u11`. But that becomes mor ecomplicated and it's trading it a s a more ?? type using const generics.

Alice: I don't thin we've used addition that much. IT's mostly shifts.

Josh: If ther's a narrow-enough slice of usecases (e.g. only shifts), then it can be worth aliginng it with specific bit-width generic types. Whereas const generics have a much more broader ability.

Miguel: Good point. Sometimes we don't know yet. In general the more we can do the more usecases we'll discover.

Gary: I prepared this doc. The may concern I have with the `Bounded` type is the turbofish syntax. When you have a non-literal number you have to put it within braces. There's already a case weher argument-position const-generics si stable (simd intrinsics)

Boxy: That's something we've been thinking about. In the doc, you have the argument position const generics and it has type `T`. Right now you can't write a const generic that has type `T`. Your bounded integer type is now generic over an integer type. ??

Gary: It doesn't need to be generic over the integer type. We can specify u32, u16 etc.

Benno: One problem with turbosfish is that if you have generic arguments and const generic arguments, you have to write underscores if you want to only specify the generic argumenst.

Alice: A lot of the time I suggested const generics, the feedback was that the syntax is bad and people didn't want to do itt.

Miguel: Sometimes it's because C developers are not used to the syntax yet, but it's indeed very busy nevertheless. It would have to be repeated in many lines in some cases. C++ also had `constexpr` parameters proposals back in the day.

Alice: There's also whether you could use const type for atomic orderings. We have our own API and it'd be nice if that didn't have to be a runtime parameter. Right now we're getting around it with ZST.

Boxy: What do you mean youu get around it with zero sized types?

Alice: https://hackmd.io/NmCuEB9ISFGfj2cbTUvFBQ?view#Atomics-API

Boqun: We want this to look like a parameter to the function to simplify things.

Gary: The unit type approach works well for us. This is basically similar to what's in STD. But for the standard library it might be useful to change this to the argument position const generic. Then a code that wants to set this dynamically they could migrate to the new edition and check things at compile time.

Boxy: I think I understand this use case. We can move on. Thank you.

Alice: IO region offsets: https://hackmd.io/NmCuEB9ISFGfj2cbTUvFBQ?view#IO-region-offsets

Alice: We have registers that aren't just a value but an array. And maybe we have 24 values and the code wants to get the fifth value. And behind the scene the fifth value is a struct with field, so you'r doing `5 * (size of struct) + offset`. It would be great to use bounded integers to make sure this is 24 at most.

Boxy: So you want general arithmetic.

Alice: We have Bounded with a maximum value and do an arithmetic within that maximum.

Miguel: We have many things that are going to be, in, say, 90% of the cases, constant (or at least known to the optimizer).

Gary: We're approximating this feature where we're approximating this in `build_assert!`. We output an invalid symbol that the optimizer optimizes out and if not, we get a link-time error.

Miguel: On the C side they do the same trick: it relies on the optimiser. But C has an advantage over Rust because both GCC and Clang offer an attribute that will give an error in the compiler already if a thing is not constant (rather than getting an obscure error on the linker), i.e. you get better diagnostics and an earlier error. The biggest complain we have is the diagnostics when you get undefined symbol error. Also it's finicky, you can't rely on it everywhere.

https://clang.llvm.org/docs/AttributeReference.html#error-warning

https://gcc.gnu.org/onlinedocs/gcc/Common-Attributes.html#index-error

Alice: But it's not constant always. One of the Nova people pointed that they have an array where we know the size but they may have an index into the array so it may not be constant.

Benno: So they're still compile-time bounded.

Miguel: The attribute on the C side is "diagnostic is emited if a call to this symbol is not optimised". It's not a compile-time constant, it's more that this is detected after the optimiser. We use it when we know what the number is compile-time.

Alice: I've been argunig that this is a bad idea to rely on.

Miguel: Alice's concern is that a new version of LLVM will not optimising it. But the C side relies on this already. So we want to get at least to that level. But if we can rely on it less using const code, that's great. We need something at least for the trivial cases.

Alice: Bounded integers solve almost all the cases in the Rust code that concerns me.

Gary: Another issue is the lack of const trait impl. We have a lot of functions that are exactly the same as trait functions but they're written specifically to be able to mark as const. Stabilizing that would also be realyl important for us.

Boxy: I don't know much about the status of const traits.

Benno: We definitely want teh full const trait machinery. But if we could just mark an implementation function as const in a trait and if you call that specific instance it's const but a general call wouldn't. That would help.

Josh: That's theoretically possibly by factoring out a const helper function, you just can't have that functtion be the the function in the trait impl. But: if you have a trait that provides a method `x` and that method can't be const, we'll provide an inherent method on a concrete type with the same name and make *that* const. The call will look the same way.

Alice: It also doesn't work with extension traits. Also, you should dbo that for `minimum` and `maximum`.

Josh: Send a patch.

Alice: I tried, it was rejected. https://internals.rust-lang.org/t/int-min-max-in-const-fn/23232

Josh: `minimum` and `maximum` have been a pain lately due to the floating point discussions of what exactly that mean. I'm sorry it was rejected. What was the rationale?

Alice: The rationale was "we'll have const traits any time now"

Gary: Can we have stable const traits for core types before const trait impl is stable generally?

Josh: From a lang surface area ponit of view, if that's feasible in the cases you're not naming the traits, it seems fine to do it first and name it later. You won't be able to write bounds but if you want to be able to do that in a const block, there's no obvious bloc.

Boxy: I've no idea how const traits are implemented. You'd have to talk to oli.

Boxy: Is there stuff other than integers you want in const generics?

Alice: I have a workaround but I want pointers. The other usecases are much more important. But if you read my asm RFC and passing the const-evaluated pointers, you'll see some ugly workarounds to pass pointers as static.

Alice: https://rust-lang.github.io/rfcs/3848-asm-const-ptr.html

Josh: I've seen a number of usecases for simple string constants. Not string methods, modifying strings. Jush "here's a constant literal string as a const parameter, the only thing you can do it is take it out and subsequently use it in the implementation of that type". Useful for doing things like parameter extraction and inferring something about the type of the parameter.

Josh: It feels every time string constants come up, a discussion around how complicated those are. But if we could just pass it through, that would have still been really useful.

Miguel: In C++ they have string literals in the template parameters. People had been asking about that for a long time and now it's there. There are many usecases wher ethis would benefit.

Benno: Just doing that for all types as a first impl step -- if you can do it in a string, you should in theory be able to do it for other tyes -- it would be cool for us to replace some typestate patterns where we need a sealed trait and replace it with an enum. That should work with just having a pass-through for const generics.

Gary: I want to make the location argument of this function const: https://rust.docs.kernel.org/next/kernel/io/trait.Io.html#method.read

Boxy: Can you explain it more?

Gary: Location is an offset into the ?? region. T gets offset from the location (L), address we should look at. This is a generic type, not just an integer.

Boxy: Is your argumentto the method always known in compile time?

Gary: 99% of the cases.

Boxy: Alice, you said you wanted raw pointers. Do you always know the address of the pointer at compile time?

Alice: It'll always point to a static or an offset froom a static.

Benno: Do you nede to do any modification to the pointer at const time?

Alice: I might need an offset to it.

Boxy: Would it always work for your usecase to do a const of a reference rather than a pointer?

Alice: I don't necessarily want to create a mutable reference because maybe the memory is not mutable. Or it might be an `extern "C"` static where you can't create a reference to it but you can't create a raw pointer.

Boxy: Do you only want bounded integers or also bounded floats?

Alice: We don't want floats in the kernel at all.

Boxy: This has been really useful.

Miguel: Thanks Boxy for joining! We'll probably want you here for the coherence domain too. We saw your blog post. I saw you said the coherence-domain solution is not great in general. But for the kernel, it's its own world and then the ?? evolution we wouldn't care. It's all in a single unit we control. For us it's the obvious thing. Bjorn suggested it when I asked him. It would be a really simple solution taht works for us.

Boxy: My blogpost supports more general thing but I'm not saying we can't do smaller solutions. Thank you.

### `statx` ABI evolvability

https://github.com/rust-lang/libs-team/issues/761#issuecomment-4120492410
https://hackmd.io/kWst10__RL-rp3qmwwSxdQ?edit=&stext=27982%3A106%3A1%3A1774436738%3AlqJtPs

Context: Libs-API is considering using [`statx`](https://man7.org/linux/man-pages/man2/statx.2.html) for creating [`std::fs::Metadata` on Linux](https://doc.rust-lang.org/std/fs/struct.Metadata.html). They'd like to know if the structure can grow in the future and if so, how. How can they handle that if they wanted some of the new data available.

Josh: We had an ask to turn `statx` into a stdlib metadata structure. We can do this. The structure is designed such that we can check what's set. What we're trying to undrestand is what the path of evolution of `statx` is. There's no length being passed alongside the structure. Can you actually make the struct lon7ger fromthe kernel side? The concern we had was: what happens if the kernel's structure gets larger? What would that look like. What happens if we want to look at the new fields but not everyone working with us will have set / retrieved those fields.

Josh: We're talking about taking this a stable API surface.

Miguel: We should defer to the filesystem and syscall maintainers. We can contact them, if you'd like us contact.

Josh: Helping us start the right thread and asking "what are the ways this could evolve in the future" and how could something that wants it to accept this have a permanently stable ABI, that would be helpful.

Miguel: Is this for metadata only for Unix?

Josh: This would be a linux-speecific MetadataExt method converting statx to Metadata.

Alice: The context is to invoke statx in io_uring in tokio.

Josh: We want to make sure if someone passes us statx is when they don't understand the data and we do or vice versa. Will that cause breakage?

Alice: Tokio can ask the standard library for the bits it wants to set. The standard library can ask "what do you need" -- list the minimum flags.

Josh: That's a good point.

Gary: Why do you need the stability guarantee? Tokio must be getting statx from the kernel. Even if it grows longer, tokio must use some flags to let kt now that it can be longer than the current size.

Josh: There's some careful terminology in the man page statx. IT says if you set up a flag and the kernel doesn't know it or fs doesn't have the data, it'll clear the field in the mask and it'll set it to default. Which means we can always be able to read the value and assume it's a sensible default. But if you extend the data structure, it would always be possible for someone to manufacture a statx and pass it to us and us getting confused. We need to know how defensive do we need to be in terms of new fields, checking the mask and never reading the fields that aren't there.

Gary: IF you use an old kernel and the kernel clears the field, it won't know what the field is.

Josh: That's a good point. That makes me surprised a linked field is'nt included in the syscall.

Josh: Sounds like we should be at least moderately defensive and in our conversion method we may need to overtly fill in any fields we feel we may need when the're not implied by the flags.

Alice: The standard library could expose a statx opaque thing that would create a struct of a given size. Tokio could call `::new` on that.

Josh: That makes sense.

Josh: Given your usecase, would it cause any problems if we documented that the stable surface area is to only pass the one you got from the kernel. You should never manufacture a statx yourself?

Alice: That should be okay.

Josh: It sounds like we can 90% make the safe assumptions and then ask whether these are going to bite us in the next decade.

Miguel: You can also contact Alejandro Colomar (the maintainer of the man pages).

Josh: We can add the interface now and usnstable ,nda then run this by linux fl before stabilization.

### rustfmt `use` formatting

We have an issue here: https://github.com/rust-lang/rustfmt/issues/6829

## Compiler features

### Flags that need stabilization

* [`-Zbranch-protection`](https://github.com/rust-lang/rust/issues/113369) (arm64)
* [`-Zcf-protection`](https://github.com/rust-lang/rust/issues/93754) (x86_64)
* [`-Zcrate-attr`](https://github.com/rust-lang/rust/issues/138287)
* [`#![register_tool]`](https://github.com/rust-lang/rust/issues/66079)
* The RFC is in FCP and it's been discussed by the Lang team on 2026-03-11. The vibe overall is positive, TC's going to read it and then hopefully give his checkbox.
* 2026-03-25: No updates since last meeting
* [`-Zdebuginfo-compression`](https://github.com/rust-lang/rust/issues/120953)
* Stabilization proposal: https://github.com/rust-lang/rust/pull/150625, needs to address feedback from Mark
* [`-Zdirect-access-external-data`](https://github.com/rust-lang/rust/issues/127488) (loongarch, and maybe x86_64 soon too)
* Gary opened [discussion](https://rust-lang.zulipchat.com/#narrow/channel/425075-rust-for-linux/topic/New.20relocation.20model.20for.20relocatable.20code.20but.20static.20data/with/568485173) here.
* No updates since 2026-01-11
* `-Zfixed-x18` (arm64)
* [`-Zfunction-return`](https://github.com/rust-lang/rust/issues/116853) (x86)
* `-Zfunction-sections`
* [`-Zunpretty=expanded`](https://github.com/rust-lang/rust/issues/43364)
* [`-Zsanitizer=kernel-address`](https://github.com/rust-lang/rust/issues/123615) (arm64, riscv64)
* [`-Zsanitizer=shadow-call-stack`](https://github.com/rust-lang/rust/issues/123615) (arm64, riscv64)
* [`-Zsanitizer=kcfi` and `-Zsanitizer-cfi-normalize-integers`](https://github.com/rust-lang/rust/issues/123479) (arm64, riscv64, x86_64)

### Flags needed in the future

* [`-Zharden-sls`](https://github.com/rust-lang/rust/issues/116851) (x86_64)
* [PR#136597](https://github.com/rust-lang/rust/pull/136597)
* Wesley opened: https://github.com/rust-lang/rust/pull/152821
* The `-Zharden-sls` PR will be rebased on top
* [`-Zmin-function-alignment`](https://github.com/rust-lang/rust/issues/82232)
* [`-Zrandomize-layout`](https://github.com/rust-lang/rust/issues/106764)
* [`-Zregparm`](https://github.com/rust-lang/rust/issues/131749) (x86_32)
* [`-Zreg-struct-return`](https://github.com/rust-lang/rust/issues/116973) (x86_32)
* [`-Zsanitizer=kernel-hwaddress` and `-Zsanitizer-recover=kernel-hwaddress`](https://github.com/rust-lang/rust/issues/123615) (arm64)
* [`-Zsanitize-kcfi-arity`](https://github.com/rust-lang/rust/issues/138311) (x86_64)
* [`-Zsanitize=kernel-hwaddress`](https://github.com/rust-lang/rust/pull/153049)
* Tracking issue: https://github.com/rust-lang/rust/issues/154171
* Waiting on bors

### Other

## 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 is requesting a vibecheck from Lang and Compiler for [arbitrary_self_types: Split the Autoderef chain
#146095](https://github.com/rust-lang/rust/pull/146095#issuecomment-3799546097).

This is nominated for Lang, but they ran out of time to discuss it today.

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

Current status / updates? / Anything to discuss?

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

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

### `asm_const_ptr`

https://github.com/rust-lang/rust/pull/138618 waiting for review.

### In-place initialization

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

Current status / updates? / Anything to discuss?

### 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
Wiki to map out the solution space: https://rust-lang.github.io/beyond-refs

Current status / updates? / Anything to discuss?

Tomas: There's going to be a Lang Design meeting next Wednesday (2026-04-01).

Benno: I would like to highlight the TL;DR comment https://github.com/rust-lang/rust-project-goals/issues/390#issuecomment-4099385451 describing the plan for 2026. I also updated the tracking issue with the exact details of the plan.

> We have an updated plan for this goal in 2026 consisting of three major steps:
> - `a-mir-formality`,
> - Implementation,
> - Experimentation.
>
> Some of their subtasks depend on other subtasks for other steps. You can find the details in the updated tracking issue https://github.com/rust-lang/rust/issues/145383. Here is a short rundown of each:
>
> **`a-mir-formality`:** we want to create a formal model of the borrow checker changes we're proposing to ensure correctness. We also want to create a document explaining our model in a more human-friendly language. To really get started with this, we're blocked on the new expression based syntax in development by Niko.
>
> **Implementation:** at the same time, we can start implementing more parts in the compiler. We will continue to improve FRTs, while keeping in mind that we might remove them if they end up being unnecessary. They still pose for a useful feature, but they might be orthogonal to field projections. We plan to make small and incremental changes, starting with library additions. We also want to begin exploring potential desugarings, for which we will add some manual and low level macros. When we have that figured out, we can fast-track syntax changes. When we have a sufficiently mature formal model of the borrow checker integration, we will port it to the compiler. After further evaluation, we can think about removing the `incomplete_feature` flag.
>
> **Experimentation:** after each compiler or standard library change, we look to several projects to stress-test our ideas in real code. I will take care of experimentation in the Linux kernel, while @tmandry will be taking a look at testing field projections with `crubit`. @joshtriplett also has expressed eagerness of introducing them in the standard library; I will coordinate with him and the rest of t-libs-api to experiment there.

## Meeting chat