---
title: Triage meeting 2025-08-20
tags: ["T-lang", "triage-meeting", "minutes"]
date: 2025-08-20
discussion: https://rust-lang.zulipchat.com/#narrow/channel/410673-t-lang.2Fmeetings/topic/Triage.20meeting.202025-08-20/
url: https://hackmd.io/jEorn4aKSMGPQ0vN9XHHZQ
---

# T-lang meeting agenda

- Meeting date: 2025-08-20

## Attendance

- People: Tyler Mandry, Lori, RustyYato, theemathas, Josh, TC, Tomas Sedovic, scottmcm, zachs18 (not T-lang)

## Meeting roles

- Driver: TC
- Minutes: Tomas Sedovic

## 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.

### Updates from Tyler

Tyler: The project goals RFC is up, Niko plans to merge it by the end of September 1st.

Tyler: Please take a look: https://github.com/rust-lang/rfcs/pull/3849. I'm happy with what's there.

Tyler: We need to select a Council representative. TC has been ours for a year. We have to choose a facilitator. I volunteered, Josh and TC seconded it. I'd like to select one by the end of the week if possible.

Josh: We're also needing to select new project directors. That has a facilitator (Tomas). They're expecting each team to coordinate amongs themselves and put forth people nominated for the director slots. That one's on a longer timeline.

https://rust-lang.zulipchat.com/#narrow/channel/392734-council/topic/2025.20project.20director.20elections/with/535322266

https://blog.rust-lang.org/inside-rust/2025/08/20/electing-new-project-directors-2025/

Tyler: Is there a Zulip thread for this?

TC: I'll open one for us.

TC: We'll take all the nominations and bring them up to the Council. Last year we also had a doc where people could introduce themselves. That worked out great, we're doing that again. We'll be trying to put forward a good slate to give the Council something to put through.

TC: On the Council side, I'm not done yet. There are still things on my radar to do. I'll be asking for the support of people here. And I'll likely be standing for a PD seat. I've been filling in for Santiago for the last few meetings because he had to stand down. It means I won't be at the meeting where we elect project directors, and I'll ask someone else here to do that. Probably Scott, as he has the active context of being a PD, and that's helpful to the council discussions.

(Scott joined and agreed with Tyler's nomination, Niko agrees as well.)

TC: We now have unanimous consent: Tyler is the facilitator for the Council selection process for lang.

Josh: Would you like to walk through how we'll propose the council nominations?

Tyler: I'll read the process. But the basic process: we select a facilitator, they request nominations from the team and sub-teams. I'll be doing that on Zulip. People can self-nominate. There will be some open discussion and people can share their agreement or reservation and we can iterate until the group feels good about it.

Josh: The council representative for Lang and for every team that's the subteam for Lang. They represent a lot more people than just in this room. Part of what the Facilitator will do is making sure that their voices are heard as well.

TC: I recommend we create a hackmd like we do for PD selection and then people can describe themselves for the nominations.

Tyler: Yes, makes sense. Next week I'll start collect nominations. I'll skip the week of RustConf. Then I'll propose a candidate. If everyone's happy, we're done. If not, we'll have two business weeks to iterate and report our final choice.

Tomas: Regarding PD, the nominations are open now as well.

Scott: Anyone curious, please reach out to me. Or Tyler.

Josh: The other person we can pull in is Santiago Pastorino who has served on that role.

TC: Lori, did you get a chance to talk to Santiago again?

Lori: I did talk to him and we'll talk again.

TC: For the reason Josh mention I suggested Lori and Santiago talk.

TC: The council election happens before the PD one does. So the person we select for the council seat will be deciding on the PD elections (unless recusing oneself due to standing for a PD seat).

Josh: It is a notable property of the Foundation board that the seats for the project are given equal weight to the seats of the corporate members as a group. Any given thing that passes on the board needs a majority of the corporate members and the majority of the Project members.

Lori: I'm glad you brought that up. I don't know if the Project actually understands the weight of the Project Director role. There is a big impact from the Project Directors. They're voting on things that effect the Foundation which hopefully helps steward the Project.

TC: I think on the Council side we need to do a better job in setting out our expectations. People there have been great but we've left them a bit out in the woods.

TC: The upcoming three year strategy will define what success is for the Foundation over the next three years. As you've seen I've been collecting thoughs from the teams I represent as a council rep. If you think of any ideas on that, please talk with me.

TC: By the way I recommend reading the Council minutes if you're interested in what goes on. These minutes used to be rather impenetrable, but making these readable and representative of the meeting has been one of my priorities. This has now been helped further by Tomas taking them. I still edit them and make sure they represent the feel and content of the meeting.

Josh: Historically, this has been a role that's been a challenge for people because of the many different responsibilities in different directions. I think there's going to be a lot of direction and ability to shape the role, working with the Council. There's also never been more resources than now. We have Tomas as the PM. We also have Lori to help liaise with the Project. A lot of the things that fell on the Project Directors can now be done/helped by Tomas & Lori.

TC: In the past the Council didn't know what the Foundation was doing. This meant the reps couldn't communicate these happenings with their teams and collect relevant and timely feedback.

TC: Since this communication wasn't happening, everything fell on the project directors. This is one reason that I pushed for the board deck to be shared with the Council before the board meeting. We look at it -- talk about it in our meetings before and after the Foundation board call -- share feedback with the Foundation and collect answers and further context to bring back to the council and to the Project.

TC: We've now streamlined the process of sharing it and providing this feedback, creating better channels for shared communication. Things like this add up. This has been something I've taken an interest in, and we need to think when selecting PDs about our expectations for this kind of communication and the way in which the PDs represent the council and the Project.

### Next meeting with RfL

We're next meeting with RfL on 2025-08-27 to review the status of RfL project goals.

https://github.com/rust-lang/rfcs/pull/3614

## Nominated RFCs, PRs, and issues

### "Make sure to treat only param where clauses as inherent" rust#145262

**Link:** https://github.com/rust-lang/rust/pull/145262

TC: It's in FCP. I've unnominated it.

### "fix drop scope for `super let` bindings within `if let`" rust#145342

**Link:** https://github.com/rust-lang/rust/pull/145342

TC: This went into FCP.

Theemathas: There's been an update since the last meeting. I wrote a summary at the bottom of the PR.

TC: But that doesn't change what we're stabilizing, right?

TC: I think we still want to get this one out as quickly as possible. Scott, we could use your checkbox.

Minimization: https://github.com/rust-lang/rust/pull/145342#issuecomment-3190686395

### "Match guard can both move and static-promote a single constant" rust#145237

**Link:** https://github.com/rust-lang/rust/issues/145237

TC: theemathas, tell us about it.

theemathas: In the match guard

TC: If the scrutinee of a match is a value expression, we evaluate that expression into a tempoary. If there are guards, we take a shared borrow of that temporary. Because we've now taken a shared reference, that triggers static promotion. But you can still move into the guard which means you can static promote it and move into the guard. On a different issue, Ralf mentioned he didn't want this to be a static promotion candidate. What do we think about this behavior?

Josh: This is some very impressive corner-case finding, thank you!

Josh: What purpose is the static promotion serving? This test case demonstrates that it happens. Do we have something that demonstrates that it needs to happen?

Scott: Interesting that it's happening at all. It's happening to a variable by the time

TC: It's not happening to a named variable. We don't statically promote a reference to a named variable. There's no named variable at the time promotion is happening.

Scott: No matter what the MIR looks like, at least in the OP of the thread, that's a reference to a named variable.

theemathas: There's a separate issue where a promotion happens where there's a raw reference instead.

TC: Whatever we do with promotion, that reference is not to the named variable that you see in the source code. That's totally separate from the promotion. We're promoting based on the shared reference taken due to the presence of any guard, not the one taken in the guard.

Scott: This sounds like the same kind of conversation we had on where does our safe check happen? I look at the input source code and see that and that's not happening here. So I'd not expect this to static promote.

TC: The example is confusing because it looks like the `&x` is doing the const promotion and that's not what's happening here. If you have `x if true` -- any guard at all, it will static promote. It's not const-promoting the `x`, it's const-promoting the scrutinee. The scrutinee is evaluated to a temporary and any guard at all causes a shared reference to the temporary to be created and any shared reference is a candidate for const promotion.

Scott: And the promotion rule is: we saw a reference in MIR, we can't promote it? That rule feels fundamentaly wrong to me. Any Copy type you don't use the actual referenced value. Phrasing this rule as "it's a MIR local that's a user MIR local as opposed to a compiler-inserted MIR local" doesnt't sound good.

Josh: Looking at the static promotion logic and it's definitely a little baffling. I had no idea you could promote an integer to be `'static int`.

Scott: It's arguably in more places than it has to be. I wish we could come up with a rule that means we could not promote locals to static.

Josh: TC, I tried to do this experiment with `if true` and I couldn't reproduce it. If you have a good example with just `if true` please provide it.

https://github.com/rust-lang/rust/issues/145237#issuecomment-3194320641

The example you're looking for is:

fn _f2() {
    match None::<String> {
        x if true => {}
        _ => {}
    }
}

TC: The key part is if you look at the MIR you'll see the static promotion. You have to use the guard to create a temporary that then gets promoted.

Josh: I tried to write a function that returned `&'static u64`

fn func() -> &'static u64 {
    match 42 {
        x if true => &x,
        _ => unreachable!(),
    }
}
// Does not compile

Josh: If change this to:

fn func() -> &'static u64 {
    match 42 {
        ref x if true => x,
        _ => unreachable!(),
    }
}

// but this also works:
fn func() -> &'static u64 {
    match 42 {
        ref x => x,
        _ => unreachable!(),
    }
}

... it does work.

TC: But of course that would be static promoted.

theemathas: the name `x` applies to two different places.

TC: You have two places: the temporary and the place after the move. And you can write a bunch of examples that highlight the difference between the places. The one you move into still has a drop scope. So you have to be getting a reference to the temporary place. The one you pick up in the guard is promoted but not the one that's on the stack.

Scott: What do we need to do in this meeting? Is this something the Types could weigh in?

TC: I don't think it's types. I think it's const eval; so Ralf, and Oli maybe.

TC: The broad picture here is: we've done a lot of const promotion prior to stabilizing const blocks. But in a lot of the places where we did it was "we wish we didn't have to do it but we don't have const blocks", but we have const blocks now. There are a lot of places where we could do explicit promotion now rather than the implicit behaviour.

Scott: I'll make a comment saying this should be a ?? level rather than MIR level. If we move towards the direction of "the only things eligible are things you could wrap in a const block" -- I'll write that in the thread.

TC: It's interesting that this doesn't seem to create any particular problems though, in this case. It's not something that's really dangerous. It's just weird. Hard to think of too many drawbacks otherwise.

Josh: "dangerous" is the wrong term. One thing that seems potentially broken for static promotion you don't expect happening is: data living for longer than you expect it to. And taking up more memory than you expect it to. E.g. having a `None` of an `Option<... 1MB buffer>`. That could get static promoted because `None` with any `Option` type could get static-promoted. You can end up with a megabyte of static data sitting in a binary.

### "Add `homogeneous_try_blocks` RFC" rfcs#3721

**Link:** https://github.com/rust-lang/rfcs/pull/3721

Scott: This RFC has been open for almost a year. Have people read it, have thoughts about it? We could start a lang experiments.

Josh: I know people have been asking for this for a long time. Getting the types right for type inference was a big blocker. And this RFC seems to solve exactly that. I wanted to ask: What do you need, Scott, for the next step?

Scott: I think I had a PR that implemented this a year ago. If people are okay with landing it on nightly?

Josh: :thumbsup:

TC: Ship this as an experiment.

TC: Before we stabilize try blocks I want to have a discussion about returning an opaque type from `try {}`. But reading this RFC I don't think this intersects much with that. We'd need this anyway.

TC: I'm curious to hear about any patterns where what's in this RFC isn't what you want.

Scott: There are patterns when you have multiple `?` items inside of try block. If you're not in the try block you've written them out in the signature. But in the try block you don't have that. A common way to do this is to call `contex()` on it and then you have a single `anyhow` type back. There's a lot of different proposals to specify this. This RFC is a simple case of a non-annotated tryblock should be a homogenious try block and we can cover the heterogenous ones later. The hard part is what do you actually write there to ascribe it.

TC: There's also a libs-api intersection. We're pretty okay with this on the lang side. But on the libs side they were unhappy with the complexity of the trait hierarchy.

Josh: I think on the lang side the main concern was that this RFC didn't exist.

TC: This makes the desugaring a bit more complicated to constraint the type inference. But I'm okay with that.

Scott: Libs API has given out some good feedback is the thread there.

TC: Dust off the PR, let's get it into nightly. I propose we consider this to be a part of the proposal for the try blocks.

tmandry (in absentia): I looked over the RFC and I'm in favor of the idea. It seems to follow from the other design constraints we have chosen.

(The meeting ended here.)

---

(Josh and TC continued here.)

### "Do not materialise X in [X; 0] when X is unsizing a const" rust#145277

**Link:** https://github.com/rust-lang/rust/pull/145277

Josh: If you drop the `'static` does it still drop?

TC: Are you thinking of cases like this:

use core::{mem, ptr, sync::atomic::{AtomicU64, Ordering}};

static COUNT: AtomicU64 = AtomicU64::new(0);

struct S;
impl Drop for S {
    fn drop(&mut self) {
        COUNT.fetch_add(1, Ordering::Relaxed);
    }
}
trait Tr {}
impl Tr for S {}

fn main() {
    assert_eq!(0, COUNT.load(Ordering::Relaxed));
    let _a: &'static [Box<dyn Tr>; 0] = &[const { unsafe {
        panic!(); //~ This panic fires.
        mem::transmute::<_, Box<S>>(ptr::dangling_mut::<S>())
    }}; 0];
    assert_eq!(1, COUNT.load(Ordering::Relaxed));
    //~^ Drop was run.
    let _b = [const { unsafe {
        panic!(); //~ This panic does not fire.
        mem::transmute::<_, Box<S>>(ptr::dangling_mut::<S>())
    }}; 0];
    assert_eq!(1, COUNT.load(Ordering::Relaxed));
    //~^ Drop wasn't run.
}

TC: Minimization of the panic case:

use std::rc::Weak;

fn main() {
    const X: Weak<u8> = Weak::new();
    let _a: &'static [Weak<dyn Send>; 0] = &[const { panic!(); X }; 0];
    //~^ Panics.
    let _b = [const { panic!(); X }; 0];
    //~^ Does not panic.
}

zachs18: This does also still panic if `X: Weak<dyn Send>`

    const X: Weak<dyn Send> = Weak::<u8>::new();
    let _a: &'static [Weak<dyn Send>; 0] = &[const { panic!(); X }; 0];
    //~^ Panics.

use std::rc::Weak;

fn main() {
    const X: Weak<dyn Send> = Weak::<u8>::new();
    let _a: &'static [Weak<dyn Send>; 0] = &[const { panic!(); X }; 0];
    //~^ Panics.
    let _b = [const { panic!(); X }; 0];
    //~^ Does not panic.
}

Josh: I've checked a box.

### "Reject invalid literal suffixes in tuple indexing, tuple struct indexing, and struct field name position" rust#145463

**Link:** https://github.com/rust-lang/rust/pull/145463

TC: I've proposed FCP.

Josh: I've checked a box.

### "Stabilize s390x `vector` target feature and `is_s390x_feature_detected!` macro" rust#145656

**Link:** https://github.com/rust-lang/rust/pull/145656

Josh: I've checked a box.

### "Prevent downstream `impl DerefMut for Pin<LocalType>`" rust#145608

**Link:** https://github.com/rust-lang/rust/pull/145608

### "Tracking Issue for Reborrow trait lang experiment" rust#145612

**Link:** https://github.com/rust-lang/rust/issues/145612

Josh: Posted a +1.

(The post-meeting ended here.)

---

### "Tracking Issue for enum access in offset_of" rust#120141

**Link:** https://github.com/rust-lang/rust/issues/120141

### "repr(ordered_fields)" rfcs#3845

**Link:** https://github.com/rust-lang/rfcs/pull/3845

### "`ref` patterns can const-promote a single constant more than once" rust#145555

**Link:** https://github.com/rust-lang/rust/issues/145555

### "Stabilize the `breakpoint` function" rust#142325

**Link:** https://github.com/rust-lang/rust/pull/142325