Clippy wrongly suggests replacing &mut String with &mut str · Issue #9542 · rust-lang/rust-clippy (original) (raw)

Summary

In egui crate the TextEdit widget constructor signature is as follows:

pub fn singleline(text: &'t mut dyn TextBuffer) -> Self {
    Self {
        desired_height_rows: 1,
        multiline: false,
        ..Self::multiline(text)
    }
}

TextBuffer is implemented as modifiable for String and as non-modifiable for &'_ str.

I want to have modifiable text buffer but in my project I have to use indirection to use singleline method. Clippy seems to trigger false positive for my use case, as changing &mut String to &mut str doesn't even compile. I'm attaching reproductible example below. Playground link: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=fec4899f9c23ecbb68c8e49aca409782

Lint Name

ptr_arg

Reproducer

I tried this code:

use std:📑:PhantomData;

trait DoAThing { fn a_thing(&mut self); }

impl<'a> DoAThing for &'a str { fn a_thing(&mut self) { todo!() } }

impl DoAThing for String { fn a_thing(&mut self) { todo!() } }

struct Create<'t> { _phantom: PhantomData<&'t ()>, }

impl<'t> Create<'t> { fn a_method(thing: &'t mut dyn DoAThing) -> Self { thing.a_thing(); Self { _phantom: Default::default(), } } }

fn external_attempt(src: &mut String) { Create::a_method(src); }

fn main() {

}

I saw this happen:

warning: writing `&mut String` instead of `&mut str` involves a new object where a slice will do
  --> src/main.rs:32:26
   |
32 | fn external_attempt(src: &mut String) {
   |                          ^^^^^^^^^^^ help: change this to: `&mut str`
   |
   = note: `#[warn(clippy::ptr_arg)]` on by default
   = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#ptr_arg

I expected this to compile without warnings.

Version

rustc 1.63.0 (4b91a6ea7 2022-08-08)
binary: rustc
commit-hash: 4b91a6ea7258a947e59c6522cd5898e7c0a6a88f
commit-date: 2022-08-08
host: x86_64-unknown-linux-gnu
release: 1.63.0
LLVM version: 14.0.5

Additional Labels

No response