-
Notifications
You must be signed in to change notification settings - Fork 13.6k
Reuse machinery from tail_expr_drop_order
for if_let_rescope
#137455
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Conversation
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. |
b8b1754
to
a348d62
Compare
☔ The latest upstream changes (presumably #137608) made this pull request unmergeable. Please resolve the merge conflicts. |
a348d62
to
864cca8
Compare
…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.
…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
…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.
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
…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
…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
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.
Given that #137444 was beta-backported, can/should this PR be too? |
Nope, this is not really as drastic to warrant backporting. |
Namely, it defines its own
extract_component_with_significant_dtor
which 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_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 #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. ↩