Change:
<ins> // check-pass // // rust-lang/rust#73592: borrow_mut through Deref should work. // // Before #72280, when we see something like `&mut *rcvr.method()`, we // incorrectly requires `rcvr` to be type-checked as a mut place. While this // requirement is usually correct for smart pointers, it is overly restrictive // for types like `Mutex` or `RefCell` which can produce a guard that // implements `DerefMut` from `&self`. // // Making it more confusing, because we use Deref as the fallback when DerefMut // is implemented, we won't see an issue when the smart pointer does not // implement `DerefMut`. It only causes an issue when `rcvr` is obtained via a // type that implements both `Deref` or `DerefMut`. // // This bug is only discovered in #73592 after it is already fixed as a side-effect // of a refactoring made in #72280. #![warn(unused_mut)] use std::pin::Pin; use std::cell::RefCell; struct S(RefCell<()>); fn test_pin(s: Pin<&S>) { // This works before #72280. let _ = &mut *s.0.borrow_mut(); } fn test_pin_mut(s: Pin<&mut S>) { // This should compile but didn't before #72280. let _ = &mut *s.0.borrow_mut(); } fn test_vec(s: &Vec<RefCell<()>>) { // This should compile but didn't before #72280. let _ = &mut *s[0].borrow_mut(); } fn test_mut_pin(mut s: Pin<&S>) { //~^ WARN variable does not need to be mutable let _ = &mut *s.0.borrow_mut(); } fn test_mut_pin_mut(mut s: Pin<&mut S>) { //~^ WARN variable does not need to be mutable let _ = &mut *s.0.borrow_mut(); } fn main() { let mut s = S(RefCell::new(())); test_pin(Pin::new(&s)); test_pin_mut(Pin::new(&mut s)); test_mut_pin(Pin::new(&s)); test_mut_pin_mut(Pin::new(&mut s)); test_vec(&vec![s.0]); } </ins>

Discussion:
CI on suddenly started failing as we run with . the error is for the following code which stops compiling if the referenced is removed. (Sorry in advance if this is known, but I couldn't find a matching issue) CI run: Source Code: Edit: It seems that the nightly version might not be what triggered it, but rather a change in the underlying implementation of the that is being called above. No warnings under rustc 1.45.0-nightly ( 2020-05-06) rustc 1.44.1 ( 2020-06-17) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Let's find the cause of this regression. ping cleanup
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
Reduced somewhat:
Bisected with : searched nightlies: from nightly-2020-05-06 to nightly-2020-06-21 regressed nightly: nightly-2020-06-20 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.2</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Just bisected, found similar results. Thanks Culprit PR is which is a rollup, however I don't see any obvious culprit in there...
Actually, I think is the only possible culprit here, cc
Consider this code, derived from This does not compile with stable or beta compiler, but compiles fine with the nightly compiler. I suspect this is a soundness issue, given that I think it was expected for to only fix diagnostics, and not let code like this compile.
does not only fix diagnostics. It fixes two cases that should compile but didn't. I am looking into this right now.
I don't think this is a soundness issue I might be missing something obvious, but why should this not compile?

Clearly is sufficient for this to run, because takes .
I digged deeper and pin-pointed the reason for the behaviour change: Previous we type-check the receiver of the method with needs = when the result is type-checked with needs = . This means that of will be used even though would be sufficient. For types like which gives something with this is overly restrictive and unnecessary, so the compilation fails in stable. This compiles in stable: My PR fixes this and will only use when necessary, so is no longer needed (actually, it should be a bug that it is previously required in this case).
Given that rustc is allowed to generate additional warning in new versions, My opinion is that no fixes are necessary on rustc. I would recommend to be used, or spell out explicitly to mute the warning on nightly while let the code compile on stable.
I was worried that the says But this appears to be incorrect, removing the succesfully compiles in the original crate when using the same nightly rustc that produced the warning. So there isn't different behaviour between the original crate and the reduced test case.
I retested to make sure to cover the cases mentioned above. When removing the stable 1.44.1 rustc 1.45.0-nightly ( 2020-05-06) both fail with the following error However the nightly (1.46.0-nightly ( 2020-06-20)) version does compile.
I agree with that this appears to be a bug fix, and that should not have been required.
I think we should then close this issue as working as intended?
We may want to add a UI test to ensure that the code without mut compiles and the code with mut triggers a warning.
Yes, +1 to a suitable test.
claim