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

# T-lang meeting agenda

- Meeting date: 2025-08-27

## Attendance

- People: TC, Tomas Sedovic, fmease, theemathas, Aapo Alasuutari, Eric Holk, RustyYato, simulacrum, Josh, Lori, Gillaume, Taylor (cramertj), Niko, Tyler Mandry, yosh

## Meeting roles

- Driver: TC
- Minutes: Tomas Sedovic

## Scheduled meetings

- 2025-08-27: "Design meeting: Ergonomic ref-counting" [#343](https://github.com/rust-lang/lang-team/issues/343)
- 2025-09-03: "Design meeting: Review RFC 3804 `cfg_alias`" [#345](https://github.com/rust-lang/lang-team/issues/345)
- 2025-09-10: "Design meeting: Extending const generics -- temperature check" [#341](https://github.com/rust-lang/lang-team/issues/341)
- 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)

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!)

### Council Member Selection

Tyler: Got 1 person who wants to continue as council rep (TC). But people should consider signing up.

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

Guillaume and fmease: doc(attribute)

RustyYato: repr(ordered_fields)

Aapo Alasuutari: Reborrow

Theemathas: super let

### 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 meeting with RfL today right after the design meeting.

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

## Nominated RFCs, PRs, and issues

### "Glob import causes ambiguity on nightly" rust#145575

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

TC: This was flagged by Eric Huss for my attention. This was a lang stabilization that occurred without us and has caused regressions. Do we want to retroactively do this? Take it back?

Josh: If we've correctly identified which item led to the potential lang visible change, the PR went in last month. It's got a milestone and it hasn't reached stable yet. This would hit stable if we do nothing.

Josh: Crater run results have not yet come back. I'd be shocked if this doesn't cause widespread regressions. I regularly see crates that mark things as pub(crate) to import them from the top level of a crate. They import a bunch of external crates at the top level of a crate. And in other portions just use `crate::something`. Combine that with a wildcard and you get this ambiguity. It would be helpful to know what the improvement was trying to achieve.

Tyler: I was thinking the same thing.

TC: What is exactly the rule for our behaviour? What is the rule under which we accept this?

struct String;

mod m {
    use crate::*;
    const _: String = super::String;
}

https://github.com/rust-lang/rust/issues/145575#issuecomment-3225490359

Niko: Why is the super::String example interesting? What's the `super` have to do with it?

TC: It's not about the `super`; the type position use is the focus there. In the prelude we have String that's glob imported. And here we glob import the one from the crate root. And the `String` here in type position is to confirm which one we got. And the question is why we're not getting an ambiguity error.

Josh: The rationale is that we're trying to make it that when we add new names into the crate, things don't break.

TC: That would be my expectation too.

Niko: Do we have coverage of these rules in the Reference?

TC: I didn't check but that's a great question.

Niko: Feels like an area that would be beneficial for us to nail down.

Josh: I've checked reference and it doesn't answer the question.

Niko: I know the Ferrocene folks put a lot of effort into name resolution.

Niko: I'm nervous about this change, it doesn't make sense to me yet. But I don't have a clear mental model so it's hard to be sure what's right or wrong.

Tyler: We're making changes to a model that we don't all share. That to me flags we should have a design meeting or something along those lines.

Josh: To elaborate on the notion of "is there any documentation in the Reference". Since there's nothing to patch, the obvious response is: where is the corresponding Reference change on the stabilization report. So we would retroactively expect to have a stabilization report as well as the text that would go to the Reference on what exactly changed.

TC: To summarize, our feeling is, "explain to us why this shouldn't be reverted". As a process matter, this should have had a Lang FCP. Therefore, the default would be reverting it.

Josh: Can we specify the date by which it needs to be released?

TC: The next beta branch is about two weeks away.

Josh: Then I'd propose: "here's a date, if you can give us a stabilization report to consider by that date" then we can consider it. If not, we'll revert it and then you can do the stabilization report at your leasure.

TC: That would be next week.

Josh: And I expect next week half the team will be at RustConf. So let's ask for revert and stabilization report.

TC: I agree, let's revert and ask for stabilization report.

### "don't apply temporary lifetime extension rules to non-extended `super let`" rust#145838

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

TC: This is about the behavior of the `pin!` macro and `format_args!`. We caused a regression in behavior when we stabilized use for super let for pin in format_args. For super let we have this guiding model for what the equivalence should be. What we stabilized was not in line with that model. There are two PRs from dianne that are believed to bring super let in line with that model. And that fixes the temporary lifetime behaviour of pin and format_args.

TC: There's a comment where I suggest some additional tests to confirm behavior. She confirmed that those tests hold and added those tests. Mara also said this is correct.

Niko: This makes sense to me. The original goal of the super let was that it was something taht could be referenced in the result of that expression. It lives as long as the result lives. I think this is aligned with that?

theemathas: My mental model is: I think of super let as a binary operator. You think of the expression before super let and after it as operands.

https://github.com/rust-lang/rust/issues/145784#issuecomment-3222236928

Niko: Okay, I see.

TC: The equivalence relationship we're upholding, as a reminder, is:

{ super let v = &$EXPR; v } === &$EXPR

Niko: I agree with this.

TC: What we were doing violated this.

Josh: The first example of the PR description (pin of a block) is a good example.

TC: I'd also highly recommend looking at the test cases.

Josh: If I understand the example correctly...

`f(pin!({ &temp() }))`

`temp()` shouldn't be lifetime extended

but if you wrote:

`f(pin!({ super let x = temp(); &x }))`

would that work?

theemathas: Yes.

Niko: Yes.

Josh: And the problem was it was forcing an extended context?

Niko: Right.

Josh: Assuming crater doesn't scream, this seems fine.

TC: This is fine either way: we regressed behavior. We need to do this.

Josh: I'll check a box.

### "Tracking Issue for NUL-terminated file names with `#[track_caller]`" rust#141727

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

TC: This probably didn't mean to include us in the proposed FCP. We could all just check our boxes. Or someone from libs-api could restart.

Josh: This is probably procedurally unintentional. It wasn't supposed to clear out the Lang boxes. I'll remove lang and restart.

TC: Note also that we have a separate FCP for stabilizing the language behavior. I filed a holding concern to give libs api time to resolve this. I'll resolve it when the stabilization is updated according to the change here.

### "Add new `doc(attribute = "...")` attribute" rust#142472

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

TC: In the standard library documentation we have a documentation for each keyword. They're proposing something to rustdoc to document attributes like we document keywords. They're asking us here because we own the documents for keywords and attributes and since this is going to result in a lot of reviews. I talked with Eric Huss and asked him to leave feedback. His vibe was that adding the keyword documentation to the standard library didn't work very well. It overlaps a lot with the Reference and is hard to keep up to date and in sync. He wasn't thrilled about doing that for attributes args too.

TC: For my part, I see value in it appearing in the search, and maybe we then just link to the Reference.

Josh: The documentation for keywords for standard library docs was a huge success. I agree the duplication is a potential issue and that seems like an argument to linking relevant portions of the Reference. Right now if you search for "cfg" you get the `cfg!` macro, but you don't get the `cfg` attribute. For other things like `config_addr` there's nothing. Having something show up even if it's just a link to the Reference would be a huge win.

TC: I agree. I understand the motivation to adding it to the documentation. But also about not duplicating it.

Niko: I'd go somewhere in between. Very simple docs -- giving people short summary of the purpose -- something that wouldn't become dated. An example or two of the most common usage would help most people.

Guillaume: Since mdbook is using markdown, we can reuse the same files in std docs by including them. I was also going to suggest something like what Niko said: short summary with a link to the Reference.

Josh: If you do want to include the files from the Reference in the standard library docs, you should coordinate with the build-std folks to make sure it doesn't break. If we have the brief summary + link to the reference, then we should back-link the Reference to the std library docs so peole making changes to the Reference should make sure to check/update the stdlib docs too.

TC: In terms of the review load, as a point of comparison, in the Reference, where we're currently revising the documentation for all attributes, going through all these attributes has been a significant project between Eric and myself.

Niko: If the description is long enough to merit a backling or review from you, that's too long. It should be something that shouldn't be reviewed. Also include_str is not a good idea -- we should be aiming for decoupling.

Josh: I found avoiding the second click idea motivating. What if we made the doc attribute take a URL that would go straight to the Reference. If you had a URL for the relevant piece for the reference directly in the doc attribute, the search results on the standard library docs would say "built-in attribute, see Language Refernce" and it wolud take you directly there.

TC: Yes, I was thinking something similar. I think it's a great idea to link directly from the search results.

Guillaume: If we do that, if we make such results link directly to the reference, inter-doc links won't be able to link to the attributes any more. And second, is the Reference always distributed when we install docs locally? If not, things break without internet connection? Having a page even if it just contains a link to the reference is the right approach.

Niko: I think we're too deep in the same meeting.

Josh: I agree. We should give the feedback that we're looking for (getting as close as possible to one click to the reference). Whether that's a redirect, generated doc page, direct link. Try and see what comes back to us.

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

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

TC: I proposed FCP. Josh checked a box. Whatever we're trying to do, what we're doing now is not it. Just ascribing the type changes the drop order.

Niko: Reading your comment, I'm confused where the extra type ascription is.

Josh: Try reading the very last comment from TC (https://github.com/rust-lang/rust/pull/145277#issuecomment-3208202976)

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

theemathas: I found the behaviour. What's going on is that writing the type annotation causes the compiler in MIR to add unsized coersion. It doesn't do anythnig except that the point when it adds the ??. It cretaes a temporary which then gets dropped.

Tyler: My only worry with this change would be: there are situations where we consider code unreachable and we don't do as much checking in unreachable code. If this change makes us consider the initializer expression unreachable and changes how we check it, that might limit our options in the future. Does anyone know?

TC: We're only changing this in the case where the type is ascribed.

Tyler: I agree that's bad.

Niko: I think we should approve this. I just don't exactly understand what's happening what the change is needed. ... We already don't drop constants that don't have zero length. But we didn't understand that this was a constant. An unsized constant is still a constant.

Niko: We have a check when you make a zero-length array and it checks if it's a constant and does something special (and posits it's a non-drop). If its a constant we do this. The check odesn't consider this a constant because it was an unsized costant. Now it sees an unsized constant as a constant.

Niko: The example: in the first case it's coerced from Weak.

TC: On my first example on the page there's no (obvious surface-level) coercion:

https://github.com/rust-lang/rust/pull/145277#issuecomment-3177196595

Niko: You can sometimes drop other things. In the general case converting a `dyn` to another `dyn`, you can change things. So it inserts an upsize coersion.

theemathas: there's a similar construction that causes an ICE: https://github.com/rust-lang/rust/issues/140123#issuecomment-2990136588

Tyler: If we see a constant expression, that has an initializer to 0, we do not evaluate the const expression. Is that the idea?

TC: Yes. We were already doing this except in certain edge cases.

Tyler: That makes sense to me.

Niko: I've checked my box. It's in FCP. I've added a section to address a comment, TC you can look at it.

---

TC: On a meta note, we're getting behind on our list of nominated items.

Niko: I'm a big fan of timers. Maybe we could have a quick hits for the first 15 minutes. For things like "this needs a checkbox, please check a box".

Josh: We could even do these ahead of the meeting. Using rfcbot-rs

TC: It's already ordered to put the easy things first, modulo that items with time sensitivity still come ahead.

(The meeting ended here.)

---

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

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

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

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

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

### "Opportunistically split `!=` to successfully parse never type" rust#145536

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

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

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

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

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

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

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

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

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

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

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