FP redundant_clone: Box

[matthiaskrgr]

Summary

.

Lint Name

redundant_clone

Reproducer

I tried this code:

pub fn main() {
    let i: Box<_> = Box::new(1);
    let j = i.clone();
    assert_eq!(*i, 2);
}

I saw this happen:

warning: redundant clone
 --> unique-decl-init-copy.rs:3:14
  |
3 |     let j = i.clone();
  |              ^^^^^^^^ help: remove this
  |
note: cloned value is neither consumed nor mutated
 --> unique-decl-init-copy.rs:3:13
  |
3 |     let j = i.clone();
  |             ^^^^^^^^^
  = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#redundant_clone
  = note: `#[warn(clippy::redundant_clone)]` on by defaul

But

pub fn main() {
    let i: Box<_> = Box::new(1);
    let j = i;
    assert_eq!(*i, 2);
}

does not compile

warning: unused variable: `j`
 --> unique-decl-init-copy.rs:3:9
  |
3 |     let j = i;
  |         ^ help: if this is intentional, prefix it with an underscore: `_j`
  |
  = note: `#[warn(unused_variables)]` on by default

error[E0382]: borrow of moved value: `i`
 --> unique-decl-init-copy.rs:4:5
  |
2 |     let i: Box<_> = Box::new(1);
  |         - move occurs because `i` has type `std::boxed::Box<i32>`, which does not implement the `Copy` trait
3 |     let j = i;
  |             - value moved here
4 |     assert_eq!(*i, 2);
  |     ^^^^^^^^^^^^^^^^^ value borrowed here after move
  |
  = note: this error originates in the macro `assert_eq` (in Nightly builds, run with -Z macro-backtrace for more info)
help: consider cloning the value if the performance cost is acceptable
  |
3 |     let j = i.clone();
  |              ++++++++

error: aborting due to previous error; 1 warning emitted

Version

rustc 1.70.0-nightly (511364e78 2023-03-16)
binary: rustc
commit-hash: 511364e7874dba9649a264100407e4bffe7b5425
commit-date: 2023-03-16
host: x86_64-unknown-linux-gnu
release: 1.70.0-nightly
LLVM version: 15.0.7

Additional Labels

No response

[matthiaskrgr]

This seems to be a regression, at least on beta, there is no such warning, hm.

[matthiaskrgr]

Hmm, nightly-2023-03-15-x86_64-unknown-linux-gnu doesn't have this FP while rustc 1.70.0-nightly (511364e78 2023-03-16) does

[matthiaskrgr]

Ooh, I bet this broke in rust-lang/rust#108958 cc @clubby789

[clubby789]

@rustbot claim

[clubby789]

Hmm. I'm not sure how this specifically could have broken it - that PR pretty much just removes it from match arms, the expression itself hasn't emitted since I removed it in rust-lang/rust#108516. I'll try a bisect

---

searched nightlies: from nightly-2023-03-15 to nightly-2023-03-17
regressed nightly: nightly-2023-03-17
searched commit range: rust-lang/rust@ab65486...511364e
regressed commit: rust-lang/rust@511364e

bisected with cargo-bisect-rustc v0.6.5

Host triple: x86_64-unknown-linux-gnu
Reproduce with:

cargo bisect-rustc 2023-03-15 --end 2023-03-17 --script=./script.sh -vv 

[clubby789]

cc @cjgillot

@rustbot release

[matthiaskrgr]

Oh my bad then, sorry 😅 this looked like the obvious contender to me since it removed box stuff and I thought maybe it removed a "saveguard" when linting against boxes...

[Jarcho]

I remember seeing this come up before, but can't find the issue now. This isn't a false positive as the new value isn't used, but the suggestion should be to remove the whole binding.

[ryoqun]

I think this issue's root cause is same as this (see my cross post: #10577 (comment))

pub fn main() {
    let i: Box<_> = Box::new(1);
    let j = i.clone();
    assert_eq!(*i, 2);
}

this is fine with +nightly-2023-03-16-x86_64-unknown-linux-gnu but starts to emit false positives with +nightly-2023-03-17-x86_64-unknown-linux-gnu

then again, i think this pr is suspicious: rust-lang/rust#108944