Triage meeting 2025-12-17

--- title: Triage meeting 2025-12-17 tags: ["T-lang", "triage-meeting", "minutes"] date: 2025-12-17 discussion: https://rust-lang.zulipchat.com/#narrow/channel/410673-t-lang.2Fmeetings/topic/Triage.20meeting.202025-12-17/ url: https://hackmd.io/quqVssZ8TMimTzLNB2YgUw --- # T-lang meeting agenda - Meeting date: 2025-12-17 ## Attendance - People: TC, Josh, Tyler, Niko, scottmcm, Aapo, Robert Seacord, Nadri, Tomas, Yosh, Jack, Amanieu, cramertj ## Meeting roles - Driver: TC - Minutes: Tomas Sedovic ## Scheduled meetings None. Edit the schedule here: https://github.com/orgs/rust-lang/projects/31/views/7. ## Announcements or custom items (Meeting attendees, feel free to add items here!) ### Submitting 2026 Project goals Tomas: You can propose 2026 project goals now: https://rust-lang.github.io/rust-project-goals/how_to/propose_a_goal.html (deadline: end of January 2026) Roughly the same process. Template has been simplified a little. Clarified the team asks (t-shirt sizes based on the level of support required from the team). https://rust-lang.zulipchat.com/#narrow/channel/546987-project-goals.2F2026-workshop Niko: We left a lot of time for discussion. We went over the existing goals and we'll make a draft of the conversations thus far early next year. For our team, if you can handle it purely in triage e.g. a new lint, that's small. If you need a champion, that's medium. If we need to have design meetings, that's large. We don't want too many large things so we should be selective. Tyler: Do you anticipate havinga different granularity goal due to the 1-yejr period? Niko: not really. We say six months but the goals do typically take more. Tyler: Have you thought about course-correcting, updating goals throghout the year? Niko: Yes. Every quarter we'll do a check-in on the goals. I'd like for the bigger things to have milestones that correlate with the checkins. And we're hoping to have morefunding from the Leadership Council to do some of that outreach work. TC: As part of the request for 2026 there will be funding request for submitting a compiler-ops and hoping to be able to get another PM position and I'm hoping to be able to reach out to our second choice if they're still interested. Niko: Josh, the line betwene medium and large we'll have to negotiate a little bit. Just having a design meeting doesn't necessarily imply Large. Josh: So it's more "this probably needs 1 design meeting that needs to be prioritized and reserved in the queue". Niko: I'd put Benno's Field Projections as a large thing. ### Program management vacation Tomas: I'll be off for the next to weeks (starting Monday 2025-12-22 and back on Monday 2026-01-05). TC: Let's talk about our lang meetings. The next one is 24th Christmas eve. And 31st would be New Year's eve. I suspect people would not want to meet then. The next one would be on January 7th. *lots of thumbs-ups* ### Guest attendee items TC: For any guests who are present, please note in this section if you're attending for the purposes of any items on (or off) the agenda in particular. ### Moving right along TC: As we've been doing recently, due to the impressive backlog, I'm going to push the pace a bit. If it's ever too fast or you need a moment before we move on, please raise a hand and we'll pause. ### Design meeting at 12:30 EST / 09:30 PST / 17:30 CET TC: Remember that we have a design/planning meeting that starts half an hour after this call ends. ### Next meeting with RfL There are no Rust for Linux meetings scheduled until the end of the year. TC: Noting for anyone who hasn't heard, Rust is officially part of the Linux kernel; it's no longer an experiment. https://github.com/rust-lang/rfcs/pull/3614 ## Nominated RFCs, PRs, and issues ### "Trait method impl restrictions (`final` methods)" rfcs#3678 **Link:** https://github.com/rust-lang/rfcs/pull/3678 Josh: I think it didn't finish getting boxes checked. TC: I proxied a concern for Amanieu. Amanieu: I really feel the behaviour around dyn compatibility should be a core feature of this RFC not a future possibility. It changes the way users will use `final fn` Josh: You feel `final` should automatically make it such? Amanieu: Correct. Scott: There are cases where having it in the vtable would be useful, so I'd prefer for this to be orthogonal. Tyler: If you know the trait, you know the trait method is final, why do you need it in the vtable? Scott: If it's a provided method that cals other trait methods, it may be useful for those calls to be separate vtable entries. E.g. `RangeBounds` if you have `contains` and you made that final, on a `RangeFull` having a vtable entry that returns `true` is different behaviour and consequences if `contains` runs two matches and does a lookup. If we put somethnig on an `Iterator`, made it final, put in a loop, you'd want the loop inside the dyn. Amanieu: I agree but I think that's an implementation detail. The `final` keyword should guarantee that you can call this method on a dyn trait without that method making the object non-dyn-compatible. It doesn't say anything about vtables TC: Couldn't the semantic be that if you use `final`, if the method would have been dyn-compatible the compiler could decide to put it in the vtable? Josh: That was going to be my suggestion. Marking something `final` if it's not dyn-compatible you wouldn't be able to put it in the vtable anyway. If it could have been dyn-compatible, we could say the compiler gets to choose, or mark what you prefer. Jack: Having the compiler figure it out is not great semantics. I want it to be really obvious whether a function would be in a vtable or not. Scott: Do we want to say "you can always take the `final` off and if it has a lot of vtable consequences??". Adding `final` can't be a non-breaking change but removing it could be? I could see people making their trait methods `final` to start out and then someone showing up with a reason they want to override and the library author wanting to remove it compatibly. Might be fine if they just add `where Self: Sized` anyway though. Taylor: If a trait method is marked as final, for safety purposes you could assume in a downstream crate that you know the upstream's correct. But if the final is removed, that's no longer correct. Josh: We don't want to just say "the complier can decide". But we can defer what the behaviour is. For now, we could have it not-effect the vtable. And then we could choose to add an opt-out, say under some circumstances we could do it automatically. Niko: I second everything. The rule is: is it a dyn-compatible method? Basically, is it a generic? Does it have to be monomorphized? I think we need to change dyn-compatibility. It should be opt-in. Josh: Amanieu, what you're asking for is you want `final fn` to never affect dyn compatibility of the trait. Amanieu: Yes. Josh: That's written in the RFC now. Amanieu: Scott just said it had the opposite definition. Scott: I intended to phrase it as orthogonal. Josh: When I wrote that into the reference-level explanation section was: this does not affect the dyn compatibility of the trait. Amanieu: The other interpretation is: whether or not the function is final could affect dyn-compatibility. Josh: If I reword that function, would that be acceptable? Scott: I like Taylor's point that people depending on it for unsafe, we shouldn't say that removing it is non-breaking. TC: Scott, that's noted in the RFC. Scott: If you want it not in the vtable, you could always add an inherent method on dyn. So the thing in the vtable is what you can't do now. So my preference is for it to say it goes in the vtable. The new capability here is Niko: This has been a fairly complex discussion. I'd feel better if Josh wrote up the summary of the concern, prose and cons and how it's proposed to be resolve and vote on it. TC: Makes sense to me. Josh: Should that be an issue on a repository? Or a comment in the RFC. Niko: The process I proposed was an issue in rust-lang/rust. Josh: I'll write that up. https://github.com/rust-lang/rust/issues/150101 ### "Explicitly export core and std macros" rust#139493 **Link:** https://github.com/rust-lang/rust/pull/139493 TC: We were waiting on a clear understanding what the PR was doing for name resolution. With the help of Jane we now have that. TC: It's taking all the macros not exported in the prelude to the prelude. And taking the code that's not in the macro use ?? TC: There's a compensating change to panic. Interesting is the interaction with no-implicit-prelude. There's been a hack added to pull all built-in macros. panic which was previously not automatically pulled in now does get pulled in along with no-implicit-prelude (along with `unreachable!`). I asked if that could be removed but apparently not. I proposed an FCP. Jack: Is there a way to make future compatibility lint for these? TC: I'd love for someone to put up a lint for FCW. Jack: Would you want to see this before it gets merged? TC: It's a problem for everything else like `assert!`. Almost no one uses no-implicit-prelude. I'd love to see someone removing the line that removes this and then crater run it to see what this FCW would effect. Jack: That's what I'd want to happen. TC: I agree with you. The reason I'd merge this anyway is that this affects so many of our macros. We need to address the holistic problem anyway and this PR has a lot of value in and of itself. Jack: That's convincing. Given how infrequently no-implicit-prelude is, that's something to think about but it's not too concerning. Tyler: I'll check a box. TC: Nadri what do you think? Would you check a box? Nadri: I agree this isn't a huge issue, I'd check a box. As a meta point, I like saying "we'll do this now, and maybe someone can do something better later". Jack: If the expected impact is small, we can leave it open. If adding something greatly increases the scope, it's not as safe to do. TC: Huge thanks to Jane for diving in and also huge thanks to Petrochenkov for supporting Jane on that. ### "const-eval can construct uninhabited values via recursive static initialization" rust#143047 **Link:** https://github.com/rust-lang/rust/issues/143047 TC: We looked at this before. We decided it's a bug, it's unsoundness. We asked to look at the crater run. We haven't seen the crater run back because it breaks the build. This error is having recursive statics, it breaks with this change. TC: I suggested putting the PRs in dependencies so we can do a FCW starting with warn-in-deps. Tyler: Sounds right. Josh: part of my concern was: the things that are dependencies of rustc are also widely used-dependencies. If we patch things like thiserror, we won't see breakages. TC: If we fix thiserror and it doesn't show up in the breakage report, then the breakage report doesn't affect the churn Josh: If you have it in your lockfile and don't do an update that would be broken. I'm suggesting we do as little as we can to do the crater run without changing what's on crates.io. TC: It's up to the implementor. Id' look at what's happening on rustc and I wouldn't want to keep the unsoundness around. Josh: They're not doing something unsound, because they're not using uninhabited. Nadri: It's not just uninhabited. The InBoundsIndex example doesn't use uninhabited: https://github.com/rust-lang/rust/issues/143047#issuecomment-3011571056 Josh: I see. So you can manufacture a type out of thin air you shouldn't be able to create. Josh: Other than the soundness issue, creating the recursive set of static values should be possible to do without unsafe and unsoundness. TC: You don't need unsafe. You can use pointers. Josh: The text as written uses unsafe. Nadri: Creating a recursive thing is safe but in a dodgy way. If you try to read it, const-eval shouts at you. But the issue is that meree existance of this value causes unsoundness. Josh: So this is const-eval's equivalent of having a pointer to uninitialised memory without `MaybeUninit`? Niko: It's the same issue as this: https://smallcultfollowing.com/babysteps/blog/2018/08/13/never-patterns-exhaustive-matching-and-uninhabited-types-oh-my/ Niko: just as with the `match`, it's very obvious that you should be able to use `&` to point at uninhabited things and if you're wearing your safe hat, you want the opposite. I agree with Josh, I want to help the safe code out to be able able to assume that `&T` is a reference to a valid thing. Nadri: This one is about manimulating unsafe values in safe code which is never ok. Feels kinda different, not sure I follow the connection ### "Stabilize 29 RISC-V target features (`riscv_ratified_v2`)" rust#145948 **Link:** https://github.com/rust-lang/rust/pull/145948 TC: We're picking up checkboxes, it's a dual FCP, most of us need to check a box. Scott please take a look. Amanieu: None of these extensions introduce new registers or change the ABI. ### "Revert "Do not check privacy for RPITIT."" rust#146470 **Link:** https://github.com/rust-lang/rust/pull/146470 Nadri: there's a crater running TC: nothing to do on the this one ### "Support importing path-segment keyword with renaming" rust#146972 **Link:** https://github.com/rust-lang/rust/pull/146972 TC: It's making `super` and `$crate` imports more consistent. I'll propose FCP. Tyler: https://github.com/rust-lang/rust/pull/146972#issuecomment-3637894109 has a change description Nadri: The Reference PR linked doesn't reflect the change in this PR. It clarifies the current state. We'll need a Reference PR for that change eventually. TC: I'll propose FCP merge and file that concern. Josh: This looks great to me, checked a box. Niko: I was wondering why we deny `use super::self` Tyler: I think you need to use `self` within braces. There's no reason to use `self` outside of braces. It's redundant. Niko: That sounds like a lint. I want to have some nice consistent axioms. I think about macros and code generators. If it works in braces, it sholud work outside braces. Josh: We still can't support `use self` or `use ::self`, that would imply using `self` which doesn't make sense Niko: I'll raise a concern on the issue, these are some examples ```rust use foo::self; // why would this be an error? use foo::{self}; // OK today. // I expect the following to EITHER both work OR both error: use $path::{self} use $path::self use super; // I can see the argument for this is an error use super::self; // I guess then that this should be // Josh: by that argument, this should work too: use super::{self as name}; ``` Niko: There's the actual path and the name you want to refer to it. `super` and `self` don't have an actual name. If you override them, then you can use them. TC: I think you should file a concern about this. I think the model you're proposing is philosophically not the model they're proposing here. So it'd be good to have clarity. Tyler: Definitely it should be a concern. Your axiom makse sense to me. If we're deciding something away from I want to see why. ## Champion updates / Project goals People: TC, tmandry, Josh, Nadri, Aapo, Jack, Yosh, Tomas https://rust-lang.github.io/rust-project-goals/lang/recent-updates.html ### "Finish the std::offload module" rust-project-goals#109 **Link:** https://github.com/rust-lang/rust-project-goals/issues/109 TC: In short, getting much of this work into nightly has become unblocked. Manuel is doing a lot of good work that's highly strategic for us as a Project. See the updates on the tracking issue for further details. ### "Getting Rust for Linux into stable Rust: language features" rust-project-goals#116 **Link:** https://github.com/rust-lang/rust-project-goals/issues/116 RFC 3848: Pass pointers to const in assembly is merged, we have a tracking issue open. Ding keeps working on the Reference draft for Deref / Receiver and we're keeping the supertrait auto-impl experiment as an alternative/fallback. Lots of design movement on In-place Init and Field Projections. But both are large efforts and the goals are moving to 2026. Ding planned to bring up Field Projections syntax at LPC, I haven't heard back. Tyler: On in-place init and Field projections benig large: I'll create a wiki where we'll centralize a lot of the knowledge we've been building up. It would be great to centralize the knowledge that Nadri and Benno put together. Josh: The updates should include the Rust for Linux major update on it no longer being an experiment. Josh: It also got its first CVE. And separately, there was a confirmation from Google that Rust for Linux is shipped in Android. Josh: This was a crash in userland that brought down the kernel. That's always a CVE. ### "Stabilize cargo-script" rust-project-goals#119 **Link:** https://github.com/rust-lang/rust-project-goals/issues/119 Josh: The current blocker is the front matter stabilization and that's proceeding albeit with some back-and-forth with lang around the `CR` (carriage returns). epage felt frustrated about the back-and-forth as he wasn't involved in those discussions. TC: There's also Jack's concern around item context stripping shebangs and front matter as opposed to expression stripping. Jack: I'd expect if by the time the Reference PR comes, the Lang team should decide whether it's a problem. If after reviewing the Reference PR they think is okay, I'll drop my concern. Unlike no-implicit-prelude this may significantly increase the number of people who might be relying on it. ### "SVE and SME on AArch64" rust-project-goals#270 **Link:** https://github.com/rust-lang/rust-project-goals/issues/270 Tyler: David opened a PR to partially implement the scalable vector side of it. There's been branistorm about the implicit bound of `MetaSized`/`SizeOfVal` on `Deref::Target` and other associated types. lcnr had a blog post on using FCW instead of hard errors for making the transition easier. https://lcnr.de/blog/2025/11/28/implicit-auto-traits-assoc-types.html ### "C++/Rust Interop Problem Space Mapping" rust-project-goals#388 **Link:** https://github.com/rust-lang/rust-project-goals/issues/388 Tyler: Not much of an update. Jon has been doing a lot of stuff in W21. He dot them to approve a paper that says C++ should have a safe subset. Which they rejected in the past. Jack: As a PD, if people have thoughts on what they'd like the Foundation resources to go on. This was discussed in the last board meetings. Let me know if you have thoughts or would like to see something specific, let me know. Josh: That development on the C++ committee is impressive but it doesn't seem to address the C++ interop. Has there been an update on that? TC: Jack with my lang hat on, to answer your question: I'd love to see a lot more reporting from the Foundation-employed full-time people working on this, in terms of blog posts, goals updates, etc. That context, about what is already happening, would help us in steering the direction. Jack: I agree that this is good. But I'm also curious to hear about specific things you want to see. Tyler: Agreed with that. Tyler: Josh to address your question: it lets us in the long run more safe interopt between Rust and C++. Having more annotations on C++ to see whether a function is safe to call or even track lifetimes. Tomas: I had reached out to Jon, but didn't have a lot of success in terms of getting updates on this. Jack: I'm aware that an update should be coming, but have not heard a lot about what is planned for the next year. Knowing what the lang team wants here helps me as a PD to go back to the Foundation with what we want in this space. ### "Continue Experimentation with Pin Ergonomics" rust-project-goals#389 **Link:** https://github.com/rust-lang/rust-project-goals/issues/389 TC: Frank's been working on things. It's been moving along; Nadri's been helping with some of the reviews. TC: The basic idea is still to make what we have work better without foreclosing any of the future work such as `Move`, etc. ### "Design a language feature to solve Field Projections" rust-project-goals#390 **Link:** https://github.com/rust-lang/rust-project-goals/issues/390 Tyler: Last time Nadri had a proposal for first-class smart custom pointers. It leans on existing syntax for talking about places and taking a reference to those places. And adds a new operation to take a projection to a place. Question around: should it be a canonical projection, mode-preserving operation? Josh: I've been talking with Nadri about the first class places mechanism and I'm really enthusiastic about that getting traction quickly. Nadri: Benno and I have been going hard on this. We've got a list of open questions, some things that feel resolved. Open ones: what do we do about mode-preserving stuff, projection one-field-at-a-time vs all-at-once, closure captures, interactions with other features. The heart of it is starting to feel solid, we're more playing with the edges now. ### "Develop the capabilities to keep the FLS up to date" rust-project-goals#391 **Link:** https://github.com/rust-lang/rust-project-goals/issues/391 TC: The FLS team's been going great. Pete and I got the team spun up. We got tshepang on board who's been posting the release updates. We added Hristian recently -- he was on the original FLS team. My mission is to get the team bootstrapped and operating according to best practices. This has been happening. People are doing the right things, e.g. writing tests, precisely checking against the Reference, etc. TC: It's great to have an aligned community working on this within the umbrella of the Project. ### "Evolving trait hierarchies" rust-project-goals#393 **Link:** https://github.com/rust-lang/rust-project-goals/issues/393 Tyler: Taylor's the champion but she's not here. She left an update earlier today. There's a PR to implement this in the parser. The RFC is mostly sitting there, there's been a lot of good discussion on it. I had a discussion with Josh and Amanieu on how this could be used in the standard library. They pulled in some people on the Types team as well. Tyler: Standard library might have a good use for this for their migration to a new WriteFmt trait. Josh: Is there any further investigation around `auto impl Supertrait { type Assoc = impl Trait }`? That was the other thing we needed to evolve certain trait hierarchies. Tyler: It's blocked on supporting impl trait in associated type position. There's also a question on what it should mean in the default context. Josh: So once we have the impl trait in associated type and once we have that we can look at the auto impl Supertrait thing. Josh: We'd love to be able to ship the new Write trait in the next edition. If we can get the features sufficient enough so they're in the nightly of the standard library, that would be helpful. Jack: There's a good possibility we'll get the next solver by the next edition. It's good enough to get something on nightly if the aim is edition. Josh: I'm hoping we'd be able to ship these additional features that depend on shipping the new trait solver. TC: Speaking with an edition hat on, we still need to schedule the next edition precisely, so that will affect what's likely in the next edition. ### "In-place initialization" rust-project-goals#395 **Link:** https://github.com/rust-lang/rust-project-goals/issues/395 Tyler: There have been two main paths: impl init and init expression that Alice proposed. The out pointers proposal that Taylor had written. We've been trying to push the boundaries of both and see how far they go. Yosh made a connection to placing and how that could be implemented in terms of outpointers. Yosh: The way I'm trying to split up the spaces is to say that placing functions is the higher-level notation that should be able to desugar to either one. That makes it more manageable. Tyler: Some people have been advocating for more return value place guarantee. That's the third path under discussion. Niko: I've been thinking that for 2026 I'd like to push on async functions with dyn dispatch (probably with the `.box` operator) which backs up the having a high-level form we agree should be implementable. It's an application of this. Tyler: You could implement it in terms of either one. Yosh: We still need to figure out how we decide between the low-level proposals within the group. The outpointer proposal started talking about owned references and init references. That seems to make great progress. Josh: Has there been any exploration on the init expression side for how we would handle what impl init would the different values (option, result etc.). How would the init expression handle that? Tyler: There's been a proposal to make a Try-like trait that lets you do what Try does. But that's the wrinkle for impl-init. If you return a Result you need to know whether you suceed before calling the init function. Josh: That seems like the major thing to figure out. This seems like the major feature of `impl Init`, that you can put it in an arbitrary generic like `Option` or `Result`. We'd want to evaluate that against any downsides `impl Init` has. Tyler: Rust closures don't do the things like breaking from inside of a closure or do effects across closure boundaries. That's probably what's been pushing progress in understanding what outpointers can and can't do. Tyler: This is a great time to centralize the knowledge in a wiki. Niko: I feel we need to deep dive into this, spend some time. It could interact with effect direction, etc. I was thinking of proposing doing this on All Hands. But maybe blocking time on our calendar would be valueable. Josh: There would be a value in having a design meeting as a second step. But it seems we need to hear enough of both proposals so we can start looking at the tradeoffs and decide which things we want out of these solutions we select. TC: Often when you write things down you learn things. It feels this is at a point where the authoring of the design document (regardless of the meeting) might have a lot of value. Scott: We might even be able to simplify some of the document authoring with people talking about what they want to accomplish rather than just the details. Getting the wishlist out of the different sides would be interesting. Yosh: I planned to write an RFC, just to put it all down. Specifically for placing functions and make that self-contained so we could evaluate it. Something like that might be helpful for the other proposals. Niko: I like the idea Scott is proposing. Kind of get a take on the various 'philosophies' involved and try to craft a medley Nadri: It doesn't feel ready for Lang to be involved directly. But I'm feeling the need to see things written down. We all have our own idea but it's not settled yet. TC: Niko often likes making book repositories on which people can collaborate; it seems that might be helpful here. Niko: Nadri, that sounds good. I think it makes sense that it's not the time for Lang to come in and settle something. But if you wrote it down there'd be value for other people read it and see what that brings up. Nadri: Any time Rust for Linux arrived they demolished our requirements on what we have to do. ### "Reborrow traits" rust-project-goals#399 **Link:** https://github.com/rust-lang/rust-project-goals/issues/399 Aapo: Last month there were discussions on being able to see what the point even is. It's all about making `&mut` exclusive reference semantics available to user types. You can take it by value in your method and call some other methods, use it somehow by value multiple times over and it'll automatically reborow itself. Aapo: You can already do this in userland today, you just need an explicit reborrow method. A caveat is you need to know *when* you should call it. The last use count should reborrow if the last use count ??. This is the purpose fo the Reborrow trait -- to make this automatic and to make it possible to return the values that are created. Tyler: If you implement a manual reborrow method it shortens the lifetime significantly. Actual reborrow keeps the original lifetime. Aapo: That's largely accurate. There are cases where reborrowing `&mut` shortens the lifetime. We have the `CoerceShared` trait. Ding has been helping me, we have a mostly-working Reborrow trait and not quite-working CoerceShared. We're currently only implementing these for a single-lifetime struct and CoerceShared only for a single data field but we want to go forward. Niko: We on the types team talked about the idea of "removing variance". What we get out of subtyping in variance you can also get by unpacking and repacking the structure in a way that Aapo described. I think lcnr talked about refactoring how we handle things internally. Jack: It could be worth poking the types channel and thinking about it. Aapo: That does sound interesting. With multiple lifetimes you'll need to do this for CoerceShared. If there's a types-level work to help us deal with this, that would be great. I'll pop into the T-Types channel. #### Purpose ```rust // Note: not Clone or Copy #[derive(Reborrow)] struct MyMutMarker<'a>(...); fn inner_call<'a>(marker: MyMutMarker<'a>) -> PhantomData<&'a ()> { PhantomData } fn outer_call<'a>(marker: MyMutMarker<'a>) -> PhantomData<&'a ()> { inner_call(marker); return inner_call(marker); } ``` Enable user types to opt in to `&mut`-like exclusive reborrowing semantics. Important note is that this can be done in userland using an explicit `reborrow` method, but returned values cannot originate from a custom type created using the exclusive `reborrow` method as it produces a local lifetime bound to the function's stack. In userland this would not work (referring above): ```rust return inner_call(marker.reborrow()); // marker.reborrow() is a &mut self method ``` In addition to `&mut` exclusive reborrowing semantics we want to support going from `&mut` to `&`; this is called `CoerceShared`. The traits thus look like: ```rust trait Reborrow {} trait CoerceShared<Target: Copy>: Reborrow {} ``` #### Update Basic Reborrow trait has been implemented and works, but currently requires `let mut marker` binding for `marker` for the reborrowing to work: that's a bug and should be fixed. `CoerceShared` is being worked on but is more complex as it requires converting from `T` to `Target`. We're implementing only one-lifetime `Reborrow` and `CoerceShared` initially, and at-most-one non-Phantom data field `CoerceShared` to avoid having to figure out rmeta initially. ### "reflection and comptime" rust-project-goals#406 **Link:** https://github.com/rust-lang/rust-project-goals/issues/406 Scott: Oli has a PR open that Boxy just started reviewing. There's a couple of different ways there. The champion division is great, internally is there's multiple directions of where it ends up. Josh: Couple things in the queue. The thing being reviewed is: PR for adding comptime functions as an experiment. They don't have a syntax but have an internal attribute. Adding functions that you can only call in comptime and not runtime. Next step is exposing some API for the comptime functions that talks to the compiler. And that could then open it to reflection where you could walk the fields of the structs. The further work on designing the exact API is on pause, we need to get comptime in and see what we need to call a function from the compiler. TC: I was talking with oli about stable MIR. What Niko and I discussed is that one pass of the stable MIR could be a subset of Rust. Oli said this is connected to the reflection work. It made me think about rustc_public -- there's a compiler MCP up for it. https://github.com/rust-lang/compiler-team/issues/949 Nadri: That's the new name for stable MIR. Niko: The intention is not to make those stable APIs at present. People still have to build their toolchains on nightly. But it should be a lot more tractable in practice. Long term, I'd like to get to a point where it's possible to do more plugin-y things on stable. Scott: The Stable MIR tried to do a bunch of things that can be upgraded and stable. But now they want to do a version and increase the versions in a stable way so tools can see those. Overall we're not stable enough to have a perfectly stable thing. There's too many things that we want to add that are difficult to add stably. Kind of like `syn` is stable but you have to update your code to use the new stuff. Josh: With my library hat on, I'd be surprised if that directly ends up being related to the api for comptime and reflection. I think that would be more directly executed by the compiler. The major advantage for comptime is to let you navigate structures that are in the compiler's memory. Nadri: stable MIR doesn't serialize. Josh: To clarify, I'd be surprised if rustc_public ends up being part of the story for reflection. Scott: I agree on that. It's pretty much "consume after compilation" API. Nadri: rustc_public has clear ambitions today. If we do get it to stable, the questions of what it means to expand the rust types, that may be used by comptime. My day job is writing something like rustc_public and using it. but it's not there and it'll take a long time. TC: My understanding is you publish a bridge with the crate and you'd bump the new version of the crate. Nadri: we'd need a maximum supported version rust version. TC: Exactly. But you don't know how what's the maximum version when you publish a particular version of the crate, so you'd have to backport that. Niko: The more we can align our interfaces with stable surface areas the fewer questions we need to answer. I think we should move away from MIR in terms of it being the basis for these kind of analyses. My hope is that stable MIR becomes a subset of Rust syntax that we define as the canonical subset. The rest of our semantics desugars to it. That's kind of what Ralf is doing with MiniRust. There are things today where there is no syntax. E.g. giving up a place that you refer to with enum. In mir you can say you have some Option whose field is `Some`. We don't have syntax for that but we'd need that. TC: The specificational side of it is also interesting. If we have a subset of Rust that behaves like this, it could provide a basis for specifying the semantics, opsem, etc. ### "MIR move elimination" rust-project-goals#396 **Link:** https://github.com/rust-lang/rust-project-goals/issues/396 Nadri: opsem discussions happening and no strong consensus I believe. looks hard to get this right in terms of opsem and the current design is being iterated on. Amanieu: This was discussed at the opsem meeting a month ago. Ralf uncovered an interesting issue with the proposal. The way the address of a local is chosen would depend on future information based on how that local is used. That causes issues for formal models of Rust. Amanieu: Both cases start the same way. You observe both addresses of `x` and `y`. `y` is initialised by moving `x`. ```rust // This program has DB let x = String::new(); let xaddr = &raw const x; let y = x; // Move out of x and de-initialize it. let yaddr = &raw const y; x = String::new(); // assuming this does not change the address of x // x and y are both live here. Therefore, they can't have the same address. assume(xaddr != yaddr); drop(x); drop(y); // This program has UB let x = String::new(); let xaddr = &raw const x; let y = x; // Move out of x and de-initialize it. let yaddr = &raw const y; // So far, there has been no constraint that would force the addresses to be different. // Therefore we can demonically choose them to be the same. Therefore, this is UB. assume(xaddr != yaddr); // If the addresses are the same, this next line triggers NB. But actually this next // line is unreachable in that case because we already got UB above... x = String::new(); // x and y are both live here. drop(x); drop(y); ``` (NB is "no behaviour", you don't know which of the future branches are valid.) Josh: NB is this branch is "Never" but as long as there's some other branch that isn't never you can pick that interpretation instead? Nadri: yes. Tyler: What's the inherent problem. Why is moving the assume a problem? Amanieu: Ralf was adamant that this causes a lot of problems for the formal models of the language. Nadri: Can we not figure out statically which locals must be disjoint and which ones may not be? Add some detail to opsem so we don't need to look into the future? Amanieu: it's possible, but you'd need to encode the table of which of these are avalilable at the same time. I'd like to avoid it. Niko: I assumed that we'd require that when we move out of a local variable and reinitialize it, the address that you reinitialize it may be different. Amanieu: In my initial model you'd get the same address. When you reinitialize a field, you need to keep the same address. But in this new proposal moving out of a local may change the address but it must keep it for the field. Niko: This sounds like what we actually what we want. This has been an ongoing discussion for the last five years. Amanieu: I need to rework the RFC with the new semantics and avoid the No Behaviour issue. It will be less powerful. Amanieu: When you initialize a struct with an aggregate constructor, we can have the source local overlap with the field it will be moved into. Josh: So if you're building a local of type `X` and put it in a field of type `X`, you can put it directly where it's going to go, and elide the move? Amanieu: Yes. Josh: But if you're extracting a local of type `X` from a field of type `X` in a struct, you can't do the same, with this new model. Amanieu: Yes. Josh: What about if you throw the rest of the struct away? That would eliminate a lot of moves. I want to keep "take out the field, throw the rest away" without a memcpy. Amanieu: That *could* work. But it breaks down if you do two or more fields. Josh: Would be nice to handle that too, if possible. ### "Const Generics" rust-project-goals#100 **Link:** https://github.com/rust-lang/rust-project-goals/issues/100 Niko: Boxy and I established a time to start syncing and we're talking aobut the 2026 goals. The plan is to make big progress next year. Niko: If folks have ideas for things that are blocked on this work, I'd be interested in better examples and help us move this down the line. ### "Ergonomic ref-counting: RFC decision and preview" rust-project-goals#107 **Link:** https://github.com/rust-lang/rust-project-goals/issues/107 Niko: There's been no motion. My plan is to write up a plan for next year. That will probably begin with the Alias/Share trait. And the `move` expressions. Both of those seem like no-brainers for me. I also have a blog post or two to capture some of the discussions (e.g. how you'd do nested closures and how we can move even forward). ### "Unsafe Fields" rust-project-goals#273 **Link:** https://github.com/rust-lang/rust-project-goals/issues/273 Scott: This is still stuck on the RFC approval. Couple boxes got checked, but there's been concern on which version we want, which parts we want to stabilize. I think people want to hove to an experiment first. Tyler: Given there are open questions there, should I prioritize this in my review queue or wait for the qeustinos to be resolved first. Josh: Similarly, does this need a design meeting? It seems to be blocked on the team, we should figure out how to unblock it. Nadri: If the author is willing to experiment, IIRC the issue around the design is about what people would need to write and the experiment would be great for that. Niko: I thought we all settled on this, Ralf said he wants simple semantics. My sense is we're being reluctant to just make the call. Maybe there's cases for that but are we really looking for data on this? TC: Don't we have an experiment for this? Nadri: I don't recall seeing impl work. TC: I thought we explicitly approved an experiment at least. Josh: We need ot make a call here: (1) go ahead with unsafe to do anything with and we can always add something else later or (2) we want unsafe to write and read fields and then we can bikeshed the syntax. Nadri: IT's already implemented on nightly. Josh: What's the syntax for "unsafe to write and safe to read" variant? TC: On the RFC Scott said we'll want at least some knobs before stabilizing it. And I said if we wanted to stabilize that, we'd want to do a design first. https://github.com/rust-lang/rfcs/pull/3458#issuecomment-3309004965 https://github.com/rust-lang/rfcs/pull/3458#issuecomment-3309611480 Scott: It exists in the compiler, it's not used in the standard library. To move forward I'd like to see what does it look like in say `Vec`. What implications to the code people would write would be. If we can use it in a bunch of unsafe code and see how it comes out, it'd clear things up. Niko: +1 to using the stdlib. if the problem is "we need more usage data" -- let's get it! Tyler: Nadri, does this connect to field projections or custom places? Would I be able to say "this projection could be unsafe to read/write". Nadri: It could in theory. The field projection proposal makes it harder to figure out what "read" and "write" even means Tyler: That's an interesting point. Tyler: Are we hesitated to decide on `unsafe mut` because we can't agree on the syntax or whether it's a good idea? Niko: We often say "we have this thing that's useful but we should block on something that's even more useful". And that makes sense if we don't have a good usecase. But if we have usecases for the current suggestion, then we should do it. Otherwise it demotivates people to doing the work and it lets to the effort to stall. We want the default to be as unsafe as possssible. You want your assumptions to be written out. Therefore this is a subset of the right design. We definitely also want to have safe reads, but those should be opt in. So let's move with this. Scott: Niko said what I was going to say but better. We've talked a lot about not just punting a syntax choice to stabilization. Here we've all decided this is what we want and this is how we're going to write it. So we should accept the RFC with that. Even if I wanted something extra, I don't think that should block the RFC. TC: The part I have concern about is when you said "I don't think we want to stabilize this without doing more things". I want us to agree either that we would stabilize what the RFC says or if not, then we need to talk about those other things. Niko: I agree with that. I think we're ready to stabilize. I'd prefer we do not defer stabilizations for these kinds of reasons. Josh: I have a lot of sympathy for not forcing people to write tons of safety comments. If we can trivially ship the feature, then we should. But if we can't trivially add that and find ourselves blocking on it, let's ship what we have. Niko: But also, no one's using this at all. Nadri: Also, we can make accessors. If you want to disjointly borrow some of the unsafe fields, that's very niche. TC: Scott, do you still feel you'd strongly expect to want things other than this RFC before stabilizing? Scott: I don't know. I'm not feeling that I'd want to block the stabilization over this. TC: OK; that's good enough for me to resolve the concern then. I'll do that and check a box, and that will put this into FCP. Nadri: This seems like some sort of a misshap and it would be great if we expressed that on the RFC. Josh: +1. Nadri: How did this happened? TC: It's on our radar but not nominated. Niko: This is what this process was to do. Tyler: We don't have the process for RFCs in general, but for Project goals at least. Niko: I agree, we should show empathy. I'd also like us to write down how to adopt these things going forward. ## Nominations not reached ### "Stabilize ppc inline assembly" rust#147996 **Link:** https://github.com/rust-lang/rust/pull/147996 Josh: Proposed FCP. ### "Stabilize Frontmatter" rust#148051 **Link:** https://github.com/rust-lang/rust/pull/148051 ### "Consider `Result<T, Uninhabited>` and `ControlFlow<Uninhabited, T>` to be equivalent to `T` for must use lint" rust#148214 **Link:** https://github.com/rust-lang/rust/pull/148214 ### "Stabilize the `supertrait_item_shadowing` feature" rust#148605 **Link:** https://github.com/rust-lang/rust/pull/148605 ### "const-eval: always do mem-to-mem copies if there might be padding involved" rust#148967 **Link:** https://github.com/rust-lang/rust/pull/148967 ### "Promote `uninhabited_static` lint to a hard error" rust#149518 **Link:** https://github.com/rust-lang/rust/pull/149518 ### "reduce `unreachable-code` churn after `todo!()`" rust#149543 **Link:** https://github.com/rust-lang/rust/pull/149543 ### "resolve: Report more visibility-related early resolution ambiguities for imports" rust#149596 **Link:** https://github.com/rust-lang/rust/pull/149596 ### "stabilize `cfg_select!`" rust#149783 **Link:** https://github.com/rust-lang/rust/pull/149783 ### "Do not deduplicate captured args while expanding `format_args!`" rust#149926 **Link:** https://github.com/rust-lang/rust/pull/149926 ### "deprecate `Eq::assert_receiver_is_total_eq` and emit FCW on manual impls" rust#149978 **Link:** https://github.com/rust-lang/rust/pull/149978 ### "Revise decision process: champion vs FCP decisions" lang-team#360 **Link:** https://github.com/rust-lang/lang-team/pull/360 ### "Fallback `{float}` to `f32` when `f32: From<{float}>` and add `impl From<f16> for f32`" rust#139087 **Link:** https://github.com/rust-lang/rust/pull/139087 ### "`#![register_{attribute,lint}_tool]`" rfcs#3808 **Link:** https://github.com/rust-lang/rfcs/pull/3808 ### "`RUSTC_ALLOW_UNSTABLE_<feature>`: a `RUSTC_BOOTSTRAP` alternative" rfcs#3882 **Link:** https://github.com/rust-lang/rfcs/pull/3882 ### "CMSE calling conventions" rfcs#3884 **Link:** https://github.com/rust-lang/rfcs/pull/3884 ### "Add `cargo_cfg_target_family_multivalued` FCW" rust#147545 **Link:** https://github.com/rust-lang/rust/pull/147545 ### "Add a FRC about implicit numeric widening" lang-team#356 **Link:** https://github.com/rust-lang/lang-team/pull/356 ### "RFC: cfg_target_version" rfcs#3750 **Link:** https://github.com/rust-lang/rfcs/pull/3750 ### "repr(ordered_fields)" rfcs#3845 **Link:** https://github.com/rust-lang/rfcs/pull/3845 ### "Match guard can both move and static-promote a single constant" rust#145237 **Link:** https://github.com/rust-lang/rust/issues/145237 ### "`ref` patterns can const-promote a single constant more than once" rust#145555 **Link:** https://github.com/rust-lang/rust/issues/145555 ### "Uplifts and extends `clippy::needless-maybe-sized` into rustc" rust#145924 **Link:** https://github.com/rust-lang/rust/pull/145924 ### "Decide about future of `rustc_legacy_const_generics`" rust#146613 **Link:** https://github.com/rust-lang/rust/issues/146613 ### "Tracking Issue for enum access in offset_of" rust#120141 **Link:** https://github.com/rust-lang/rust/issues/120141 ### "Stabilize the `breakpoint` function" rust#142325 **Link:** https://github.com/rust-lang/rust/pull/142325