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

# Lang/RfL meeting 2025-09-24

## Attendance

People: Aapo Alasuutari, Benno Lossin, Gary Guo, Ramon de C Valle, Paul Murphy, Wesley Wiser, Ding

Minutes: 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)

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

(add your notes or announcements here)

## Compiler features

* [merged] Sanitizers target modificators / https://github.com/rust-lang/rust/pull/138736
* [merged] Add assembly test for -Zreg-struct-return option / https://github.com/rust-lang/rust/pull/145382
* [merged] CI: rfl: move job forward to Linux v6.17-rc5 to remove temporary commits / https://github.com/rust-lang/rust/pull/146368
* -Zharden-sls / https://github.com/rust-lang/rust/pull/136597
* Waiting on review?
* `register_tool` / https://github.com/rust-lang/rust/issues/66079
* Anything else?

Gary: Register tool is not in the 2025H2 goal list. https://github.com/rust-lang/rust/issues/66079

Tyler: register tool would be a lang RFC. We could schedule a design meeting for this:

https://github.com/rust-lang/rfcs/pull/3808

Miguel: Is that RFC for `register_tool` or something else?

Tyler: I'll take a look at the RFC after the meeting and if it's ready and simple maybe we can resolve it with an FCP otherwise we'll schedule a design meeting.

Miguel: We need it mainly for klint to have extra and more complex lists. It uses register_tool which is unstable and it would be great to have it stable. It's getting more and more useful so we're looking at making it part of the upstream kernel.

Tyler: It disables an unknown attributes error.

Josh: Does the proposed idea of adding crate attributes for the command-lines subsume this? Can you pass register_tool as a crate atribute?

Tyler: Are the tools you're using a property of the crate? Property of the build?

Josh: First we need to ship the rfc. But once we've shipped that, I've seen an ask for a CLI option. But having shipped the attribute, having crate_attr would solve the problem.

Gary: That's how the RFC was written. It assumes it would be used together with crate_attr.

Gary: There's a new compiler feature discussed during kangrejos: warning on stack size. It's being discussed, may be added as a compiler feature.

Tyler: How do you configure the level at which to warn at?

Gary: There's no way to configure specific lints for Rust currently. So this may be a wider design issue on how you'd pass a configuration to a lint. Clippy allows you to configure them globally. Maybe that's the more broader feature to discuss.

Tyler: Would you be okay with this just being nightly only for now? How important is it to get to a stable version of this?

Gary: It will help the developer experience, but it's not necessary to get a working build. It's more about how to catch errors earlier.

Tyler: My suggest is we uplift the lint into rustc with a flag and that allows us to configure the value.

Miguel: Nightly is fine with us as long as it doesn't change with every release. I'd add it to the required section. It's used in the C compiler. Not urgent but something we're definitely going to use.

Miguel: What's the difference between the clippy and klint lints?

Gary: clippy sums up the sizes of the local places. If there are a lot of places with non-overlapping lifetime, Clippy would say it can stack overflow, even if it doesn't. Clippy is more conservative, klint is more precise. LLVM already has this feature.

## Lang features

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

#### `Deref` / `Receiver` status

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

*Last time, Ding was working on a document that would explain how PR [#146095](https://github.com/rust-lang/rust/pull/146095) would change the feature.*

Tomas: Any updates?

Ding: I am aiming to publish short changes report this week, I had limited bandwidth last week but I have been fixing the shadowing diagnostics.

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

Tomas: There were a couple more comments since the last time. Where are we with the RFC?

Ding: I have proposed to Taylor C. about a possible future extension to allow opting in with probing for existing `impl Supertrait`s, but without guarantee of complete avoidance of overlapping yet. The bottom line is that we should make `impl Supertrait` auto-filling by default for simpler compiler design. The RFC is still fresh as of writing and pending reviews.

Ding: Maybe we can put in examples from the crate refactoring on the `kernel` crate as one of the motivating example.

Ding: Getting reviews, I'm resolving the concerns one by one.

Ding: I saw a PR regarding CoercePointee that was marked as not so related. It was give a t-lang approval. They were asking for a test case in which they discovered a corner case they didn't cover. Would that revoke the t-lang approval automatically?

https://github.com/rust-lang/rust/pull/145277

TC: We have an ongoing FCP, we've got four boxes checked. Are you asking whether your final comment invalidates the FCP? Is this related to the example theemathas came up with? What's the case we're talking about?

Ding: We're talking about nnethercode's request for a test case to be covered. And Ralf's comment too. And the last case in your example.

TC: The question is whether we still want to do this even though if you do the `as` cast it's... you're saying the final example in my code is still going to drop?

Ding: Yes. I agree with Ralf that the fix is not comprehensive. But my argument is that we can get this in first and open an issue to discuss the plan for the final fix.

TC: And your conjecture is that the final test in my code should not drop?

https://github.com/rust-lang/rust/pull/145277#issuecomment-3308794668

Ding: Yes. You have a constant behind the `as` cast, it's still a value. At the moment the how the MIR is being built out of THIR is not very satisfactory

TC: I'm trying to distinguisg the `as` cast from other cases to see if it needs a special treatment. If we do an as cast, it doesn't change the special behavior for `Copy`, right? Right. So this special behavior should match that special behaviour. That's how I'd reason about it.

TC: This doesn't make it harder to fix the other one, right?

Ding: I think so. I'll have to talk to Ralf to get more opinions on the better way to build the repeat expression here. The idea is that the build process is not analyzing the repeat expression hard enough.

TC: So one option would be just fixing it in this PR. Another option is doing it later. Sounds like maybe you need to talk with Ralf and the othres to see what the best path is here. Is that right?

Ding: Yes.

TC: Tyler, Josh does that sound right to you?

TC: The constant on the left-hand-side of the repeat should be handled the same way as the repeat length operand. And Ding is saying there's one edge case where that isn't the case. And whether that would invalidate the FCP. And I don't think it does.

Tyler: I agree.

Josh: Yes, unless there's something that makes this harder to fix later.

TC: OK, Ding, you have your answer here. As long as this doesn't make it harder to fix this completely, this doesn't destabilize our FCP.

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

[Lang design meeting scheduled for 2025-10-08](https://github.com/rust-lang/lang-team/issues/347)

Tomas: Anything else to discuss now?

Gary: Nothing for now, I will resume impl work after design meeting.

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

Benno posted a comprehensive update to the goal tracking issue: https://github.com/rust-lang/rust-project-goals/issues/390#issuecomment-3326839670

Last time: Benno opened a PR for field representing types: https://github.com/rust-lang/rust/pull/146307. Seems to be receiving plenty of comments.

Tomas: Where are we now?

Benno: I'm getting good reviews from lcnr. Might take a bit longer, lcnr is at a conference now and will take some time off later. They suggested someone else may take a look.

https://github.com/rust-lang/rust/pull/146307#issuecomment-3323415682

#### NUL-terminated file names with #[track_caller] aka `feature(file_with_nul)` (`file_as_c_str` method)

Everything seems to have been merged:
* [Tracking issue](https://github.com/rust-lang/rust/issues/141727)
* [Implementation PR](https://github.com/rust-lang/rust/pull/145928)
* [Stabilization PR](https://github.com/rust-lang/rust/pull/145664)

There's now an open Release Notes issue: https://github.com/rust-lang/rust/issues/146716
* Alice, you're being asked to add a draft there

Anything else to do here?

Tomas TODO: Alice won't make it today. Look at the [release notes process](https://forge.rust-lang.org/release/release-notes.html#preparing-release-notes) see what's actually needed here.

Tyler: Generally they ask the PR author to draft something and the release team will compile them and edit them a bit. They just generally want to rely on the author's context.

Miguel: A bot creates an issue.

Tyler: Sometimes the release notes are a one-sentence summary. But generally you want to include new stabilizations and any behavior that might have changed.

Miguel: They're really useful.

Tyler: You can look at the releases.md file in the repo and grab some examples there. It should be ideally written by Alice -- they're asking the PR aouthor to make sure they're not missing any context.

### Other topics

Ding: do we revoke t-lang approval https://github.com/rust-lang/rust/pull/145277

Aapo: Do you use a lot of inline assembly? And do you use for parameters you'd pass on the stack? AFAIK Rust inline assembly doesn't support values offset on the stack.

Gary: You're talking about memory operand, right?

Aapo: Yes.

Gary: I think we do want memory operand eventually, but it requires some design and implementation effort.

Miguel: https://github.com/Rust-for-Linux/linux/issues/354 (some context)

Miguel: Alejandra said she was committed to supporting Rust for Linux in the kernel. She'll put some time to support clippy in the kernel.

Josh: She's awesome and her work on clippy is great. I'm excited to see her Rust for Linux stuff going forward.

Miguel: She'd love to have some official commitment from the clippy team. She'll try to speak with them.