Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Auto merge of #18252 - ShoyuVanilla:issue-15799, r=Veykril
fix: Do not consider mutable usage of deref to `*mut T` as deref_mut Fixes #15799 We are doing some heuristics for deciding whether the given deref is deref or deref_mut here; https://github.com/rust-lang/rust-analyzer/blob/5982d9c420d0dc90739171829f0d2e9c80d98979/crates/hir-ty/src/infer/mutability.rs#L182-L200 But this heuristic is erroneous if we are dereferencing to a mut ptr and normally those cases are filtered out here as builtin; https://github.com/rust-lang/rust-analyzer/blob/5982d9c420d0dc90739171829f0d2e9c80d98979/crates/hir-ty/src/mir/lower/as_place.rs#L165-L177 Howerver, this works not so well if the given dereferencing is double dereferencings like the case in the #15799. ```rust struct WrapPtr(*mut u32); impl core::ops::Deref for WrapPtr { type Target = *mut u32; fn deref(&self) -> &Self::Target { &self.0 } } fn main() { let mut x = 0u32; let wrap = WrapPtr(&mut x); unsafe { **wrap = 6; } } ``` Here are two - outer and inner - dereferences here, and the outer dereference is marked as deref_mut because there is an assignment operation. And this deref_mut marking is propagated into the inner dereferencing. In the later MIR lowering, the outer dereference is filtered out as it's expr type is `*mut u32`, but the expr type in the inner dereference is an ADT, so this false-mutablility is not filtered out. This PR cuts propagation of this false mutablilty chain if the expr type is mut ptr. Since this happens before the resolve_all, it may have some limitations when the expr type is determined as mut ptr at the very end of inferencing, but I couldn't find simple fix for it 🤔
- Loading branch information