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

# T-lang meeting agenda

- Meeting date: 2025-10-08

## Attendance

- People: TC, nikomatsakis, tmandry, Josh, dianne, Jack, Martin, Aapo, Yosh, scottmcm

## Meeting roles

- Driver: TC
- Minutes: TC

## Scheduled meetings

- 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-10-08 to review the status of RfL project goals.

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

Looking at https://github.com/rust-lang/rfcs/pull/3848

## Nominated RFCs, PRs, and issues

### "Lint regression: `dead_code` ignores `#[allow(dead_code)]` on traits" rust#144060

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

TC: Last week we had talked about this.

Josh; A PR went up in:

https://github.com/rust-lang/rust/pull/144113

TC: One example we considered was this one, which warns in 1.89 but not in 1.88. Did we find out anything about this?

#[allow(dead_code)]
trait Foo {
    fn f();
}

impl Foo for u32 {
    fn f() {
        g();
    }
}

fn g() {} //[1.89]~ WARN

fn main() {}

Josh: If I'm reading 144113 correctly, I think it may fix this as well.

Niko: The behavior I proposed considered what is public, so I think I'd warn here.

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

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

This is waiting for scottmcm.

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

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

This is waiting for scottmcm.

### "Temporary lifetime extension for blocks" rust#146098

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

TC: The crater runs came back as clean as could be expected. I'll go ahead and propose FCP.

TC: And this is in FCP.

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

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

Josh: People have made comments that what they really want are compile-time constant arguments. Our only mechanism for this is `legacy_const_generics`.

If we could mark a parameter (not the whole function) as `const`, the compiler could enforce that it is a compile-time constant, and then you can use that constant inside the function as a constant. For instance, you can use it as an asm *immediate*, or write a `const if` on it.

Niko:

// Implication: this does not implement the `Fn` trait.
fn foo(const N: usize) {
    let x = [22; N];
    // can also use this in an `asm!` as a constant
}

// becomes

fn foo<const N: usize>() {
    ...    
}

// and `foo(22)` becomes `foo::<22>()`

// ...but you can't do this in any other way

We should get more feedback from compiler folks on what the issue is with legacy const generics and why it needs to be a different kind of const. We should also get feeback on the above sketch to see if it has the same problems, or different problems.

### "Allow passing `expr` metavariable to `cfg`" rust#146961

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

tmandry: Petrochenkov seems to think this is a special case of something he wants to do anyway.

Josh: It seems, in principle, that we could allow the macro fragments in any position -- that's what we'd do if we treated them exclusively as tokens. The limitation, as I understand, relates to compile-time performance. I'll propose FCP.

TC, tmandry: +1.

TC: It's in FCP.

Niko: Why would you not want this? It's hard to think of a good reason not to do this.

Josh: In theory, if you wanted to build a "correct by construction" macro system, maybe you wouldn't want this, but this isn't what we have anyway.

### "FCW for repr(C) enums whose discriminant values do not fit into a c_int" rust#147017

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

(Discussion, mostly reviewing what RalfJ had said.)

TC: This is now in FCP.

### "Move CoercePointee to core::ops" rust#147068

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

tmandry: (Gives the background.)

Josh: We talked about this in the libs-api call yesterday, and we found this confusing. The comment at the top of `ops` suggests that it's for overloaded operators, which this isn't.

### "Add warn-by-default lint for visibility on `const _` declarations" rust#147136

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

### "unused_must_use: Don't warn on `Result<(), Uninhabited>` or `ControlFlow<Uninhabited, ()>`" rust#147382

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

### "RFC: Allow cfg-attributes on elements of tuple type declarations" rfcs#3532

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

### "RFC: `#[export_visibility = ...]` attribute" rfcs#3834

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

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

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

### "`rustc_const_eval`: respect `target.min_global_align`" rust#142198

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

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

### "Not linting irrefutable_let_patterns on let chains" rust#146832

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

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

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

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

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