Tracking Issue for Rust 2024: Rescope temporary lifetimes with respect to else
#124085
Closed
8 tasks done
Assignees
Labels
A-edition-2024
Area: The 2024 edition
C-tracking-issue
Category: An issue tracking the progress of sth. like the implementation of an RFC
L-if_let_rescope
Lint: if_let_rescope
S-tracking-ready-for-edition
Status: This issue is ready for inclusion in the edition.
T-lang
Relevant to the language team, which will review and decide on the PR/issue.
Comments
traviscross
added
T-lang
|
@rustbot claim |
|
Update: #107251 has been repurposed for this edition change. |
traviscross
added
S-tracking-impl-incomplete
traviscross
added
the
S-tracking-design-concerns
bors
added a commit
to rust-lang-ci/rust
that referenced
this issue
Aug 25, 2024
…er-run, r=<try> [CRATER RUN DO NOT MERGE] Let chain lint crater run Tracked by rust-lang#124085 Related to rust-lang#107251 cc `@jieyouxu` for review context cc `@traviscross` for edition tracking There is one unresolved issue that `cargo fix --edition` does not emit `if-let-rescope` lint. Details in rust-lang/cargo#14447. Note that this patch is assuming that the feature gate `if_let_rescope` is always on just for this crater run.
bors
added a commit
to rust-lang-ci/rust
that referenced
this issue
Aug 29, 2024
…er-run, r=<try> [CRATER RUN DO NOT MERGE] Let chain lint crater run Tracked by rust-lang#124085 Related to rust-lang#107251 cc `@jieyouxu` for review context cc `@traviscross` for edition tracking There is one unresolved issue that `cargo fix --edition` does not emit `if-let-rescope` lint. Details in rust-lang/cargo#14447. Note that this patch is assuming that the feature gate `if_let_rescope` is always on just for this crater run.
bors
added a commit
to rust-lang-ci/rust
that referenced
this issue
Sep 1, 2024
…er-run, r=<try> [CRATER RUN DO NOT MERGE] Let chain lint crater run Tracked by rust-lang#124085 Related to rust-lang#107251 cc `@jieyouxu` for review context cc `@traviscross` for edition tracking There is one unresolved issue that `cargo fix --edition` does not emit `if-let-rescope` lint. Details in rust-lang/cargo#14447. Note that this patch is assuming that the feature gate `if_let_rescope` is always on just for this crater run.
bors
added a commit
to rust-lang-ci/rust
that referenced
this issue
Sep 5, 2024
…er-run, r=<try> [CRATER RUN DO NOT MERGE] Let chain lint crater run Tracked by rust-lang#124085 Related to rust-lang#107251 cc `@jieyouxu` for review context cc `@traviscross` for edition tracking There is one unresolved issue that `cargo fix --edition` does not emit `if-let-rescope` lint. Details in rust-lang/cargo#14447. Note that this patch is assuming that the feature gate `if_let_rescope` is always on just for this crater run.
bors
added a commit
to rust-lang-ci/rust
that referenced
this issue
Sep 12, 2024
…r=jieyouxu Rescope temp lifetime in if-let into IfElse with migration lint Tracking issue rust-lang#124085 This PR shortens the temporary lifetime to cover only the pattern matching and consequent branch of a `if let`. At the expression location, means that the lifetime is shortened from previously the deepest enclosing block or statement in Edition 2021. This warrants an Edition change. Coming with the Edition change, this patch also implements an edition lint to warn about the change and a safe rewrite suggestion to preserve the 2021 semantics in most cases. Related to rust-lang#103108. Related crater runs: rust-lang#129466.
bors
added a commit
to rust-lang-ci/rust
that referenced
this issue
Sep 13, 2024
…r=jieyouxu Rescope temp lifetime in if-let into IfElse with migration lint Tracking issue rust-lang#124085 This PR shortens the temporary lifetime to cover only the pattern matching and consequent branch of a `if let`. At the expression location, means that the lifetime is shortened from previously the deepest enclosing block or statement in Edition 2021. This warrants an Edition change. Coming with the Edition change, this patch also implements an edition lint to warn about the change and a safe rewrite suggestion to preserve the 2021 semantics in most cases. Related to rust-lang#103108. Related crater runs: rust-lang#129466.
bors
added a commit
to rust-lang-ci/rust
that referenced
this issue
Sep 14, 2024
…er-run, r=<try> [CRATER RUN DO NOT MERGE] Let chain lint crater run Tracked by rust-lang#124085 Related to rust-lang#107251 cc `@jieyouxu` for review context cc `@traviscross` for edition tracking There is one unresolved issue that `cargo fix --edition` does not emit `if-let-rescope` lint. Details in rust-lang/cargo#14447. Note that this patch is assuming that the feature gate `if_let_rescope` is always on just for this crater run.
bors
added a commit
to rust-lang-ci/rust
that referenced
this issue
Sep 14, 2024
…er-run, r=<try> [CRATER RUN DO NOT MERGE] Let chain lint crater run Tracked by rust-lang#124085 Related to rust-lang#107251 cc `@jieyouxu` for review context cc `@traviscross` for edition tracking There is one unresolved issue that `cargo fix --edition` does not emit `if-let-rescope` lint. Details in rust-lang/cargo#14447. Note that this patch is assuming that the feature gate `if_let_rescope` is always on just for this crater run.
bors
added a commit
to rust-lang-ci/rust
that referenced
this issue
Sep 16, 2024
…er-run, r=<try> [CRATER RUN DO NOT MERGE] Let chain lint crater run Tracked by rust-lang#124085 Related to rust-lang#107251 cc `@jieyouxu` for review context cc `@traviscross` for edition tracking There is one unresolved issue that `cargo fix --edition` does not emit `if-let-rescope` lint. Details in rust-lang/cargo#14447. Note that this patch is assuming that the feature gate `if_let_rescope` is always on just for this crater run.
bors
added a commit
to rust-lang-ci/rust
that referenced
this issue
Sep 17, 2024
…er-run, r=<try> [CRATER RUN DO NOT MERGE] Let chain lint crater run Tracked by rust-lang#124085 Related to rust-lang#107251 cc `@jieyouxu` for review context cc `@traviscross` for edition tracking There is one unresolved issue that `cargo fix --edition` does not emit `if-let-rescope` lint. Details in rust-lang/cargo#14447. Note that this patch is assuming that the feature gate `if_let_rescope` is always on just for this crater run.
bors
added a commit
to rust-lang-ci/rust
that referenced
this issue
Sep 17, 2024
…er-run, r=<try> [CRATER RUN DO NOT MERGE] Let chain lint crater run Tracked by rust-lang#124085 Related to rust-lang#107251 cc `@jieyouxu` for review context cc `@traviscross` for edition tracking There is one unresolved issue that `cargo fix --edition` does not emit `if-let-rescope` lint. Details in rust-lang/cargo#14447. Note that this patch is assuming that the feature gate `if_let_rescope` is always on just for this crater run.
bors
added a commit
to rust-lang-ci/rust
that referenced
this issue
Sep 17, 2024
…er-run, r=<try> [CRATER RUN DO NOT MERGE] Let chain lint crater run Tracked by rust-lang#124085 Related to rust-lang#107251 cc `@jieyouxu` for review context cc `@traviscross` for edition tracking There is one unresolved issue that `cargo fix --edition` does not emit `if-let-rescope` lint. Details in rust-lang/cargo#14447. Note that this patch is assuming that the feature gate `if_let_rescope` is always on just for this crater run.
bors
added a commit
to rust-lang-ci/rust
that referenced
this issue
Sep 17, 2024
…er-run, r=<try> [CRATER RUN DO NOT MERGE] Let chain lint crater run Tracked by rust-lang#124085 Related to rust-lang#107251 cc `@jieyouxu` for review context cc `@traviscross` for edition tracking There is one unresolved issue that `cargo fix --edition` does not emit `if-let-rescope` lint. Details in rust-lang/cargo#14447. Note that this patch is assuming that the feature gate `if_let_rescope` is always on just for this crater run.
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this issue
Sep 30, 2024
…ope-lint, r=jieyouxu Preserve brackets around if-lets and skip while-lets r? `@jieyouxu` Tracked by rust-lang#124085 Fresh out of rust-lang#129466, we have discovered 9 crates that the lint did not successfully migrate because the span of `if let` includes the surrounding brackets `(..)` like the following, which surprised me a bit. ```rust if (if let .. { .. } else { .. }) { // ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ // the span somehow includes the surrounding brackets } ``` There is one crate that failed the migration because some suggestion spans cross the macro expansion boundaries. Surely there is no way to patch them with `match` rewrite. To handle this case, we will instead require all spans to be tested for admissibility as suggestion spans. Besides, there are 4 false negative cases discovered with desugared-`while let`. We don't need to lint them, because the `else` branch surely contains exactly one statement because the drop order is not changed whatsoever in this case. ```rust while let Some(value) = droppy().get() { .. } // is desugared into loop { if let Some(value) = droppy().get() { .. } else { break; // here can be nothing observable in this block } } ``` I believe this is the one and only false positive that I have found. I think we have finally nailed all the corner cases this time.
traviscross
added
S-tracking-ready-to-stabilize
traviscross
removed
the
S-tracking-impl-incomplete
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this issue
Oct 28, 2024
…rescope, r=traviscross,lcnr Stabilize if_let_rescope Close rust-lang#131154 Tracked by rust-lang#124085
workingjubilee
added a commit
to workingjubilee/rustc
that referenced
this issue
Oct 29, 2024
…rescope, r=traviscross,lcnr Stabilize if_let_rescope Close rust-lang#131154 Tracked by rust-lang#124085
workingjubilee
added a commit
to workingjubilee/rustc
that referenced
this issue
Oct 29, 2024
…rescope, r=traviscross,lcnr Stabilize if_let_rescope Close rust-lang#131154 Tracked by rust-lang#124085
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this issue
Oct 29, 2024
…rescope, r=traviscross,lcnr Stabilize if_let_rescope Close rust-lang#131154 Tracked by rust-lang#124085
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this issue
Oct 29, 2024
Rollup merge of rust-lang#131984 - dingxiangfei2009:stabilize-if-let-rescope, r=traviscross,lcnr Stabilize if_let_rescope Close rust-lang#131154 Tracked by rust-lang#124085
traviscross
removed
the
S-tracking-ready-to-stabilize
hlinnaka
added a commit
to neondatabase/neon
that referenced
this issue
Nov 3, 2024
Compiling with nightly rust compiler, I'm getting a lot of errors like this:
error: `if let` assigns a shorter lifetime since Edition 2024
--> proxy/src/auth/backend/jwt.rs:226:16
|
226 | if let Some(permit) = self.try_acquire_permit() {
| ^^^^^^^^^^^^^^^^^^^-------------------------
| |
| this value has a significant drop implementation which may observe a major change in drop order and requires your discretion
|
= warning: this changes meaning in Rust 2024
= note: for more information, see issue #124085 <rust-lang/rust#124085>
help: the value is now dropped here in Edition 2024
--> proxy/src/auth/backend/jwt.rs:241:13
|
241 | } else {
| ^
note: the lint level is defined here
--> proxy/src/lib.rs:8:5
|
8 | rust_2024_compatibility
| ^^^^^^^^^^^^^^^^^^^^^^^
= note: `#[deny(if_let_rescope)]` implied by `#[deny(rust_2024_compatibility)]`
and this:
error: these values and local bindings have significant drop implementation that will have a different drop order from that of Edition 2021
--> proxy/src/auth/backend/jwt.rs:376:18
|
369 | let client = Client::builder()
| ------ these values have significant drop implementation and will observe changes in drop order under Edition 2024
...
376 | map: DashMap::default(),
| ^^^^^^^^^^^^^^^^^^
|
= warning: this changes meaning in Rust 2024
= note: for more information, see issue #123739 <rust-lang/rust#123739>
= note: `#[deny(tail_expr_drop_order)]` implied by `#[deny(rust_2024_compatibility)]`
They are caused by the `rust_2024_compatibility` lint option.
When we actually switch to the 2024 edition, it makes sense to go
through all these and check that the drop order changes don't break
anything, but in the meanwhile, there's no easy way to avoid these
errors. Disable it, to allow compiling with nightly again.
hlinnaka
added a commit
to neondatabase/neon
that referenced
this issue
Nov 3, 2024
Compiling with nightly rust compiler, I'm getting a lot of errors like this:
error: `if let` assigns a shorter lifetime since Edition 2024
--> proxy/src/auth/backend/jwt.rs:226:16
|
226 | if let Some(permit) = self.try_acquire_permit() {
| ^^^^^^^^^^^^^^^^^^^-------------------------
| |
| this value has a significant drop implementation which may observe a major change in drop order and requires your discretion
|
= warning: this changes meaning in Rust 2024
= note: for more information, see issue #124085 <rust-lang/rust#124085>
help: the value is now dropped here in Edition 2024
--> proxy/src/auth/backend/jwt.rs:241:13
|
241 | } else {
| ^
note: the lint level is defined here
--> proxy/src/lib.rs:8:5
|
8 | rust_2024_compatibility
| ^^^^^^^^^^^^^^^^^^^^^^^
= note: `#[deny(if_let_rescope)]` implied by `#[deny(rust_2024_compatibility)]`
and this:
error: these values and local bindings have significant drop implementation that will have a different drop order from that of Edition 2021
--> proxy/src/auth/backend/jwt.rs:376:18
|
369 | let client = Client::builder()
| ------ these values have significant drop implementation and will observe changes in drop order under Edition 2024
...
376 | map: DashMap::default(),
| ^^^^^^^^^^^^^^^^^^
|
= warning: this changes meaning in Rust 2024
= note: for more information, see issue #123739 <rust-lang/rust#123739>
= note: `#[deny(tail_expr_drop_order)]` implied by `#[deny(rust_2024_compatibility)]`
They are caused by the `rust_2024_compatibility` lint option.
When we actually switch to the 2024 edition, it makes sense to go
through all these and check that the drop order changes don't break
anything, but in the meanwhile, there's no easy way to avoid these
errors. Disable it, to allow compiling with nightly again.
hlinnaka
added a commit
to neondatabase/neon
that referenced
this issue
Nov 4, 2024
Compiling with nightly rust compiler, I'm getting a lot of errors like this:
error: `if let` assigns a shorter lifetime since Edition 2024
--> proxy/src/auth/backend/jwt.rs:226:16
|
226 | if let Some(permit) = self.try_acquire_permit() {
| ^^^^^^^^^^^^^^^^^^^-------------------------
| |
| this value has a significant drop implementation which may observe a major change in drop order and requires your discretion
|
= warning: this changes meaning in Rust 2024
= note: for more information, see issue #124085 <rust-lang/rust#124085>
help: the value is now dropped here in Edition 2024
--> proxy/src/auth/backend/jwt.rs:241:13
|
241 | } else {
| ^
note: the lint level is defined here
--> proxy/src/lib.rs:8:5
|
8 | rust_2024_compatibility
| ^^^^^^^^^^^^^^^^^^^^^^^
= note: `#[deny(if_let_rescope)]` implied by `#[deny(rust_2024_compatibility)]`
and this:
error: these values and local bindings have significant drop implementation that will have a different drop order from that of Edition 2021
--> proxy/src/auth/backend/jwt.rs:376:18
|
369 | let client = Client::builder()
| ------ these values have significant drop implementation and will observe changes in drop order under Edition 2024
...
376 | map: DashMap::default(),
| ^^^^^^^^^^^^^^^^^^
|
= warning: this changes meaning in Rust 2024
= note: for more information, see issue #123739 <rust-lang/rust#123739>
= note: `#[deny(tail_expr_drop_order)]` implied by `#[deny(rust_2024_compatibility)]`
They are caused by the `rust_2024_compatibility` lint option.
When we actually switch to the 2024 edition, it makes sense to go
through all these and check that the drop order changes don't break
anything, but in the meanwhile, there's no easy way to avoid these
errors. Disable it, to allow compiling with nightly again.
conradludgate
pushed a commit
to neondatabase/neon
that referenced
this issue
Nov 4, 2024
Compiling with nightly rust compiler, I'm getting a lot of errors like this:
error: `if let` assigns a shorter lifetime since Edition 2024
--> proxy/src/auth/backend/jwt.rs:226:16
|
226 | if let Some(permit) = self.try_acquire_permit() {
| ^^^^^^^^^^^^^^^^^^^-------------------------
| |
| this value has a significant drop implementation which may observe a major change in drop order and requires your discretion
|
= warning: this changes meaning in Rust 2024
= note: for more information, see issue #124085 <rust-lang/rust#124085>
help: the value is now dropped here in Edition 2024
--> proxy/src/auth/backend/jwt.rs:241:13
|
241 | } else {
| ^
note: the lint level is defined here
--> proxy/src/lib.rs:8:5
|
8 | rust_2024_compatibility
| ^^^^^^^^^^^^^^^^^^^^^^^
= note: `#[deny(if_let_rescope)]` implied by `#[deny(rust_2024_compatibility)]`
and this:
error: these values and local bindings have significant drop implementation that will have a different drop order from that of Edition 2021
--> proxy/src/auth/backend/jwt.rs:376:18
|
369 | let client = Client::builder()
| ------ these values have significant drop implementation and will observe changes in drop order under Edition 2024
...
376 | map: DashMap::default(),
| ^^^^^^^^^^^^^^^^^^
|
= warning: this changes meaning in Rust 2024
= note: for more information, see issue #123739 <rust-lang/rust#123739>
= note: `#[deny(tail_expr_drop_order)]` implied by `#[deny(rust_2024_compatibility)]`
They are caused by the `rust_2024_compatibility` lint option.
When we actually switch to the 2024 edition, it makes sense to go
through all these and check that the drop order changes don't break
anything, but in the meanwhile, there's no easy way to avoid these
errors. Disable it, to allow compiling with nightly again.
bors
added a commit
to rust-lang-ci/rust
that referenced
this issue
Nov 6, 2024
…-lint, r=<try> Skip `if-let-rescope` lint unless requested by migration Tracked by rust-lang#124085 Related to rust-lang#131984 (comment) Given that `if-let-rescope` is a lint to be enabled globally by an edition migration, there is no point in extracting the precise lint level on the HIR expression. This mitigates the performance regression discovered by the earlier perf-run. cc `@Kobzol` `@rylev` `@traviscross` I propose a `rust-timer` run to measure how much performance that we can recover from the mitigation. 🙇
15 tasks
github-merge-queue bot
pushed a commit
to neondatabase/neon
that referenced
this issue
Nov 8, 2024
Compiling with nightly rust compiler, I'm getting a lot of errors like
this:
error: `if let` assigns a shorter lifetime since Edition 2024
--> proxy/src/auth/backend/jwt.rs:226:16
|
226 | if let Some(permit) = self.try_acquire_permit() {
| ^^^^^^^^^^^^^^^^^^^-------------------------
| |
| this value has a significant drop implementation which may observe a
major change in drop order and requires your discretion
|
= warning: this changes meaning in Rust 2024
= note: for more information, see issue #124085
<rust-lang/rust#124085>
help: the value is now dropped here in Edition 2024
--> proxy/src/auth/backend/jwt.rs:241:13
|
241 | } else {
| ^
note: the lint level is defined here
--> proxy/src/lib.rs:8:5
|
8 | rust_2024_compatibility
| ^^^^^^^^^^^^^^^^^^^^^^^
= note: `#[deny(if_let_rescope)]` implied by
`#[deny(rust_2024_compatibility)]`
and this:
error: these values and local bindings have significant drop
implementation that will have a different drop order from that of
Edition 2021
--> proxy/src/auth/backend/jwt.rs:376:18
|
369 | let client = Client::builder()
| ------ these values have significant drop implementation and will
observe changes in drop order under Edition 2024
...
376 | map: DashMap::default(),
| ^^^^^^^^^^^^^^^^^^
|
= warning: this changes meaning in Rust 2024
= note: for more information, see issue #123739
<rust-lang/rust#123739>
= note: `#[deny(tail_expr_drop_order)]` implied by
`#[deny(rust_2024_compatibility)]`
They are caused by the `rust_2024_compatibility` lint option.
When we actually switch to the 2024 edition, it makes sense to go
through all these and check that the drop order changes don't break
anything, but in the meanwhile, there's no easy way to avoid these
errors. Disable it, to allow compiling with nightly again.
Co-authored-by: Arpad Müller <[email protected]>
github-merge-queue bot
pushed a commit
to neondatabase/neon
that referenced
this issue
Nov 8, 2024
Compiling with nightly rust compiler, I'm getting a lot of errors like
this:
error: `if let` assigns a shorter lifetime since Edition 2024
--> proxy/src/auth/backend/jwt.rs:226:16
|
226 | if let Some(permit) = self.try_acquire_permit() {
| ^^^^^^^^^^^^^^^^^^^-------------------------
| |
| this value has a significant drop implementation which may observe a
major change in drop order and requires your discretion
|
= warning: this changes meaning in Rust 2024
= note: for more information, see issue #124085
<rust-lang/rust#124085>
help: the value is now dropped here in Edition 2024
--> proxy/src/auth/backend/jwt.rs:241:13
|
241 | } else {
| ^
note: the lint level is defined here
--> proxy/src/lib.rs:8:5
|
8 | rust_2024_compatibility
| ^^^^^^^^^^^^^^^^^^^^^^^
= note: `#[deny(if_let_rescope)]` implied by
`#[deny(rust_2024_compatibility)]`
and this:
error: these values and local bindings have significant drop
implementation that will have a different drop order from that of
Edition 2021
--> proxy/src/auth/backend/jwt.rs:376:18
|
369 | let client = Client::builder()
| ------ these values have significant drop implementation and will
observe changes in drop order under Edition 2024
...
376 | map: DashMap::default(),
| ^^^^^^^^^^^^^^^^^^
|
= warning: this changes meaning in Rust 2024
= note: for more information, see issue #123739
<rust-lang/rust#123739>
= note: `#[deny(tail_expr_drop_order)]` implied by
`#[deny(rust_2024_compatibility)]`
They are caused by the `rust_2024_compatibility` lint option.
When we actually switch to the 2024 edition, it makes sense to go
through all these and check that the drop order changes don't break
anything, but in the meanwhile, there's no easy way to avoid these
errors. Disable it, to allow compiling with nightly again.
Co-authored-by: Arpad Müller <[email protected]>
conradludgate
pushed a commit
to neondatabase/neon
that referenced
this issue
Nov 8, 2024
Compiling with nightly rust compiler, I'm getting a lot of errors like
this:
error: `if let` assigns a shorter lifetime since Edition 2024
--> proxy/src/auth/backend/jwt.rs:226:16
|
226 | if let Some(permit) = self.try_acquire_permit() {
| ^^^^^^^^^^^^^^^^^^^-------------------------
| |
| this value has a significant drop implementation which may observe a
major change in drop order and requires your discretion
|
= warning: this changes meaning in Rust 2024
= note: for more information, see issue #124085
<rust-lang/rust#124085>
help: the value is now dropped here in Edition 2024
--> proxy/src/auth/backend/jwt.rs:241:13
|
241 | } else {
| ^
note: the lint level is defined here
--> proxy/src/lib.rs:8:5
|
8 | rust_2024_compatibility
| ^^^^^^^^^^^^^^^^^^^^^^^
= note: `#[deny(if_let_rescope)]` implied by
`#[deny(rust_2024_compatibility)]`
and this:
error: these values and local bindings have significant drop
implementation that will have a different drop order from that of
Edition 2021
--> proxy/src/auth/backend/jwt.rs:376:18
|
369 | let client = Client::builder()
| ------ these values have significant drop implementation and will
observe changes in drop order under Edition 2024
...
376 | map: DashMap::default(),
| ^^^^^^^^^^^^^^^^^^
|
= warning: this changes meaning in Rust 2024
= note: for more information, see issue #123739
<rust-lang/rust#123739>
= note: `#[deny(tail_expr_drop_order)]` implied by
`#[deny(rust_2024_compatibility)]`
They are caused by the `rust_2024_compatibility` lint option.
When we actually switch to the 2024 edition, it makes sense to go
through all these and check that the drop order changes don't break
anything, but in the meanwhile, there's no easy way to avoid these
errors. Disable it, to allow compiling with nightly again.
Co-authored-by: Arpad Müller <[email protected]>
This was referenced Nov 9, 2024
traviscross
removed
the
S-tracking-needs-documentation
|
@rustbot labels +S-tracking-ready-for-edition On the edition side, we've reviewed this item, and it's now ready for Rust 2024. Huge thanks to @dingxiangfei2009 for his great work on pushing this item forward and getting it done. |
rustbot
added
the
S-tracking-ready-for-edition
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This is a tracking issue for shortening the scope of temporary lifetimes in
if-letblocks to end beforeelse. E.g.:About tracking issues
Tracking issues are used to record the overall progress of implementation. They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions. A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature. Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.
Steps
if_let_rescopefor Edition 2024 #131154Unresolved Questions
TODO.
Related
Implementation history
The text was updated successfully, but these errors were encountered: