Lang/RfL meeting 2025-11-19

--- title: "Lang/RfL meeting 2025-11-19" tags: ["T-lang", "design-meeting", "minutes"] date: 2025-11-19 discussion: https://rust-lang.zulipchat.com/#narrow/channel/410673-t-lang.2Fmeetings/topic/RfL.20meeting.202025-11-19/with/558259742 url: https://hackmd.io/YcVTpbP_Rbq219m7VyR-RQ --- # Lang/RfL meeting 2025-11-19 ## Attendance People: Alice, Alejandra, Aapo, Benno, Gary, Ding, Nadrieril, Tyler, Josh, Miguel, TC Driver: Miguel Notes: Tomas ## 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) [Rust unstable features needed for the kernel](https://github.com/Rust-for-Linux/linux/issues/2) [Rust wanted features from RfL](https://github.com/Rust-for-Linux/linux/issues/354) ### 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 ### `rustdoc` checking (or runtime toggle) for private and hidden items Miguel: I sent these two issues (feature requests): * https://github.com/rust-lang/rust/issues/149105 * https://github.com/rust-lang/rust/issues/149106 Miguel: We talked about them for a while -- it came up again because during 1.92 nightlies `rustdoc` started to check it, but when I asked in the PR, it turned out it was not intentional. Benno actually sent a patch about it, wondering why older compilers didn't catch it. Guillaume fixed it. However, it would actually be nice to get checking for private and hidden documentation (e.g. for intra-doc links etc.). We'd like the documentation fro private and hidden stuff to work the same as the public. But we'd like a runtime toggle in the generated docs. So you could see the private ones. BinaryCat implemented a toggle for this. Guillaume suggested they could implement a hack that they could test in their RfL Rust documentation in the kernel. We can test it out there. ### Unsafe macros and bug hitting `container_of!` `unsafe_op_in_unsafe_fn` not respected in imported declarative macros: https://github.com/rust-lang/rust/issues/112504#issuecomment-3534431442 Miguel: We hit this bug. When you import a declarative macro, it's not respected. We were using a macro with unsafe code and it didn't have the unsafe block. And rust/clippy didn't warn us about the missing block or about the missing safety comment. Then someone tried to use it and they hit the error then. Miguel: Regarding unsafe macros in general, we'd probably use that a lot. ### Clippy `// PANIC` lints `// PANIC: ...`: https://github.com/rust-lang/rust-clippy/issues/15861 (context at https://github.com/rust-lang/rust-clippy/issues/15895) and https://github.com/rust-lang/rust-clippy/issues/15896. `// CAST: ...`: https://github.com/rust-lang/rust-clippy/issues/15963 and https://github.com/rust-lang/rust-clippy/issues/15964. `// ORDERING: ...`: https://github.com/rust-lang/rust-clippy/issues/16073 and https://github.com/rust-lang/rust-clippy/issues/16074. Miguel: We were talking about having an `ORDERING` comment to explain why that ordering was picked. Similar to the `PANIC` etc. comments. Miguel: These style of comments would be useful for us and we keep coming up with new ones. ### `rustfmt` No update. Ding: I have a PR to tackle on issue on import-granularity. https://github.com/rust-lang/rustfmt/pull/6723. It is just one of them. I will ask Manish to take a look. Miguel: Ding, did we hit this? You're saying it's related to the https://github.com/rust-lang/rustfmt/issues/4991 (import_granularity). But what we're really missing is having each use on its own line. Ding: I'll look into the vertical layout setting. Manish and I have been talking. I'd like to see how far we can push whatever's blocking the removal of the trailing comma comment out. Miguel: We were lucky, just by adding the comment, rustfmt actually formats it exactly the way we want. We just want to have an actual option to do this. I opened a PR that does this, just to see if it'd work and it did. ## LWN articles * [The current state of Linux architecture support](https://lwn.net/SubscriberLink/1045363/60611dc5ec3f7099/) * Miguel: this one mentions Rust, there's discussion in the article, Josh replied to it I think * Josh: They built a table for architectures and I've realised that they were mapping Tier-1 and Tier-2 and so I asked them to change "tested" to "compiler tested" ## Compiler features * -Zharden-sls / https://github.com/rust-lang/rust/pull/136597 * azhogin rebased the PR and addressed the review comments. * Waiting for review again. * `#![register_tool]` / https://github.com/rust-lang/rust/issues/66079 * Waiting on [RFC#3808](https://github.com/rust-lang/rfcs/pull/3808) * Gary wasn't here last time. The question is, do we want register_tool or go with Tyler's idea? * Gary: I was checknig the Zulip thread. * Tyler: I'm looking at it now. I have this intuition that metadata like this should be versioned and use lightweight checking. * Tyler: Is that a workable model for Rust for Linux? Should we go with the current RFC and build toward something else in the future. * Gary: I we want to get this feature to stable, this is the only feasible thing in the short term. What you're proposing will take a lot of work. And someone brought up Macro 2.0 into the discussion. * Tyler: Josh has an RFC for declarative macro in item position. I don't think we need to wait for the full macro rework. * Tyler: But for my first question, do you agree the model is coherent and workable? * Gary: I think it is, but the definition of the custom attributes will need to appear somewhere. Now you have a different dependency that the tool will need to supply. * Gary: Do you think it would be workable that a user of Clippy would have to download a dependency provided by the Clippy team? * Tyler: I imagine the dependency would be shipped alongside the toolchain. * Gary: But you need to make sure everything needs to use the dependency even if you're not using Clippy * Tyler: That is what I'm proposing. * Nadri: Is your idea written out somewhere? * Tyler: https://rust-lang.zulipchat.com/#narrow/channel/213817-t-lang/topic/namespaced.20tool.20attrs * Tyler: you declare lints in tool_attributes using declarative macro syntax * Josh: I had an additional piece of nuance since we last talked about it. I think there's value in being able to declare these and have completion and doc comments, rustc parsing the individual rules so rustc could tell you this isn't work with an external tool. But to what extent do we want to "carrot" vs "stick" this? We could say you probably want to do this because we give you a bunch of features. On the other side here is a quick way to do something without having to publish a crate. And for that I'd love for people to pull up some crate for Rust parsing without having to go edit a crate and do a patched version of a crate to test the actual tool change they're making. * Josh: There's value in doing both the "screw it I'm doing this" and doing the careful parsing and writing out docs etc. * Nadri: That's not quite the fallback. The attribute will get expanded and that info is not kept cross-crate. * Tyler: It wouldn't be an attribute macro. * Nadri: This isn't a workable fallback today. * Josh: I meant, if we have a mechanism Tyler's proposing declaring attributes with a macro syntax, someone could define a macro just parsing tokens trees. * Gary: Would I be able to say "anything from klint is allowed" or "anything with this prefix is allowed" * Tyler: I think youd' still need to define the attribute names. * Gary: When developing a tool you'd have an chicken-and-egg issue. You need to publish a crate to use the tool and define the attributes. * Nadri: rustc aren't meaningful for crate names. It feels weird that cargo sets a name but as a tool author, there could be many different names * Tyler: I agree, there's an open design question on how to get this. * Tyler: I was hoping I was going to read the RFC, get excited and propose an FCP. But given what I've heard from the Crubit team moving away from it my enthusiasim is lower. But I don't want to block it. * Josh: Regarding name resolution, people might expect to be able to write `use klint::{attr as otherattr};`, but the tool may not want to support that because it doesn't actually do full name resolution. * Josh: There are a *lot* of things people expect to be able to do with name resolution. And people would reasonably expect these and be surprised that they didn't. * Josh: I'd love to see a proposal for this as an option thing for people to be *able* to do. But I'd be hesitant to say this should be the only way to do it. * Nadri: today any tool apart from clippy and rustdoc needs to use nightly rustc. I don't think it needs to be stabilised soon. * Tyler: There are examplse of tools that simply just parse the code using syn. * Gary: The issue is that in order to reference an attribute to parse at all you need the nightly. For Rust for Linux we want to move away from nightly. * Tyler: Supporting this mental model brings in a lot of complexity. And I think I'm convinced that we may want to have a simpler method which is what this RFC does. * Gary: There are also dependencies that you want to define as only tools, and will never be attribute macros. So having register_tool would let you * Tyler: I can imagine being very cautious about these dependencies. But I think auditing these would be easy -- just one line per attribute. * Gary: If I don't have to split the tool to another crate that'll make my life easier. * Tyler: That's valid. * Tyler: I'm going to propose to adding a "future possibility" section and FCPing it. * Josh: +1 for a future possibilitise section * -Zno-jump-tables / https://github.com/rust-lang/rust/pull/145974 [merged] * Anything else? ## Lang features #### Layout of type ids Current status? Alice: There was some discussion that a team (compiler?) said they shouldn't do it. And then people said they wanted it. Miguel: Someone suggested using a union. Alice: I think that's fine to say pointers are very large and it should be bigger. https://github.com/rust-lang/rust/pull/148265 https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/TypeId.20minimum.20size.20guarantees/near/553265615 Alice: This will be discussed at a compiler design meeting. We'll need to find the date when this is. https://github.com/rust-lang/compiler-team/issues/941 TODO(Tomas): find out the date, make sure RfL folks get invited NOTE(Tomas) link to private DM so I can follow-up quickly: https://rust-lang.zulipchat.com/#narrow/dm/250987,893815-dm/near/558290058 #### `Deref` / `Receiver` https://rust-lang.zulipchat.com/#narrow/channel/522311-t-lang.2Fcustom-refs/topic/Consequences.20of.20making.20Deref.20a.20subtrait.20of.20Receiver/with/547014978 Current status? Ding: I am drafting the Rust language reference PR. A new section on arbitrary method receiver will explain the `Receiver` trait and how it interacts with method resolution. I have a summary of recommendation on when `Receiver` trait is suitable. Ding: I'd like to implement further optimisations. It's scanning for candidates wastefully. It's a linear scan. I think I can figure out to speed it up. ### 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 Any updates? Ding: I posted a PR to fix an unsoundness around `DispatchFromDyn` trait https://github.com/rust-lang/rust/pull/149068. It could use some reviews. Ding: An ask to t-lang. Should we ever allow `Receiver` a dyn-compatible trait? [Issue has been filed](https://github.com/rust-lang/rust/issues/149094). Ding: Maybe T-Types should look as well. Jack is requested review from T-Types [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 Any updates? Ding: I am experimenting with further optimisation of candidate selection. The PR will be updated accordingly. #### [RFC #3851: Supertrait Auto-impl](https://github.com/rust-lang/rfcs/pull/3851) - obi1kenobi requests more detailed consideration for semver impact edge cases: https://github.com/rust-lang/rfcs/pull/3851#discussion_r2430827437 Current status? Ding: I had a limited bandwidth. I will conclude my edit requested by `obi1kenobi` this week. I have been focusing on the parser implementation. #### [RFC #3848: Pass pointers to `const` in assembly](https://github.com/rust-lang/rfcs/pull/3848) Merged \o/ #### 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 Field representing types (FRT) PR: https://github.com/rust-lang/rust/pull/146307. Current status? / Anything to discuss? ## In-place initialization https://rust-lang.zulipchat.com/#narrow/channel/528918-t-lang.2Fin-place-init/topic/Fundamental.20Issue.20of.20Effects.20and.20In-place-init/with/558268061 Benno: There's a fundamental problem that we won't be able to solve without having keyword generics. Josh: What do you think would be the best path forward? Would this be best resolved with the people working on this and the champion? Or should there be a design meeting? Benno: We should talk with the keyword generics folks (e.g. Yosh who's already involved with in-place initialisation) Josh: I hope we can figure out how not to depend on keyword generics because it's not clear at all whether this feature will land. Alice: Exactly what I was thinking. Benno: If we solve this without effect generics, it will impact the effect generics. Josh: If we're in space where we can do a small portion without having full effect generics that would be great. Generalizing it to `Try` seems straightforward. Especially given we have a mechanism on nightly to ignore `Result<(), !>` e.g. to more smoothly work with types that can't fail. Benno: Yeah, that's exactly the case. Josh: When I was worried earlier, I'm no longer worried if only some features might block on it. Alice: Some of the proposals (e.g. Olivier's proposal that's similar to what C++ does) don't have this problem. Benno: I don't think they have async support. Alice: Olivier didn't put it into the RFC. But let's discuss this later. Josh: Going through your document, it seems that outpointers have a similar issue but handle some of the cases naturally. But the compare and contrast of which one to pick, I'm looking forward to understtanding what we should choose here. Tyler: This does get into some of the outpointer areas and how far we can push them. Benno: What I mean by "the same thing" is: it's one level up but you still need that level to be useful. If we solve it for keyword generics we solve it for the trait case and then there's no need for outpointers necessarily. But I feel Init expression given how they're similar to struct initialisers are very nice. Josh: With init expressions the issue is they don't support ?? at all. But with outpointer you get all of that. Benno: To me there isn't really a distinction between those two. The FnONce trait is the special thing you have. *** Josh: Congratulations to Alice to being nominated and accepted as a language-advisor. That officially went through. Thank you for all the great work and our experience with the recent RFCs.