Passing mutable references

[Pyriphlegethon]

This issue already has a lint, only the second one still needs fixing

Passing a mutable reference to a function that takes an immutable reference:

fn takes_an_immutable_reference(a: &i32) -> bool {
    *a > 10
}

fn main() {
    let mut five = 5;
    println!("{}", takes_an_immutable_reference(&mut five));
}

If I'd find this code in somebody's code base I'd think that the function will mutate the argument and I'd have to make a copy if I want to preserve the original value. This lint should only be applied if the argument is actually passed as &mut, the following code should be ok:

fn takes_an_immutable_reference(a: &i32) -> bool {
    *a > 10
}

fn main() {
    let mut five = 5;
    let five_ref = &mut five;
    println!("{}", takes_an_immutable_reference(five_ref));
}

Taking a mutable reference and not mutating it:

fn takes_a_mutable_reference(a: &mut i32) -> bool {
     *a > 10
}

The rust compiler will complain whenever it sees a mutable binding that is not mutated. Strangely enough, it won't complain about mutable arguments that are never mutated. I guess this might be a hard problem?

Thanks for rust-clippy! It's an awesome tool!

[Manishearth]

I like this idea. Though I'm surprised the compiler doesn't complain here.

If I'd find this code in somebody's code base I'd think that the function will mutate the argument and I'd have to make a copy if I want to preserve the original value.

It's stuff like this which makes me love Rust. 😄

Thanks for rust-clippy! It's an awesome tool!

You're welcome! Glad you enjoyed it!

[llogiq]

We should tread carefully here. The mut is part of the interface, so implementing a trait may well require it. Also there may be situations in which we want to rule out other aliases despite not mutating an instance.

The former can be detected, the latter probably not, short of a mind-reading extension to clippy.

[birkenfeld]

The other lint is about taking a mutable reference and not mutating it:

This may be problematic though, as @llogiq says. At least trait impls should be excluded, and for pub items the public API would change. (Although IIUC taking &T instead of &mut T wouldn't lead to compile errors, but only clippy warnings 😄)

[Pyriphlegethon]

Yeah, didn't know that a trait impl couldn't strengthen the constraints for its arguments. That really seems like it should be allowed.
The easy fix would be to not check any trait impls like @birkenfeld said.

[oli-obk]

I'm gonna take this lint. I just spend 15 minutes chasing 5 functions in circles in miri to check why in the world they mutate an argument only to figure out that all of them could take a &T instead of a &mut T without any change in behaviour. Apparently I didn't get to this... And I ran into the same problem... again... in miri...

// increase this counter if you ran into this problem again and still didn't fix it: 3

[RalfJung]

The other lint is about taking a mutable reference and not mutating it:

This may be problematic though, as @llogiq says. At least trait impls should be excluded, and for pub items the public API would change. (Although IIUC taking &T instead of &mut T wouldn't lead to compile errors, but only clippy warnings 😄)

Not just that; when there is unsafe code around, the &mut may be necessary to preserve safety of the API. The following version of as_mut_slice compiles, but is wrong:

    pub fn as_mut_slice<T>(self_: &Vec<T>) -> &mut [T] {
        unsafe {
            from_raw_parts_mut(self_.as_ptr() as *mut T, self_.len())
        }
    }

[L0uisc]

I came here from TWIR call for participation. Isn't it better to put the second part of the issue directly into rustc?

[samueltardieu]

Triaging.

This is implemented in the needless_pass_by_ref_mut nursery lint.