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

# Lang/RfL meeting 2025-02-26

## Attendance

People: TC, nikomatsakis, Miguel Ojeda, Alice Ryhl, Xiang Fei Ding, Boqun Feng, Gary Guo, Josh Triplett, Jubilee, Oli, Guillaume Gomez, Trevor Gross

## Resolution to the drama

Linus chimed in with support. Christoph resigned from maintaining the affected subsystems.

RalfJ is going back and forth with Linus about the memory model.

- <https://lore.kernel.org/rust-for-linux/CAHk-=[e-mail]/>
- <https://lore.kernel.org/rust-for-linux/[e-mail]/>
- <https://lore.kernel.org/rust-for-linux/CAHk-=wh=[e-mail]/>
- https://lore.kernel.org/rust-for-linux/CANiq72kSdPvh81uOm=N-=[e-mail]/

Gary: To be fair, there were long periods where noalias was not emitted at all because of LLVM bugs. So it's not like it's a huge ask to not emit these as a perhaps perma-unstable option.

NM: This is true, but rustc will also do (and probably does, in stdlib) optimizations.

## Tracking

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

### Arbitrary self types v2

Stabilization remains blocked on:

- https://github.com/rust-lang/rust/pull/136764
- https://github.com/rust-lang/rust/pull/136776

### Blog post about how the RfL project goal has gone

Alice presented a talk last week about this. We're still waiting for the recording to go up. This was at RustNation.

The framing is that in the first iteration, we mostly did the lang items. In the second iteration, we're doing more compiler items.

Niko will write out a first draft of this kind of blog post. Miguel is happy to help review or write too.

### Derive smart pointer

There's been some progress on this. There's a problem here on tuple unsizing. Alice made some proposals; CE has an alternate solution in mind and claimed the issue. It's waiting on that now.

Ding also submitted a PR that tried to solve that problem and another in one go. But half of it was dropped.

There may be a way that we can improve the trait solver so that we can tag trait impls as unstable. That's probably a solution here. Niko will touch base on CE about this.

Alice is thinking about making a PR to just remove the unsizing of tuples.

Ding: I'd raise: should we just stabilize `unsized_tuple_coercion`?

https://github.com/rust-lang/rust/issues/42877

NM: There seem to be weak arguments on both sides. Absent a strong motivation, I am tempted to remove it. We could nominate it for lang discussion. [Added comment.](https://github.com/rust-lang/rust/issues/42877#issuecomment-2686010847)

Alice: I'll put in a PR for that.

PR for stabilizing `derive_coerce_pointee`:

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

How far does that go to unblocking `derive_coerce_pointee`?

Tracking issue for `derive_coerce_pointee`:

https://github.com/rust-lang/rust/issues/123430

The items that overlap with arbitrary self types are:

- https://github.com/rust-lang/rust/pull/136764
- https://github.com/rust-lang/rust/pull/136776

The theory is that we need to merge those two PRs and then merge a PR to remove tuple unsizing, and then we'll have cleared the way both for arbitrary self types and derive coerce pointee.

There was discussion in a recent types meeting suggesting that it might be difficult to make this into a FCW.

### asm_goto

This is waiting on review of a Reference PR.

- <https://github.com/rust-lang/reference/pull/1693>
- <https://github.com/rust-lang/rust/pull/133870>

### Support for pointers with asm_const

Feature request:

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

Implementation unblocked by https://github.com/rust-lang/rust/pull/137180, and initial step is https://github.com/rust-lang/rust/pull/137686

Within RfL, having this has been identified as something that would be very helpful.

### 2025 goals

https://rust-lang.github.io/rust-project-goals/2025h1/rfl.html

### ABI-modifying compiler flags

The RFC was accepted by T-compiler:

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

There's a PR that started work on this:

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

We've created tracking issue:

https://github.com/rust-lang/rust/issues/136966

Niko [pinged azhogin on Zulip](https://rust-lang.zulipchat.com/#narrow/channel/425075-rust-for-linux/topic/ABI-modifying.20flags.20.23136966) to see whether they are interested in continuing the work they started in <https://github.com/rust-lang/rust/issues/133138>.

### Extract dependency information, configure no-std externally

Miguel is planning to look into this flag, and then discuss with everyone here.

One of the questions is whether we could skip `core` and do it only for the non-sysroot crates.

We last discussed it in:

https://hackmd.io/Jq3Xo0ZARAKNsRBC3lXkEA

tmandry had said:

> tmandry: Do you want toolchain runtimes (libstd, compiler-rt) in your dep info? In my experience this features does 90% of what I want it to do, but removing the inclusion of runtimes is the only question I have before stabilizing. (we don't understand this point)

This is part of what Miguel is looking into.

### Rustdoc features to extract doc tests

We understand this to be implemented. Miguel talked with Guillaume at FOSDEM, and he's interested in implementing this in the kernel. He's looking into that.

### Clippy configuration

There's a discussion involving flip1995:

<https://rust-lang.zulipchat.com/#narrow/channel/257328-clippy/topic/stablization.20of.20clippy.2Etoml.20a/near/486169617>

Flip1995 wrote this pre-RFC: https://hackmd.io/@flip1995/By87NXIc1g

Miguel: Either a file or flags would be OK for the kernel. In some ways, having flags is easier for the kernel and other things with custom build systems.

> What we need is that Clippy does not break in the future when using it. For that, there are a few aspects:
>
> - The stability of each of the configuration keys and values (currently we use: msrv, check-private-items and disallowed-macros).
> - The stability of the .clippy.toml file (i.e. its existence). The kernel does not necessarily need that it is a file -- we could also use flags, for instance.
> - The stability of the CLIPPY_CONF_DIR environment variable. The kernel uses it since it supports builds outside the source tree and thus we need to point it to the source tree so that it finds .clippy.toml. If we were not to use the .clippy.toml, file, this would not be needed.
> - How to handle different compiler versions: for other tools (e.g. rustc), the kernel already handles passing different sets of flags depending on the compiler version. It would be easy for us to do the same for Clippy if the configuration options could be passed that way. Otherwise, if it is a file, there is the question of how to handle unknown keys/values. The kernel could also consider generating the configuration file on the fly, to avoid that issue.

### Blessed way to rebuild std

https://rust-lang.github.io/rust-project-goals/2025h1/build-std.html

David's team at ARM has talked through a document about how to go about this. The next step is putting out a kind of vision document about what we should be doing. The immediate goal will be the parts of it that are needed for RfL.

Wesley, Josh, and some others on the Cargo team have reviewed the document and are giving feedback. It's in the pre-pre-RFC stage.

There's still a lot of iterating on the right design.

### What kind of compiler flags will Rust-for-Linux need?

https://github.com/Rust-for-Linux/linux/issues/2

Wesley sent a PR to stabilize `-Zdwarf-version`.

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

Wesley has proposed FCP merge here and is enthusiastic about doing it. If there's a bug here, it'd be in LLVM. This is leaned on heavily in other places.

It's currently waiting for checkboxes on the FCP.

### `cfg(no_global_oom_handling)`

https://rust-lang.zulipchat.com/#narrow/channel/219381-t-libs/topic/no_global_oom_handling.20removal/near/498600545

RfL doesn't use this any more, but it's still in the code for Linux 6.12 which is an LTS kernel.

We could backport the commit that removes the use. Otherwise, this caps the maximum Rust version (which would not be a great look).

In discussion, it sounds likely on the kernel side this could be removed from LTS.

From [Zulip](https://rust-lang.zulipchat.com/#narrow/channel/219381-t-libs/topic/no_global_oom_handling.20removal):
> Daniel Paoliello:
>
>> We are still using this in the Windows kernel. Unfortunately, using kernel::alloc is not an option for us since it's GPLed.

### Disabling the orphan rule

https://github.com/rust-lang/rust/issues/136979

NM: I want to read through the thread, but I'm generally in favor of doing something hacky to disable the orphan rule, even though that would temporarily move us away from doing the kernel in stable Rust. But is that what you want, or are you OK waiting?

Miguel: All the flags we use in the kernel have to be approved by me, and I'll only do that if you tell us that it's OK to use.

Josh: There was I think some confusion on the thread between something that would be on a stabilization path and something that's more temporary. We'd previously had discussions, e.g., about how we could do it only in a bin crate.

Oli: We can happily support the experiment by making it unpleasant to use for normal users. We do that for internal things, and that'd be better than forking `rustc`.

Oli: What I would mainly like to see as a separate experiment is what you would have to do if you didn't do that.

TC: Since the kernel controls all of its code, and doesn't have SemVer guaratees to uphold, it does have the ultimate sledgehammer workaround available of adding dummy generic parameters to all of its traits and then tagging its impls. That comes at some ergonomic cost, of course.

Josh: Exposing `#[fundamental]` here could help.

Oli: +1.