warn on strings that look like inline format strings but aren't

[matthiaskrgr]

What it does

fn main() {
    let number = 123;
    let s = "{number:?}"; // this is likely a bug.
    println!("{s}");
}

Lint Name

No response

Category

No response

Advantage

No response

Drawbacks

No response

Example

fn main() {
    let number = 123;
    let s = "{number:?}"; // this is likely a bug.
    println!("{s}");
}

Could be written as:

fn main() {
    let number = 123;
    let s = format!("{number:?}"); 
    println!("{s}");
}

[awused]

I've noticed myself running into this a fair bit with the new format syntax, especially when refactoring code. Before, "{}", arg would be two arguments and fail type checking if I put it into a function call that was expecting a &str, but now "{arg}" is one &str and type checks without issue.

[matthiaskrgr]

I just found an even more interesting case IRL in kani, where it looks like expect()would take a format string, but it does just print the raw strwithout applying any formatting 😄

model-checking/kani#2865

pub fn main() {
    let mut x = Some(3);
    let y = "aaa";
    x = None.expect("hello {y}");
}

will print literally hello {y} instead of hello aaa

[TTWNO]

Found some code in my crate that did the same thing:

role.rs:632: let encoded = to_bytes(ctxt, &from_role).expect("Unable to encode {from_role}");
role.rs:635: from_slice(&encoded, ctxt).expect("Unable to convert {encoded} into Role");
interface.rs:390: let serde_val = serde_plain::to_string(&iface).expect("Unable to serialize {iface}");
tests.rs:35: .expect("Could not set sender to {unique_bus_name:?}")
tests.rs:91: .expect("Could not set sender to {unique_bus_name:?}")
tests.rs:169: .expect("Could not set sender to {unique_bus_name:?}")

Could we get a comment on if this would be a reasonable lint or not?