---
title: Triage meeting 2023-04-25
tags: triage-meeting
---

# T-lang meeting agenda

* Meeting date: 2023-04-25

## Attendance

* Team members: tmandry, scottmcm, pnkfelix
* Others:

## Meeting roles

* Action item scribe:
* Note-taker: tmandry

## Scheduled meetings
- ~~"The #[diagnostic] attribute namespace" [lang-team#204](https://github.com/rust-lang/lang-team/issues/204)~~ already happened

## Announcements or custom items

(Meeting attendees, feel free to add items here!)

## Action item review

* [Action items list](https://hackmd.io/gstfhtXYTHa3Jv-P_2RK7A)

## Pending lang team project proposals

None.

## PRs on the lang-team repo

None.

## RFCs waiting to be merged

None.

## Proposed FCPs

**Check your boxes!**
### "unsafe attributes" rfcs#3325

- **Link:** https://github.com/rust-lang/rfcs/pull/3325
- [**Tracking Comment**](https://github.com/rust-lang/rfcs/pull/3325#issuecomment-1396911253):
> Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [x] @joshtriplett
> * [x] @nikomatsakis
> * [x] @pnkfelix
> * [x] @scottmcm
> * [x] @tmandry
>
> Concerns:
>
> * ~~change-syntax-to-drop-parentheses~~ resolved by https://github.com/rust-lang/rfcs/pull/3325#issuecomment-1458714974
> * ~~maybe-make-this-part-of-next-edition~~ resolved by https://github.com/rust-lang/rfcs/pull/3325#issuecomment-1458690311
> * syntax-not-ideal (https://github.com/rust-lang/rfcs/pull/3325#issuecomment-1458714974)
>
> Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
>
> cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
> See [this document](https://github.com/rust-lang/rfcbot-rs/blob/master/README.md) for info about what commands tagged team members can give me.
- [**Initiating Comment**](https://github.com/rust-lang/rfcs/pull/3325#issuecomment-1396911218):
> @rfcbot merge

### "RFC: UTF-8 characters and escape codes in (byte) string literals" rfcs#3349

- **Link:** https://github.com/rust-lang/rfcs/pull/3349
- [**Tracking Comment**](https://github.com/rust-lang/rfcs/pull/3349#issuecomment-1396747916):
> Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [x] @joshtriplett
> * [x] @nikomatsakis
> * [ ] @pnkfelix
> * [ ] @scottmcm
> * [ ] @tmandry
>
> Concerns:
>
> * raw-byte-strings-with-unicode (https://github.com/rust-lang/rfcs/pull/3349#issuecomment-1396747889)
> * waiting-on-update-re-using-char-and-string-tables (https://github.com/rust-lang/rfcs/pull/3349#issuecomment-1503875165)
>
> Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
>
> cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
> See [this document](https://github.com/rust-lang/rfcbot-rs/blob/master/README.md) for info about what commands tagged team members can give me.
- [**Initiating Comment**](https://github.com/rust-lang/rfcs/pull/3349#issuecomment-1396747889):
> I do think we should permit `br"¥¥¥"`, but I don't think we should make any of the other changes proposed in that table, for the reasons @m-ou-se stated.
>
> I'm going to go ahead and propose FCP for this. This does *not* preclude making further changes to how this information is presented.
>
> @rfcbot merge
>
> @rfcbot concern raw-byte-strings-with-unicode

### "RFC: Start working on a Rust specification" rfcs#3355

- **Link:** https://github.com/rust-lang/rfcs/pull/3355
- [**Tracking Comment**](https://github.com/rust-lang/rfcs/pull/3355#issuecomment-1513641410):
> Team member @tmandry has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [ ] @joshtriplett
> * [ ] @nikomatsakis
> * [ ] @pnkfelix
> * [ ] @scottmcm
> * [x] @tmandry
>
> No concerns currently listed.
>
> Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
>
> cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
> See [this document](https://github.com/rust-lang/rfcbot-rs/blob/master/README.md) for info about what commands tagged team members can give me.
- [**Initiating Comment**](https://github.com/rust-lang/rfcs/pull/3355#issuecomment-1513641387):
> @rfcbot fcp merge
>
> We talked about this in the lang team triage meeting and agreed that this is ultimately a council-level decision. That said, it seems like a good idea to get formal lang team buy-in ahead of the council making a decision on this.
>
> Since we can do that now while the council is still forming, I'm opening an FCP for it. **Note that this will still need a _separate_ FCP to actually be merged once the governance council is formed.**

### "The `#[diagnostic]` attribute namespace" rfcs#3368

- **Link:** https://github.com/rust-lang/rfcs/pull/3368
- [**Tracking Comment**](https://github.com/rust-lang/rfcs/pull/3368#issuecomment-1505729113):
> Team member @tmandry has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [ ] @Aaron1011
> * [x] @cjgillot
> * [x] @davidtwco
> * [x] @eddyb
> * [x] @estebank
> * [ ] @joshtriplett
> * [ ] @lcnr
> * [x] @matthewjasper
> * [ ] @michaelwoerister
> * [ ] @nagisa
> * [ ] @nikomatsakis
> * [x] @oli-obk
> * [ ] @petrochenkov
> * [ ] @pnkfelix
> * [ ] @scottmcm
> * [x] @tmandry
> * [ ] @wesleywiser
>
> Concerns:
>
> * doesnt-pull-its-weight (https://github.com/rust-lang/rfcs/pull/3368#issuecomment-1514914043)
> * is-attribute-namespace-tool-module (https://github.com/rust-lang/rfcs/pull/3368#issuecomment-1514908284)
> * lang-team-signoff (https://github.com/rust-lang/rfcs/pull/3368#issuecomment-1505729088)
> * ~~translation~~ resolved by https://github.com/rust-lang/rfcs/pull/3368#issuecomment-1511696325
> * version-namespace (https://github.com/rust-lang/rfcs/pull/3368#issuecomment-1505729088)
>
> Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
>
> cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
> See [this document](https://github.com/rust-lang/rfcbot-rs/blob/master/README.md) for info about what commands tagged team members can give me.
- [**Initiating Comment**](https://github.com/rust-lang/rfcs/pull/3368#issuecomment-1505729088):
> @rfcbot merge
>
> I think we should merge this RFC, modulo some concerns I note below.
>
> It would be good to merge it soon so we can get the `#[diagnostic]` namespace parsed by rustc, so any crate using it in the future won't have to bump its MSRV past the first rustc version that knows about `#[diagnostic]` (even if it doesn't support any attributes yet – unknown attributes are allowed to be no-ops in the RFC).
>
> ## Concerns
>
> @rfcbot concern version-namespace
>
> I personally think we should not include the version namespace in the current proposal but include it as a future possibility. @oli-obk pointed out to me that we can always decide to include a version namespace later, and choose to require it in a new edition if we decide that it was a mistake to let you use a diagnostic attribute _without_ a version. However, I think we should choose the more ergonomic option for now.
>
> This doesn't necessarily represent the whole lang team's opinion (sorry for churn around that), but I'll try to push on getting consensus here.
>
> @rfcbot concern lang-team-signoff
>
> Several members of the lang team don't necessarily want to bypass the lang team for the stabilization process, though I'm sympathetic to the argument that there could be too much high-frequency churn and don't want the lang team to get in the way of progress. I propose modifying the RFC to say that the lang team can choose to adopt an expedited process for stabilization of new attributes and fields with an FCP (this would not require a new RFC).
>
> ## Additional feedback
>
> I think it would be ideal to strengthen the wording around warning on unrecognized lints or fields. I think these should _always_ be a warn-by-default lint.
>
> We may want to make it possible for a diagnostic attribute to affect or create new warn-by-default lints, which by my read is not allowed in the current RFC ("Any attribute in this namespace may... only affect the messages emitted by a compiler in case of a failed compilation.")
>
> Personally I think it's reasonable to allow affecting existing warnings in the current RFC, and leave the creation of new ones as a future possibility. Or if either of these were considered and rejected, the RFC should say why.

### "Tracking issue for RFC 2515, "Permit impl Trait in type aliases"" rust#63063

- **Link:** https://github.com/rust-lang/rust/issues/63063
- [**Tracking Comment**](https://github.com/rust-lang/rust/issues/63063#issuecomment-1360043090):
> Team member @nikomatsakis has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [x] @cramertj
> * [x] @joshtriplett
> * [x] @nikomatsakis
> * [ ] @pnkfelix
> * [ ] @scottmcm
>
> Concerns:
>
> * ~~~~ resolved by https://github.com/rust-lang/rust/issues/63063#issuecomment-1361432898
> * docs (https://github.com/rust-lang/rust/issues/63063#issuecomment-1364525286)
> * function-defining-uses (https://github.com/rust-lang/rust/issues/63063#issuecomment-1385946789)
>
> Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
>
> cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
> See [this document](https://github.com/rust-lang/rfcbot-rs/blob/master/README.md) for info about what commands tagged team members can give me.
- [**Initiating Comment**](https://github.com/rust-lang/rust/issues/63063#issuecomment-1360043060):
> @rfcbot fcp merge
>
> This has been a long-time coming. Let's Do This!
>
> [Stabilization report in this comment.](https://github.com/rust-lang/rust/issues/63063#issuecomment-1354392317)

cramertj: matklad still has concerns about the proposal without `#[defines]` because rust-analyzer still wants to know about auto traits

cramertj: I think having IDE completions be fast and a little bit wrong is generally the right thing

scottmcm: I think I agree but it would be hard to draw a line between a little bit wrong and too wrong.

cramertj: auto traits shouldn't really matter, IMO. okay to get a delayed error. similar to why we decided auto traits appearing in function signature is not actually that important.

tmandry: Have you brought this up in the thread?

cramertj: Pointed out that this could give you wrong methods, and in a world with auto trait specialization could get wrong type inference(?)

tmandry: I think I'd want it to still suggest the method that won't work for completion, and then get an error telling me why it won't work.

cramertj: Agreed. Compared to having to use `#[defines]` attributes, slightly wrong suggestions seems like the smaller burden.

scottmcm: Could see extension traits being an issue. What if your IDE automatically added where bounds to your methods if you used a blanket impl with where clauses.

cramertj: Like the idea where you start typing a generic function in Rust and your IDE automatically adds bounds as you type

scottmcm: Like if you use `<` it adds `PartialOrd`.

... anyway ..

scottmcm: Version of this that I might like is if you click on a TAIT and get a link to go to the thing that defines it.

cramertj: Weird implications of the attribute; it's weird that if the code can't name a path that a `#[defines]` attribute could.

pnkfelix: We could make it optional. But it wouldn't add value if it isn't checked.

scottmcm: What if 95% of the time it's super obvious because it's in the return type and we don't require the attribute in that case(?)

cramertj: I'm liking `#[defined_at]` because we can land without that in a way that's forward-compatible with landing it later.

TC: One issue is that if you're using `impl Trait` they could be nested and have different definition sites.

cramertj: You could break it out into multiple things.

TC: (something about destructuring types, sorry missed this)

Lokathor: The attribute doesn't have to be real rust syntax, it can be a filename.

tmandry: I think we should check it if it's there. Also would be open to not requiring it in the obvious cases but requiring it the weird ones.

pnkfelix: There was a point where this is something that can recursively blow up.

https://github.com/rust-lang/rust/issues/107645#issuecomment-1513777528

TC: This is based on the idea of "stable autoderef-based stabilization" (there was a blog post about how to do this in Rust since we don't have stabilization).

cramertj: I'm not yet convinced that this is that different from the autocomplete case.

TC: All methods based on autoderef are actually valid, it's a matter of which methods to call when there's ambiguity (the technique is based on the way rustc chooses which method to dispatch to).

tmandry:

cramertj: Question is, are we comfortable moving forward with a world where we start with no attribute?

scottmcm: If we do we can't walk that back and force people to use it without a new edition.

cramertj: This is to assist IDEs or human readers, so having it be a warning seems fine?

scottmcm: The cycles problem makes it sound like there might be a stronger reason to require it.

scottmcm: Maybe we think we can stabilize it anywhere in a signature for now, and we know that's not enough, and we can find a path forward potentially with an attribute for those later?

cramertj:

TC: No worse than checking RPIT. oli said implementing signatures actually simplified the implementation in the compiler and the cycle check.

cramertj: The signature check means you only need to check the function bodies that have the TAIT in return position, right?

TC: I get the sense that the implementer is happy with the current implementation (without the check). My general sense is that if the lang team is comfortable with accepting what's currently implemented and the RA tradeoff oli'd be okay with that.

tmandry: I think I remember oli saying they'd changed their mind on something.

tmandry: I'm on board to move forward with signatures-only if it's a useful enough MVP.

https://github.com/rust-lang/rust/issues/107645#issuecomment-1468728409
> Within the defining scope, attempts to check whether TAIT implements an auto-trait will yield a cycle error unless the auto-trait is listed in the TAIT's bounds. This is suboptimal, but the ideal fix is unclear.

scottmcm: I think this is why further restricting defining scopes is helpful for more than just IDEs.

cramertj: I thought we broke these cycles by checking auto traits outside of checking the function body (which just generated obligations to check later). I'm guessing this autoderef thing would break that. Interesting. You could have the function body type check differently based on whether the type is Send or not.

http://lukaskalbertodt.github.io/2019/12/05/generalized-autoref-based-specialization.html

cramertj: You can currently do this with RPIT, and it also works with TAIT in nightly because we stopped doing the obligation thing (to break cycles) anymore. It's no longer enough to just look at the type check and say "this call site requires `Send` or `Sync`" because the rest of the type check of the function can depend on whether the type is actually `Send` or `Sync`.

cramertj: One big reason that auto traits leak is that we don't have a way to write "this return type impls `Send` if `T: Send`".

TC: If you could put that in a where clause we could check it... that's kind of the problem the IDE is having. If I were writing an IDE I'd lazily evaluate functions and infer those annotations, cache them, and use them to avoid slowdowns.

cramertj: Not sure you have a way to infer them. Not just Send and Sync, also Sized, Freeze, etc.

TC/cramertj: You could infer it by looking at the usage.

scottmcm: Are we reaching a point where we agree with Niko's FCP?

pnkfelix: Niko did speak in favor of the defines attribute (scottmcm: Niko has a concern on it, we can't move forward without that).

tmandry: All I can say is I'm open to not having an attribute in the obvious cases and not stabilizing or requiring one in the non-obvious ones.

scottmcm: I think Niko's FCP is to restrict to signatures but not have `#[defines]`.

tmandry: Should we schedule another design meeting and pull in oli?

cramertj: Oli's support for `#[defines]` is the only point that has given me second thoughts. I'd like to understand that. The attribute feels like something we can add later, *if* it's not going to add unnecessary compiler complexity to resolve the cycles issue.

tmandry: I'll open a follow-up issue for a lang team meeting.

### "Stabilise inline_const" rust#104087

- **Link:** https://github.com/rust-lang/rust/pull/104087
- [**Tracking Comment**](https://github.com/rust-lang/rust/pull/104087#issuecomment-1350231887):
> Team member @scottmcm has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [x] @cramertj
> * [x] @joshtriplett
> * [x] @nikomatsakis
> * [ ] @pnkfelix
> * [x] @scottmcm
>
> Concerns:
>
> * ~~expectations-around-panics-in-inline-const~~ resolved by https://github.com/rust-lang/rust/pull/104087#issuecomment-1449080210
> * optimization-dependent-errors (https://github.com/rust-lang/rust/pull/104087#issuecomment-1449080210)
> * ~~post-monomorphization-errors~~ resolved by https://github.com/rust-lang/rust/pull/104087#issuecomment-1448730779
> * should-unused-code-cause-errors (https://github.com/rust-lang/rust/pull/104087#issuecomment-1410921524)
>
> Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
>
> cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
> See [this document](https://github.com/rust-lang/rfcbot-rs/blob/master/README.md) for info about what commands tagged team members can give me.
- [**Initiating Comment**](https://github.com/rust-lang/rust/pull/104087#issuecomment-1350231871):
> Restarting the FCP from https://github.com/rust-lang/rust/pull/104087#issuecomment-1315946122
>
> @rfcbot fcp merge

Lokathor: Concern about const not being recursive.

scottmcm: I think it's specific to arrays. It lowers to an associated consts. Let's open an issue, not sure it's a stabilization blocker.

cramertj: Seems forward compatible.

### "Stabilize `anonymous_lifetime_in_impl_trait`" rust#107378

- **Link:** https://github.com/rust-lang/rust/pull/107378
- [**Tracking Comment**](https://github.com/rust-lang/rust/pull/107378#issuecomment-1430287200):
> Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [x] @joshtriplett
> * [ ] @nikomatsakis
> * [ ] @pnkfelix
> * [ ] @scottmcm
> * [ ] @tmandry
>
> Concerns:
>
> * elaborate-cases-and-future-directions (https://github.com/rust-lang/rust/pull/107378#issuecomment-1480280524)
> * why-not-higher-rank (https://github.com/rust-lang/rust/pull/107378#issuecomment-1480280524)
>
> Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
>
> cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
> See [this document](https://github.com/rust-lang/rfcbot-rs/blob/master/README.md) for info about what commands tagged team members can give me.
- [**Initiating Comment**](https://github.com/rust-lang/rust/pull/107378#issuecomment-1430287177):
> We discussed this in today's @rust-lang/lang meeting, and we think this is ready for an FCP to merge:
>
> @rfcbot merge
>
> We'd also like to make sure that future work on type-alias impl Trait (TAIT) doesn't automatically assume anonymous lifetimes will work there, and thinks carefully about how or if that should work.

### "TAIT defining scope options" rust#107645

- **Link:** https://github.com/rust-lang/rust/issues/107645
- [**Tracking Comment**](https://github.com/rust-lang/rust/issues/107645#issuecomment-1468728438):
> Team member @nikomatsakis has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [x] @joshtriplett
> * [x] @nikomatsakis
> * [x] @pnkfelix
> * [x] @scottmcm
> * [x] @tmandry
>
> Concerns:
>
> * explicit-alternative (https://github.com/rust-lang/rust/issues/107645#issuecomment-1469979788)
> * why-not-just-the-return-type (https://github.com/rust-lang/rust/issues/107645#issuecomment-1468796621)
>
> Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
>
> cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
> See [this document](https://github.com/rust-lang/rfcbot-rs/blob/master/README.md) for info about what commands tagged team members can give me.
- [**Initiating Comment**](https://github.com/rust-lang/rust/issues/107645#issuecomment-1468728409):
> @rfcbot fcp merge
>
> I propose that we accept https://github.com/rust-lang/rust/pull/107809. It implements a conservative path forward. Basically any function that constraints a TAIT but doesn't list the TAIT in its arguments/return type is a hard error, giving us room to change the behavior in the future.
>
> ### Final behavior as I understand it
>
> * A TAIT has a *defining scope* that corresponds to the enclosing module or item.
> * A *defining use* for a TAIT is any item that (a) is within the defining scope and (b) contains a function that lists the TAIT in the argument or return types, either before or after normalization (*see edge case below).
> * Within the defining scope, an item is called *constraining* if it puts constraints on the value of the TAIT. i.e., for the item to type check, the hidden type of the TAIT must have a particular value. This could occur because of a `let` (e.g., `let x: TAIT = 22_u32`), a return (e.g., `return 22_u32` in a function whose return type is `TAIT`), or in other ways.
> * Any *constraining* item within the defining scope that is not a *defining use* is a hard error. This means we can later opt to allow such a use; or to allow it with an annotation of some kind; or to make other such changes.
> * All *defining uses* must fully infer the hidden type of the TAIT and must infer the same type for the TAIT.
> * WIthin the defining scope, TAITs must always be given generic arguments (e.g., `fn foo<T>() -> TAIT<T>` and not `fn foo() -> TAIT<u32>`). This ensures inference is tractable and well-defined.
>
> ### Current bugs and limitations (forwards compatible to change)
>
> * Within the defining scope, attempts to check whether `TAIT` implements an auto-trait will yield a cycle error unless the auto-trait is listed in the TAIT's bounds. This is suboptimal, but the ideal fix is unclear.
> * A function that has an argument which is an associated type referencing a TAIT (e.g. `<TAIT as SomeTrait>::SomeItem`) ought to be considered a *defining use*. However, in the compiler today, if that associated type can be normalized, and the normalized form does not reference the TAIT, the function is not. This can only cause more errors.
>
> @rustbot labels -I-lang-nominated

### "Make late_bound_lifetime_arguments a hard error." rust#108782

- **Link:** https://github.com/rust-lang/rust/pull/108782
- [**Tracking Comment**](https://github.com/rust-lang/rust/pull/108782#issuecomment-1468627626):
> Team member @nikomatsakis has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [ ] @joshtriplett
> * [x] @nikomatsakis
> * [ ] @pnkfelix
> * [x] @scottmcm
> * [ ] @tmandry
>
> Concerns:
>
> * types-team-input (https://github.com/rust-lang/rust/pull/108782#issuecomment-1477170467)
>
> Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
>
> cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
> See [this document](https://github.com/rust-lang/rfcbot-rs/blob/master/README.md) for info about what commands tagged team members can give me.
- [**Initiating Comment**](https://github.com/rust-lang/rust/pull/108782#issuecomment-1468627594):
> @rfcbot fcp merge
>
> Discussed in a (minimally attended) lang-team triage meeting and we are in favor of moving forward with this.
>

## Active FCPs
### "Stabilize raw-dylib, link_ordinal, import_name_type and -Cdlltool" rust#109677

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

## P-critical issues

None.

## Nominated RFCs, PRs and issues discussed this meeting

(none yet, move things from the section below as they are discussed)

## Nominated RFCs, PRs and issues NOT discussed this meeting
### "RFC: Start working on a Rust specification" rfcs#3355

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

### "dyn Trait comparison should not include the vtable pointer" rust#106447

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

### "Remove misleading target feature aliases" rust#107707

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

### "expand: Change how `#![cfg(FALSE)]` behaves on crate root" rust#110141

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