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

## Attendance

People: Alejandra González, Ding, Alice, Benno, Miguel, Aapo, Josh, Tyler, TC

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)

### `-Cunsigned-char`

Miguel: Context at: https://github.com/Rust-for-Linux/linux/issues/514 -> "`-funsigned-char` (GCC, Clang)."

Alice: I want to think about whether we could fix `core::ffi::c_char` being `i8` when it should be `u8`.

Alice: This came up a few times. The context: in the kernel we pass a parameter to the C compiler called '-funsigned-char'which means that C char is unsigned no matter what. That means rustc and C disagree. We have a workaround, but I was experimenting with generated code and it's a bit of a problem. The signedness is important for control flow integrity. usize and u64 may be considered the same but u8 and i8 are not.

Josh: This seems like something we could do. Didn't we add a parameter to the Rust compiler for this?

Alice: We haven't done anything. We could add a flag that does this.

Josh: I think this is in the same category where what the kernel wants to do is to define important aspects of the target on the fly rather than defining the target completely. Proposal: add an unstable option to the compiler to set whether the char is signed or unsigned (default is the target's value) and use this in core::ffi. And we probably could stabilize the option in the future.

Josh: Caveat, using that option will get you bad things if you compile this and using a preconpiled standard library.

Alice: It's a target modifier.

Josh: Exactly.

Miguel: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/rust/ffi.rs

Alice: I still run into it.

Miguel: We're running to this with `CStr`. We're finally using the standard library's CStr. And it's `as_ptr` returns a pointer to `c_char`.

https://doc.rust-lang.org/std/ffi/struct.CStr.html#method.as_ptr

Josh: Have any of the target modifier options been stabilized at this point?

Alice: Do we have the list of flags somewhere?

Josh: I'm wondering if it might make sense to group target modifiers flags somehow. Give them a common prefix or put them in a differnt option group. In the compiler, right now `-C` means anything that's stable but it's supposed to mean "codegen options". So I'm suggesting that we might want to come up with a broad strategy for all these.

Miguel: Both options are fine. We just need a way to use this.

Josh: There are a couple of stable options under -C that look like they may be target modifiers.

Alice: What about `-C sanitizer`?

Josh: That's not stable yet I think.

Alice: I think that's an interesting idea. Do you want to start a zulip thread? Under Compiler?

Josh: I can do that.

Miguel: There are other options such as red zone, `-C llvm-args`, etc.

Tyler: char, signed char and unsigned are separate types in C. If I were to redo it again, I'd maybe have them separate types in Rust.

Tyler: https://docs.rs/ffi_11/latest/ffi_11/ is a crate that preserves this distinction

Josh: I had the impression that char in c is not a distinct type, it's just whatever is the target's default.

Alice: It's distinct.

Tyler: It's distinct in C++.

Josh: I think in C you can't tell whether something is char or unsidgned char if the target is unsigned char.

Miguel: You can use e.g. `_Generic` to tell. `char`, `unsigned char` and `signed char` are three different types in C:

> The three types char, signed char, and unsigned char are collectively called the character types. The implementation shall define char to have the same range, representation, and behavior as either
signed char or unsigned char.

Alice: You can tell a different with the control flow integrity.

Alice: It would be great if we could define integer types in general. We could define a c_char, but also C enums.

Tyler: I think that would be incredibly useful.

Alice: if we had that, we could also define things like u63.

Miguel: Are you talking about something similar to the `_BitInt(N)` that's in C23? e.g. `_BitInt(63)`. Rust will probably want to have something to represent those (FFI).

Alice: I want a type that's as big as u64 but where the top bit is always 0.

Tyler: Pattern types are one direction for this, `x: u64 is 0..u64::MAX/2`

### Layout of `TypeID`

Question from Danilo: layout of TypeID and size changes? They want to store TypeID in a c struct. Is it okay to have a build assertion in the kernel that the TypeID isn't greater than 16 bytes?

Josh: I would expect the type ID to match whichever it aliases, yeah. The size won't change.

Josh: That seems reasonable. If we want to promise that's a stable property for all time we can ratify it. We could do an FCP for that.

Tyler: Does it need to know it will never be more than 16 bytes or know that C code will break if it ever changes? It would be useful if the standard library published a set of C headers that would represent the Rust types in C. Would that be helpful?

Alice: Yes.

Josh: We've talked about that for a long time.

Josh: The fact that TypeID is 128 bits not 64 bits is an implementation detail to make sure they can generate random bits and not have collisions. It seems inefficient to have the Linux kernel have to pass around 128 bits to do that.

Tyler: I think it's unlikely to grow past 16 bytes.

Josh: It won't grow past 16 bytes. Can we make it smaller?

Alice: If we hardcode it, will it break your CI if we you change it? Because you run our code in your CI.

NOTE: Rust's CI runs Rust for Linux and has been for over a year. Planning to even build it with Clippy warnings as errors.

Josh: Are you saying we don't need to ratify it because Rust for Linux will detect it or because it's already a stability guarantee?

Tyler: It's not a stability guarantee but they can detect a build failure.

Josh: Since Rust for Linux plans to run on stable rust we don't want to break them if we make this change in a later stable version. You need a stability guarantee if you're going to run on stable Rust.

Alice: Either way it seems like something others would find useful too.

Josh: Would it suffice for your purposes that we'd guarantee it's never going to be bigger but it could be smaller?

Alice: That's fine.

Tyler: I like it being a number of bytes because then we'll have a known amount of entropy, rather than dependent on the pointer size.

Josh: I'm sure it's 16 bytes even on 32-bit platforms.

Ding: yeah, [seems to be](https://github.com/rust-lang/rust/blob/4d94478977b5d6c0caa1e66390c6b137520af368/library/core/src/any.rs#L718).

Miguel: If you really wanted to reduce the maximum and we needed an exact side, you could eventually provide a flag so the users could decide and we could have the build assert meanwhile for the exact size.

Alice: I'll have Danilo open the pull request.

Tyler: It's a library guarantee so you want their approval as well.

### All hands

Tyler: I opened a proposal for the council to officially invite RFL to the All Hands. They haven't met since I opened it. https://github.com/rust-lang/leadership-council/issues/236

TC: Do you want for the proposal to invite not just the RfL team but also people like Greg KH?

Tyler: I think that's a great idea.

Miguel: Erik, Greg and I discussed it, and as far as I know Greg will be there (both conf and All-Hands).

TC: From visibility standpoint it's a good look for us to invite Linux leadership. And we can delegate to them to choos who that is. It makes cleaner FCP if you proposed inviting Rust for Linux and leadership for the Linux project. And I can FCP the whole thing.

Miguel: I am happy to provide the invitation in-person / mention the All Hands at the Linux Maintainers Summit (early December, an in-person event, 30 people, with Linus, Greg, et al.). Maybe a few others apart from Greg would like to join.

TC: Last year we invited Linus and Greg. We should do that.

The next council meeting is this Friday 24th.

## `rustfmt`

Miguel: We will use the trailing empty comment workaround for the moment, which formats the code essentially like we want it, in stable Rust. I am in contact with the `rustfmt` team (and `contributors` subteam), I think we will discuss how to move forward in the near future, ideally stabilizing something that provides the logic that `rustfmt` currently runs when detecting the comment (vertical layout) but without needing it.

https://docs.kernel.org/rust/coding-guidelines.html#imports
https://git.kernel.org/linus/4a9cb2eecc78fa9d388481762dd798fa770e1971

## `// PANIC: ...`

Context: https://github.com/rust-lang/rust-clippy/issues/15895

Tracking Issue(s): https://github.com/rust-lang/rust-clippy/issues/15861 and https://github.com/rust-lang/rust-clippy/issues/15896.

Miguel: On the Rust for Linux side we discussed using `// PANIC: ...` comments (please see context above), and I discussed the idea with Alejandra. Alejandra was okay with it and someone (Henry Barker) has stepped up to implement it.

## `rustdoc` JSON doctests

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

Miguel: I tested the kernel patch that Guillaume wrote, I simplified it further to remove all the hacks we had which required 2 scripts and intermediate files (which is one of the big reasons I wanted to have a proper feature for that, apart from the stability itself), and the `rustdoc` feature that Guillaume wrote looks like does exactly what we want now, so we will see if we can stabilize it. I will likely merge the new way in the kernel, but we still need to keep the old way for a while (~2 years?).

## Peter Zijstra asked again on `--emit=noreturn` again

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

Miguel: Peter Zijstra asked about `--emit=noreturn` again. Not a huge priority (he would rather see including C headers from Rust directly). Maybe we can discuss it next week, especially if someone from the compiler team is there.

## 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* since last week (Wesley left a comment above: https://github.com/rust-lang/rust/pull/136597#discussion_r2426704113).
* `#![register_tool]` / https://github.com/rust-lang/rust/issues/66079
* Waiting on [RFC#3808](https://github.com/rust-lang/rfcs/pull/3808)
* Tyler planned to take a look and see if can be resolved with an FCP or will schedule a design meeting
* ?
* -Zno-jump-tables / https://github.com/rust-lang/rust/pull/145974
* Waiting on t-compiler
* FCP missing 2 check boxes
* Anything else?

Tyler: I looked at the RFC, the Crubit team started using it and then they moved it to an attribute instead, it was discoverable, namespaced and hypothetically if you had a declarative attribute macro you could have syntax there. Does that work for your usecase? ANd how urgently do you need this feature?

Miguel: How long do you think this would take?

Tyler: Someone would have to write a new RFC.

Miguel: I will ping Gary.

Tyler: It would imply you have a rustfmt tool attribute namespace, you'd need a rustfmt crate/module in the prelude. I think that makes sense. But to give a little bit of color:

// In crate klint
tool_attr_rules! preempt_count {
    (expect = $range:expr);
}

tool_attr_rules! no_args {
    ();
}

lint_group!(some_lint);
// User code
#[klint::preempt_count(expect = 0..)]
fn foo() {}

#[klint::no_args]
#[allow(klint::some_lint)]
fn bar() {}

https://rust-lang.zulipchat.com/#narrow/channel/213817-t-lang/topic/namespaced.20tool.20attrs/with/544748021

Tyler: For the crubit team it felt too much to require a separate crate for each tool namespace. E.g. one for klint.

Miguel: We'd need one attribute per crate, right? In our usecase we could just add it via `-Zcrate-attr`, thus it would be essentially "invisible" for us either way.

Josh: If we used the approach to register_tool then the tool that would build your code would add it and for people where there was no such tool, people would add the register_tool attribute. There are other approaches (e.g. associate it with a crate) -- that sounds like an overkill.

Tyler: For the register_tool case it would be a Cargo.toml option or a lib.rs attribute?

Josh: Yes, either of those. Or having crate-addr which the Cargo could turn this into.

Tyler: Long term I like the crate approach. The question for me is whether we need a short term stopgap.

Miguel: The crate approach would be fine.

Josh: If we did go the separate crate route, we don't really need a register tool there. A cfg "am I the rust compiler" could ignore the macro attribute and if it's a separate tool, it would handle it.

Tyler: The fact that a macro attribute can rewrite the entire contents of what it's attached to.

Josh: That's a problem I'm working on solving. Assume there's a way to defin an innert attribute with arguments.

Tyler: Great, then we should use that here. My question with the innert attribute is: these are typically used as an attribute macro.

Josh: The default with Derive is that you can define new code but you can't change the existing code. With an attribute you need to parse the code. And I think we need to create an attribute like Derive that may only create tokens but can't modify any existing code.

Tyler: I think in the case of register_tool attribute it would only expand to another inert attribute.

Josh: If you wanted an attribute that doesn't modify the expansion but also have it apply an attribute to the tokens would be harder. We'd have to have another thing that lets you do this.

Tyler: The property we would need is that the attributes are available. It's not quite the same as Derive where you're adding new code.

Josh: Is your primary goal that you want to be able to tab-complete and make them visible to things like rust analyzer?

Tyler: That and also avoiding a new special-cased thing.

Josh: There is a reasonable argument that someone might prefer to define a tool namespace and not tell you the name of any attributes in it. It would be an inconvenience for some tools to have a crate that not just defines a namespace but also every single argument.

Tyler: You can accept a list of TokenTrees.

Josh: A source of tension would be if you always have to update a crate every time you want to add a new functionality to a new tool.

Tyler: That seems like a reasonable constraint to me.

## Lang features

#### `Deref` / `Receiver`

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

*Last time*, Ding fixed the diagnostics and was going to publish the new changeset. Up next was a second feature flag to reflect the old `Deref -> Receiver` one-chain method resolution for comparison and experimentation.

What's the current status?
Ding: I would like to discuss the experimentation plan. There is a little quirk about the coherence check that even `#[unstable_feature_bound(..)]` is not allowing us to work around the `impl` overlaps. Also, the feature gate controling the method resolution would theoretically lead to interesting inconsistency crossing the crate boundaries.

<details>
<summary>The example</summary>

// Crate A
// NOTE: we are not applying `#![feature(merge_chain)]` feature gate here in A
impl<T: ?Sized> Receiver for MyBox<T> {
    type Target = T;
}
impl<T: ?Sized> Deref for MyBox<T> {
    type Target = Inner<T>;
    ..
}
impl<T> Inner<T> {
    fn method(&self) { .. }
}
struct AType;
impl AType {
    fn method(self: MyBox<AType>) { .. } // this is preferred in case `??.method()`
}
let x: MyBox<AType>;
x.method(); // this is resolved to `AType::method`
// === crate boundary ===
// Crate B
#![feature(merge_chain)]
use a::{AType, MyBox};
impl MyStruct {
    fn method(self: MyBox<MyStruct>) {
        // WF error, `MyBox<MyStruct>` cannot receive `method` for `MyStruct`
    }
}
// also...
let x: MyBox<AType>;
x.method(); // this is resolved to `Inner::method` here in this crate

</details>

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

[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

[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, will be merged soon?

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

obi1kenobi requesting more details about the SemVer hazard section: https://github.com/rust-lang/rfcs/pull/3851#discussion_r2430827437

Current status?

Ding: After talking to @cramertj and getting her blessing on the general direction of the RFC, I am starting the implementation on the foundation features. I will post here when the parser code is ready. Meanwhile, I will continue to resolve the questions around the `extern impl` directive.

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

Finished FCP, will be merged soon. Next steps?

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

Oli self-assigned the PR, but no comments since. [lcnr left a comment](https://github.com/rust-lang/rust/pull/146307#discussion_r2425810683) on `walk` not supporting normalization.

Current status?