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

# T-lang meeting agenda

- Meeting date: 2025-09-17

## Attendance

- People: Josh, TC, tmandry, nikomatsakis, scottmcm, Folkert de Vries, RustyYato, Amanieu, Yosh

## Meeting roles

- Driver: TC
- Minutes: TC

## Scheduled meetings

- 2025-09-17: "Design meeting: Unsafe fields RFC review" [#344](https://github.com/rust-lang/lang-team/issues/344)
- 2025-09-24: "Design meeting: `cfg_version`" [#337](https://github.com/rust-lang/lang-team/issues/337)
- 2025-10-01: "Design meeting: Wasmtime team sync" [#342](https://github.com/rust-lang/lang-team/issues/342)
- 2025-10-08: "Design meeting: Review RFC 3848 (Pass pointers to `const` in assembly)" [#347](https://github.com/rust-lang/lang-team/issues/347)

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 2025-09-24 to review the status of RfL project goals.

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

### Nominations for PDs

Josh: We need to decide about nominations for PDs tomorrow.

## Nominated RFCs, PRs, and issues

### "Use const generics for array `Default` impl" rust#61415

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

TC: The question here is whether we're willing to accept some amount of magic in the standard library so as to finally add the `Default` impl for non-zero arrays. lcnr and Boxy put forward that the amount of magic required here is tolerable.

tmandry: I feel comfortable that there's some way we could generalize this in the future, but I'm not sure about that.

tmandry: It seems there are multiple ways that this could work going forward, and one of the options is it always being a special case. So to approve this we need to accept that it could always be a special case.

NM: We already have special magic around zero length arrays, with respect to const and `Copy`. This seems in line with that.

NM: My vibe here is +1.

TC: +1.

Josh: Broadly speaking, +1, with some trepidation if it involves specialization rather than another proposed approach.

NM: In the limit, we have some special trait that identifies the zero value.

tmandry: If we're framing this in terms of specialization, the question is what's the likelihood of that subset being able to be stabilized.

NM: We could say, e.g.:

impl<const N: usize> Default for [T; N]
where
    if N != 0 { T: Default }
{
    // Josh: and a body that looks something like this:
    fn default() -> T {
        const if N != 0 {
            [T::default(); N]
        } else {
            []
        }
    }
}

NM: There are many routes. I'm not concerned about us being able to find coherent designable options. We might not ever think any of them carry their weight as compared to a special case, but they might. What I sketched above doesn't seem too hard to do.

tmandry: I'm not sure we should go there, but I feel maybe comfortable saying yes here for now.

NM: Not handling zero-length arrays is very irritating. The lack thereof increases pressure to adopt these more complex proposals, also. I think we should just make it work given that we have precedent.

tmandry: So the argument is that if your language can't express this it should find a way to express it. Ok.

TC: OK, we're all +1 then, so we'll leave a comment expressing appetite and ask for a PR to be nominated for us.

### "Allow borrowing array elements from packed structs with ABI align <= packed align" rust#145419

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

TC: FCP has been proposed; it needs Niko's checkbox and has concerns from scottmcm (listing exact rules, which has been done) and from tmandry (semver hazard, which RalfJ has addressed).

NM: Checked.

tmandry: OK, so this is purely about making it work for const generic arrays. I'll resolve the concern.

TC: Then we'll need scottmcm to resolve the other concern.

---

TC: scottmcm is here now, discussing again.

TC: Have a look at the Reference PR here for the rules:

https://github.com/rust-lang/reference/pull/1984/files

tmandry: I don't love that we added a SemVer hazard here, but it seems that ship has sailed.

scottmcm: I'll resolve the concern; I don't like the implementation, but it's not a lang problem.

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

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

TC: We need a checkbox from scottmcm here. It's a dual FCP, so we need everyone to check off.

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

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

TC: This one needs a checkbox from scottmcm; no concerns are filed.

### "the `#[track_caller]` shim should not inherit `#[no_mangle]`" rust#145724

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

tmandry: We need to propose FCP?

TC: Right.

Folkert: This goes against the RFC, so we need to confirm the behavior here.

NM: I'd be curious to know how we made the decision, but I can see a rationale for it.

scottmcm: Do we need to allow this combination.

NM: That'd be my inclination, but it is available on stable, for better or worse.

Folkert: It'd be weird for it to not work in a program, because the behavior here is creating a function pointer.

Folkert: The shim gets the location of where you turned the function into a function pointer.

scottmcm: I agree that's the only thing it could possibly do, but I'm not sure that's what anyone is expecting. It wouldn't be surprising if you had to make a lambda that called it.

NM: Is the thing you're concerned about that it will lose the `track_caller` information?

scottmcm: It's the parameter mismatch that's funky.

NM: I could see it surprising people, but there's a method to the madness. I like that it can be desugared -- if you think of `fn` pointers as a `dyn Fn`.

NM: I'll propose FCP. I feel strongly that the behavior in the RFC is correct.

TC: Folkert; that make sense to you?

Folkert: Yes, I think that's the only thing that makes sense.

### "Having made lint `ambiguous_glob_imports` deny-by-default and report-in-deps" rust#146651

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

TC: This went in without us, so we're confirming retroactively that this was OK.

Josh: Has the process failure been dealt with separately?

TC: No. I'd like us to reaffirm in our reply here that all changes to lint levels need a lang FCP.

(The meeting ended here.)

---

### "Decide about future of `rustc_legacy_const_generics`" rust#146613

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

### "Stabilize 29 RISC-V target features (`riscv_ratified_v2`)" rust#145948

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

### "Add the `cpuid` target feature" rust#146560

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

### "Allow specifying multiple bounds for same associated item, except in trait objects" rust#146593

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

### "`dangerous_implicit_autorefs` suggestion is wrong" rust#140721

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

### "error out when `repr(align)` exceeds COFF limit" rust#142638

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

### "Tracking Issue for `darwin_objc`" rust#145496

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

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

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

### "Uplifts and extends `clippy::needless-maybe-sized` into rustc" rust#145924

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

### "compiler and language documentation disagree on lifetime extension for array expressions" rust#146092

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

### "Add a new lint `UNCONSTRUCTABLE_PUB_STRUCT` to detect unconstructable public structs" rust#146440

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

### "Add lint about redefining runtime symbols" rust#146505

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

### "Result/Option layout guarantee clarifications" rust#146509

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

### "Extend format_args implicit arguments to allow field access" rfcs#3626

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

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

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