Lang/RfL meeting 2026-01-14

--- title: "Lang/RfL meeting 2026-01-14" tags: ["T-lang", "design-meeting", "minutes"] date: 2026-01-14 discussion: https://rust-lang.zulipchat.com/#narrow/channel/410673-t-lang.2Fmeetings/topic/RfL.20meeting.202026-01-14/with/567961290 url: https://hackmd.io/zarNfGlIRm2WlUd7nw78Jw --- # Lang/RfL meeting 2026-01-14 ## Attendance People: Alice, Benno, Gary, Miguel, Paul Murphy, Wesley Wiser, Xiangfei Ding, Nadri, TC, Tomas Sedovic, Josh, Driver: Tomas 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) [Rust wanted features](https://github.com/Rust-for-Linux/linux/issues/354) ### Project 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 * In-place initialization: https://rust-lang.github.io/rust-project-goals/2025h2/in-place-initialization.html * Field projections: https://rust-lang.github.io/rust-project-goals/2025h2/field-projections.html ## Announcements or custom items (please add topics here) Josh: It seems the LWN article was the initial announcement. But it's being reported in a lot more sources. This is going to drive momentum. Some people were waiting for something more major before checking out Rust and this was it. Thank you for working on it! Miguel: I saw people saying the same as well. A lot of people weren't following the kernel closer but with these news they might feel they may no longer just wait and see. Tyler: Congrats everyone here! Miguel: And yours! Thank you for the communication channel and your support. Miguel: At the maintainer summit I talked about the same things as at the LPC talk. Everything went well. https://lwn.net/SubscriberLink/1050174/6b6d55c90ce1100f/ https://www.youtube.com/watch?v=L1sRHWiIYlw Tomas: The CPython folks also reached out. Josh: They're very enthusiastic at the Python Core team level. The CPython folks need so much less that they'll need that's unstable, they're much more excited about having this in the core sooner. But they're aware of the small amount of push-back from people who are very into C. I think there would be some value of cross-pollination of lessons learned. If one of the folks here could join the Rust for CPython meeting and do a one-time thing talking about their experiences, the negative sentiment, how we got people on board, that would be really appreciated. The summaries on LWN would be more useful. Miguel: Happy to help! Josh: There are things Python does on that Linux doesn't even. Please talk to Tomas if you're interested and I can reach into the discord they have for this. TODO: Tomas to let the R4L folks with schedule, meeting links, find a right time for them to join Miguel: I'm working on pinging maintainers for the All-Hands. At least a few of us from the core team will likely be there. Miguel: I'll ping the rustfmt team again to see how that's going. I contacted Manish, Caleb and jieyou. And the last update I had form a month ago. And Ding also said he was involved. Ding: I haven't been in touch with Manish. I noticed that jieyou is working on the tree sync which is the biggest thing. I'll ping him. And the PR I posted will remain on review. We'll need to get those sorted out. ## Compiler features Tomas: I've added all the compiler issues we're tracking in our goals here. The vast majority hasn't seen any movement in months as far as I can see. ### Flags that need stabilization * [`-Zbranch-protection`](https://github.com/rust-lang/rust/issues/113369) (arm64) * [`-Zcf-protection`](https://github.com/rust-lang/rust/issues/93754) (x86_64) * [`-Zcrate-attr`](https://github.com/rust-lang/rust/issues/138287) * [`#![register_tool]`](https://github.com/rust-lang/rust/issues/66079) * 2025-12-03: Tyler was going to fully review the RFC again and then look at this. * Tyler: I proposed FCP on the RFC. It's lang nominated, it's on the lang team to pick it up and discuss. If it's urgent I can bring it up * [`-Zdebuginfo-compression`](https://github.com/rust-lang/rust/issues/120953) * Wesley: I'm looking at stabilizing https://github.com/rust-lang/rust/pull/150625 * Josh: This is one more reason to encourage the Trifecta Tech folks who are working on a zstd-rs in pure Rust. This came up for Python as well. * Miguel: Linked to our list. * Miguel: Inside the kernel we have a copy of the C library. Eventually the Rust one could be proposed for the kernel -- some companies/users may want to use a memory-safe version. * Josh: It would be interesting to consider zlib-rs in the Kernel to have an option to use it if you're already building with Rust. It is faster. * Miguel: If it's close to ready, it could be a potential RFC. * Gary: If the speed is die to vectorization, then it doesn't matter in the kernel context? * Josh: The implementation is production ready and it should be configurable to be used in the kernel * Gary: We haven't figured out how to make part of the code use hardfloat yet for Rust. * Josh: That's a good point. But the rust code in question is conditional on target features. Might be a good case study. * [`-Zdirect-access-external-data`](https://github.com/rust-lang/rust/issues/127488) (loongarch, and maybe x86_64 soon too) * Gary: Some discussion in https://rust-lang.zulipchat.com/#narrow/channel/425075-rust-for-linux/topic/New.20relocation.20model.20for.20relocatable.20code.20but.20static.20data/with/566044955 * Wesley can take a look * Miguel: https://github.com/rust-lang/rust/pull/150494 was merged a few days ago. * `-Zfixed-x18` (arm64) * [`-Zfunction-return`](https://github.com/rust-lang/rust/issues/116853) (x86) * `-Zfunction-sections` * [`-Zunpretty=expanded`](https://github.com/rust-lang/rust/issues/43364) * [`-Zsanitizer=kernel-address`](https://github.com/rust-lang/rust/issues/123615) (arm64, riscv64) * [`-Zsanitizer=shadow-call-stack`](https://github.com/rust-lang/rust/issues/123615) (arm64, riscv64) * [`-Zsanitizer=kcfi` and `-Zsanitizer-cfi-normalize-integers`](https://github.com/rust-lang/rust/issues/123479) (arm64, riscv64, x86_64) ### Flags needed in the future * [`-Zharden-sls`](https://github.com/rust-lang/rust/issues/116851) (x86_64) * [PR#136597](https://github.com/rust-lang/rust/pull/136597) * Waiting on author since 2025-12-03: https://github.com/rust-lang/rust/pull/136597#discussion_r2586642641 * TODO Tomas to ping Andrew * [`-Zmin-function-alignment`](https://github.com/rust-lang/rust/issues/82232) * [`-Zrandomize-layout`](https://github.com/rust-lang/rust/issues/106764) * [`-Zregparm`](https://github.com/rust-lang/rust/issues/131749) (x86_32) * [`-Zreg-struct-return`](https://github.com/rust-lang/rust/issues/116973) (x86_32) * [`-Zsanitizer=kernel-hwaddress` and `-Zsanitizer-recover=kernel-hwaddress`](https://github.com/rust-lang/rust/issues/123615) (arm64) * [`-Zsanitize-kcfi-arity`](https://github.com/rust-lang/rust/issues/138311) (x86_64) ### Other #### `--emit=noreturn` background: The kernel use `objtool` to analyze the object files. It checks whether things are correct on the structure/assembly level. These are checks Miguel has to manually: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/objtool/check.c#n186 Gary: it's on my radar to improve objtool on handling of noreturn, but I haven't had time to look at it yet. Miguel: I think the last time it was discussed was https://lore.kernel.org/rust-for-linux/20251022081331.GJ4067720@noisy.programming.kicks-ass.net/, but the last patch that came up was in late December: https://lore.kernel.org/rust-for-linux/20251223113538.1016078-1-fujita.tomonori@gmail.com/, so it keeps coming up. #### build-std: Context RFC was approved and merged https://github.com/rust-lang/rfcs/pull/3873 First two feature RFCs are in FCP: - build-std: always https://github.com/rust-lang/rfcs/pull/3874 - build-std: explicit dependencies https://github.com/rust-lang/rfcs/pull/3875 ## Lang features ### `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 / updates? / Anything to discuss? Ding: [rust#146095](https://github.com/rust-lang/rust/pull/146095) is back into review. I will look out for crater run results, see if I accidentally break method resolutions. Ding: The method resolution was updated. I did a benchmark, didn't break anything. This PR opens opportunity to work with the Receiver target digressing from Deref target. This is behind and unstable feature flag so we can just ship arbitrary self types. So the main part of the feature is ready for stabilization discussion. I'm looking to shipping it at some time. I hope we can have review bandwidth to look at it. Tyler: Has anyone been reviewing it yet? Ding: The last person reviewing it was Jack. He gave thumbs-up on the perf run. But there's been no more news from him. Tyler: Looks like there's already a crater run. ### [RFC #3851: Supertrait Auto-impl](https://github.com/rust-lang/rfcs/pull/3851) Current status / updates? / Anything to discuss? Tomas: Ding proposed this as a 2026 Project goal: https://github.com/rust-lang/rust-project-goals/pull/436. This will be considered by the Project teams when we look at all the goals (in the next few weeks). PR is at https://github.com/rust-lang/rust/pull/149335. Tyler: For existing goals and new goals alike, the kind of review I expect to do is: are your ambitions realistic, aligned to the asks of the team, aligned with those ambitions, if there's not been a lot of progress I might be wondering why you might expect a lot more done. In a separate pass for looking at the needs of e.g. too many lang design asks. Miguel: I hoped that now that Rust for Linux is no longer experimental, maybe there will be more funding (money, people) and some flexibility might be needed there. Ding: the AST parser is still under review, I am having a chat with petrochenkov@ in the background. I will tag it ready once I minimise the `todo!`s in this iteration. Ding: I need to throw out a proper error saying that this is an unstable feature. ### Arbitrary Self Types [Arbitrary Self Types: Tracking issue #44874](https://github.com/rust-lang/rust/issues/44874) - Waiting on the Deref/Receiver Current status / updates? / Anything to discuss? Ding: on Monday we found `#[feature(arbitrary_self_types_pointer)]` a bit quirky. tmandry@ I suppose we should talk about it on Friday. Tyler: I didn't remember the feature gate existed. The last time we talked about this with the members of lang, the consensus was we didn't want to support `Receiver` on raw pointer types. They have methods and libs-api may want to add new methods on pointers and that would be a breaking change. I'd like to dig more into the conflict you're references. Alice: What does the feature do? Ding: It allows the raw pointers `*const T` to show up as `Receiver<T>` in general. I didn't follow how this exactly came into place or its motivation. But it is on the shelf. Alice: It sounds like it should just be removed. Benno: In the meeting Nadri, Ding and I had on Monday we talked about the field projection autoref feature and we discussed `Receiver` of course. Our consensus was `Receiver` and `HasPlace` should be separate. `Receiver` shouldn't add methods since a downstream user can depend on those. So I think this feature should just be removed. Nadri: We were talking about autoref and we want autoref to happen when the right requirements are met, which means basically `Receiver`. If raw pointers have `Receiver` they'd be autoref and we don't want that. Tyler: I don't know if anyone would oppose to the feature. Someone should propose the PR and nomitate it for lang TC: I think it's OK to remove it. Some history: originally we were considering a different resolution rule that would allow things like raw pointers without preventing Libs-API from extending them in the future. We've decided against that more complicated version. I don't think we're likely to do that at this point. ### `derive(CoercePointee)` [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 Current status / updates? / Anything to discuss? Ding: I am cooking a proper fix to prevent accidental "specialisation" of trait implementation, like in the case of `DispatchFromDyn`. Insofar [#149968](https://github.com/rust-lang/rust/pull/149968) will stop the bleeding for `derive(CoercePointee)` for now. Alice: We had an issue with certain casts with raw pointers. We're moving to a direction that it has a valid vtable. That was merged and it's a breaking change. The PR was opened in February. The Reference PR for that is still open. https://github.com/rust-lang/rust/pull/136776 https://github.com/rust-lang/reference/pull/1951 TC: Eric Huss and I talked extensively about this yesterday on the lang-docs office hours call. The PR here talks about shortening lifetimes in the context of `as` casts. But that's not specific to `as` casts. Long term, anything that is true of coercion should be in the Coercion chapter not in the as cast chapter. Alice: as cast never change the vtable so that's not true. TC: We need to look at that. If coersions aren't a strict subset of the things you can do with as casts, we need to disentangle that here. Also, we'd like a commit that moves it out of footnote without making any other changes. Alice: I fixed that already. TC: Thanks; Eric had some concerns there. If you could double check that and reply with that assertion, that'd be helpful. ### `asm_const_ptr` Implementation is complete; waiting for code reviews. https://github.com/rust-lang/rust/pull/138618 (the merge conflict is just for the feature gate) ### In-place initialization Goal tracking issue: https://github.com/rust-lang/rust-project-goals/issues/395 Current status / updates? / Anything to discuss? Ding: on the documentation front, I am writing a post into https://github.com/rust-lang/beyond-refs to describe all the proposals. This will include Alice's new proposal from LPC 2025. Watch out https://rust-lang.github.io/beyond-refs when published. ### Field projections 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 / updates? / Anything to discuss? Wiki to map out the solution space: https://rust-lang.github.io/beyond-refs Benno: I updated the FRTs PR to the latest design, which makes them more minimal and the PR much simpler. Ding and I will meet tomorrow to discuss it and then I'll mark it as ready for review. December was very productive for the design, we answered very important questions and started working on the wiki. I'm also working on the project goal text for this year. I would like to have more compiler support for implementing this year, while also finishing the design. ## Other topics ### Macros, attributes, derives, etc Josh: What features would you need from Rust in order to ditch proc macros and the vendored `syn`/etc? Josh: There is now support in nightly for writing attributes and derives to use declarative macros. That's harder to write but: how much support would you need from improvements to declarative macros in favor of ditching proc macros in favor of declarative? I want to help. Miguel: The actual Syn PR is 6.19. It's to be released in two weeks. That means we just got it. Benno: https://github.com/Rust-for-Linux/pin-init/blob/dev/syn2/internal/src/pin_data.rs That's 500 lines of Syn code but it seems unreasonable to do that ina declarative macro. Josh: I think you could ultimately be able to reasonably write this as a declarative macro. I'm asking more for what you would need in the futuure to make this better. Benno: Parsing for generic arguments. And when you add a new feature, syn will get that eventually. Josh: That's true today. Waht I'd like to get to is "I want to parse a struct" and you'd be able to access all fields Benno: One thing this does is it replaces the Self type with a concrete type. I'm not sure if you want to implement that in the compiler itself. Another macro implements custom syntax. Josh: I'd be happy to chat with you async about this. I'd like to get to the point of writing declarative macro you could use existing Rust syntax and write the macro in. Miguel: If we could eventually remove our dependency on Syn, we would like that. Josh: oli is looking at implementing runtime macros for reflection. I want to implement tham in macro time. From chat: How to implement split_for_impl without writing a full parser w/ token munching? Benno Lossin https://github.com/Rust-for-Linux/pin-init/blob/dev/syn2/internal/src/init.rs Gary Guo I think https://github.com/rust-lang/rust/issues/83527 is probably required to make complex macros possible with decl. macros