Make trait refs & assoc ty paths properly induce trait object lifetime defaults by fmease · Pull Request #129543 · rust-lang/rust

fmease · 2024-08-25T03:08:55Z

Trait Object Lifetime Defaults

Primer & Definitions

You could read this section in the Reference but it has several issues (see rust-lang/reference#1407). Here's a small explainer by me that only mentions the parts relevant to this PR:

Basically, given dyn Trait (≠ dyn Trait + '_) we want to deduce its trait object lifetime bound from context without relying on normal region inference as we might not be in a body¹. The "context" means the closest – what I call — (eligible) container C<X0, …, Xn> that wraps this trait object type. A container is to be understood as a use site of a "parametrized definition" (more general than type constructors). Currently eligible are ADTs, type aliases, traits and enum variants.

So if we have C<dyn Trait> (e.g., &'r dyn Trait or Struct<'r, dyn Trait>), D<C<dyn Trait>> or C<N<dyn Trait>> (e.g., Struct<'r, (dyn Trait,)>), we use the explicit² outlives-bounds on the corresponding type parameter of C to determine the trait object lifetime bound. Here, C & D denote (eligible) containers and N denotes a generic type that is not an eligible container. E.g., given struct Struct<'a, T: 'a + ?Sized>(…);, we elaborate Struct<'r, dyn Trait> to Struct<'r, dyn Trait + 'r>.

Finally, we call lifetime bounds used as the default for constituent trait object types of an eligible container C the trait object lifetime defaults (induced by C) which may be shadowed by inner containers.

Changes Made

Make resolved associated type paths / projections eligible containers.
- <Y0 as TraitRef<X0, …, Xn>>::AssocTy<Y1, …, Ym> now induces trait object lifetime defaults for constituents Y0 to Ym (TraitRef is considered a separate container, see also list item (2)).
- Notably, for the self type Y0 of (resolved) projections we now look at the bounds on the Self type param of the relevant trait (e.g., given trait Outer<'a>: 'a { type Proj; } or trait Outer<'a> where Self: 'a { type Proj; } we elaborate <dyn Inner as Outer<'r>>::Proj to <dyn Inner + 'r as Outer<'r>>::Proj).
In type-relative paths Y0::Name<Y1, …, Ym> consider the trait object lifetime default indeterminate
- Meaning if we're in an "item context" / "item signature" / "non-body" (& the trait object type isn't bounded by any outlives-bounds which would take precedence over the default) we will reject any implicit trait object lifetime bounds that would take on that default
- Reason: Limitations of the current implementation which can't be easily overcome
  - RBV (which resolves trait object lifetime defaults by recursing into the local crate "in one sitting") would require the resolution of type-relative paths in order to look up the generics but these paths are only resolved in HIR ty lowering (that can selectively lower local items) which depends on the results of RBV (cyclic dependency!)
  - While one might be able to resolve type-relative paths in RBV in an ad-hoc fashion, it would require a lot of duplication with HIR ty lowering and its impl would be very brittle (RTN does something like that in RBV but we require a more sophisticated resolver)
  - I did attempt that but it got too gnarly and brittle and would've likely been incomplete anyway
  - See also this GH thread
  - See also #t-types/meetings > 2025-09-16 weekly @ 💬
- This should still be maximally forward compatible and allow us to implement the desired behavior in the future.
Fixes trait object lifetime defaults inside trait refs TraitRef<X0, …, Xn> (this fell out from the previous changes). They used to be completely broken due to a nasty off-by-one error for not accounting for the implicit Self type param of traits which lead to cases like
- Outer<'r, dyn Inner> (with trait Outer<'a, T: 'a + ?Sized> {}) getting rejected as indeterminate (it tries to access a lifetime at index 1 instead 0) (playground)
- Outer<'r, 's, dyn Inner> (with trait Outer<'a, 'b, T: 'a + ?Sized> {}) elaborating dyn Inner to dyn Inner + 's instead of dyn Inner + 'r(!) (playground)
- The same applies to trait alias refs (feature trait_alias)
In associated type binding TraitRef<AssocTy<X0, …, Xn> = Y> consider the trait object lifetime default indeterminate (in X0, …, Xn and Y) if X0, …, Xn contains any lifetime arguments.
- Meaning if we're in an item context (& the trait object type isn't otherwise bounded) we will reject any implicit trait object lifetime bounds that would take on that default
- This reserves us the right to (1) take into account the item bounds of AssocTy in the future when computing the default for Y (2) take into account the parameter bounds of AssocTy in the future when computing the defaults for X0, …, Xn.
- This extends a preexisting hack that – given TraitRef<X0, …, Xn, AssocTy<Y0, …, Ym> = Z> – treats the default indeterminate in Y0, …, Ym and Z if X0, …, Xn contains any lifetime arguments.
- Rephrased, this hack / reservation previously didn't account for GAT args, only trait ref args, which is insufficient
- See also this GH comment of mine

Motivation

Both trait object lifetime default RFCs (599 and 1156) never explicitly specify what constitutes a — what I call — (eligible) container but it only makes sense to include anything that can be parametrized by generics and can be mentioned in places where we don't perform full region inference … like associated types. So it's only consistent to make this change.

Breakages

These changes are theoretically breaking because they can lead to different trait object lifetime bounds getting deduced compared to main which is obviously user observable. Moreover, we're now explicitly rejecting implicit trait object lifetime bounds inside type-relative paths (excl. the self type) and on the RHS of assoc type bindings if the assoc type has lifetime params.

However, the latest crater run found 0 non-spurious regressions (see here and here).

Examples (5)

trait Outer<'a> { type Ty<T: ?Sized + 'a>; }
impl<'a> Outer<'a> for () { type Ty<T: ?Sized + 'a> = &'a T; }
trait Inner {}

fn f<'r>(x: <() as Outer<'r>>::Ty<dyn Inner>) { // now `dyn Inner + 'r` instead of `dyn Inner + 'static`
    let _: <() as Outer<'r>>::Ty<dyn Inner + 'static> = x; // => error: lifetime may not live long enough (`'r` must outlive `'static'`)
}

trait Outer { type Ty; }
trait Inner {}

impl<'a> Outer for dyn Inner + 'a { type Ty = &'a (); }

fn f<'r>(x: *mut &'r <dyn Inner as Outer>::Ty) { // now `dyn Inner + 'static` (due to lack of bounds on `Outer`) instead of `dyn Inner + 'r` (since the assoc ty now shadows the default induced by the ref ty ctor `&`)
    let _: *mut &'r <dyn Inner + 'r as Outer>::Ty = x; // => error: lifetime may not live long enough (`'r` must outlive `'static`)
}

trait Outer { type Ty<'a, T: 'a + ?Sized>; }
trait Inner {}

fn f<'r, T: Outer>(x: T::Ty<'r, dyn Inner>) {} // => error: indeterminate (reservation)

trait Outer { type Ty<'a>: ?Sized/* + 'a*/; }
trait Inner {}

fn f<'r>(_: impl Outer<Ty<'r> = dyn Inner>) {} // => error: indeterminate (reservation)

trait Outer { type Ty<'a, T: ?Sized + 'a>; }
trait Inner {}

fn f<'r>(_: impl Outer<Ty<'r, dyn Inner> = ()>) {} // => error: indeterminate (reservation)

Fixes #115379.
Fixes #140710.
Fixes #141997.

If we are in a body we do use to normal region inference as a fallback. ↩
Indeed, we don't consider implied bounds (inferred outlives-bounds). ↩

fmease · 2024-08-25T03:09:05Z

@bors try

[crater] Properly deduce the object lifetime default in GAT paths Fixes rust-lang#115379. r? ghost

bors · 2024-08-25T03:10:17Z

⌛ Trying commit 8bfcd86 with merge 24cd45d...

bors · 2024-08-25T05:05:36Z

☀️ Try build successful - checks-actions
Build commit: 24cd45d (24cd45d7714ba43afd4b8e62fb677b069b21c4a5)

fmease · 2024-08-25T05:06:34Z

@craterbot check

craterbot · 2024-08-25T05:06:42Z

👌 Experiment pr-129543 created and queued.
🤖 Automatically detected try build 24cd45d
🔍 You can check out the queue and this experiment's details.

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

[CRATER] Crater Rollup This is a " crater rollup" of: * rust-lang#126452 * rust-lang#128784 * rust-lang#129392 * rust-lang#129422 * rust-lang#129543 **What is a crater rollup?** It's simply a crater job that is run on all of the containing PRs *together*, and then we can set the crates list for each of these jobs to just the failures after it's done. It should cut out on the bulk of "normal" crates that do nothing and simply just take time to build. r? `@ghost`

[CRATER] Crater Rollup This is a " crater rollup" of: * rust-lang#126452 * rust-lang#128784 * rust-lang#129392 * rust-lang#129422 * rust-lang#129543 * rust-lang#129604 **What is a crater rollup?** It's simply a crater job that is run on all of the containing PRs *together*, and then we can set the crates list for each of these jobs to just the failures after it's done. It should cut out on the bulk of "normal" crates that do nothing and simply just take time to build. r? `@ghost`

compiler-errors · 2024-08-31T12:23:28Z

@craterbot crates=https://gist.githubusercontent.com/compiler-errors/4a09d64cd15dc3dca50edeea26cc9938/raw/b4181c225709e120a11d91cce69d0d4da3e652d0/regressed.txt

craterbot · 2024-08-31T12:23:37Z

📝 Configuration of the pr-129543 experiment changed.

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

traviscross · 2024-08-31T19:27:22Z

@craterbot crates=https://gist.githubusercontent.com/compiler-errors/4a09d64cd15dc3dca50edeea26cc9938/raw/b4181c225709e120a11d91cce69d0d4da3e652d0/regressed.txt p=1

(Bump it up the queue as this will go quickly.)

craterbot · 2024-08-31T19:27:26Z

📝 Configuration of the pr-129543 experiment changed.

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

craterbot · 2024-09-01T07:57:21Z

🚧 Experiment pr-129543 is now running

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

craterbot · 2024-09-01T12:35:33Z

🎉 Experiment pr-129543 is completed!
📊 6 regressed and 0 fixed (98236 total)
📰 Open the full report.

⚠️ If you notice any spurious failure please add them to the blacklist!
ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

rust-bors · 2026-01-14T23:52:38Z

☀️ Try build successful (CI)
Build commit: 5ff9315 (5ff93158e08fa2205cd4b86cddf9eae95952cc96, parent: 86a49fd71fecd25b0fd20247db0ba95eeceaba28)

fmease · 2026-01-15T06:24:22Z

@craterbot check

craterbot · 2026-01-15T06:24:31Z

👌 Experiment pr-129543-2 created and queued.
🤖 Automatically detected try build 5ff9315
🔍 You can check out the queue and this experiment's details.

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

craterbot · 2026-01-21T06:04:05Z

🚧 Experiment pr-129543-2 is now running

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

craterbot · 2026-01-22T23:39:47Z

🎉 Experiment pr-129543-2 is completed!
📊 6 regressed and 2 fixed (784728 total)
📊 1940 spurious results on the retry-regressed-list.txt, consider a retry¹ if this is a significant amount.
📰 Open the summary report.

⚠️ If you notice any spurious failure please add them to the denylist!
ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

re-run the experiment with crates=https://crater-reports.s3.amazonaws.com/pr-129543-2/retry-regressed-list.txt ↩

BoxyUwU · 2026-01-22T23:46:05Z

@craterbot check crates=https://crater-reports.s3.amazonaws.com/pr-129543-2/retry-regressed-list.txt p=1

craterbot · 2026-01-22T23:46:14Z

👌 Experiment pr-129543-3 created and queued.
🤖 Automatically detected try build 5ff9315
🔍 You can check out the queue and this experiment's details.

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

craterbot · 2026-01-24T10:53:26Z

🚧 Experiment pr-129543-3 is now running

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

craterbot · 2026-01-24T17:17:55Z

🎉 Experiment pr-129543-3 is completed!
📊 1 regressed and 0 fixed (1879 total)
📊 115 spurious results on the retry-regressed-list.txt, consider a retry¹ if this is a significant amount.
📰 Open the summary report.

⚠️ If you notice any spurious failure please add them to the denylist!
ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

re-run the experiment with crates=https://crater-reports.s3.amazonaws.com/pr-129543-3/retry-regressed-list.txt ↩

fmease · 2026-02-04T08:58:13Z

Alright, this is now finally ready for a rereview wrt. both implementation and pFCP'ed semantic changes! Changes since last comment of mine:

I've extended a preexisting 'hack' / reservation concerning assoc ty bindings to properly account for GATs, too. This means more theoretical breakages. Please see bullet point (4) in the PR description for technical details. Crater came back clean. The impl is found in the last commit (ae8c0a5)
I've added a lot more tests and improved / fleshed out the preexisting ones
I've heavily improved the source code comments I had added
I've rewritten several parts of the PR description to be more informative & legible
I've added 5 example breakages to the PR description (in a collapsed section)

@lcnr, @BoxyUwU, I'd be super happy if you both could take a look esp. in regards to the (latest version of the) pFCP'ed semantic changes since I'd love it if this can finally go into FCP :D Thanks a lot in advance :)

fmease · 2026-02-10T00:55:48Z

tests/ui/object-lifetime/object-lifetime-default-inferred.rs

This test didn't actually test what it meant to test. I've therefore replaced it with a new one (tests/ui/object-lifetime/object-lifetime-default-inferred-args.rs). It was added in the initial generic_arg_infer PR.

It's meant to test that the presence of _ in a generic arg list doesn't throw off the trait object lifetime default calculations which is a very valuable thing to test (hence me adding a replacement). Sadly, it doesn't test that.

First of all, the only places in this file that contain implicit trait object lifetime bounds that are in the mere vicinity of an inferred arg _ are the two &dyn Tests at the bottom. However, these just get elab'ed to &'?0 (dyn Test + '?1) and &'2 (dyn Test + '?3) since the implicit inferred lifetimes passed to & aren't named, so the default is indeterminate meaning fresh region vars for both since we're in a body.

The two _ passed as part of the fn calls have no influence whatsoever on the defaults chosen for the dyn Test "in random as-casts"; that's not how trait object lifetime defaulting works.

…ir own args (excl. self ty) This automatically fixes trait object lifetime defaulting for trait refs and trait alias refs, too. These used to be broken because the index calculation for going from middle generic args back to HIR ones didn't take into account the implicit self ty param present on traits. Moreover, in item signatures reject hidden trait object lifetime bounds inside type-relative paths (excl. the self ty) on grounds of the default being indeterminate.

…or their self ty

* print `Empty` as it's called in code, otherwise it's unnecessarily confusing * go through the middle::ty Generics instead of the HIR ones, so we can dump the default for the implicit `Self` type parameter of traits, too * allow the attribute on more targets (it used to be allowed anywhere for the longest time but someone must've incorrectly restricted it during the migration to the new attribute parsing API)

…ntiated assoc ty bindings Namely, on the RHS and in the args of the bindings.

rustbot · 2026-02-10T17:29:31Z

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

lcnr

When do we actually use trait object defaults in bodies? isn't it better to just always infer them unless we're in an ItemCtxt?

View changes since this review

lcnr · 2026-03-02T13:15:51Z

compiler/rustc_hir_analysis/src/collect/resolve_bound_vars.rs

+        //
+        // FIXME(mgca, #151649): Assoc (and free?) consts should also qualify.
+        // FIXME(return_type_notation, #151662): Assoc fns should also qualify.
+        let depth = path.segments.len() - index - 1;


can you add a comment explaining what "depth" is, afaict what we care about for AssocTy is if we have T::Assoc, are we in T and for variant we have T::Variant we check whether we're in Variant? That feels odd to me.

I guess assoc types want the info from their trait and everything else wants it from itself, but that doesn't explain variant, with enums you can have generic args both on the enum and on the variant, i.e. both Enum::<args>::Variant and Enum::Variant::<args> are valid

lcnr · 2026-03-02T13:16:04Z

compiler/rustc_hir_analysis/src/collect/resolve_bound_vars.rs

+            ) if depth == 0 => Some((def_id, path.segments)),
+            // Note: We don't need to care about definition kinds that may have generics if they
+            // can only ever appear in positions where we can perform type inference (i.e., bodies).
            _ => None,


how annoying is it to make this exhaustive?

lcnr · 2026-03-02T13:17:48Z

compiler/rustc_hir_analysis/src/collect/resolve_bound_vars.rs

+                        generics: &ty::Generics,
+                        tcx: TyCtxt<'_>,
+                        def_id: DefId,
+                    ) -> (usize, usize) {


comment please 🤔 depth is "index of segment in reverse order" and "index" is "index of args of segment"?

lcnr · 2026-03-02T13:25:28Z

tests/ui/object-lifetime/object-lifetime-default-trait-ref-lifetime-bound-on-assoc-ty.rs

+//@ check-pass
+
+trait Trait<T: ?Sized> { type Assoc<'a> where T: 'a; }
+impl<T: ?Sized> Trait<T> for () { type Assoc<'a> = &'a T where T: 'a; }


is this impl needed?

lcnr · 2026-03-02T13:26:14Z

tests/ui/object-lifetime/object-lifetime-default-trait-ref.rs

+// We deduce `dyn Inner + 'r` from bound `'a` on ty param `T` of trait `Outer`.
+fn assoc_ty_proj<'r>(_: <() as Outer<'r, dyn Inner>>::Ty) {}
+
+impl<'a, T: 'a + AbideBy<'a> + ?Sized> Outer<'a, T> for () { type Ty = &'a T; }


move this to trait definition?

lcnr · 2026-03-02T13:26:24Z

tests/ui/object-lifetime/object-lifetime-default-trait-ref.rs

+
+impl<'a, T: 'a + AbideBy<'a> + ?Sized> Outer<'a, T> for () { type Ty = &'a T; }
+
+trait Inner {}


same here, move this up

lcnr · 2026-03-02T13:28:44Z

compiler/rustc_hir_analysis/src/collect/resolve_bound_vars.rs

+                            self.tcx.parent(def_id),
+                            &path.segments[..path.segments.len() - 1],
+                        )),
+                        _ => None,


what are the cases where this change goes from indeterminate to pass-through due to this change?

something something exhaustive match possible?

lcnr · 2026-03-02T13:37:24Z

tests/ui/object-lifetime/object-lifetime-default-assoc-ty-binding-item-bounds.rs

+
+fn is_static<T>(_: T) where T: 'static {}
+
+// FIXME: Ideally, we'd elaborate `dyn Bar` to `dyn Bar + 'static` instead of rejecting it.


do we? 😅 I am not even sure whether this is desirable or not.

lcnr · 2026-03-02T13:40:56Z

In the list of examples, can you match them to each of the changes from this PR. i.e have

Make resolved associated type paths / projections eligible containers.

// this now chooses `'a` and compiles

// this previously chose `'b` and now chooses `'c`, causing an error

...

after this I am gonna start the FCP

this is a really impressive PR :> sorry for taking so long to get to it.

rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Aug 25, 2024

bors added a commit to rust-lang-ci/rust that referenced this pull request Aug 25, 2024

Auto merge of rust-lang#129543 - fmease:obj-lt-def-gat, r=<try>

24cd45d

[crater] Properly deduce the object lifetime default in GAT paths Fixes rust-lang#115379. r? ghost

fmease removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Aug 25, 2024

craterbot added S-waiting-on-crater Status: Waiting on a crater run to be completed. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Aug 25, 2024

fmease changed the title ~~[crater] Properly deduce the object lifetime default in GAT paths~~ [crater] Properly deduce object lifetime defaults in GAT paths Aug 25, 2024

compiler-errors mentioned this pull request Aug 27, 2024

[CRATER] Crater Rollup #129660

Closed

craterbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-crater Status: Waiting on a crater run to be completed. labels Sep 1, 2024

fmease added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Sep 2, 2024

workingjubilee added the C-crater Category: Issue for tracking crater runs label Feb 14, 2025

fmease removed the C-crater Category: Issue for tracking crater runs label Apr 17, 2025

fmease mentioned this pull request Jan 25, 2026

mGCA: Type-level free & assoc const paths don't induce trait object lifetime defaults #151649

Open

This comment has been minimized.

Sign in to view

fmease mentioned this pull request Jan 25, 2026

RTN paths don't induce trait object lifetime defaults #151662

Open

fmease mentioned this pull request Feb 4, 2026

Trait object lifetime defaults of GATs are not respected #115379

Open

fmease mentioned this pull request Feb 7, 2026

Fix bound var resolution for trait aliases #152309

Merged

This comment has been minimized.

Sign in to view

fmease commented Feb 10, 2026

View reviewed changes

This comment has been minimized.

Sign in to view

fmease added 7 commits February 10, 2026 18:29

Split out fn compute_object_lifetime_defaults

ff1afc4

Don't needlessly search for already-found HIR generic param

b98151d

Make resolved assoc ty paths induce a trait object lifetime default f…

961aa56

…or their self ty

Rename hir::GenericArgs::{num,has}_generic_params to *_generic_args

b1a12c3

Render trait object lifetime defaults indeterminate in lifetime-insta…

2fec74f

…ntiated assoc ty bindings Namely, on the RHS and in the args of the bindings.

lcnr reviewed Mar 2, 2026

View reviewed changes


		impl<'a, T: 'a + AbideBy<'a> + ?Sized> Outer<'a, T> for () { type Ty = &'a T; }

		trait Inner {}


		fn is_static<T>(_: T) where T: 'static {}

		// FIXME: Ideally, we'd elaborate `dyn Bar` to `dyn Bar + 'static` instead of rejecting it.

Uh oh!

Conversation

fmease commented Aug 25, 2024 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Trait Object Lifetime Defaults

Primer & Definitions

Changes Made

Motivation

Breakages

Footnotes

Uh oh!

fmease commented Aug 25, 2024

Uh oh!

bors commented Aug 25, 2024

Uh oh!

bors commented Aug 25, 2024

Uh oh!

fmease commented Aug 25, 2024

Uh oh!

craterbot commented Aug 25, 2024

Uh oh!

compiler-errors commented Aug 31, 2024

Uh oh!

craterbot commented Aug 31, 2024

Uh oh!

traviscross commented Aug 31, 2024

Uh oh!

craterbot commented Aug 31, 2024

Uh oh!

craterbot commented Sep 1, 2024

Uh oh!

craterbot commented Sep 1, 2024

Uh oh!

rust-bors bot commented Jan 14, 2026

Uh oh!

fmease commented Jan 15, 2026

Uh oh!

craterbot commented Jan 15, 2026

Uh oh!

craterbot commented Jan 21, 2026

Uh oh!

craterbot commented Jan 22, 2026

Footnotes

Uh oh!

BoxyUwU commented Jan 22, 2026

Uh oh!

craterbot commented Jan 22, 2026

Uh oh!

craterbot commented Jan 24, 2026

Uh oh!

craterbot commented Jan 24, 2026

Footnotes

Uh oh!

This comment has been minimized.

fmease commented Feb 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

This comment has been minimized.

This comment has been minimized.

fmease Feb 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

This comment has been minimized.

This comment has been minimized.

rustbot commented Feb 10, 2026

Uh oh!

lcnr left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

fmease commented Aug 25, 2024 •

edited by rustbot

Loading

fmease commented Feb 4, 2026 •

edited

Loading

fmease Feb 10, 2026 •

edited

Loading

lcnr left a comment •

edited by rustbot

Loading