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

## Attendance

People:

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

(add your notes or announcements here)

Miguel: we've raised the point about no_panic again. Having a way to avoid panics. People keep bringing this up and sooner or later we'll have to open this can of worms. There's Alexandre from Nova they seem pretty keen to discuss this. Maybe Nvidie might be able to put some resources in there. (Related mailing list discussion: https://lore.kernel.org/rust-for-linux/CANiq72=nGbziZCKt=AneE_vXw76i=[e-mail]/)

Miguel: one way is via an attribute that would compiler check that it won't panic. Maybe on the translation unit check there's not panicking. The check overflows are wrap, but can we have "report on continue". We'd first need to understand what's possible on rust side. It keeps coming on the mailing list.

Tyler: For the no panic stuff if you can get someone to commit resources that would be great. A project goal for the next year would be great. We can start having conversations before that. The best thing would probably be to guarantee within a function there's no transitive panic. But we could talk about translation unit / per-crate check.

Tyler: Overfolw handling is probably going to be handled separately. It's easy to add an overflow handler that reports and continuoes. In Rust code today we can't do that for panics. So we'de have to take a different approach.

Miguel: Mara was working on the overflow thing. I think Mara wasn't thinking of replacing the overflow return value. But there was a case for maybe we could do saturation instead. For refcount we saturate as well. For slice indexing there's always the discusison of: the kernel doesn't want to crash. Mayb what we want is having a safety comment, something that forces us to do it there. You could also return a default value. The policy for C is "if you know a condition is true and you really know it, you don't need to check. But if you're not 100% sure you shouldn't add a panic, you should do an if".

TC: Has anyone mentioned effects yet? `nopanic` has been part of the discussion there. Have a look at t-lang/effects channel. Essentially if we had a system to mark functions with the set of effects that they express in a similar way to what we do with unsafe (which maybe isn'n an effect) or const (a negative effect) or async. If we had some way to express that a function may panic, we could check statically that within some context that nothing will panic. We could have some unsafe opt-out in the form of a way to unsafely bring the `panic` effect into scope.

TC: Another angle is what's been happening with the `target_feature(enable = ..)` work. That has a similar shape to what we'd want here. It would be nice if if we could unify this work. Talk with veluca93 who has been working on this. And be on the lookout for the interaction with traits functions, refinement, etc.; that's the hard part.

Aapo: On the arithmetic panics I've had the need where I know that this place doens't panic but I'd love the compiler to understand it as well. I've had to go to assembly to verify that.

Alice: All these concerns were: in this region of code of not having panic and dealing with traits. This reminds us of the k-lint plugin -- that does' similar stuff.

Gary: k-lint didn't do things like panic. Basically after you compile something to a binary you know about panic. It's not something you know on the MIR level.

Alice: Depends if you want to check before or after the optimization. I didn''t mean k-linwt does panics, more that the mechanisms are similar.

Gary: In some cases it seems siilar to our build_error mechanism.

Alice: The analogy of target feature work, the language support, that's what I'm talking about.

Tyler: One big uqestion is whether you want to annotate every step of the way. Or you call this function here and nine steps down the call steps the funciton can panic. There's a practical consideration here. Modeling it as a negative effect like const sounds nice.

Benno: It could just work for us if we forbid all panics essentially. We don't need the annotation because we don't want panics at all.

Alice: In practice, you're going to end up wicth parts of the kernel that will panic.

Benno: But what I'm saying is that Rust panic shouldn't be able to called.

Miguel: There's not a single solution. In our cases maybe we want to customize the indexing itself to d w

Tomas: Clippy lints?

Miguel: We've disccussed this. Unclear if they cover everything we need. And they wouldn't guarantee everythning. (Related discussion in the mailing list: https://lore.kernel.org/rust-for-linux/CANiq72nJiJ4K6jy17x-YRYnJpjqTnohYWvoFrLkYQp0X4tLL=[e-mail]/)

Tyler: There's a chance that's good enough in practice. But the dependencies would be the main thing you'd have to worry about.

Miguel: Sometimes we want to panic anyway but that's very rare. Having a way to force people to write something similar to the SAFETY comment would be nice.

Tyler: That could be impplemented as a clippy lint.

Miguel: Does clippy know if an expression or a statement can panic?

Tyler: It's not going to be exhaustive.

Miguel: Let me contact Alexandre.

## Compiler features

* Sanitizers target modificators / https://github.com/rust-lang/rust/pull/138736
* Landed
* Add assembly test for -Zreg-struct-return option / https://github.com/rust-lang/rust/pull/145382
* Landed
* -Zharden-sls / https://github.com/rust-lang/rust/pull/136597
* Waiting on review?
* CI: rfl: move job forward to Linux v6.17-rc5 to remove temporary commits / https://github.com/rust-lang/rust/pull/146368
* Landed during this meeting.
* The kernel-side commits landed, removing the need for the workarounds for https://github.com/rust-lang/rust/pull/145928 and https://github.com/rust-lang/rust/pull/144443.
* Anything else?

## Lang features

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

TC: Ding has a proposal on unblocking 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/

Tomas: Any updates?

Ding: I promised a document to explain how this PR [#146095](https://github.com/rust-lang/rust/pull/146095) would change the feature. I am working on the document.

Ding: We need a bit more effort in recovering some of the diagnostics code and error detection for the feature. I'm doing that right now.

Tyler: I read your doc, my question is: is there a maximally forward compatible version of doing this where we could disallow divergent deref and receive impls? Would there be something preventing the same type from ipmlementing the same type for deref and receiver with different types?

Tyler: Currently we have the balnket impl from deref to receiver.

TC: It's that blanket impl that's blocking the arbitrary self types stabilization due to how that prevents using `Pin<_>` with arbitrary self types. We've got to get rid of that blanket impl to do the stabilization we want to do.

Ding: we also talked to ProgrammerJake who also agrees those two features are orthogonal to each other, but due to historical reasons the traits were overalpping.

Arbitrary self types used to work exclusively with the Deref trait.

Tyler: I can see the arguments for them being separate traits. It would make the edcision easier if we had the ability to make that decision in the future.

TC: I don't think it'd be clean to do it just by trying to enforce that the two associated types match. Consider that there could be generics in play. You'd have to prove that the types would be the same for any possible instantiation of generics. Probably instead we'd have to create a supertrait with the associated type so we could be sure that there's only one type, but then that brings us back to needing to block this on the lang work needed to be able to restructure trait hierarchies. What's exciting with Dings' proposal is we're not blocked on that. But, of course, it's reasonable too that we could decide to continue to block on that, though that could block it for a long time.

TC: The next step, in my view, is having a vibe that this is plausible. Then we can let Ding land this in nightly so we poke at it. It's still all unstable.

TC: Then, later, yes, we'll probably need to make a hard decision about what door we want to walk through.

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

Tomas: Any updates?

Ding: I am editing the RFC. The reviews have pointed out that some examples are not complete. Taylor C. pointed out a problem with mandatory `extern impl` even when downstream supertrait `impl`s are present. I am proposing to weaken the requirement for certain cases to make the RFC more appealing for the trait evolution use cases.

Ding: Taylor Cramer was the early proponet of trait evolution. Supertrait/butrait were established later. We might run into unhappy users who were implementing both subtrait and supertraits. They may be penalized by having to insert this extern impl. I'm trying to understand the penalty and see if we can make potential users happier without requiring to insert this declaration. Working on final details of the proposal. Alice, I'll include you in the discussion.

Tyler: This is related to the Receiver/Deref discussion. If this RFC gets approved, is it straightforward to implement?

Ding: It's more complex than the arbitrary self type deref separation. I have a branch where I'm working on this but it'll likely take much longer to land this behind a feature gate.

Tyler: We could potentially do this and only allow deref and receiver to use it. You still think like this would be a bigger project?

Ding: I think we can land a very weak version of the proposal. That might work out but I haven't tried it yet. We could have layered feature gates.

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

Alice: No news.

Gary: Currently preparing for Kangrejos, going to probably work on it after.

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

Last time: Benno and Ding had an experimental implementation in: https://github.com/BennoLossin/rust/tree/field-projections. They planned to clean up the `todo!()`s in the code next.

Tomas: Where are we now?

Benno: We were able to clean up the `todo!()`s and I opened a PR: https://github.com/rust-lang/rust/pull/146307 :rocket:

Current status: waiting for people to have a look.

#### NUL-terminated file names with #[track_caller] aka ~~`file_with_nul`~~`file_as_c_str`
[Tracking issue](https://github.com/rust-lang/rust/issues/141727)
* Entered final comment period two days ago: https://github.com/rust-lang/rust/issues/141727#issuecomment-3265710816

[Implementation PR](https://github.com/rust-lang/rust/pull/145928): merged.

[Stabilization PR](https://github.com/rust-lang/rust/pull/145664): FCP completed, disposition to merge

### Other topics

Ding: Alice, Benno and I talked about the next steps on in-place initialization. We concluded we'd like to put some of the effort into looking at the outpointer proposal. I'd be writing some documents to describe how we're going to realise in-place initialization with outpointer. Starting with a concrete explanation of the lang feature and potential impact on the borrow check rules. These should be small. And I'd formulate a porposal after Kangrejos.

Tyler: I think there's more discussions to be had but it's great that you're looking at it and making progress. Looking forward.

TC: Looking forward.

TC: How many kernel maintainers who aren't RfL are going to show up?

Miguel: We have Greg for example. And a handful of other maintainers and a few developers. We'll have people from the Nova project. We'll have people from GCC as well as GCC Rust. We'll have someone from Debian. We'll have two from Coccinelle for Rust. LWN will be there as well.

TC: Let's try to interview Greg and the Nova folks.

Miguel: I'll reach out to the interesting people that come to mind.