The ordinary lowering of thir::ExprKind::Let is unreachable
#121892
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
After desugaring, `let` expressions should only appear inside `if` expressions or `match` guards, possibly nested within a let-chain. In both cases they are specifically handled by the lowerings of those expressions, so this case is currently unreachable.
rustbot
added
S-waiting-on-review
|
LGTM! @bors r+ rollup=always |
bors
added
S-waiting-on-bors
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this pull request
Mar 2, 2024
The ordinary lowering of `thir::ExprKind::Let` is unreachable After desugaring, `let` expressions should only appear inside `if` expressions or `match` guards, possibly nested within a let-chain. In both cases they are specifically handled by the lowerings of those expressions, so this case is currently unreachable. --- Context: https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/Lowering.20of.20.60thir.3A.3AExprKind.3A.3ALet.60.20is.20unreachable My conclusions are partly based on the observation that stubbing out this match arm doesn't cause any test failures. So either this really is unreachable, or it can be reached in some obscure circumstances that our test suite doesn't cover. If we end up needing this code (or something like it) for an implementation of rust-lang/rfcs#3573, it should be easy enough to pull it back out of version control history. I looked into having the `if`/`match` lowerings call back into `expr_into_dest`, but from what I can tell that won't work well, because there are extra scoping considerations that require some awareness of the enclosing if/match. r? `@Nadrieril`
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this pull request
Mar 2, 2024
The ordinary lowering of `thir::ExprKind::Let` is unreachable After desugaring, `let` expressions should only appear inside `if` expressions or `match` guards, possibly nested within a let-chain. In both cases they are specifically handled by the lowerings of those expressions, so this case is currently unreachable. --- Context: https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/Lowering.20of.20.60thir.3A.3AExprKind.3A.3ALet.60.20is.20unreachable My conclusions are partly based on the observation that stubbing out this match arm doesn't cause any test failures. So either this really is unreachable, or it can be reached in some obscure circumstances that our test suite doesn't cover. If we end up needing this code (or something like it) for an implementation of rust-lang/rfcs#3573, it should be easy enough to pull it back out of version control history. I looked into having the `if`/`match` lowerings call back into `expr_into_dest`, but from what I can tell that won't work well, because there are extra scoping considerations that require some awareness of the enclosing if/match. r? ``@Nadrieril``
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Mar 2, 2024
…iaskrgr Rollup of 6 pull requests Successful merges: - rust-lang#121194 (Refactor pre-getopts command line argument handling) - rust-lang#121666 (Use the OS thread name by default if `THREAD_INFO` has not been initialized) - rust-lang#121758 (Move thread local implementation to `sys`) - rust-lang#121759 (attempt to further clarify addr_of docs) - rust-lang#121888 (style library/core/src/error.rs) - rust-lang#121892 (The ordinary lowering of `thir::ExprKind::Let` is unreachable) r? `@ghost` `@rustbot` modify labels: rollup
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Mar 2, 2024
…iaskrgr Rollup of 7 pull requests Successful merges: - rust-lang#121666 (Use the OS thread name by default if `THREAD_INFO` has not been initialized) - rust-lang#121758 (Move thread local implementation to `sys`) - rust-lang#121759 (attempt to further clarify addr_of docs) - rust-lang#121855 (Correctly generate item info of trait items) - rust-lang#121888 (style library/core/src/error.rs) - rust-lang#121892 (The ordinary lowering of `thir::ExprKind::Let` is unreachable) - rust-lang#121895 (avoid collecting into vecs in some places) r? `@ghost` `@rustbot` modify labels: rollup
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Mar 2, 2024
…iaskrgr Rollup of 7 pull requests Successful merges: - rust-lang#121666 (Use the OS thread name by default if `THREAD_INFO` has not been initialized) - rust-lang#121758 (Move thread local implementation to `sys`) - rust-lang#121759 (attempt to further clarify addr_of docs) - rust-lang#121855 (Correctly generate item info of trait items) - rust-lang#121888 (style library/core/src/error.rs) - rust-lang#121892 (The ordinary lowering of `thir::ExprKind::Let` is unreachable) - rust-lang#121895 (avoid collecting into vecs in some places) r? `@ghost` `@rustbot` modify labels: rollup
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Mar 2, 2024
Rollup merge of rust-lang#121892 - Zalathar:expr-kind-let, r=Nadrieril The ordinary lowering of `thir::ExprKind::Let` is unreachable After desugaring, `let` expressions should only appear inside `if` expressions or `match` guards, possibly nested within a let-chain. In both cases they are specifically handled by the lowerings of those expressions, so this case is currently unreachable. --- Context: https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/Lowering.20of.20.60thir.3A.3AExprKind.3A.3ALet.60.20is.20unreachable My conclusions are partly based on the observation that stubbing out this match arm doesn't cause any test failures. So either this really is unreachable, or it can be reached in some obscure circumstances that our test suite doesn't cover. If we end up needing this code (or something like it) for an implementation of rust-lang/rfcs#3573, it should be easy enough to pull it back out of version control history. I looked into having the `if`/`match` lowerings call back into `expr_into_dest`, but from what I can tell that won't work well, because there are extra scoping considerations that require some awareness of the enclosing if/match. r? ```@Nadrieril```
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
After desugaring,
letexpressions should only appear insideifexpressions ormatchguards, possibly nested within a let-chain. In both cases they are specifically handled by the lowerings of those expressions, so this case is currently unreachable.Context: https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/Lowering.20of.20.60thir.3A.3AExprKind.3A.3ALet.60.20is.20unreachable
My conclusions are partly based on the observation that stubbing out this match arm doesn't cause any test failures. So either this really is unreachable, or it can be reached in some obscure circumstances that our test suite doesn't cover.
If we end up needing this code (or something like it) for an implementation of rust-lang/rfcs#3573, it should be easy enough to pull it back out of version control history.
I looked into having the
if/matchlowerings call back intoexpr_into_dest, but from what I can tell that won't work well, because there are extra scoping considerations that require some awareness of the enclosing if/match.r? @Nadrieril