---
title: Triage meeting 2026-02-04
tags: ["T-lang", "triage-meeting", "minutes"]
date: 2026-02-04
discussion: https://rust-lang.zulipchat.com/#narrow/channel/410673-t-lang.2Fmeetings/topic/Triage.20meeting.202026-02-04/
url: https://hackmd.io/85et5jBxQoeEY8mZtcTh8A
---

# T-lang meeting agenda

- Meeting date: 2026-02-04

## Attendance

- People: Josh, TC, Tyler Mandry, scottmcm, Niko Matsakis, dianne, Jack, Nadri, Nurzhan Saken, Tomas Sedovic, David Wood, Zachary Sample, Benno Lossin, dianne, James Muriuki

## Meeting roles

- Driver: TC
- Minutes: Tomas Sedovic

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

### Tomas: Nurzhan Saken, our new Program manager joined us!

He'll be joining the meetings this week to get to know y'all. I'll take the minutes this week and Nurzhan will do it the next one. After a few weeks, we'll likely alternate the calls.

So you can get familiar with both of our faces, get to know us and know to reach out to us. And so we both remain plugged into the Project.

### Tomas: 2026 goals

First look at 2026 goals post: https://blog.rust-lang.org/inside-rust/2026/02/03/first-look-at-2026-project-goals/

Please take a look, think about asks on your team. It has some examples for the sizes that team asks can be.

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

davidtwco: I'm here in case "cfgs for target modifiers" rust#152038 comes up, but no need to nudge it too much

Benno: I'm here for questions on "Lint against inherent methods on types implementing Receiver and Deref" rust#151583

### 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-02-11 (next week) to review the status of RfL project goals.

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

### Welcome to Nurzhan Saken

TC: We've excited to have brought on Nurzhan this week as our second Project program manager. Welcome to Nurzhan.

### Project goals 2026

Tomas: The list of 2026 goals is out.

## Nominated RFCs, PRs, and issues

### "Support importing path-segment keyword with renaming" rust#146972

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

TC: Niko left some thoughts here after Eric asked some questions. On the last call we had a question on the edition dependent behaviour. Eric replied: https://github.com/rust-lang/rust/pull/146972#issuecomment-3843936582. I commented on the other part: what do we do about the `super` situation. Niko: https://github.com/rust-lang/rust/pull/146972#issuecomment-3813369189

TC: I think that's the right answer. I think those three rules in align with what Niko is saying:

* I didn't realize we support `use super` and `use self::super` but I would expect them to be equivalent.
* I think it's fine for us to have special things like `super` that can only appear in the prefix; I do not think this means we have to support `use foo::bar::super::baz`, for the reasons we articulated before (it introduces ambiguity when `foo::bar` is a `pub use` about "which super" is intended).
* I do not understand the rationale for forbidding use `self::super::bar` from importing a module, near as I can tell that works on stable.

TC: rules: https://github.com/rust-lang/rust/pull/146972#issuecomment-3844252762

* When using super to import a parent module, you must use as to define the binding name.
* It (`super`) may only be used in leading segments of the path, possibly after an initial `self` segment.
* `super` may be repeated several times after the first `super` or `self` to refer to ancestor modules.

Josh: The rules seem to make sense. But I also agree with petrochenkov's comment: https://github.com/rust-lang/rust/pull/146972#issuecomment-3847086154

TC: That's speaking to the 2015 part.

Josh: I tried to figure out if the comment is disagreeing with what we're saying.

TC: There are 2 separate things. Look at Eric's comment: `pub use ::{self as other};` is error on all editions. For this PR, it compiles on 2015 only. In all other editions it's an error. It kind of makes sense for 2015. With the PR as it is, we added the rule about extern prelude not being imported.

Nadri: Meta point: the amount of time and details we've invested in this feels more like a design meeting. That feels like not "triage".

Josh: Not doing a further design without a design meeting makes sense. But it sounds maybe we're aligned now.

TC: That's my expectation here too. I'm asking for a vibe on the consensus that we want to do on the `super` part, highlight the 2015 part to confirm that's what we want to do.

Nadri: Sounds good, the reason I named that is the amount of specific explanation to get into all this; a document would help I think. Generally I'm naming that we could have seen this coming 1-2 meetings earlier and might have wanted to do it as a design meeting then. Naming this for next time we have an item like that.

Jack: +1

Josh: +1

Tyler: On the rules you call out TC, the rules look good to me. I don't understand the context around making the edition-specific change.

Josh: `::` means something different in 2015 than elsewhere. In 2018, it means `crate::`. We're consistent with the cross-edition behavior in how editions handle paths.

TC: In 2015 `::` is equivalent to the root module, later it's equivalent to the extern prelude. If we allowed `use :: as foo` that's theoretically possible as an alias to the extern prelude.

Tyler: It seems there's a way to write this in 2015 already: `pub use crate as other`

Josh: Sounds like the description TC gave around behavior re super is what everyone agrees. It seems the description Eric did is aligned with what Petrochenkov said and that we're good there too.

TC: There's concern for me no the FCP to review these and the PR doesn't align with these now. We need meeting consensus.

Tyler: I still don't understand why we're making an edition specific change to allow something we can spell in a different way in 2015

TC: It simplifies the rule for the Reference. It's consistent with the concept that you can name and rename the root module but not the extern prelude

Niko: I understood this falls out of the changes we want. It's not a breaking change, right?

TC: No, it's new code allowed in 2015

Tyler: That's okay then

### "Stabilize the `supertrait_item_shadowing` feature" rust#148605

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

TC: Nominated for 2 reasons: checkboxes but also: boxy left a note: https://github.com/rust-lang/rust/pull/148605#issuecomment-3841287120

> Do we have anyone who can actually vouch for the impl at this point?

Scott: That's a compiler reviewer concern. If we're happy with the rules, that should be fine.

Jack: Yes. It comes down to implementation review. I imagine the Types team on the FCP would highlight. I think boxy meant this to register a concern from the types team. Who implemented it?

Amanieu: compiler-errors

Niko: "It was errs? Ship it"

TC: I agree it's mostly compiler side. I raised it to see if we can find a way to support this and help it move forward.

### "Make PinCoerceUnsized require Deref" rust#149218

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

TC: Scott, we're picking up a checkbox. With it, it'll go into FCP. Do you have any questions? Amanieu, so would yours

Amanieu: I'll have a look at it.

Scott: IT's a breaking change but the crater report said it was okay?

TC: Yes. My proposal for FCP is we're merging this but leaving open question whether Deref should be a supertrait for PinCoerrceUnsized

### "Do not deduplicate captured args while expanding `format_args!`" rust#149926

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

TC: As soon as Scott and/or Niko checks it, it'll go into FCP.

TC: OK. Now in FCP.

TC: This will unblock your RFC, Josh

Josh: If you could, please take a look at the RFC 3626: https://github.com/rust-lang/rfcs/pull/3626 . It's awaiting lang checkboxes, which AIUI were waiting on resolving this issue.

### "Lint against inherent methods on types implementing `Receiver` and `Deref`" rust#151583

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

TC: We talked about it last week, Benno wrote down our vibes: https://github.com/rust-lang/rust/issues/151583#issuecomment-3821277954

TC: We were a bit on the fence, but many of us were warm on the warn-by-default. The question is: is there anything we can say to give Benno more of a way forward

Benno: I gathered that you thought the lint would be a better idea, would be great to get a bit of a vibe check on that.

Benno: The other thing I suggested was to suggest to add the lint and run a crater run to see how much of an effect that has.

Josh: I'd be substantially convinced by data from the crater run. If we have a lot of crates that use `Deref` and do this and would get warnings, I'd continue to be skeptical. If there aren't huge issues I'd be open to it; new things should not do this

Scott: There's a huge difference from derefing to an arbitrarry generic argument vs somethnig specific.

Benno: This is if you directly to a generic. If you deref to `&[T]` you don't get a warning.

Scott: That makes sense.

Josh: The only concern is: is this a massive noise for existing users

Nadri: If we make a warning, it's policy that it's bad practice to add methods on smart pointers. I think that's not great. Interesting smart pointers are usually more than just the `T`. E.g. `Pin` has legitimate need to have inherent methods.

Josh: I'm against the general policy that this is always wrong because the reasons you said. Often having a method with a sufficient specific name can avoid conflits. I'm open to this lint because it's saying you shouldn't do this *accidentally*. If we were doing it from scratch, I'd be up for having a keyword for an intentional method on a smart pointer.

Nadri: I agree with you: if we had a good way to tell a user "this is a warning, you don't have to fix it". I think most our warnings are saying "do this differently"

Benno: Could we add this to the help text?

TC: Benno, last week you made an argument for discouraging this across the board

Benno: Smart pointerness of the Receiver trait. If you implement it, you make users never be able to have a method with that same name. If you have a smart pointer internal to your ecosystem. But if you have a crate with a smart pointer that everyone can use, you shouldn't have a method that shadows every other thing.

Niko: What swayed me was that the lint was very limited. Just for generics, and only if it's sufficiently public. I agree with Nadri I don't like lint where the response is `allow`. I wonder if there's yet another slice: e.g. is it all T. I think it's a better story if we tell people to make a change when a lint fires

Josh: I do think we have cases as precedent where you have a lint to encourage you in a direction but you can allow to go in a different direction. E.g. nonstandard naming in FFI cases. This seems like a reasonable precedent. But it seems we are okay with getting the data. So I propose to pick this back up when we have the crater run data.

Scott: I was going to say the same thing. Let's look at the crater result.

TC: Benno, you have your answer. We're inviting the PR, please nominate it for us and give us the data.

Benno: thanks!

### "`unused_parens` does not lint parentheses around method receiver" rust#151985

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

scottmcm: FWIW, we don't lint on this: <https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=628edee76be6c29408c22e21f5bce107>

let x = 2.0 * (std::f32::consts::PI);

Oh, wait, we also don't lint on this: <https://play.rust-lang.org/?version=nightly&mode=debug&edition=2024&gist=46ac865753eca7964a4188e8dd504855>

    let z = std::f32::consts::PI;
    let x = 2.0 * (z);
    dbg!(x);

Josh: I think we should lint it. It's surprising we've missed this. If there were any other knid of expressions (e.g. involving `&` or `*` we'd be careflu)

TC: chenyukang posted this: https://github.com/rust-lang/rust/issues/151985#issuecomment-3835411438

warning: unnecessary parentheses around method receiver
   --> library/coretests/tests/floats/mod.rs:779:13
    |
779 |             (Float::MIN_POSITIVE).midpoint(Float::MIN_POSITIVE),
    |             ^                   ^

Josh: I'd lint on this.

TC: Makes sense to me

Nadri: As a human parser, I know the rules but I'd still probably add parenttheses here. It looks like you're starting a path, I'd keep parens about this. If human want to add parens that feel disambiguatory, I'd let them

Scott: We don't lint on parenthesized paths in an expression today. So I'd say this one is about a single ident because we lint on it if it's in an expression as well. If we want to do a change about paths not warning, that should be a separate conversation.

TC: Is our vibe "we want to be consistent with expression and lint there?"

Josh: +1 doing the thing we agree on. This case is different than the expression, but that should be a separate, lower priority thing

Tyler: I agree we should be linting on 227 and I'm happy to punt on linting on paths on line 221

TC: I'd propose linting on the paths. Like Josh says it's entirely unambiguous

Josh: I'd propose we start asking for a lint on the path, do a top 1k crates and see what it shows up.

TC: I'd second that

Scott: I'd push back on "it's completely unambiguous". This lint already intentionally doesn't lint on things that are technically unambiguous. I can see the argument that parts of a path are so strong as

Josh: I suggested this principle "this literally can't parse any other way".

TC: Is the consensus to get more data?

Tyler: The proposal is to crater run linting on all the cases we've discussed?

TC: Yes

Josh: Yes

Scott: I'd phrase it as tentative approval for path cases and if crater shows it's horrible, we'll reconsider

TC: We're inviting a PR for this to be able to do the crater run.

### "cfgs for target modifiers" rust#152038

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

David: We have target modifiers across compilation units. They often change something in the ABI. Knowing which target modifiers are enabled is important to generate code for e.g. naked functions and ASM in generate the right assembly.

David: there's this Chromium bug: https://github.com/rust-lang/rust/issues/151486. I propose adding a config for every target modifier

David: I was thinking of things like branch-protection group, maybe even align

Tyler: This would be perfect application for namespaces. E.g. `modifier::branch_protection`.

David: Currently target modifier isn't a thing users interact with. Alice and Trevor argue we should either include it in the ??

Tyler: I like it as user terminology

Scott: It feels important enough to have a name for it.

David: If you change up these flags, things could change and you'd have to know ??

TC: Agreed on target modifier as a name and I'd like to have a namestpace

Josh: +1 on target modifier as a name. In C there's no distinction between GCC and Clang targets.

David: Should they all have a `cfg`?

Josh: I wouldn't say to unthinkingly *always* add a cfg for every target modifier, but anything that people might reasonably config on, e..g. any ABI changes.

Tyler: Are there examples of target modifiers that only have a single value? There are boolean modifiers. There's the branch protection which can have multiple value. And some that have a single value like `regparm`.

Josh: +1, branch protection is a list, regparm is a single integer?

Tyler: Yes.

TC: I'd want to see a survey of how many of these we'd say aren't useful to have a config. It would be convenient if we didn't have to decide on whether to have a config or not on all of them

Tyler: I agree. With typed cfg, does it makes sense to wait on that or should we do it now? If there's not anyone asking for this, we could do it now and do a migration in the future.

Josh: We support typed cfg now if the compiler does it, but we don't support passing it in on the command line. My understanding is typed config is supported if the compiler's doing it directly.

Tyler: What the single value configs let you do is you could have a cfg macro that would let you substitute

Josh: I see. We don't have a way you could get the integer value of regparm. You can compare things. But I don't think we should block on that.

TC: David, what do you see as the next steps?

David: I'll come back to you with a list and a proposal for the namespaces.

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

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

### "`#![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

### "UB inconsistency when derefing a place in a closure" reference#2121

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

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

### "Revise decision process: champion vs FCP decisions" lang-team#360

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

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