Implement `super let` #139112

m-ou-se · 2025-03-29T16:49:30Z

Tracking issue: #139076

This implements super let as proposed in #139080, based on the following two equivalence rules.

For all expressions $expr in any context, these are equivalent:

& $expr
{ super let a = & $expr; a }

And, additionally, these are equivalent in any context when $expr is a temporary (aka rvalue):

& $expr
{ super let a = $expr; & a }

So far, this experiment has a few interesting results:

Interesting result 1

In this snippet:

super let a = f(&temp());

I originally expected temporary temp() would be dropped at the end of the statement (;), just like in a regular let, because temp() is not subject to temporary lifetime extension.

However, it turns out that that would break the fundamental equivalence rules.

For example, in

g(&f(&temp()));

the temporary temp() will be dropped at the ;.

The first equivalence rule tells us this must be equivalent:

g({ super let a = &f(&temp()); a });

But that means that temp() must live until the last ; (after g()), not just the first ; (after f()).

While this was somewhat surprising to me at first, it does match the exact behavior we need for pin!(): The following should work. (See also #138718)

g(pin!(f(&mut temp())));

Here, temp() lives until the end of the statement. This makes sense from the perspective of the user, as no other ; or {} are visible. Whether pin!() uses a {} block internally or not should be irrelevant.

This means that nothing in a super let statement will be dropped at the end of that super let statement. It does not even need its own scope.

This raises questions that are useful for later on:

Will this make temporaries live too long in cases where super let is used not in a hidden block in a macro, but as a visible statement in code like the following?
```
let writer = {
    super let file = File::create(&format!("/home/{user}/test"));
    Writer::new(&file)
};
```
Is a let statement in a block still the right syntax for this? Considering it has no scope of its own, maybe neither a block nor a statement should be involved

This leads me to think that instead of { super let $pat = $init; $expr }, we might want to consider something like let $pat = $init in $expr or $expr where $pat = $init. Although there are also issues with these, as it isn't obvious anymore if $init should be subject to temporary lifetime extension. (Do we want both let _ = _ in .. and super let _ = _ in ..?)

Interesting result 2

What about super let x; without initializer?

let a = {
    super let x;
    x = temp();
    &x
};

This works fine with the implementation in this PR: x is extended to live as long as a.

While it matches my expectations, a somewhat interesting thing to realize is that these are not equivalent:

super let x = $expr;
super let x; x = $expr;

In the first case, all temporaries in $expr will live at least as long as (the result of) the surrounding block.
In the second case, temporaries will be dropped at the end of the assignment statement. (Because the assignment statement itself "is not super".)

This difference in behavior might be confusing, but it might be useful.
One might want to extend the lifetime of a variable without extending all the temporaries in the initializer expression.

On the other hand, that can also be expressed as:

let x = $expr; super let x = x; (w/o temporary lifetime extension), or
super let x = { $expr }; (w/ temporary lifetime extension)

So, this raises these questions:

Do we want to accept super let x; without initializer at all?
Does it make sense for statements other than let statements to be "super"? An expression statement also drops temporaries at its ;, so now that we discovered that super let basically disables that ; (see interesting result 1), is there a use to having other statements without their own scope? (I don't think that's ever useful?)

Interesting result 3

This works now:

super let Some(x) = a.get(i) else { return };

I didn't put in any special cases for super let else. This is just the behavior that 'naturally' falls out when implementing super let without thinking of the let else case.

Should super let else work?

Interesting result 4

This 'works':

fn main() {
    super let a = 123;
}

I didn't put in any special cases for super let at function scope. I had expected the code to cause an ICE or other weird failure when used at function body scope, because there's no way to let the variable live as long as the result of the function.

This raises the question:

Does this mean that this behavior is the natural/expected behavior when super let is used at function scope? Or is this just a quirk and should we explicitly disallow super let in a function body? (Probably the latter.)

The questions above do not need an answer to land this PR. These questions should be considered when redesigning/rfc'ing/stabilizing the feature.

bors · 2025-04-01T11:41:03Z

☔ The latest upstream changes (presumably #138740) made this pull request unmergeable. Please resolve the merge conflicts.

compiler/rustc_ast_pretty/src/pprust/state.rs

compiler/rustc_hir_analysis/src/check/region.rs

lcnr

needs non-feature gate tests

Co-authored-by: lcnr <[email protected]>

rustbot · 2025-04-04T09:23:30Z

Changes to the size of AST and/or HIR nodes.

cc @nnethercote

lcnr · 2025-04-04T11:41:45Z

@bors try @rust-timer queue

Implement `super let` Tracking issue: rust-lang#139076 This implements `super let` as proposed in rust-lang#139080, based on the following two equivalence rules. 1. For all expressions `$expr` in any context, these are equivalent: - `& $expr` - `{ super let a = & $expr; a }` 2. And, additionally, these are equivalent in any context when `$expr` is a temporary (aka rvalue): - `& $expr` - `{ super let a = $expr; & a }` So far, this experiment has a few interesting results: ## Interesting result 1 In this snippet: ```rust super let a = f(&temp()); ``` I originally expected temporary `temp()` would be dropped at the end of the statement (`;`), just like in a regular `let`, because `temp()` is not subject to temporary lifetime extension. However, it turns out that that would break the fundamental equivalence rules. For example, in ```rust g(&f(&temp())); ``` the temporary `temp()` will be dropped at the `;`. The first equivalence rule tells us this must be equivalent: ```rust g({ super let a = &f(&temp()); a }); ``` But that means that `temp()` must live until the last `;` (after `g()`), not just the first `;` (after `f()`). While this was somewhat surprising to me at first, it does match the exact behavior we need for `pin!()`: The following _should work_. (See also rust-lang#138718) ```rust g(pin!(f(&mut temp()))); ``` Here, `temp()` lives until the end of the statement. This makes sense from the perspective of the user, as no other `;` or `{}` are visible. Whether `pin!()` uses a `{}` block internally or not should be irrelevant. This means that _nothing_ in a `super let` statement will be dropped at the end of that super let statement. It does not even need its own scope. This raises questions that are useful for later on: - Will this make temporaries live _too long_ in cases where `super let` is used not in a hidden block in a macro, but as a visible statement in code like the following? ```rust let writer = { super let file = File::create(&format!("/home/{user}/test")); Writer::new(&file) }; ``` - Is a `let` statement in a block still the right syntax for this? Considering it has _no_ scope of its own, maybe neither a block nor a statement should be involved This leads me to think that instead of `{ super let $pat = $init; $expr }`, we might want to consider something like `let $pat = $init in $expr` or `$expr where $pat = $init`. Although there are also issues with these, as it isn't obvious anymore if `$init` should be subject to temporary lifetime extension. (Do we want both `let _ = _ in ..` and `super let _ = _ in ..`?) ## Interesting result 2 What about `super let x;` without initializer? ```rust let a = { super let x; x = temp(); &x }; ``` This works fine with the implementation in this PR: `x` is extended to live as long as `a`. While it matches my expectations, a somewhat interesting thing to realize is that these are _not_ equivalent: - `super let x = $expr;` - `super let x; x = $expr;` In the first case, all temporaries in $expr will live at least as long as (the result of) the surrounding block. In the second case, temporaries will be dropped at the end of the assignment statement. (Because the assignment statement itself "is not `super`".) This difference in behavior might be confusing, but it _might_ be useful. One might want to extend the lifetime of a variable without extending all the temporaries in the initializer expression. On the other hand, that can also be expressed as: - `let x = $expr; super let x = x;` (w/o temporary lifetime extension), or - `super let x = { $expr };` (w/ temporary lifetime extension) So, this raises these questions: - Do we want to accept `super let x;` without initializer at all? - Does it make sense for statements other than let statements to be "super"? An expression statement also drops temporaries at its `;`, so now that we discovered that `super let` basically disables that `;` (see interesting result 1), is there a use to having other statements without their own scope? (I don't think that's ever useful?) ## Interesting result 3 This works now: ```rust super let Some(x) = a.get(i) else { return }; ``` I didn't put in any special cases for `super let else`. This is just the behavior that 'naturally' falls out when implementing `super let` without thinking of the `let else` case. - Should `super let else` work? ## Interesting result 4 This 'works': ```rust fn main() { super let a = 123; } ``` I didn't put in any special cases for `super let` at function scope. I had expected the code to cause an ICE or other weird failure when used at function body scope, because there's no way to let the variable live as long as the result of the function. This raises the question: - Does this mean that this behavior is the natural/expected behavior when `super let` is used at function scope? Or is this just a quirk and should we explicitly disallow `super let` in a function body? (Probably the latter.) --- The questions above do not need an answer to land this PR. These questions should be considered when redesigning/rfc'ing/stabilizing the feature.

bors · 2025-04-04T11:42:57Z

⌛ Trying commit 0bec927 with merge 4bce3fd...

bors · 2025-04-04T13:49:41Z

☀️ Try build successful - checks-actions
Build commit: 4bce3fd (4bce3fdb7444449969801cc883e3f92767b58dff)

rust-timer · 2025-04-04T15:43:23Z

Finished benchmarking commit (4bce3fd): comparison URL.

Overall result: no relevant changes - no action needed

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.

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

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

Results (primary 5.4%, secondary -0.6%)

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)	5.4%	[5.4%, 5.4%]	1
Regressions ❌ (secondary)	3.4%	[3.0%, 3.8%]	2
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-4.5%	[-4.5%, -4.5%]	2
All ❌✅ (primary)	5.4%	[5.4%, 5.4%]	1

Cycles

Results (secondary 3.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
Regressions ❌ (secondary)	3.0%	[3.0%, 3.0%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Binary size

Results (secondary 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
Regressions ❌ (secondary)	0.0%	[0.0%, 0.0%]	2
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Bootstrap: 778.988s -> 780.503s (0.19%)
Artifact size: 365.99 MiB -> 366.00 MiB (0.00%)

lcnr · 2025-04-07T08:09:54Z

coolio

@bors r+ rollup

bors · 2025-04-07T08:09:56Z

📌 Commit ccbef74 has been approved by lcnr

It is now in the queue for this repository.

Implement `super let` Tracking issue: rust-lang#139076 This implements `super let` as proposed in rust-lang#139080, based on the following two equivalence rules. 1. For all expressions `$expr` in any context, these are equivalent: - `& $expr` - `{ super let a = & $expr; a }` 2. And, additionally, these are equivalent in any context when `$expr` is a temporary (aka rvalue): - `& $expr` - `{ super let a = $expr; & a }` So far, this experiment has a few interesting results: ## Interesting result 1 In this snippet: ```rust super let a = f(&temp()); ``` I originally expected temporary `temp()` would be dropped at the end of the statement (`;`), just like in a regular `let`, because `temp()` is not subject to temporary lifetime extension. However, it turns out that that would break the fundamental equivalence rules. For example, in ```rust g(&f(&temp())); ``` the temporary `temp()` will be dropped at the `;`. The first equivalence rule tells us this must be equivalent: ```rust g({ super let a = &f(&temp()); a }); ``` But that means that `temp()` must live until the last `;` (after `g()`), not just the first `;` (after `f()`). While this was somewhat surprising to me at first, it does match the exact behavior we need for `pin!()`: The following _should work_. (See also rust-lang#138718) ```rust g(pin!(f(&mut temp()))); ``` Here, `temp()` lives until the end of the statement. This makes sense from the perspective of the user, as no other `;` or `{}` are visible. Whether `pin!()` uses a `{}` block internally or not should be irrelevant. This means that _nothing_ in a `super let` statement will be dropped at the end of that super let statement. It does not even need its own scope. This raises questions that are useful for later on: - Will this make temporaries live _too long_ in cases where `super let` is used not in a hidden block in a macro, but as a visible statement in code like the following? ```rust let writer = { super let file = File::create(&format!("/home/{user}/test")); Writer::new(&file) }; ``` - Is a `let` statement in a block still the right syntax for this? Considering it has _no_ scope of its own, maybe neither a block nor a statement should be involved This leads me to think that instead of `{ super let $pat = $init; $expr }`, we might want to consider something like `let $pat = $init in $expr` or `$expr where $pat = $init`. Although there are also issues with these, as it isn't obvious anymore if `$init` should be subject to temporary lifetime extension. (Do we want both `let _ = _ in ..` and `super let _ = _ in ..`?) ## Interesting result 2 What about `super let x;` without initializer? ```rust let a = { super let x; x = temp(); &x }; ``` This works fine with the implementation in this PR: `x` is extended to live as long as `a`. While it matches my expectations, a somewhat interesting thing to realize is that these are _not_ equivalent: - `super let x = $expr;` - `super let x; x = $expr;` In the first case, all temporaries in $expr will live at least as long as (the result of) the surrounding block. In the second case, temporaries will be dropped at the end of the assignment statement. (Because the assignment statement itself "is not `super`".) This difference in behavior might be confusing, but it _might_ be useful. One might want to extend the lifetime of a variable without extending all the temporaries in the initializer expression. On the other hand, that can also be expressed as: - `let x = $expr; super let x = x;` (w/o temporary lifetime extension), or - `super let x = { $expr };` (w/ temporary lifetime extension) So, this raises these questions: - Do we want to accept `super let x;` without initializer at all? - Does it make sense for statements other than let statements to be "super"? An expression statement also drops temporaries at its `;`, so now that we discovered that `super let` basically disables that `;` (see interesting result 1), is there a use to having other statements without their own scope? (I don't think that's ever useful?) ## Interesting result 3 This works now: ```rust super let Some(x) = a.get(i) else { return }; ``` I didn't put in any special cases for `super let else`. This is just the behavior that 'naturally' falls out when implementing `super let` without thinking of the `let else` case. - Should `super let else` work? ## Interesting result 4 This 'works': ```rust fn main() { super let a = 123; } ``` I didn't put in any special cases for `super let` at function scope. I had expected the code to cause an ICE or other weird failure when used at function body scope, because there's no way to let the variable live as long as the result of the function. This raises the question: - Does this mean that this behavior is the natural/expected behavior when `super let` is used at function scope? Or is this just a quirk and should we explicitly disallow `super let` in a function body? (Probably the latter.) --- The questions above do not need an answer to land this PR. These questions should be considered when redesigning/rfc'ing/stabilizing the feature.

Rollup of 8 pull requests Successful merges: - rust-lang#138603 (Report line number of test when should_panic test failed) - rust-lang#139035 (Add new `PatKind::Missing` variants) - rust-lang#139112 (Implement `super let`) - rust-lang#139365 (Default auto traits: fix perf) - rust-lang#139397 (coverage: Build the CGU's global file table as late as possible) - rust-lang#139455 ( Remove support for `extern "rust-intrinsic"` blocks) - rust-lang#139461 (Stop calling `source_span` query in significant drop order code) - rust-lang#139466 (Trivial tweaks to stop tracking source span directly) r? `@ghost` `@rustbot` modify labels: rollup

Rollup of 9 pull requests Successful merges: - rust-lang#139035 (Add new `PatKind::Missing` variants) - rust-lang#139108 (Simplify `thir::PatKind::ExpandedConstant`) - rust-lang#139112 (Implement `super let`) - rust-lang#139365 (Default auto traits: fix perf) - rust-lang#139397 (coverage: Build the CGU's global file table as late as possible) - rust-lang#139455 ( Remove support for `extern "rust-intrinsic"` blocks) - rust-lang#139461 (Stop calling `source_span` query in significant drop order code) - rust-lang#139465 (add sret handling for scalar autodiff) - rust-lang#139466 (Trivial tweaks to stop tracking source span directly) r? `@ghost` `@rustbot` modify labels: rollup

Rollup merge of rust-lang#139112 - m-ou-se:super-let, r=lcnr Implement `super let` Tracking issue: rust-lang#139076 This implements `super let` as proposed in rust-lang#139080, based on the following two equivalence rules. 1. For all expressions `$expr` in any context, these are equivalent: - `& $expr` - `{ super let a = & $expr; a }` 2. And, additionally, these are equivalent in any context when `$expr` is a temporary (aka rvalue): - `& $expr` - `{ super let a = $expr; & a }` So far, this experiment has a few interesting results: ## Interesting result 1 In this snippet: ```rust super let a = f(&temp()); ``` I originally expected temporary `temp()` would be dropped at the end of the statement (`;`), just like in a regular `let`, because `temp()` is not subject to temporary lifetime extension. However, it turns out that that would break the fundamental equivalence rules. For example, in ```rust g(&f(&temp())); ``` the temporary `temp()` will be dropped at the `;`. The first equivalence rule tells us this must be equivalent: ```rust g({ super let a = &f(&temp()); a }); ``` But that means that `temp()` must live until the last `;` (after `g()`), not just the first `;` (after `f()`). While this was somewhat surprising to me at first, it does match the exact behavior we need for `pin!()`: The following _should work_. (See also rust-lang#138718) ```rust g(pin!(f(&mut temp()))); ``` Here, `temp()` lives until the end of the statement. This makes sense from the perspective of the user, as no other `;` or `{}` are visible. Whether `pin!()` uses a `{}` block internally or not should be irrelevant. This means that _nothing_ in a `super let` statement will be dropped at the end of that super let statement. It does not even need its own scope. This raises questions that are useful for later on: - Will this make temporaries live _too long_ in cases where `super let` is used not in a hidden block in a macro, but as a visible statement in code like the following? ```rust let writer = { super let file = File::create(&format!("/home/{user}/test")); Writer::new(&file) }; ``` - Is a `let` statement in a block still the right syntax for this? Considering it has _no_ scope of its own, maybe neither a block nor a statement should be involved This leads me to think that instead of `{ super let $pat = $init; $expr }`, we might want to consider something like `let $pat = $init in $expr` or `$expr where $pat = $init`. Although there are also issues with these, as it isn't obvious anymore if `$init` should be subject to temporary lifetime extension. (Do we want both `let _ = _ in ..` and `super let _ = _ in ..`?) ## Interesting result 2 What about `super let x;` without initializer? ```rust let a = { super let x; x = temp(); &x }; ``` This works fine with the implementation in this PR: `x` is extended to live as long as `a`. While it matches my expectations, a somewhat interesting thing to realize is that these are _not_ equivalent: - `super let x = $expr;` - `super let x; x = $expr;` In the first case, all temporaries in $expr will live at least as long as (the result of) the surrounding block. In the second case, temporaries will be dropped at the end of the assignment statement. (Because the assignment statement itself "is not `super`".) This difference in behavior might be confusing, but it _might_ be useful. One might want to extend the lifetime of a variable without extending all the temporaries in the initializer expression. On the other hand, that can also be expressed as: - `let x = $expr; super let x = x;` (w/o temporary lifetime extension), or - `super let x = { $expr };` (w/ temporary lifetime extension) So, this raises these questions: - Do we want to accept `super let x;` without initializer at all? - Does it make sense for statements other than let statements to be "super"? An expression statement also drops temporaries at its `;`, so now that we discovered that `super let` basically disables that `;` (see interesting result 1), is there a use to having other statements without their own scope? (I don't think that's ever useful?) ## Interesting result 3 This works now: ```rust super let Some(x) = a.get(i) else { return }; ``` I didn't put in any special cases for `super let else`. This is just the behavior that 'naturally' falls out when implementing `super let` without thinking of the `let else` case. - Should `super let else` work? ## Interesting result 4 This 'works': ```rust fn main() { super let a = 123; } ``` I didn't put in any special cases for `super let` at function scope. I had expected the code to cause an ICE or other weird failure when used at function body scope, because there's no way to let the variable live as long as the result of the function. This raises the question: - Does this mean that this behavior is the natural/expected behavior when `super let` is used at function scope? Or is this just a quirk and should we explicitly disallow `super let` in a function body? (Probably the latter.) --- The questions above do not need an answer to land this PR. These questions should be considered when redesigning/rfc'ing/stabilizing the feature.

rustbot assigned lcnr Mar 29, 2025

This comment was marked as outdated.

Sign in to view

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Mar 29, 2025

This was referenced Mar 29, 2025

Tracking Issue for super let #139076

Open

Implement pin!() using super let #139114

Open

m-ou-se force-pushed the super-let branch from 1e8e3ab to fe98f53 Compare March 30, 2025 08:41

This comment has been minimized.

Sign in to view

m-ou-se force-pushed the super-let branch from fe98f53 to ef5b70e Compare March 30, 2025 10:54

m-ou-se mentioned this pull request Mar 30, 2025

Allow storing format_args!() in variable or const #139135

Draft

lcnr reviewed Apr 1, 2025

View reviewed changes

compiler/rustc_ast_pretty/src/pprust/state.rs Outdated Show resolved Hide resolved

lcnr reviewed Apr 1, 2025

View reviewed changes

compiler/rustc_hir_analysis/src/check/region.rs Outdated Show resolved Hide resolved

lcnr reviewed Apr 1, 2025

View reviewed changes

m-ou-se mentioned this pull request Apr 2, 2025

Experimental feature gate for super let #139080

Merged

m-ou-se and others added 5 commits April 4, 2025 09:44

Implement super let.

3123df8

Fix typo in pretty printing super let.

f02e278

Co-authored-by: lcnr <[email protected]>

Boolean hate.

3e6cc76

Add feature gate test for cfg'd out super let.

b9babad

fixup! Implement super let.

6c3417d

m-ou-se force-pushed the super-let branch from 65a6af2 to c39a4b9 Compare April 4, 2025 09:16

m-ou-se marked this pull request as ready for review April 4, 2025 09:23

This comment has been minimized.

Sign in to view

m-ou-se force-pushed the super-let branch from c39a4b9 to 29585f0 Compare April 4, 2025 10:19

This comment has been minimized.

Sign in to view

m-ou-se force-pushed the super-let branch from 29585f0 to 0bec927 Compare April 4, 2025 11:26

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 Apr 4, 2025

This comment has been minimized.

Sign in to view

Add tests for super let.

ccbef74

m-ou-se force-pushed the super-let branch from 0bec927 to ccbef74 Compare April 4, 2025 14:32

rustbot removed the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Apr 4, 2025

m-ou-se requested a review from lcnr April 4, 2025 21:32

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Apr 7, 2025

Zalathar mentioned this pull request Apr 7, 2025

Rollup of 8 pull requests #139478

Closed

Zalathar mentioned this pull request Apr 7, 2025

Rollup of 9 pull requests #139482

Merged

bors merged commit 27c6e40 into rust-lang:master Apr 7, 2025
6 checks passed

rustbot added this to the 1.88.0 milestone Apr 7, 2025

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Implement `super let` #139112

Implement `super let` #139112

m-ou-se commented Mar 29, 2025 •

edited

Loading

This comment was marked as outdated.

This comment has been minimized.

bors commented Apr 1, 2025

lcnr left a comment

rustbot commented Apr 4, 2025

This comment has been minimized.

This comment has been minimized.

lcnr commented Apr 4, 2025

This comment has been minimized.

bors commented Apr 4, 2025

This comment has been minimized.

bors commented Apr 4, 2025

This comment has been minimized.

rust-timer commented Apr 4, 2025

lcnr commented Apr 7, 2025

bors commented Apr 7, 2025

Implement super let #139112

Implement super let #139112

Conversation

m-ou-se commented Mar 29, 2025 • edited Loading

Interesting result 1

Interesting result 2

Interesting result 3

Interesting result 4

This comment was marked as outdated.

This comment has been minimized.

bors commented Apr 1, 2025

lcnr left a comment

Choose a reason for hiding this comment

rustbot commented Apr 4, 2025

This comment has been minimized.

This comment has been minimized.

lcnr commented Apr 4, 2025

This comment has been minimized.

bors commented Apr 4, 2025

This comment has been minimized.

bors commented Apr 4, 2025

This comment has been minimized.

rust-timer commented Apr 4, 2025

Overall result: no relevant changes - no action needed

Instruction count

Max RSS (memory usage)

Cycles

Binary size

lcnr commented Apr 7, 2025

bors commented Apr 7, 2025

Implement `super let` #139112

Implement `super let` #139112

m-ou-se commented Mar 29, 2025 •

edited

Loading