Simplify some code that depend on Deref#97077
Conversation
This comment has been minimized.
This comment has been minimized.
|
☔ The latest upstream changes (presumably #97265) made this pull request unmergeable. Please resolve the merge conflicts. |
|
Blocked on #95576 |
|
☔ The latest upstream changes (presumably #95576) made this pull request unmergeable. Please resolve the merge conflicts. |
|
@rustbot label: -S-blocked +S-waiting-on-author |
|
Some changes occurred to MIR optimizations cc @rust-lang/wg-mir-opt |
|
@bors r+ |
Rollup of 9 pull requests Successful merges: - rust-lang#92390 (Constify a few `(Partial)Ord` impls) - rust-lang#97077 (Simplify some code that depend on Deref) - rust-lang#98710 (correct the output of a `capacity` method example) - rust-lang#99084 (clarify how write_bytes can lead to UB due to invalid values) - rust-lang#99178 (Lighten up const_prop_lint, reusing const_prop) - rust-lang#99673 (don't ICE on invalid dyn calls) - rust-lang#99703 (Expose size_hint() for TokenStream's iterator) - rust-lang#99709 (`Inherited` always has `TypeckResults` available) - rust-lang#99713 (Fix sidebar background) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
|
|
||
| /// If MirPhase >= Derefered and if projection contains Deref, | ||
| /// It's guaranteed to be in the first place | ||
| pub fn has_deref(&self) -> bool { |
There was a problem hiding this comment.
This is super confusing, we now have is_indirect and has_deref and they are basically checking the same thing except one assumes we are in a certain MIR phase and the other doesn't. These doc comments of both methods should explain when to use one vs the other.
There was a problem hiding this comment.
I wrote this function, I don't quite remember the details why we needed to check if Deref was in first place or not but I remember it making quite big difference.
| /// If MirPhase >= Derefered and if projection contains Deref, | ||
| /// It's guaranteed to be in the first place | ||
| pub fn has_deref(&self) -> bool { | ||
| self.projection.first() == Some(&PlaceElem::Deref) |
There was a problem hiding this comment.
The same debug assertion should also be added here -- right now it seems very easy to accidentally call has_deref before the "deref only in first projection" invariant has been established, and then we'll get the weirdest bugs.
There was a problem hiding this comment.
Added the debug assertion and bit better documentation here #114505
Now that we can assume #97025 works, it's safe to expect Deref is always in the first place of projections. With this, I was able to simplify some code that depended on Deref's place in projections. When we are able to move Derefer before
ElaborateDropssuccessfully we will be able to optimize more places.r? @oli-obk