---
title: "Lang/RfL meeting 2026-01-28"
tags: ["T-lang", "design-meeting", "minutes"]
date: 2026-01-28
discussion: https://rust-lang.zulipchat.com/#narrow/channel/410673-t-lang.2Fmeetings/topic/Rfl.20meeting.202026-01-28/with/570590302
url: https://hackmd.io/uJDBdVerTGK6Fo1Vyl2R2A
---

# Lang/RfL meeting 2026-01-14

## Attendance

People: Alejandra González, Alice Ryhl, Andreas Hindborg, Boqun Feng, Daniel Gomez, Gary Guo, Joshua Liebow-Feeser, Jack Wrenn, Miguel Ojeda, Nadrieril, TC, Wesley Wiser, Xiangfei Ding, Tomas Sedovic

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)

### Removing the `likely`/`unlikely` hints in favour of `cold_path`

Trevor Gross proposed stabilizing `core::hint::cold_path`: https://github.com/rust-lang/rust/pull/151576. Trevor also aims to remove the `likely`/`unlikely` hints as the same behaviour can be expressed through `cold_path`.

Question for Rust for Linux: are you depending on these hints? Would you have any issues with switching to `cold_path` instead?

Note, that it's possible to implement likely/unlikely in terms of cold_path if there's a usability concern: https://doc.rust-lang.org/nightly/std/hint/fn.cold_path.html

Miguel: Kernel uses likely/unlikely the most on the C side. But we don't use these in Rust. Stabilising cold_path is good enough for us

Tyler: Scott made the point that expressing likely/unlikely in terms of cold_path, was heavily dependent on MIR-inlining. I'd just comment that we might want to keep them long-term.

Alice: We don't use them today but there are places where we arguably we should use them. These code patst mirror the C implementation so it'd be nice to use the same pattern. At some point I lookded into C-to-Rust for calling C functions from Rust. I think it would still be nice to have likely/unlikely. Using `cold_path` would require an else branch potentially.

Gary: Mir-inline causes a lot of issues with interactios around Clippy. Clippy disables inlining and sometimes it shows an issue that goes away with a regular build.

Tyler: I think for now you can implement likely/unlikely and if it gets stabilized or adds an intrinsic and you can remove it then.

### Rust All-Hands

Miguel: We have Greg KH joining and two other maintainers said yes. We're expecting around 8-9 R4L-related people.

***

Miguel: two sets of guests today.

### Niche optimizations

Andreas: link to the zulip thread:

[RfL Zulip thread](https://rust-for-linux.zulipchat.com/#narrow/channel/288089-General/topic/Optimisation.20.20for.20enums.20of.20pointers.20to.20aligned.20objects/with/569743750)

Andreas: There are some datastructures in the kernel, we had a datastructure we're trying to implementin rust. The C code uses shifts and ors to embed data in lower bits of the pointer. Can the Rust compiler learn to use parts of pointers that aren't necessary to figure out where a pointer is pointer to encode enum discriminant?

Andreas: I talked to Ding about this, he thinks there's an opportunity for this. There are other options e.g. the page from 0 to 4k-1 is never maped. No pointer can ever point there. We have a list of ~4k values we could use for something like this.

Tyler: The difficulty with embedding niches in the pointer is: you can have a reference in the pointer, someone could read the pointer and obserne the niche. Rust mostly does this by embedding niches in an invalid value of a type. One thing you could do is have a special type htat has a niche and always mask every time to dereferences it.

Tyler: That's not expressible in stable Rust.

Andreas: Does that mean I could pick this up today?

Tyler: If you look at the `NonZero` struct whatever they're doing to create a niche at 0. For regular integers you can specify range. Pointers are specials due to provenance which makes them complicate.

Josh: The scalar valid niche would allow you to embed things but not the alignment niches. Pattern types would potentially address that.

JOsh: In theshort term: there are functionsn on pointers that would allow you to embed and point out pointer bits without breaking provenance. The result is not a dereferencable pointer and you need to mask them off before dereferencing. That said, to experiment with this today (maybe in Stable even) is to make an opaque new type that embeds a reference and embed the low bits and store them, provide accessor method to set/low bits and have a `Deref` for the type that makes the bits and dereferences. That won't be a pointer, but it's a type that you can dereference.

Andreas: We've done that. That obviously require unsafe blocks. The reason we're asking for the compiler to do this is: we're rewriting this datastructura and one of the reasons for the rewrite ismemory safety. Adding unsafe would partially defeat the purpose.

Josh: That was the answer to what you could do today. Which you've already done. To do this nicely and safely you'd need pattern types etc.

Tyler: When you're saynig you want something safe: do you want the implementation of this wrapper type itself tobe safe? Or the use to be safe?

Andreas: I want to writ ean enum definition and I want the compiler to know that the type is aligned and know that it can encode the discriminant in the pointer.

Andreas: I'd check my type with an attribute that says this is always aligned. When we store into this, we do a compile-time check for the alignment. I'd tell the compiler that this is always aligned and the rest would happen automatically.

Alice: Another application of this same thing would be: our pointers don't have the top bit set. So if you have a top bit that's an error. So you could have an integer type that's always isize and you could have a `Result<pointer, error>` and it's always the pointer.

Miguel: It is done all the time on the C side (`ERR_PTR` etc.).

Alice: We want the top bit to be set in the error code and not set otherwise

Josh: We don't have a way to give this information to the compiler.

Adreas: Is using the top bits similar to the the bottom page? The alignment is a bunch of holes in the range. Those two are differnt to implement.

Daniel Gomez: NonNull is one of the cases available for niche optimization. But for `char` you have unicode range that goes to FFFF and the rest of the range can be used for niche optimization. What we're asking is for a way to customize that particular range. We want to make explicit that a particular type has a specified range.

Tyler: If you look at the definition of NonNull, it uses: `#[rustc_layout_scalar_valid_range_start(1)]`. That wouldn't work with the alignment though.

https://doc.rust-lang.org/stable/src/core/ptr/non_null.rs.html#76

Andreas: I think we could use the top bits for this particular use case.

Nadri: Havign more niches is what we really want and it's waiting on implementation. We're waiting for someone who's familiar with layout information. There isn't any design needed.

Andreas: Is this tracked anywhere?

Josh: Last I saw, this was tiedtogether with Oli's work on pattern types. And I think that's blocked on human (oli)'s bandwidth. So everyone's eager for it to happen, we have an idea of how we want it to happen. I suggest someone wanting to do that should talk to Oli.

Andreas: If we really wanted to become the compiler engineers, we can go nuts?

Miguel: It would be a nice improvement on C. It would be nice if we could get something for the next Debian stable for Rust. If we could get some money to work on that from some companies from the Linux kernel side who are interested, I could try to ask getting companies to do this.

Benno: I want to focus on what we can do in the immediate future: you're saying you don't want to implement with unsafe rust becaues it looks like it's not making the C side safer. Is that the only concern? If so, this could be creating a macro library that creates the unsafe code for you.

Andreas: That's a good idea.

Josh: I think there's short, medium and long term here. Shortest term: taking some sensible abstraction for pointer to do stuff with and put it in Rust for Linux, it would be part of unsafe core that the driver could use safely.

Josh: The medium-term thing: the specific case you're describing for enums is simpler and we should treat that accordingly in the language. You already can't get a reference to an enum discriminant today. So we don't need any move only reference for that. Any type that has a niche in it we have ability to optimize. There's nothing fundamentally stopping us to doing more complex optimizations other than compiler work.

Josh: For any enums where the layout isn't guaranteed (`repr(Rust)`) we could experiment, implement, roll back if needed.

Andreas: That would be cool.

Ding: I'm looking forward to this for 2 reasons. (1) we'd like to have this compiled this to a meaningful automation. We could do this with macros, but that's manual labour. Having this would probably solve this side of the problem and reduice cognitive load. (2) it also gives us a language feature that's not very magical. It feels right.

Daniel: Putting this aside in a macro or library so you can audit it doesn't solve the problem itself. This is part of the code path. Every time you're walking the tree. It's not the same as putting the code inside a macro. It's really important for the 90% of the code.

Andreas: What we're doing here is a probe into where we can deploy Rust into Kernel. The XArray is one of the most important parts of the kernel. It's where we're handling paging. We're not looking to deploy this in the mid-term. It's long term, we ened the design. But even then, it's important to look at this now, it's important to look into the boundaries of putting Rust into kernel.

Miguel: Could we put this behing a feature flag?

Tyler: The core functionality shouldn't go away.

### Vendoring zerocopy

Contacts: [e-mail] / [e-mail]

Miguel: We've been considering vendoring zerocopy. We've vendored a big library `syn` in the past. But it would be the first one that's not for proc macro but rather an actual library for the kernel. I have a few questions.

Miguel: How often would we have to update this? How often does it change? I also asked about this coming to the language eventually (project-safe-transmute)? How much of this wolud gho to the standard library.

Miguel: We would be happy to have you be maintainers in the kernel if you're interested.

Joshua: regarding update frequency, from othre folks vendoring this (fuchsia, google3) -- it's usually just whenever they need a new feature.

Joshua: Regarding backcompat, we use semver. We're at 0.8. Any future 0.8.x will be backwards compatible. We intend to introduce 0.9 eventually but we're putting a lot of effort on making this stable. When we had a breaking change from 0.7 to 0.8 we had a guide.

Joshua: In terms of who's on the maintenance list: we're hesitant to take on new maintenance responsibility. If it's easy for you to vendor periodically.

Miguel: It's not so much about copy/pasting files. But if we need to update some callers

Joshua: If that ever happens, we're usually happy to help with that.

Miguel: We can tweak it in the kernel.

Joshua: on 0.8 you should never have to update callers. There are cases where we built features specifically for consumers. We'd be happy to do similar things for the kernel. We could provide doc-hidden features that we'd promise to keep for you but not support otherwise.

Miguel: ideally for Rust would be to not use any libraries other than the Standard library of Rust. What could we get from Rust stdlib. What do you thing would lang stdlib

Jack: Don't hold your breath. A lot of what we're doing is essential API work. You shouldn't anticipate that zerocopy will be the facade you'll use for transmutes for a very long time. We're identifying the really low level core abstractions that would make these safer. You'll get the compiler safety expressivity improvements over time. And eventually there may be a tiny fraction of zerocopy. We're years from away from that.

Miguel: It would also be useful to know if there's a part of zerocopy that wouldn't likely change at all. Kernel needs maintainers for everything. If you think theres' a set of APIs you don't think will change much,

Joshua: At minimum, you can always use 0.8. Since you don't have other 3rd party dependencies, you don't have to worry about another dependency forcing the upgrade. Most of the thnigs will either stay or have a backcompat polyfil. Any breaking changes we make are going to eb on how you spell the code. We'll never remove functionality.

Miguel: Thank you.

Joshua: We have a few features on shortterm roadmap: we're working on in-place initialization. We expect to have safe partial in-place initialization. We also have other feattures and we're always happy to prioritize featuers our users want.

Benno: in the kernel we have pin-init crate to safely initialize things not only in-place but also directly pinned. We're also working on a project goal to bring this into the language itself. I'd be interested to talk about how you plan to do this.

Miguel: For me it would be really imporant for the rust project to support this

Joshua: Agreed

Aapo: Agreed

Joshua: We think of this as being an experimental place to figure out outside the compiler to tweak things before getting the shape right

Josh: I do hop ewe get features related to this both in the language and libraries where appropriate. If you're blocked on needing more help please reach out and call attention to that. If you're at any point blocked on needing a vibe check, language feature, library feature.

Joshua: I'd love to set up a former communication channel.

Josh: if you're interested in doing short incerlock with the Project. Project goals are one way to do this. If you feel you're to a point with zero copy and project-safe-transmute where this would benefit with a project goal, it would be a great way to align that.

Joshua: the top ones is unsized MaybeUninit and

Linux currently has its own `FromBytes`/`AsBytes` traits. Should we vendor zerocopy?

* What about [`MaybeZeroable`](https://rust.docs.kernel.org/pin_init/derive.MaybeZeroable.html)?
* What about the kernel's missing `impl IntoBytes for *const/mut T`?

Open questions (from @joshlf/Alice):
* Maintenance strategy? Proposal: Vendor, and only update when a new feature is needed (or periodically if desired)
* Automatically apply derives to all bindgen'd types? Proposal: You probably want to maintain a (possibly compressed) mapping from type to list of traits. We do this in Fuchsia to good effect.
* Could zerocopy derive macros silently fail (allow compilation to succeed, but not emit an impl)? We could support this if need be, with caveats for code which needs `trivial_bounds`.
*

## 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)
* 2025-12-03: Tyler was going to fully review the RFC again and then look at this.
* Tyler: I proposed FCP on the RFC. It's lang nominated, it's on the lang team to pick it up and discuss. If it's urgent I can bring it up
* [`-Zdebuginfo-compression`](https://github.com/rust-lang/rust/issues/120953)
* Wesley: I'm looking at stabilizing https://github.com/rust-lang/rust/pull/150625
* Josh: This is one more reason to encourage the Trifecta Tech folks who are working on a zstd-rs in pure Rust. This came up for Python as well.
* Miguel: Linked to our list.
* Miguel: Inside the kernel we have a copy of the C library. Eventually the Rust one could be proposed for the kernel -- some companies/users may want to use a memory-safe version.
* Josh: It would be interesting to consider zlib-rs in the Kernel to have an option to use it if you're already building with Rust. It is faster.
* Miguel: If it's close to ready, it could be a potential RFC.
* Gary: If the speed is die to vectorization, then it doesn't matter in the kernel context?
* Josh: The implementation is production ready and it should be configurable to be used in the kernel
* Gary: We haven't figured out how to make part of the code use hardfloat yet for Rust.
* Josh: That's a good point. But the rust code in question is conditional on target features. Might be a good case study.
* [`-Zdirect-access-external-data`](https://github.com/rust-lang/rust/issues/127488) (loongarch, and maybe x86_64 soon too)
* Gary: Some discussion in https://rust-lang.zulipchat.com/#narrow/channel/425075-rust-for-linux/topic/New.20relocation.20model.20for.20relocatable.20code.20but.20static.20data/with/566044955
* Wesley can take a look
* Miguel: https://github.com/rust-lang/rust/pull/150494 was merged a few days ago.
* `-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)
* Waiting on author since 2025-12-03: https://github.com/rust-lang/rust/pull/136597#discussion_r2586642641
* TODO Tomas to ping Andrew
* [`-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)

### Other

#### `--emit=noreturn`

background: The kernel use `objtool` to analyze the object files. It checks whether things are correct on the structure/assembly level.

These are checks Miguel has to manually: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/objtool/check.c#n186

Gary: it's on my radar to improve objtool on handling of noreturn, but I haven't had time to look at it yet.

Miguel: I think the last time it was discussed was https://lore.kernel.org/rust-for-linux/[e-mail]/, but the last patch that came up was in late December: https://lore.kernel.org/rust-for-linux/[e-mail]/, so it keeps coming up.

#### build-std:

Context RFC was approved and merged https://github.com/rust-lang/rfcs/pull/3873

First two feature RFCs are in FCP:
- build-std: always https://github.com/rust-lang/rfcs/pull/3874
- build-std: explicit dependencies https://github.com/rust-lang/rfcs/pull/3875

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

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

No change from 2026-01-14: Implementation is complete; waiting for code reviews. https://github.com/rust-lang/rust/pull/138618 (the merge conflict is just for the feature gate)

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

## Other topics

## Meeting chat

Alice Ryhl
8:02 PM
https://hackmd.io/uJDBdVerTGK6Fo1Vyl2R2A
8:04 PM
https://hackmd.io/uJDBdVerTGK6Fo1Vyl2R2A

Gary Guo
8:09 PM
It's also just a normal unstable feature, it's core_intrinsics
*not a normal*

Joshua Liebow-Feeser
8:14 PM
If there's time, we could also discuss in-place initialization, which we're working on supporting in zerocopy.

Boqun Feng
8:14 PM
of course, we make time

Miguel Ojeda
8:16 PM
Maybe let's split the time in at least 2, so ~15 minutes for each topic?

Josh Triplett
8:17 PM
(And, similarly, reserves memory to ensure that -errno is never a valid pointre.)
*pointer

Gary Guo
8:19 PM
rustc_layout_scalar_valid_range_start

Tyler Mandry
8:20 PM
https://doc.rust-lang.org/stable/src/core/num/nonzero.rs.html#127

Joshua Liebow-Feeser
8:20 PM
You could hack this manually using: https://doc.rust-lang.org/beta/std/ptr/fn.with_exposed_provenance.html / https://doc.rust-lang.org/beta/std/primitive.pointer.html#method.expose_provenance

Gary Guo
8:20 PM
no need to use that, you can use map_addr

Benno Lossin
8:21 PM
https://rust-for-linux.zulipchat.com/#narrow/channel/288089-General/topic/Optimisation.20.20for.20enums.20of.20pointers.20to.20aligned.20objects/near/569752702

Josh Triplett
8:24 PM
I see, you want this automatically for enums.
You *already* can't get a reference to the discriminant (in safe code), so that might be doable.
(sooner)

Aapo Alasuutari
8:25 PM
Oh boy; I really want to use the top bit for error signaling in my JS engine.

Aapo Alasuutari
8:27 PM
Yup, agreed

Josh Triplett
8:28 PM
All of these are in the same category, but some are easier than others:
- using pointers in the NULL page
- using pointers in the top page (-errno)
- using high bits of pointers because you know e.g. kernel pointers always have high bit set or user pointers don't.
- using low bits of aligned pointers

Tyler Mandry
8:28 PM
#[rustc_layout_scalar_valid_range_start(1)]
https://doc.rust-lang.org/stable/src/core/ptr/non_null.rs.html#76

Andreas Hindborg
8:33 PM
I need a guarantee on the size. I don't care where the info goes.

Gary Guo
8:34 PM
I see. I was under the impression that you need it to match exact what XArray wants in the discussion in the list

Miguel Ojeda
8:36 PM
(We should wrap it soon for the other topic)

Josh Triplett
8:37 PM
(we should)

Gary Guo
8:37 PM
For enum, you can only stuff the discriminant, but for example `enum Foo { A(AlignedPtr), B(AlignedPtr) }` would still require move-only fields.

Gary Guo
8:43 PM
project-safe-transmute

Jack Wrenn
8:43 PM
I can speak to p-s-t! :)

Jack Wrenn
8:46 PM
re upgrading docs, see our last major announcement: https://github.com/google/zerocopy/discussions/1680

Gary Guo
8:47 PM
0-ver rules :)

Aapo Alasuutari
8:56 PM
Agreed!

Benno Lossin
8:57 PM
a faster user-implementer feedback loop

Miguel Ojeda
9:00 PM
That would be great indeed

Miguel Ojeda
9:02 PM
Thanks Josh & Tomas for that, it would be great to get it moving.

Josh Triplett
9:02 PM
https://rust-lang.zulipchat.com/#narrow/channel/216762-project-safe-transmute/

Jack Wrenn
9:03 PM
#pst is a good place :)
vpm-ujbq-tio