Properly deduce object lifetime defaults in projections & trait refs #129543

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

Object Lifetime Defaults (Primer, Refresher & Definitions)

You can read this section in The Reference but it's not perfect IMO. 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 object lifetime bound from context (without relying on rustc_infer's region inference as we might not be in a body¹). The "context" means the closest — what I call — eligible generic container C<X0, …, Xn> that wraps this trait object type. (Eligible generic) container is almost synonymous with type constructor but it also includes type aliases, traits & enum variants.

So if we have C<…, dyn Trait, …> (e.g., &'r dyn Trait or Struct<'r, dyn Trait>) or C<…, N<…, dyn Trait, …>, …> (e.g., &'r (dyn Trait,) or Struct<'r, (dyn Trait,)>) where N denotes a generic type that is not an eligible generic container, we use the explicit² outlives-bounds on the corresp. type param of C to determine the object lifetime bound (the details³ aren't relevant here) (e.g., given struct Struct<'a, T: 'a + ?Sized>(…);, we elaborate Struct<'r, dyn Trait> to Struct<'r, dyn Trait + 'r>).

Lastly, I call object lifetime bounds used as the default for constituent trait object types of an eligible generic container C the ambient object lifetime defaults for / induced by C (these ambient defaults may be shadowed by inner containers).

Changes Made by This PR

Make associated type paths / projections eligible generic containers.
- <Y0 as TraitRef<X0, …, Xn>>::AssocTy<Y1, …, Ym> now induces ambient object lifetime defaults for constituents Y0 to Ym (TraitRef is considered a separate container, see also list item (2)).
- Similar case with type-relative ("shorthand") paths Y0::AssocTy<Y1, …, Ym>
- 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).
Fixes 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 gnarly 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)

These changes are theoretically breaking because in certain cases they lead to different object lifetime bounds getting deduced compared to master which is obviously user observable. However, the latest crater run found 0 non-spurious regressions.

Motivation: Both object lifetime default RFCs never explicitly specify what constitutes an — what I call — eligible generic container but it only makes sense to include any type constructor or (generic) type alias that can bear outlives-bounds … like associated types. So it's only consistent to make this change.

Fixes #115379.

r? ghost

If we are in a body, we do however use to normal region inference as a fallback. ↩
Indeed, we don't consider implied bounds (inferred outlives-bounds). ↩
Like how we deal with 'ambiguities' or how we look at the bounds of inner TOTs as a fallback. ↩

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

fmease · 2025-05-07T20:29:03Z

@bors try @rust-timer queue

compiler/rustc_hir_analysis/src/collect/resolve_bound_vars.rs

Properly deduce object lifetime defaults in projections & trait refs #### Object Lifetime Defaults (Primer, Refresher & Definitions) You can read [this section](https://doc.rust-lang.org/reference/lifetime-elision.html#default-trait-object-lifetimes) in The Reference but it's not perfect IMO. 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 *object lifetime bound* from context (without relying on `rustc_infer`'s region inference as we might not be in a body[^1]). The "context" means the closest — what I call — *eligible generic container* `C<X0, …, Xn>` that wraps this trait object type. *(Eligible generic) container* is almost synonymous with type constructor but it also includes type aliases, traits & enum variants. So if we have `C<…, dyn Trait, …>` (e.g., `&'r dyn Trait` or `Struct<'r, dyn Trait>`) or `C<…, N<…, dyn Trait, …>, …>` (e.g., `&'r (dyn Trait,)` or `Struct<'r, (dyn Trait,)>`) where `N` denotes a generic type that is **not** an eligible generic container, we use the explicit[^2] outlives-bounds on the corresp. type param of `C` to determine the object lifetime bound (the details[^3] aren't relevant here) (e.g., given `struct Struct<'a, T: 'a + ?Sized>(…);`, we elaborate `Struct<'r, dyn Trait>` to `Struct<'r, dyn Trait + 'r>`). Lastly, I call object lifetime bounds used as the default for *constituent* trait object types of an eligible generic container `C` the *ambient object lifetime defaults* for / induced by `C` (these ambient defaults may be shadowed by inner containers). --- #### Changes Made by This PR 1. Make associated type paths / projections *eligible generic containers*. * `<Y0 as TraitRef<X0, …, Xn>>::AssocTy<Y1, …, Ym>` now induces *ambient object lifetime defaults* for constituents Y0 to Ym (`TraitRef` is considered a separate container, see also list item **(2)**). * Similar case with type-relative ("shorthand") paths `Y0::AssocTy<Y1, …, Ym>` * 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`). 2. Fixes object lifetime defaults inside trait refs `TraitRef<X0, …, X1>` (this fell out from the previous changes). There used be completely broken due to a gnarly off-by-one error for not accounting for the implicit `Self` type param of traits which leads to cases like * `Outer<'r, dyn Inner>` (with `trait Outer<'a, T: 'a + ?Sized> {}`) getting rejected as "inderminate" (it tries to access a *lifetime* at index 1 instead 0) ([playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=0069c89b2313f0f447ff8b6f7de9adfa)) * `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](https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=9c521165e0ac0d868a8087cd7ca861fe)) **These changes are theoretically breaking** because in certain cases they lead to different object lifetime bounds getting deduced compared to master which is obviously user observable. However, [the latest crater run](rust-lang#129543 (comment)) found 0 non-spurious regressions. **Motivation**: Both object lifetime default RFCs never explicitly specify what constitutes an — what I call — *eligible generic container* but it only makes sense to include any type constructor or (generic) type alias that can bear outlives-bounds … like associated types. So it's only *consistent* to make this change. Fixes rust-lang#115379. r? ghost [^1]: If we *are* in a body, we do however use to normal region inference as a fallback. [^2]: Indeed, we don't consider implied bounds (inferred outlives-bounds). [^3]: Like how we deal with 'ambiguities' or how we look at the bounds of inner TOT as a fallback.

bors · 2025-05-07T20:30:17Z

⌛ Trying commit ec131fe with merge 99962d8169c938d94d1a9642217089b43363e569...

bors · 2025-05-07T22:39:22Z

☀️ Try build successful - checks-actions
Build commit: 99962d8 (99962d8169c938d94d1a9642217089b43363e569)

rust-timer · 2025-05-08T00:17:26Z

Finished benchmarking commit (99962d8): comparison URL.

Overall result: ❌ regressions - please read the text below

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf.

Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please fix the regressions and do another perf run. If the next run shows neutral or positive results, the label will be automatically removed.

@bors rollup=never
@rustbot label: -S-waiting-on-perf +perf-regression

Instruction count

This is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.

	mean	range	count
Regressions ❌ (primary)	1.1%	[1.1%, 1.1%]	1
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	1.1%	[1.1%, 1.1%]	1

Max RSS (memory usage)

Results (primary 0.7%, secondary -0.9%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	1.3%	[0.4%, 5.9%]	11
Regressions ❌ (secondary)	1.9%	[1.9%, 1.9%]	1
Improvements ✅ (primary)	-0.7%	[-1.2%, -0.5%]	5
Improvements ✅ (secondary)	-3.6%	[-3.6%, -3.6%]	1
All ❌✅ (primary)	0.7%	[-1.2%, 5.9%]	16

Cycles

Results (primary -0.0%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	0.7%	[0.5%, 0.8%]	5
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-0.7%	[-1.3%, -0.5%]	5
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-0.0%	[-1.3%, 0.8%]	10

Binary size

Results (primary 0.0%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	0.0%	[0.0%, 0.0%]	8
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.0%	[0.0%, 0.0%]	8

Bootstrap: 770.356s -> 769.507s (-0.11%)
Artifact size: 365.20 MiB -> 365.10 MiB (-0.03%)

oli-obk · 2025-05-08T08:45:25Z

tests/ui/object-lifetime/object-lifetime-default-gat-resolved.rs

+    fn g<'r>(_: <() as Outer>::Ty<'r, dyn Inner>) {}
+}
+
+mod parent { // the object lifetime default comes from the parent generics


Also add a test with both self and parent lifetimes

Do you mean one where the assoc ty is type AssocTy<'own, T: ?Sized + 'own + 'parent>; or type AssocTy<'own, T: ?Sized + 'own, U: ?Sized + 'parent>; or something else entirely?

I had in mind just type AssocTy<'own, T: ?Sized + 'own> (basically identical to the first example, but showing that the extra lifetime doesn't throw it off), and ideally some sort of failure tests of cases that are using the wrong lifetime.

oli-obk · 2025-05-08T09:37:02Z

@rfcbot merge

See summary the main PR comment. For an explanation and rationale of what is going on here.

rfcbot · 2025-05-08T09:37:04Z

Team member @oli-obk has proposed to merge this. The next step is review by the rest of the tagged team members:

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!

See this document for info about what commands tagged team members can give me.

Notably, this excludes the self ty. This automatically fixes object lifetime defaulting for trait 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 of traits.

…ections

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

BoxyUwU · 2025-05-08T11:29:02Z

Could you add an example to the "theoretically breaking" section with a little bit of prose explaining why it breaks? My understanding is that something like this would break:

trait Identity<'a>: 'a {
    type Assoc: ?Sized;
}

impl<'a, T: ?Sized + 'a> Identity<'a> for T {
    type Assoc = T;
}

trait Trait {}

fn foo<'b>(a: Box<<dyn Trait as Identity<'b>>::Assoc>) {
    let a: Box<dyn Trait + 'static> = a;
}

Right now it compiles because we don't use the T: 'a bound from the trait def to compute the dyn type's lifetime bound, but with this PR we will do so, winding up with dyn Trait + 'a instead of dyn Trait + 'static. Is that correct?

BoxyUwU

Feel generally positive towards the conceptual change to the type system here. It feels like a very straightforward "bug fix" change.

BoxyUwU · 2025-05-08T11:58:38Z

compiler/rustc_hir_analysis/src/collect/resolve_bound_vars.rs

+                }
+
+                let (depth, index) = param_to_depth_and_index(generics, self.tcx, param_def_id);
+                segments[segments.len() - depth - 1]


This line seems to ICE with on this example:

trait Identity<'a> { type Assoc<U: ?Sized + 'a>: ?Sized; } impl<'a, T> Identity<'a> for T { type Assoc<U: ?Sized + 'a> = U; } trait Trait {} fn bar<'b, T: for<'c> Identity<'b, Assoc<dyn Trait + 'c> = dyn Trait + 'c>>( a: Box<<T>::Assoc<dyn Trait>>, ) { } fn main() { bar::<()>; }

Right, I didn't think about parent-supplied lifetimes in type-relative paths. Thanks for catching this! Reduced:

trait Outer<'a> { type Ty<T: ?Sized + 'a>; } impl<'a, X> Outer<'a> for X { type Ty<T: ?Sized + 'a> = (); } trait Inner {} fn f<'r, T: Outer<'r>>(a: T::Ty<dyn Inner>) {} fn main() {}

Much less messy than my example 😆

BoxyUwU · 2025-05-08T13:04:18Z

compiler/rustc_hir_analysis/src/collect/resolve_bound_vars.rs

+        // FIXME: Duplicating efforts is not robust or sustainable/maintainable.
+        // Ideally, we'd simply obtain the resulting type-dependent defs from
+        // HIR ty lowering (not only in FnCtxts but also in ItemCtxts!).


I guess you said it yourself here :)

Handling TypeRelative paths by duplicating hir ty lowering logic here seems unfortunate. Do you think it'd be reasonable to just continue with the stable behaviour for TypeRelative paths, this PR would still be a positive change for fully qualified aliases and trait refs.

Though, admittedly, I'm not sure how we'd ever make this work "properly". Propagating type dependent def resolutions from inside ty lowering into the internals here seems unlikely to happen.

Maybe we could have a special resolve_dyn_type_lifetime_bound query that returns whatever we resolved and how many type dependent defs we stepped through (i.e. some kind of [unknown, unknown, 'a, unknown]). Hir ty lowering could then track its own set of lifetime defaults coming from type dependent paths and pair that together to figure out what it should actually use.... Seems somewhat complicated 😅

Tbh, I'd find it really unfortunate if there were such an obscure behavior difference between resolved & type-relative paths! Esp. since my personal motivation for this PR is to 'streamline' the rules of object lifetime defaults by making them apply everywhere where one would expect them to.

For the longest time this branch simply rejected implicit object lifetime bounds in type-relative associated types as "indeterminate" (in item ctxts) — that I'd be more than fine with and crater also didn't complain about that. However, that'd regress tests/ui/deriving/issue-89188-gat-hrtb.rs / issue #89188.

Note that limited_resolve_type_relative_path is already used by RTN, I only extracted the logic into a separate function, so I can use it, too. So even without this PR, in PR #126651 (supporting T::AssocTy0::AssocTy1 I (still) need to update it (demonstrating how 'unsustainable' this approach already is)).

Ah okay 🤔 If it's pre-existing then I think it's fine 👍 even if long term would be nice to not have to do. Ah I guess RTN is unstable though so it would be somewhat reasonable to hold stable codepaths to a higher standard 🤔

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

rustbot assigned oli-obk May 7, 2025

This comment has been minimized.

Sign in to view

rustbot added the S-waiting-on-perf Status: Waiting on a perf run to be completed. label May 7, 2025

fmease commented May 7, 2025

View reviewed changes

compiler/rustc_hir_analysis/src/collect/resolve_bound_vars.rs Outdated Show resolved Hide resolved

compiler/rustc_hir_analysis/src/collect/resolve_bound_vars.rs Outdated Show resolved Hide resolved

This comment has been minimized.

Sign in to view

rustbot added perf-regression Performance regression. and removed S-waiting-on-perf Status: Waiting on a perf run to be completed. labels May 8, 2025

oli-obk reviewed May 8, 2025

View reviewed changes

oli-obk approved these changes May 8, 2025

View reviewed changes

rfcbot added proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. labels May 8, 2025

fmease added 5 commits May 8, 2025 12:31

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

0d034e1

Propagate the object lifetime default to the self ty of resolved proj…

a0c12b4

…ections

Tweak output of #[rustc_object_lifetime_default]

b31ee55

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

Compute object lifetime defaults for type-relative assoc ty paths, too

352dfcb

fmease removed the needs-fcp This change is insta-stable, so needs a completed FCP to proceed. label May 8, 2025

fmease force-pushed the obj-lt-def-gat branch from ec131fe to 352dfcb Compare May 8, 2025 10:53

BoxyUwU reviewed May 8, 2025

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Properly deduce object lifetime defaults in projections & trait refs #129543

Properly deduce object lifetime defaults in projections & trait refs #129543

fmease commented Aug 25, 2024 •

edited

Loading

fmease commented Aug 25, 2024

bors commented Aug 25, 2024

bors commented Aug 25, 2024

fmease commented Aug 25, 2024

craterbot commented Aug 25, 2024

compiler-errors commented Aug 31, 2024

craterbot commented Aug 31, 2024

traviscross commented Aug 31, 2024

craterbot commented Aug 31, 2024

craterbot commented Sep 1, 2024

craterbot commented Sep 1, 2024

fmease commented May 7, 2025

This comment has been minimized.

bors commented May 7, 2025

bors commented May 7, 2025

This comment has been minimized.

rust-timer commented May 8, 2025

oli-obk May 8, 2025

fmease May 8, 2025

oli-obk May 8, 2025

oli-obk commented May 8, 2025

rfcbot commented May 8, 2025 •

edited

Loading

BoxyUwU commented May 8, 2025

BoxyUwU left a comment

BoxyUwU May 8, 2025

fmease May 8, 2025

BoxyUwU May 8, 2025

BoxyUwU May 8, 2025

fmease May 8, 2025 •

edited

Loading

fmease May 8, 2025 •

edited

Loading

BoxyUwU May 8, 2025 •

edited

Loading

Properly deduce object lifetime defaults in projections & trait refs #129543

Are you sure you want to change the base?

Properly deduce object lifetime defaults in projections & trait refs #129543

Conversation

fmease commented Aug 25, 2024 • edited Loading

Object Lifetime Defaults (Primer, Refresher & Definitions)

Changes Made by This PR

Footnotes

fmease commented Aug 25, 2024

bors commented Aug 25, 2024

bors commented Aug 25, 2024

fmease commented Aug 25, 2024

craterbot commented Aug 25, 2024

compiler-errors commented Aug 31, 2024

craterbot commented Aug 31, 2024

traviscross commented Aug 31, 2024

craterbot commented Aug 31, 2024

craterbot commented Sep 1, 2024

craterbot commented Sep 1, 2024

fmease commented May 7, 2025

This comment has been minimized.

bors commented May 7, 2025

bors commented May 7, 2025

This comment has been minimized.

rust-timer commented May 8, 2025

Overall result: ❌ regressions - please read the text below

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

oli-obk commented May 8, 2025

rfcbot commented May 8, 2025 • edited Loading

BoxyUwU commented May 8, 2025

BoxyUwU left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

fmease May 8, 2025 • edited Loading

Choose a reason for hiding this comment

fmease May 8, 2025 • edited Loading

Choose a reason for hiding this comment

BoxyUwU May 8, 2025 • edited Loading

Choose a reason for hiding this comment

fmease commented Aug 25, 2024 •

edited

Loading

rfcbot commented May 8, 2025 •

edited

Loading

fmease May 8, 2025 •

edited

Loading

fmease May 8, 2025 •

edited

Loading

BoxyUwU May 8, 2025 •

edited

Loading