Triage meeting 2026-01-21

--- title: Triage meeting 2026-01-21 tags: ["T-lang", "triage-meeting", "minutes"] date: 2026-01-21 discussion: https://rust-lang.zulipchat.com/#narrow/channel/410673-t-lang.2Fmeetings/topic/Triage.20meeting.202026-01-21/ url: https://hackmd.io/FSWxiB4YSliT-dtIT6uPxQ --- # T-lang meeting agenda - Meeting date: 2026-01-21 ## Attendance - People: TC, Jack Huey, dianne, Tomas Sedovic, Josh Triplett, Aapo Alasuutari, Niko Matsakis, Tyler Mandry, @martinomburajr, Chris Sena, Yosh Wuyts ## Meeting roles - Driver: TC - Minutes: Tomas ## 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!) ### 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 We're next meeting with RfL on 2026-01-28 (next week) to review the status of RfL project goals. https://github.com/rust-lang/rfcs/pull/3614 ## Nominated RFCs, PRs, and issues ### "Don't try to evaluate const blocks during constant promotion" rust#150557 **Link:** https://github.com/rust-lang/rust/pull/150557 TC: This is a stale nomination. ### "Feature-gate `mut ref` patterns in struct pattern field shorthand" rust#151102 **Link:** https://github.com/rust-lang/rust/pull/151102 TC: Seems we missed a feature gate somewhere. Josh: It was feature gated except in the struct pattern shorthand. Josh: `ref mut` is "I want a mutable reference". `mut ref` is I want an immutable reference the pointer to which is mutable (I can change the pointer). Josh: This is stable. It's been stable for 18 months. We could do a crater run. Or: do we want to ship it? Tyler: Someone did the crater run. It's mostly clean. Josh: Option 1. unstabilize. Option 2. it's been in use for 18 months, do we just stabilize it? Do we have a stabilization report? (we don't) TC: I'm in favor of a revert. To get it right. Josh: I agree. If we had a stabilization report we could consider it. Niko: We should do the revert and encourage stabilizing it. Tyler: There were discussions aroung the syntax. Should we use parentheses? There were some open threads we left. ### "Stabilize Frontmatter" rust#148051 **Link:** https://github.com/rust-lang/rust/pull/148051 TC: Ed wanted to bring this up. But he's not able to be here. He said he'd prefer for us to defer the discussion. ### "Remove edition-dependent behavior on `panic`" rust#151084 **Link:** https://github.com/rust-lang/rust/issues/151084 TC: Does anyone recall us adding an edition-dependent behavior recently? In the last few months? Josh: This is something new? TC: Yes (no one remembers this) TC: We FCPd a PR that added an edition-dependent behavior. It wasn't clear in the FCP. TC: Wearing my edition hat we're going to pull it out. But I wanted to check with the lang team. The contributor is not happy with us and they're not going to pull the edition-dependent behavior themself. Josh: What's the actual change? TC: To prevent crater breakage we added a hack around how the panic name is resolved. We'd like to get rid of that at some point. There is a code comment about removing it at some point. Josh: What is the resolution difference? TC: If you bring the name `panic` in the scope via the standard library prelude and you also bring it via the glob import, one of them takes precedence. Niko: I remember this -- the discussion about this. My recollection was we wanted to address this via the Reference. TC: We did complete an FCP on it. jane came back and explained what this was doing, that resulted in changes in the PR itself. And we documented in the Reference what it does. I don't remember our settling how to do this in the Josh: Do we have the minutes for this? TC: The procedure was broken. Even if the Lang approved this, it also should have gone through the edition team. Jack: Looking at the code, it's not a named edition. It's just checking for anything above 2024 that would have a particular behavior. TC: That's a distinction without difference. When we talk about something going to an edition, it will automatically go into the next named edition. Niko: The right thing would be `if edition.name == edition.next` right? TC: Yes. Jack: In terms of the procedure, what was FCPd was not necessarily talked about and everybody wasn't clear what happened here. The code matches the text. TC: You've got to look at the whole edit history. This issue went through a ton of cycle with the lang team. It's not enough here to just look at the state of the top post. But even given that I agree we missed it. Josh: What was desired was to put this into the next edition and put up an FCW so everyone can fix it. Was that the expectation here? TC: That's one option that seems reasonable. Niko: Say that again Josh? Josh: For changes that would break crater a lot. Sometimes we make the change in the latest edition and put in an FCW to get the ecosystem adapt and then make the change in the previous editions. If we're doing FCW to try to get the ecosystem to stop relying on the behavior, it would disrupt the ongoing ecosystem move. TC: All we're talking about is reverting the edition check. Josh: I see, so the only thing proposed is removing the 2026 edition opting into the new behavior. We're just talking about deletenig an `if` TC: And I don't believe there's any FCW. Niko: What is the right path forward? What is the answer we eventually want? TC: We could put it in edition.next and we have procedure for that too and it would need to do more: tracking issue, nightly feature flag. It's a bigger change to put it into edition.next. My preference would be deleting the one element of the `if` block. We need to pull that out and than put it in correctly (e.g. to edition.next) Josh: +1 for doing the minimum oneline change to drop it from the future edition opt in. It sounds like we also want to have a clear review and what the process for getting something into edition.next is. I thought getting it into edition.next should make it easier for adding it and then the Edition team reviewing whether it goes into the next edition. Jack: +1 Niko: I'm good with it. I just noted the "contributor is unhappy with us" which is a good flag for us to dig a bit deeper. TC: All we expect is that there's a feature flag and a tracking issue (just like we expect for any other feature flag). Eric wrote it down, we can review it and discuss. This isn't asking for Lang team decision, it falls entirely into the Edition process. This is an FYI for the Lang team and to check whether we intended to do this. Josh: Do we want to go ahead for FCW going this across all editions? There is an issue already marked for the lint. The lint is implemented, are we ready to mark it as deny and report-in-deps? Tyler: It wasn't that much, last week? Josh: The tracking issue is October. https://github.com/rust-lang/rust/issues/147319 Jack: What was the plan to revert here again? Is it to remove the edition part? Josh: Right now there's a compatibility hack for panic. Right now it's conditioned on the 2026 edition. The plan is to remove that edition check and do the compatibility hack everywhere. TC: I'd love to bump the lint to deny but I'm not sure we've had enough time. Josh: The tracking issue open date was October. But the lint went in last week so I'm not proposing deny-in-deps. ### "Support importing path-segment keyword with renaming" rust#146972 **Link:** https://github.com/rust-lang/rust/pull/146972 Josh: We asked the PR author to make the change. Petrochenkov suggested doing what Niko requested in the second PR. I think this is ready to go in and there's going to be a second PR doing the changes. TC: I'm looking at the companion Reference PR. Does anyone has a concise summary of the PR's diff? Josh: I believe that's as described at the top of the PR. It now allows import of `self` or `super`, `$crate` with renaming. Previously we allowed `::{self}` and this is not removing those. The top comment is still accurate. TC: It's not been updated since early December so presumably it is incorrect. What you're saying is that it's correct modulo what we're chosing for compatibility. Josh: Yes. The thing we're allowing for compatibility falls into the category for redundant self. For which petrochenkov will open a lint later. TC: Niko, does this align with your model? Niko: I don't really understand what what this is. Josh: There's an update here: https://github.com/rust-lang/rust/pull/146972#issuecomment-3637894109 and an update here https://github.com/rust-lang/rust/pull/146972#issuecomment-3760497831. I believe those two cover what this is doing. Josh: This is marked as FCP. It's no longer breaking the ecosystem. I propose we start an FCP so people can review and check boxes based on these comments. Tyler: The comment says "unbreak most regressions" Josh: We reviewed a crater run. They reviewed it and said this will likely fix 90% of the breakage. Niko: They wanted to disallow `crate::self`. Tyler: That makes sense. Josh: The other thing (which we reverted) was this: `use std::{io::self};` TC: I kicked off a try build. Once that's done I'll run crater. Niko: To answer your original question I feel comfortable with these changes. They meet what I asked for. ### "Inhibit all-absent-variant optimization for all enum reprs that inhibit layout optimization, not just repr(C)." rust#146989 **Link:** https://github.com/rust-lang/rust/pull/146989 TC: We're waiting on crater. ### "Stabilize the `supertrait_item_shadowing` feature" rust#148605 **Link:** https://github.com/rust-lang/rust/pull/148605 TC: We need to ping Amanieu. I haven't seen a reference PR. Niko: I didn't have a checkbox to highlight Jack's comment: https://github.com/rust-lang/rust/pull/148605#issuecomment-3638285229 Jack: I don't think that's a blocking concern. TC: I believe it's more errors we can relax. Jack: I think for relaxing errors, there's a question for the types team. I'm not sure it's so easy to relax them. That was the start of my concern. It's errors that will be inconsistent. Niko: Having it resolve to an error is Ok and we can try to make it work later. ### "Make PinCoerceUnsized require Deref" rust#149218 **Link:** https://github.com/rust-lang/rust/pull/149218 TC: We have a proposed FCP. We need one of Amanieu, Scott or The 8472. ### "resolve: Report more visibility-related early resolution ambiguities for imports" rust#149596 **Link:** https://github.com/rust-lang/rust/pull/149596 TC: We have na FCP. Niko you've put forward an alternate model. Petrochenkov noted this is the only thing blocking parallel import resolution. TC: Petrochenkov replied to Niko's thoughts on the parallel model: https://github.com/rust-lang/rust/pull/149596#issuecomment-3674995358 Niko: I think this change is very surprising. I want to understand why we're doing it. Looking at petrochenkov's comment. TC: The use imports create a new module in declaration. Niko: I think Petrochenkov's is not a common expectation for most people. That a `use` statement is like copying and pasting but with a different visibility -- redeclaring an item. Vs. a shorthand for a path so I don't have to type it all the time. TC: I kind of agree, but this is how it works in a lot of languages. When you import something you really are copying a name. It's like a `let` assignment into that scope. Niko: I disagree. I see your point. But in e.g. Python there's a class that exists. I'm making another name, but it's still a pointer to the same class. So I'd expect the visibility be the same. TC: You've got an obojcet that represents the object. In Python you're creating a new object in the module. Niko: You're creating another reference of the object. TC: When you do `dir()` you get all the locally defined items as well as all the references. Niko: I think that's true in my model. I'm not saying the things don't exist. I'm saying they're pointers. Tyler: My comment here points out an issue with Niko's model and glob imports.. https://github.com/rust-lang/rust/pull/149596#issuecomment-3639221667 Tyler: Nadri pointed out an issue of glob imports: if we adopted themodel, the change to the behavior of glob imports would cause us to start exposing a lot of new public API surface in existing crates that didn't exist before. Niko: Can you give me an example? Tyler: ```rust mod internal { mod inner { pub struct Foo; } pub(crate) use inner::Foo; pub struct Bar; } pub use internal::*; // `Foo` would now be part of the public API of the crate ``` Niko: Is that a realistic example? To me that's the expected behavior. Tyler: I do think it's realistic. That's a pattern I've seen. You have an inner module, you put `pub` on a bunch of things, you use something from it internally. There's an `impl` pattern where you have an impl of an operating system and another operating system. Niko: Another way to say it is: since most people don't think of use statements as declaring something, there's a risk that it would expose this. I think in your example it would not become part of the public API. It's a public name to `internal`. With `pub(crate)` it would. Niko: I could understand why writing `pub(crate)` you might be surprised why you'd be able to export it. Tyler: There are crates that are relying on this behavior. So this would probably need to be an edition change. Niko: I don't like it but the conservative argument is appealing to me and I see TC's point. If I wanted to take an external crate and re-export a subset of its things, I see the appeal. Josh: I agree but want to note: the [tracking issue about improving macro visibility overall](https://github.com/rust-lang/rust/issues/148610) is the behavior we want to move to in a future edition. Josh: If we're making this an edition-dependent change, we also want to make the macro visibility change too (which is already for the next edition). ## Nominations, part 2 Attendees: Eric Holk, TC, James Muriuki, Tyler Mandry, Tomas Sedovic, Jack Huey, Josh Triplett, Aapo Alasuutari Driver: TC Minutes: Tomas ### "Mark const SIMD intrinsics as indirectly stable" rust#149648 **Link:** https://github.com/rust-lang/rust/pull/149648 Josh: Anything that's going to be used in `const` context in stable must be marked as "capable of being exposed in const". And this is making SIMD intrinsics in const context. TC: Ralf asked for a write-up. Josh: This is procedurally asking us to expose specific SIMD intrinsics. If the const-eval folks are fine with this then we defer to that. TC: the first comments: > recently most SIMD intrinsics were made available in const contexts in #147521. This PR makes the indirectly stable to use in const contexts. TC: Why don't we do it in the reverse order? Tyler: I have the same question. Josh: We have a belt and suspenders mechanism to make sure we don't expose new stable behavior in const without having that behavior marked explicitly. Without this attribute, if you even indirectly call one of these functions in const, it would not work stably in const. TC: We believe we're not allowing new code to compile? Josh: We're allowing code that wouldn't compile before if it uses these intrinsics. But we're not allowing new capabilities. TC: You believe we're allowing new Rust surface syntax to compile? Josh: Functions in the rust standard library that call these functions will now be able to call in const context. TC: You're saying the stable code cannow call these library functions that it couldn't call before. Josh: Yes. TC: Do we have a list? Josh: They're in the PR. TC: Those are the intrinsics. What are we exposing them through? Josh: Intrinsics are always considered a language capability, but in this case they're not new capabilities, they're new optimized spellings of existing capabilities. They're all doing basic math memory. TC: I'm looking for an example of code that compiles today that it wouldn't compile before. Tyler: I think we're exposing the intrinsics directly. But the PR description is confusing. TC: Josh if you feel comfortable with what we're doing here please propose the FCP directly. I don't feel comfortable. Josh: I'll start the FCP and give a summary of the language surface area this enables. ### "stabilize `cfg_select!`" rust#149783 **Link:** https://github.com/rust-lang/rust/pull/149783 TC: https://github.com/rust-lang/rust/pull/149960#discussion_r2692378060 TC: We signalled that we wanted to have exhaustiveness checking. Folkertdev raised we can do that, but it's hard. I think we could do it. Josh: My understanding was we didn't want to do it on compile time unless you actually hit the case where you don't have a match for. It would be a hard error if you're missing a branch. But that's it's fine to write `cfg_select! window / unix` and that we'd error if you weren't on any platform. But it should be ok if you're on the right platform. TC: We're talking about unreachable checking. Josh: I don't think we want to repoen whether the entire cfg_select is exhaustive. The question is whether the lint is sufficient to move forward or whether we require a new lint TC: That's correct Tyler: IS this a question of the lint name? TC: I think the lint name is correct but there's space for lint expansion later Josh: That's my understanding. I think we should ship this without expanding it and then say "we're open to this lint being more capable in the future" Tyler: We have lints that are best effort so I think we should go ahead and ship it. Josh: Our current unreachable lint is best-effort too. There may be unreachable code that the compiler doesn't know that. TC: I'm fine for this lint to be best effort as long as we're buying into the lint expansion in the future. Josh: This needs an FCP. If we don't feel this lint is a blocker, should we start an FCP. Josh: We asked for the lint to be added. We should start an FCP on the stabilization, not let the FCP go through until lint is in but write on the lint that we can do that. TC: It can be confusing that we start an FCP on the PR before it's in the final state. I suggest we let the PR in and let the author update the PR and then start an FCP. Josh: This PR I don't expect to change. The other PR isn't going to change this one, we just want it to merge before we merge this one. TC: It does. We're adding this lint as a separate PR -- under a feature game. So the stabilization PR will be removing the feature gate as well. Josh: Sure. TC: Do we want to talk about the rustfmt situation? Folkertdev is willing to do a lot of work. He's implement this on rustfmt but he needs help and we're under resourced there. (1) can anyone help him? (2) if not, are we ok shipping this accepting that rustfmt won't format anything inside this block. This is what happened with `let else` and peple found that to be unpleasant. Jack: Did the style-t meeting decide what they wanted to see in rust fmt? TC: We have more-or-less clarity of what we want to see in Style. But rustfmt has not been moving. Jack: On the rustfmt side, is it review capacity? What is not moving? Are they unclear what the style is? Josh: There's not a lot of clarity. The implementation turned out to be non-trivial. Folkert needed help and there's not bandwidth to help him with the implementation or finish the implementation. TC: The rustfmt is often months/years out of date. Josh: We did a big sync. TC: But we didn't do anything systematically. Jack: Is Folkert unable to make the changes? Or are they not clear what changes needed to be made? What could I do if I wanted to jump in? Josh: Understand rustfmt better and help Folkert to finish the change. Jack: So it's not lack of review capacity, it's lack of knowing what to do. TC: It is lack of review capacity as well. Josh: The people who know how to do the implementation don't have bandwidth. And people who have the bandwidth don't know how to do the implementation. TC: Yes. And if we're struggling to get pointers back to the implementer, we'll struggle with the review as well. Tyler: Ideally we'd have rustfmt suport for this the day it landed. If we don't, people's CI will probably going to break once it's added if they're using this feature. If it's hitting lack of capacity I don't think we should block on that. Jack: +1 Josh: Could we set a deadline for an implementation. And if there's not one, we're proceeding anyway? TC: That's implicit in the FCP. Josh: One option for the deadline is the release of the next stable date. TC: We'll land the lint, FCP it and that will set a deadline for it. ### "Do not deduplicate captured args while expanding `format_args!`" rust#149926 **Link:** https://github.com/rust-lang/rust/pull/149926 Josh: There was a previous discussion where we discovered that there was an issue with how we expanded fmt_args. We deduplicated capture arguments. If you did `format_args!(x, x, x)` it would deduplicate that and only capture `x` once. Non-idempotent `Display`/`Debug`/`Drop` etc. would be hit on this. This is a surprising behavior. Josh: I'm adding an RFC for the ability to do fields `"{x.y}"`. That would make this the same issue for Deref. We proposed that we deduplicate it. Then Mara came along saynig we shouldn't take that out, it's an important optimization. We shouldn't deoptimize a thing where Deref etc. were doing something non-idempotent. TC suggested we could do the optimization only when it's not observable. Josh: We need to decide: (1) should this have included libs-api? (2) Is this something we want to change our original proposed behavior on? Josh: There options: (1) keep deduplicating, (2) stop deduplicating entirely, (3) deduplicate only where the behavior is not observable. TC: Procedurally, Mara's not on Libs API so this is not a Libs-API request. Josh: The question is whether the Libs-API team should be notified. TC: regarding optimization, dianne says: https://github.com/rust-lang/rust/pull/149926#issuecomment-3752159708. I buy that. > If we're only concerned with how many drop-sensitive temporaries are created, this is much easier to solve. We could optimize in the most common case (multiple mentions of local variables in a formatting string) without even needing type information when expanding format_args!, since taking a reference to a variable won't create a temporary; it's just named constants and nullary constructors where that can be an issue. Josh: So we'd optimize the common case by observing the local context that would tell us that this is idempotent? TC: Correct. TC: What dianne suggests is entirely intrinsic matter. We would keep our lang proposal as is. Josh: We still want the behavior to be that it's not going to be deduplicated if TC: We don't need to say that. The compiler is always free to deduplicate without saying anything. Josh: We should post that clarification that we're fine doing this as if optimization always. TC: If Amanieu said he'd wanted libs-api I'd add that. Without that request I feel this is entirely in lang jurisdition. Tyler: `format_args` is built into the language. Josh: I'm asking whether it is lang + libs-api since it's observable for libs-api observations. Jack: It doesn't hurt to add libs-api. Procedurally it'd be nice to kick-off a perf run. TC: I've asked Amanieu whether he cares about Libs-API being here. I propose Amanieu's response on whether Libs-API cares. Jack: Josh is Libs-API. Do you want Libs-API on the FCP? Josh: Adding the team whom we expect to just check the boxes is unfortunately. But procedurally I think this should be libs-api. TC: Why do you think this is libs-api procedurally? As it is, we're changing intrinsic language behavior of a built-in language item. Jack: We have separation of concerns of separate teams. If Josh is speaking as Libs-API thinking that libs-api should be included, I don't want to be in business of teams questioning other teams. Especially on something like this where it is murky. In the past we erred on the side of caution in cases where it was murky. TC: That's why I reached asynchonously to Amanieu as the lead of libs-api. Josh is also a member of the lang team, if he's raising it I want to know why he's raising it. Josh: As the RFC author I don't want to delay this. But I think this is libs-api as it exposes a surface in the standard library. TC: Are you asking me to cancel the FCP and restart or wait for Amanieu? Josh: I'm proposing we cancel the FCP and restart. Tyler: I don't see it as clearly as libs-api in my mental model. I can see how it's murky. Josh: To be clear, likewise. TC: I proposed `fcp merge lang,libs-api` TC: Tyler, where are you on the underlying issue? Tyler: I'm going through the comments. There are comments from Jubilee about it being a bad idea and there being a misunderstanding. Josh: I think the issue was that this was documented but it potentially being a surprising behavior. TC: Tyler, what we do for array costructors with a repeat operand is: we drop it exactly the number of times the repeat operand is. We've doubled down on that. Tyler: I remember that and it's motivating. I still want to read through the comments. ### "deprecate `Eq::assert_receiver_is_total_eq` and emit FCW on manual impls" rust#149978 **Link:** https://github.com/rust-lang/rust/pull/149978 TC: We have FCP, no concerns filed. Tyler: this is a doc-hidden method on the `Eq` trait. It was stable so anyone could have implemented it. This is doing a FCW on anyone that overrides it and marking it deprecated. Makes sense to me. TC: The original lint name was horrible. I suggested a rename and the current name is better: `internal_eq_trait_method_impls` Josh: Amanieu also showed how to do this without having this method. Which is what we should move the standard library `Derive` to. Tyler: I wondered why this was necessary in the first place. Josh: We didn't have const blocks and had to put the assertions somewhere. ### "Implement lint for black_boxing ZSTs" rust#150037 **Link:** https://github.com/rust-lang/rust/pull/150037 TC: Nominated, we haven't started an FCP yet. Eric: Sometimes the black_box hint doesn't do anything. And this is creating a lint that warns about that. It's a lint so it's nominated for lang to approve. It seems good to me. Josh: It'd be helpful to know how you can observe the black box is not doing anything. Eric: https://github.com/rust-lang/rust/pull/150037 Josh: I see. It didn't occur to me that someone would apply it to a function pointer and then call the function. This makes sense to me. Jack: Is it possible to make black_box work on function pointers? Eric: Ralf said that it's not even really clear what that would mean. And we're at the mercy of LLVM being able to do the right thing. Tyler: When you pass the value through a black box you keeep the type informaition but you lose the value. But for a ZST you're not losing the value. TC: Are we happy with the lint name? Josh: Yes. ??: Agreed TC: Good enough for me. I'll start the FCP. ### "Resolving lang concern on `dyn`-compatibility of `final fn` trait methods (RFC 3678)" rust#150101 **Link:** https://github.com/rust-lang/rust/issues/150101 Josh: I have an RFC ofr having `final` methods. The discussion was whether `final` methods should be excluding from affecting `dyn` compatibility. I filed an issue to explicitly say I adjusted the language in the RFC to explicitly disambiguate it and say that `final` will exclude something to matter for `dyn` compatibility. You don't go through the v-table for a final function. TC: The concern was resolved, the RFC can go through. Josh: Yes, I think this is resolved through my change. ### "`#[expect(redundant_lifetimes)]` doesn't work when `#[derive(Debug)]` is present" rust#150553 **Link:** https://github.com/rust-lang/rust/issues/150553 TC: If you put `allow` over a `Derive`d struct that's going to generate a bunch of code -- you should propagate allow to the generated call. What do we expect when we apply `expect` over the derive? Josh: I'd expect the result of `expect` here, anywhere you write `allow` for a warning to go away, you can write expect for the warning to go away. There's no circumstance where writing `expect` should at least have the effect of `allow`. TC: Your model leads to: in the context of putting this over code expansion, at least once warning in the struct itself or any of the generated code should be silenced. Josh: Correct. TC: How do we express that as a language model? Josh: If we had a mechanism for grouping things around item levels, we could write `expect` around a bunch of things. Tyler: If we group all the `expects` by the span, and treat all expect attributes as the same span attribute we could do this. Josh: That seems like a great idea. When you write `expect` once you expect for itto silence at least on ething. Jack: Sounds implemeentable. Also scary. Jack: A better feature would be able to put items in an outer block and put `expect` on it. Josh: People asked us many times. They also want to apply `cfg`s to that. Jack: Yes. So maybe there's a short-term compiler solution. But long term we could do that too. Are there other concerns? TC: Do we have an RFC for this? Josh: We don't. Josh: The reason it's not as trivial is that braces (`{ ... }`) as the obvious grouping mechanism also introduces a scope. What happens if you write a `fn` inside the braces? Is this a scope or just a group? TC: Good point. It almost implies anonymous modules. Grouping these but not treating them as anonymous modules. Jack: That's a good callout. Is there anything Lang can say here? TC: We're being asked to speak on the idea of just propagating `allows` into the `Derive` code. We can say we really like the idea Josh proposed. We should expect to see the warning at least once. TC: If you write your own derive macro you'll have the same problem. Tyler: I can write a comment on this. Does anyone know who was involved in the implementation of `expect` so we can ping them? TC: I don't remember but I expect Urgau would know. Might even have been him. Josh: The same semantics you described Tyler would also work if at parse time we assigned a unique ID and treat it as unique based on the ID. Either would be semantically equivalent. Jack: +1 ### "Make operational semantics of pattern matching independent of crate and module" rust#150681 **Link:** https://github.com/rust-lang/rust/pull/150681 TC: We have a proposed FCP. No concerns. It's a dual FCP with opsem. Josh: I remember us deciding to stop having the special case. TC: I the top of the PR description he sets out three things. We're not doing the first one. My proposal is that items (2) and (3) are obvious and we should do them. Item (1) is less obvious and we should discuss them separately. TC: This is saying we're applying the cross-crate behavior into the intra-crate. That's Item (2). And Item (3) is a bugfix, making this do the thing we've already documented in the Reference. Tyler: Is there an intention that we'll make it not impact opsem at all? TC: They'll make a separate proposal for (1). But that does require more context to load up. We expect the author to propose item (1) for us to follow-up on. ### "Add FCW for derive helper attributes that will conflict with built-in attributes" rust#151152 **Link:** https://github.com/rust-lang/rust/pull/151152 TC: I don't recall us discussing this earlier. There's an ask here for how we name this. It's also a new lint and FCW. Josh: +1 for the lint and FCW. Let's try to spend as little time on the naming as possible. Josh: Give the desire to pluralize it, `derive_builtin_addrs_ambiguous_addrs` TC: I propose we punt this and one of us to think carefully on how to be concise. Josh: Can we post a summary we don't see an obvious issue with the lint and FCW. Could we start an FCP and file a concern for the lint name? TC: The idea seems obviously correct to me but I do want to review it more carefully. Procedurally, filing the FCP and concern on the name is OK. But then if you miss the meeting next week. Josh: I was going to ask you file a concern because I don't have a concern with the current name. TC: I think we have an RFC that proposes lint name conventions. Josh: Then can we have a lints team to delegate to, so that lang doesn't spend time on it. ### "UB inconsistency when derefing a place in a closure" reference#2121 **Link:** https://github.com/rust-lang/reference/issues/2121 Josh: Because the closure capture rules, capture `**r` and because it's not read, that's not treated as UB. But outside that we do the operation and then ignore it and the operation is UB. Josh: There's not an ask for us for which direction to take. Just to resolve inconsistency. It seems to me that the second action is UB. So if we were to make this consistent, the first one should be UB too. Jack: Given Ralf's comment, this shouldn't even be hard to implement. Josh: I expect that `let _ = **r` is treated as an operation performing `**r` which is UB in this case. And the thing not handled as UB is that `let _ = **r` is not a *read* of `**r` and closure capture doesn't capture `**r` because it's not read. Jack: It's easy to make closure capture to do `*r` because `*r` is read. Josh: I hope it's trivial but also we need to crater it. It would change what closure capture. TC: It would be great to leave these as comments. Tyler: The ask for us is that the closure and non-closure examples should act consistently. I agree with that. I'm comfortable filing an FCP. Jack: Tyler, what do you think the FCP should be? Tyler: That the closure one should be UB. Jack: Do we want to see an implementation to see if there's crater breakage? Tyler: Good point. We'd FCP the implementation change, the Reference change and crater run. Do we have consensus? TC: I need to look at it while not on a call. ### "Guarantee `repr(C)` union field offset" reference#2128 **Link:** https://github.com/rust-lang/reference/pull/2128 TC: I think we can check this off. It's a fairly well-settled point. Tyler: Yeah. (The meeting ended here.) --- ### "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 ### "RFC: Exhaustive traits. Traits that enable cross trait casting between trait objects." rfcs#3885 **Link:** https://github.com/rust-lang/rfcs/pull/3885 ### "Complex numbers" rfcs#3892 **Link:** https://github.com/rust-lang/rfcs/pull/3892 ### "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 ## Project goals ### "Const Generics" rust-project-goals#100 **Link:** https://github.com/rust-lang/rust-project-goals/issues/100 ### "Ergonomic ref-counting: RFC decision and preview" rust-project-goals#107 **Link:** https://github.com/rust-lang/rust-project-goals/issues/107 ### "Finish the std::offload module" rust-project-goals#109 **Link:** https://github.com/rust-lang/rust-project-goals/issues/109 ### "Getting Rust for Linux into stable Rust: language features" rust-project-goals#116 **Link:** https://github.com/rust-lang/rust-project-goals/issues/116 ### "Stabilize cargo-script" rust-project-goals#119 **Link:** https://github.com/rust-lang/rust-project-goals/issues/119 ### "SVE and SME on AArch64" rust-project-goals#270 **Link:** https://github.com/rust-lang/rust-project-goals/issues/270 ### "Unsafe Fields" rust-project-goals#273 **Link:** https://github.com/rust-lang/rust-project-goals/issues/273 ### "C++/Rust Interop Problem Space Mapping" rust-project-goals#388 **Link:** https://github.com/rust-lang/rust-project-goals/issues/388 ### "Continue Experimentation with Pin Ergonomics" rust-project-goals#389 **Link:** https://github.com/rust-lang/rust-project-goals/issues/389 ### "Design a language feature to solve Field Projections" rust-project-goals#390 **Link:** https://github.com/rust-lang/rust-project-goals/issues/390 ### "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 ### "Evolving trait hierarchies" rust-project-goals#393 **Link:** https://github.com/rust-lang/rust-project-goals/issues/393 ### "In-place initialization" rust-project-goals#395 **Link:** https://github.com/rust-lang/rust-project-goals/issues/395 ### "MIR move elimination" rust-project-goals#396 **Link:** https://github.com/rust-lang/rust-project-goals/issues/396 ### "Reborrow traits" rust-project-goals#399 **Link:** https://github.com/rust-lang/rust-project-goals/issues/399 ### "reflection and comptime" rust-project-goals#406 **Link:** https://github.com/rust-lang/rust-project-goals/issues/406