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

# Lang/RfL meeting 2025-07-30

## Attendance

People: Alice Ryhl, Benno Lossin, Boqun Feng, Gary Guo, Josh Triplett, Migueel Ojeda, Ramon de C Valle, Tomas Sedovic, Wesley Wiser, Xiang, TC

## Tracking

[Tracking issue](https://github.com/rust-lang/rust-project-goals/issues/116)

## 2025H2 Goals

* Lang features for RfL: https://rust-lang.github.io/rust-project-goals/2025h2/Rust-for-Linux-language.html, https://github.com/rust-lang/rust-project-goals/pull/347
* Compiler features for RfL: https://rust-lang.github.io/rust-project-goals/2025h2/Rust-for-Linux-compiler.html, https://github.com/rust-lang/rust-project-goals/pull/346

Tomas: For the next time I plan to restructure the agenda based on the new H2 goals rather than what we have in the current tracking issue. Does that make sense?

Miguel: Wahtever makse sense.

Alice: Are we have any minar blockers that we need to resolve before stabilization?

Miguel: There's a lot of things like this that I'm not sure whether we want to track. There are some nice-to-have issues. E.g. being able to check overflows but report message in a kernel log but not panic.

Tomas: I don't think we need to link every single missing feature/bug but we'd like to link a complete list from the tracking issue so we can get the full view.

## Updates from Ding

I am checking in on two items.

### Supertrait items in subtrait `impl`s, `arbitrary_self_types`

I made a small milestone this week. After patching queries for associated items and HIR item container, I have my model `Deref`/`Receiver` trait working, so much so that the trait impl checks are passing on `Receiver::Target` item in a `Deref` impl, according to the logs.

The next item I am working on is to patch a query that collects RPITITs. This query works by inspecting a real HIR `TraitImpl`. I am first trying out supplying actual `TraitImpl` instead of a `Synthesis`ed HIR node. If I see no success, I will lightly refactor this query so that it does not rely too much on HIR.

### `(p)init`

I have
- figured out how to allow a weak version of `Init` unsizing and type-check `T: impl Init<[A]>` given `T: impl Init<[A; _]>` and the `<_ as Init>::Error` projection obligations, too;

fn unsize_me<T>(x: impl Init<[T; 8]>) -> impl Init<[T]> {
    x // <-- this type-checks,
// ... and MIR will pick up the unsizing to select a shim to return a `usize` metadata instead of just `()`
}

- made a little bit more progress on MIR building; this indeed requires a bit more infrastructure work

Ding: Need to sit down with Alice regarding a new design. One concern is about Michal -- I assume he's been using the trait definition we've supplied in our PR. We need to ask the t-compiler team about thoughs about that.

Alice: Based on the design meeting for in-place initialization design meeting, I don't think we'll have the conversion from ??.

Ding: I think that's fine.

## Supertrait associated items in subtrait impl pre-RFC

Authored by Ding.

Why: "This enables us to move type `Target` from trait `Deref` into trait `Receiver` without breaking existing impl `Deref` blocks in Rust ecosystem."

[Pre-RFC](https://hackmd.io/GONeg1UDQmWUoBvBqZ6yhw) is ready for review by t-lang again.

TC: Can you summarize this Ding?

Ding: This goes back to a meeting with Taylor a motnh and a half ago. It was compared to implementable trait aliases. For this we tried to keep the current structure of the impl without introducing a lot of new syntax for it. E..g taking the `Deref` and `Receiver`, if we want to make sure the current impl Deref code to compile, we'd like to add a associated imple type called Target in the Receiver. We're going to allow users to define subtraits with supertrait items implicitly. And we've introduced mechanisms to disambiguate any name conflicts.

TC: If there's an existing impl for one of the supertraits and you have an impl of the subtrait that could be impl of the supertrait, what's the rule you use for deciding about that?

Ding: The rule would be we pick this out during coherence check and it would be reported as an overlapping impl trait. If you didn't define anything, it'd be understood that you don't want to implement the super trait here in the block.

TC: What about marker supertrait (that have no items)?

Ding: We don't automatically implement marker supertrait. To opt in you need to prefix `auto impl` to the trait bound.

Ding: See the RFC line 321: https://hackmd.io/GONeg1UDQmWUoBvBqZ6yhw?stext=8968%3A50%3A1%3A1753900506%3AqzzTdF&edit=

trait Sub: MarkerSuper1 + auto impl MarkerSuper2 {
    type Type;
}

TC: Why did you go with `auto impl`?

Ding: Just `auto` could be confused with auto traits.

TC: The challenge here is that it looks like `impl Trait` which means something else too.

TC: In terms of getting feedback, open a thread on t-lang on Zulip. CC Jules as well, and Taylor and anyone else who might be interested.

TC: Then we can nominate this for a design meeting (which we can do soon). Or you can file the RFC and we'll do a design meeting out of the RFC.

Josh: We might also see how long this will take to settle. If we think this will get through quickly, we may nominate this in a triage meeting.

TC: I think people are going to read the RFC. Actually, probably, we should file the RFC ahead of the design meeting. Then if it's easy maybe we can just get the RFC into FCP without needing anything further.

Alice: Let's set up a call about the RFC.

## [Forbid object lifetime changing pointer casts #136776](https://github.com/rust-lang/rust/pull/136776) FCP

Two reference PRs need review:

- https://github.com/rust-lang/reference/pull/1951
- https://github.com/rust-lang/reference/pull/1952

TC: We're not blocking on these yet because it's not gone into the FCP yet. We'll look into the Reference PRs, but they typically go to the top of the queue when everything else is resolved.

## Stabilize `derive(CoercePointee)` (blocked on #136776)

Stabilization PR: https://github.com/rust-lang/rust/pull/133820

Blockers:
* [[WIP] Forbid object lifetime changing pointer casts #136776]

[Unsize-coercible type causes `[SOME_CONST; 0]` to execute `Drop`, but only if type is annotated. #143671](https://github.com/rust-lang/rust/issues/143671)
* New issue found ~3 weeks ago
* Is this a blocker for stabilization?

Ding: I looked this and the issue seems to have something to do with something else. I feel like coerce pointee is not the fault here.

Alice: I agree.

Gary: You can't creat a constant box.

Alice: Well someone just did it. I think this is not a blocker, if we fix it we fix it :shrugs:. Maybe the lang/compiler team needs to weigh in?

Gary: It looks like some sort of coersion causing the issue.

Alice: Seems like Rust is adding a bunch of coersions to the same type and those are being inserted all over the place and seems like that's what's causing this.

Alice: Whom is this even a question for? Compiler, lang, types?

TC: This looks like a bug to me. Is there any argument for this being the correct behavior?

ALice: No.

TC: Then I suggest putting up the PR to fix this in whatever way it needs fixing.

Ding: I can take a stab at that. I have some capacity now.

TC: After that, nominate it to the lang team, we'll take a look at it along with the run crater.

Gary: When checking if you do anything other than const on the array, it'll cause a drop to happen. There's a coersion being added and it has the same effect as adding a brace (`[{X}; 0]`).

## Stabilize arbitrary self types v2 (blocked on: #136776 & 143527)

Blockers:
* [[WIP] Forbid object lifetime changing pointer casts #136776](https://github.com/rust-lang/rust/pull/136776)
* [[Draft] Supertrait item resolution in subtrait impls #143527](https://github.com/rust-lang/rust/pull/143527)

Ding's [arbitrary_self_type: insert implied Receiver bound on Deref #138952 PR](https://github.com/rust-lang/rust/pull/138952).

Ding: It's not a PR we need to actively maintain. Just as a backup. We've agreed that we should pursue the supertrait item in subtrait instead.

Tomas: TODO, stop tracking actively, just keep in our backpocket.

## Tracking Issue for used_with_arg #93798

https://github.com/rust-lang/rust/issues/93798
https://lore.kernel.org/rust-for-linux/[e-mail]/

Bjorn3 made a change: https://github.com/rust-lang/rust/pull/140872

Make #[used(linker)] the default on ELF too.

That means we had to now explicitly use `[used(compiler)]`

Gary: Is this not a regression because it's now a stable feature?

Miguel: I don't think it was guaranteed because the feature was stable but the value wasn't?

We can discuss this later.

(the meeting ended there)

## Support for pointers with asm_const #128464

Tracking issue: https://github.com/rust-lang/rust/issues/128464

PR by Gary: https://github.com/rust-lang/rust/pull/138618

## Sanitizers target modificators #138736

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

Needs a rebase (azhogin).

## `-Zharden-sls` flag (target modifier) added to enable mitigation against straight line speculation (SLS) #136597

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

(tracking issue: https://github.com/rust-lang/rust/issues/116851)

Needs rebase (@azhogin).

Waiting on review.

## Configure no-std externally: `--crate-attr` RFC #3791

Waiting to be merged (for over a month)? https://github.com/rust-lang/rfcs/pull/3791#issuecomment-3013686542

Did anyone start implementhing this?

## Rustdoc features to extract doc tests

Experimentation in RfL (@ojeda)?

## Clippy configuration RFC

RFC draft: https://hackmd.io/7bDe6qXzTHWIeLT7CNtuLA

Next steps?

## -Zsanitize-kcfi-arity

Tracking issue: https://github.com/rust-lang/rust/issues/138311

Implementation (merged): https://github.com/rust-lang/rust/issues/138311

Next: stabilization?