Reuse machinery from tail_expr_drop_order for if_let_rescope
#137455
Merged
+425
−186
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
rustbot
added
S-waiting-on-review
|
These commits modify the If this was unintentional then you should revert the changes before this PR is merged. Some changes occurred to MIR optimizations cc @rust-lang/wg-mir-opt |
|
☔ The latest upstream changes (presumably #137497) made this pull request unmergeable. Please resolve the merge conflicts. |
compiler-errors
force-pushed
the
drop-lint-dtor
branch
from
b8b1754 to
a348d62
Compare
8 tasks
|
☔ The latest upstream changes (presumably #137608) made this pull request unmergeable. Please resolve the merge conflicts. |
compiler-errors
force-pushed
the
drop-lint-dtor
branch
from
a348d62 to
864cca8
Compare
bors
added
S-waiting-on-bors
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this pull request
Feb 27, 2025
…oli-obk Reuse machinery from `tail_expr_drop_order` for `if_let_rescope` Namely, it defines its own `extract_component_with_significant_dtor` which is a bit more accurate than `Ty::has_significant_drop`, since it has a hard-coded list of types from the ecosystem which are opted out of the lint.[^a] Also, since we extract the dtors themselves, adopt the same *label* we use in `tail_expr_drop_order` to point out the destructor impl. This makes it much clear what's actually being dropped, so it should be clearer to know when it's a false positive. This conflicts with rust-lang#137444, but I will rebase whichever lands first. [^a]: Side-note, it's kinda a shame that now there are two functions that presumably do the same thing. But this isn't my circus, nor are these my monkeys.
This was referenced Feb 27, 2025
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Feb 27, 2025
…iaskrgr Rollup of 8 pull requests Successful merges: - rust-lang#136542 ([`compiletest`-related cleanups 4/7] Make the distinction between root build directory vs test suite specific build directory in compiletest less confusing) - rust-lang#136579 (Fix UB in ThinVec::flat_map_in_place) - rust-lang#136688 (require trait impls to have matching const stabilities as the traits) - rust-lang#136846 (Make `AssocOp` more like `ExprKind`) - rust-lang#137304 (add `IntoBounds::intersect` and `RangeBounds::is_empty`) - rust-lang#137455 (Reuse machinery from `tail_expr_drop_order` for `if_let_rescope`) - rust-lang#137480 (Return unexpected termination error instead of panicing in `Thread::join`) - rust-lang#137694 (Spruce up `AttributeKind` docs) r? `@ghost` `@rustbot` modify labels: rollup
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this pull request
Feb 27, 2025
…oli-obk Reuse machinery from `tail_expr_drop_order` for `if_let_rescope` Namely, it defines its own `extract_component_with_significant_dtor` which is a bit more accurate than `Ty::has_significant_drop`, since it has a hard-coded list of types from the ecosystem which are opted out of the lint.[^a] Also, since we extract the dtors themselves, adopt the same *label* we use in `tail_expr_drop_order` to point out the destructor impl. This makes it much clear what's actually being dropped, so it should be clearer to know when it's a false positive. This conflicts with rust-lang#137444, but I will rebase whichever lands first. [^a]: Side-note, it's kinda a shame that now there are two functions that presumably do the same thing. But this isn't my circus, nor are these my monkeys.
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Feb 27, 2025
Rollup of 4 pull requests Successful merges: - rust-lang#136579 (Fix UB in ThinVec::flat_map_in_place) - rust-lang#137455 (Reuse machinery from `tail_expr_drop_order` for `if_let_rescope`) - rust-lang#137480 (Return unexpected termination error instead of panicing in `Thread::join`) - rust-lang#137694 (Spruce up `AttributeKind` docs) r? `@ghost` `@rustbot` modify labels: rollup try-job: i686-msvc-1
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Feb 27, 2025
…iaskrgr Rollup of 8 pull requests Successful merges: - rust-lang#136542 ([`compiletest`-related cleanups 4/7] Make the distinction between root build directory vs test suite specific build directory in compiletest less confusing) - rust-lang#136579 (Fix UB in ThinVec::flat_map_in_place) - rust-lang#136688 (require trait impls to have matching const stabilities as the traits) - rust-lang#136846 (Make `AssocOp` more like `ExprKind`) - rust-lang#137304 (add `IntoBounds::intersect` and `RangeBounds::is_empty`) - rust-lang#137455 (Reuse machinery from `tail_expr_drop_order` for `if_let_rescope`) - rust-lang#137480 (Return unexpected termination error instead of panicing in `Thread::join`) - rust-lang#137694 (Spruce up `AttributeKind` docs) r? `@ghost` `@rustbot` modify labels: rollup
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Feb 28, 2025
…iaskrgr Rollup of 8 pull requests Successful merges: - rust-lang#136542 ([`compiletest`-related cleanups 4/7] Make the distinction between root build directory vs test suite specific build directory in compiletest less confusing) - rust-lang#136579 (Fix UB in ThinVec::flat_map_in_place) - rust-lang#136688 (require trait impls to have matching const stabilities as the traits) - rust-lang#136846 (Make `AssocOp` more like `ExprKind`) - rust-lang#137304 (add `IntoBounds::intersect` and `RangeBounds::is_empty`) - rust-lang#137455 (Reuse machinery from `tail_expr_drop_order` for `if_let_rescope`) - rust-lang#137480 (Return unexpected termination error instead of panicing in `Thread::join`) - rust-lang#137694 (Spruce up `AttributeKind` docs) r? `@ghost` `@rustbot` modify labels: rollup
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Feb 28, 2025
Rollup merge of rust-lang#137455 - compiler-errors:drop-lint-dtor, r=oli-obk Reuse machinery from `tail_expr_drop_order` for `if_let_rescope` Namely, it defines its own `extract_component_with_significant_dtor` which is a bit more accurate than `Ty::has_significant_drop`, since it has a hard-coded list of types from the ecosystem which are opted out of the lint.[^a] Also, since we extract the dtors themselves, adopt the same *label* we use in `tail_expr_drop_order` to point out the destructor impl. This makes it much clear what's actually being dropped, so it should be clearer to know when it's a false positive. This conflicts with rust-lang#137444, but I will rebase whichever lands first. [^a]: Side-note, it's kinda a shame that now there are two functions that presumably do the same thing. But this isn't my circus, nor are these my monkeys.
Merged
|
Given that #137444 was beta-backported, can/should this PR be too? |
|
Nope, this is not really as drastic to warrant backporting. |
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.
Namely, it defines its own
extract_component_with_significant_dtorwhich is a bit more accurate thanTy::has_significant_drop, since it has a hard-coded list of types from the ecosystem which are opted out of the lint.1Also, since we extract the dtors themselves, adopt the same label we use in
tail_expr_drop_orderto point out the destructor impl. This makes it much clear what's actually being dropped, so it should be clearer to know when it's a false positive.This conflicts with #137444, but I will rebase whichever lands first.
Footnotes
Side-note, it's kinda a shame that now there are two functions that presumably do the same thing. But this isn't my circus, nor are these my monkeys. ↩