Lang/RfL meeting 2025-05-07

Attendance

People: TC, Miguel Ojeda, Josh Triplett, Benno Lossin, Boqun Feng, David Wood, Gary Guo, Ramone, Trevor Gross

Misc

Planning for Rust Week

Rust for Linux is getting a lot of enthusiasm for Rust Week.

Many of the Rust for Linux team folks will be there: Alice, Benno, Björn, Boqun, Gary, Miguel, Trevor.

Tracking

Tracking issue

Stabilize derive(CoercePointee) (blocked on #136764 / #136776)

No update here.

Stabilize arbitrary self types v2 (blocked on #136764 / #136776)

Ding shared an update ahead of the meeting:

https://rust-lang.zulipchat.com/#narrow/channel/425075-rust-for-linux/topic/2025-05-07.20meeting/near/516734641

Hello chat, and cc TC.

In case we have a RfL meeting today and we need to provide an update, I won't be able to attend as I will be in the middle of a night class, but there is development from my end if a question is posted.

On RfL item arbitrary_self_types I am focusing on resolving the dichotomy of Deref::Target vs Receiver::Target. Boxy suggested earlier over here that we should stick to the original plan to merge Deref::Target into Receiver::Target.
However, I have feared that we will have to hack through the name resolving mechanism and indeed I have a blocker on it. I have posted asking for help from people knowing rustc_resolve well. However, in my research offline, I do not believe this will or should fly through the review.

• We have to make exception for Deref/Receiver in the name resolution so that old impl Deref blocks still compile.
• We have to make exception by creating a new compiler generated/assumed impl Receiver for any type with impl Deref.
• We still have to point the name Target in trait bounds to Receiver::Target. From my experience with the first implementation, it is probably already a comparatively easier part of this endeavour.

The t-types thread is posted after my earlier attempt at the problem. It only involves the third bullet point of redirecting Target to Receiver::Target in the trait bounds. The small problem, unfortunately in this case, is a known limitation from the old trait solver. I am still looking for an acceptable solution and I would like to talk to the types type. It could be something of a small price to pay for a short time period before the new trait solver lands.

I will continue to make myself informed by reading the meeting minutes and hopefully see you again at RustWeek 2025.

David: Probably Vadim Petrochenkov would be the right person to ask on the rustc_resolve side. I'll ping petrochenkov.

Sanitizer support and sanitize(off)

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

On the lang side, we discussed this item today:

https://github.com/rust-lang/rust/pull/123617#issuecomment-2859621119

Gary: There are some similarities to target_features(enable = ..) here.

Alice: Wouldn't you usually want to turn a specific sanitizer off?

Ramone: I started work on sanitize(off), and we discussed it on a Zulip thread. It applied it to a function and all function items within, but not recursively to calls.

Alice: It's worth noting that we don't now use sanitize(off) in the kernel. There was a bug that caused us to need it, but it was fixed.

Ramone: Anywhere you'd want to turn off a sanitizer like this, it'd be a bug in the sanitizer.

Alice: And even then, you'd want to turn it off at the level of a compilation unit. This was the one use case for allowing mismatched ABIs that I could think of.

There is a compiler side concern that's been blocking this:

https://github.com/rust-lang/rust/pull/123617#issuecomment-2192330122

David: You could technically stabilize these as target modifiers. I think Wesley's concern for this is from a user perspective that people won't be able to use these unless you're building your own core, and that could be confusing, so we'd need to be clear about our messaging.

support for pointers with asm_const

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

We talked about this in the lang call today, and we're going to leave a comment to the effect that we do want to see an RFC here.

ABI-modifying compiler flags

Alice: I filed two MCPs since we last spoke. We may need a third one. For all the use cases we have now, we should be able to get rid of target json, if we land these MCPs.

David: Seconded these two MCPs.

Miguel: These 3 PRs could be the same one (into the first one). The third incorporates all (but the first one requires work – I will ping Andrew). The third one should be clean when the first one is:

https://github.com/rust-lang/rust/pull/135927
https://github.com/rust-lang/rust/pull/140733
https://github.com/rust-lang/rust/pull/140740

It could also be in a single MCP, since they are used together.

Alice: For naming the flags, I proposed that we just match clang.

Configure no-std externally

David: RFC#3791 is in T-compiler FCP.

TC: I did ping Mark, and he said he was happy to adopt the RFC here.

Rustdoc features to extract doc tests

Miguel: I talked with Guillaume, and we'll talk more in RustWeek about it. I hope we move it forward during Rust Week.

Clippy configuration

Miguel: I emailed flip1995, but unfortunately that person doesn't have much time – he is happy to mentor, but will be at Rust Week, so I hope we can collaborate on this there. There will be a room for it.

-Zsanitize-kcfi-arity

Miguel: I emailed Peter, but I haven't received an answer yet.