Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

assigning_clones: unhelpful in test code #12752

Open
austinjones opened this issue May 2, 2024 · 0 comments
Open

assigning_clones: unhelpful in test code #12752

austinjones opened this issue May 2, 2024 · 0 comments
Labels
C-bug Category: Clippy is not doing the correct thing I-false-positive Issue: The lint was triggered on code it shouldn't have

Comments

@austinjones
Copy link

Summary

I ran into a case where assigning_clones is unhelpful, and most of our test modules are going to need #[allow(clippy::assigning_clones)].

This occurs when a test struct is initialized with some default, and you need to assign a string to one field. This inverts the order of assignee/assignment and makes tests much harder to read, and more complicated to write.

Perhaps this check should be disabled for test code?

Lint Name

No response

Reproducer

I tried this code:

fn main() {}

#[cfg(test)]
mod test {
    #[derive(Default)]
    struct Data {
        field: String,
    }

    fn test_data() -> Data {
        Data {
            field: "default_value".to_string(),
        }
    }

    #[test]
    fn test() {
        let mut data = test_data();
        data.field = "override_value".to_owned();
    }
}

I ran cargo clippy --all-targets, and I saw this happen:

    Checking assigning-clones-repro v0.1.0 (/home/austinjones/open-source/assigning-clones-repro)
warning: assigning the result of `ToOwned::to_owned()` may be inefficient
  --> src/main.rs:19:9
   |
19 |         data.field = "override_value".to_owned();
   |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: use `clone_into()`: `"override_value".clone_into(&mut data.field)`
   |
   = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#assigning_clones
   = note: `#[warn(clippy::assigning_clones)]` on by default

warning: `assigning-clones-repro` (bin "assigning-clones-repro" test) generated 1 warning (run `cargo clippy --fix --bin "assigning-clones-repro" --tests` to apply 1 suggestion)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.06s

I expected to see this happen:

    Checking assigning-clones-repro v0.1.0 (/home/austinjones/open-source/assigning-clones-repro)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.04s

Version

rustc 1.78.0 (9b00956e5 2024-04-29)
binary: rustc
commit-hash: 9b00956e56009bab2aa15d7bff10916599e3d6d6
commit-date: 2024-04-29
host: x86_64-unknown-linux-gnu
release: 1.78.0
LLVM version: 18.1.2

Additional Labels

No response

@austinjones austinjones added C-bug Category: Clippy is not doing the correct thing I-false-positive Issue: The lint was triggered on code it shouldn't have labels May 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-bug Category: Clippy is not doing the correct thing I-false-positive Issue: The lint was triggered on code it shouldn't have
Projects
None yet
Development

No branches or pull requests

1 participant