literal_string_with_formatting_args is trigger by Actix Web's wildcard route definitions

[Thomasdezeeuw]

Summary

Actix Web (https://crates.io/crates/actix-web) supports wildcard in their HTTP route definition macro. It looks something like #[post("/path/{variable:.*}")]. This triggers literal_string_with_formatting_args incorrectly.

As a work around we're adding #![allow(clippy::literal_string_with_formatting_args)] to all our files.

Lint Name

literal_string_with_formatting_args

Reproducer

I tried this code:

use actix_web::{post, HttpRequest, HttpResponse};

#[post("/path/{variable:.*}")]
pub async fn my_route(req: HttpRequest) -> HttpResponse {
    Ok(HttpResponse::Ok())
}

Creates (roughly) the following error:

error: this looks like a formatting argument but it is not part of a formatting macro
  --> path.rs:1
   |
1 | #[post("/path/{variable:.*}")]
   |              ^^^^^^^^^
   |
   = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#literal_string_with_formatting_args
   = note: `-D clippy::literal-string-with-formatting-args` implied by `-D warnings`
   = help: to override `-D warnings` add `#[allow(clippy::literal_string_with_formatting_args)]`

Version

rustc 1.85.0-nightly (45d11e51b 2025-01-01)
binary: rustc
commit-hash: 45d11e51bb66c2deb63a006fe3953c4b6fbc50c2
commit-date: 2025-01-01
host: x86_64-unknown-linux-gnu
release: 1.85.0-nightly
LLVM version: 19.1.6

Additional Labels

No response

[mladedav]

axum also triggers it since 0.8. Though it seems that this happens only if a variable with the same name is in the same scope.

[Arvamer]

ClickHouse's query parameters use {name:Type}, which is also caught by this lint. Perhaps the lint should trigger only when a string literal is used as an argument of functions like expect? Otherwise this is bound to trigger a lot of false positives in the general case.

[conradludgate]

I have another weird case, which I think is slightly different:

warning: this looks like a formatting argument but it is not part of a formatting macro
 --> /Users/conrad/Documents/neon/neon/clippy.toml:2:6
  |
2 |     "tokio::task::block_in_place",
  |      ^^^^
  |
  = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#literal_string_with_formatting_args
  = note: `#[warn(clippy::literal_string_with_formatting_args)]` on by default

I wonder why clippy is linting our clippy.toml 🤔

[y21]

I have another weird case, which I think is slightly different:

warning: this looks like a formatting argument but it is not part of a formatting macro
 --> /Users/conrad/Documents/neon/neon/clippy.toml:2:6
  |
2 |     "tokio::task::block_in_place",
  |      ^^^^
  |
  = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#literal_string_with_formatting_args
  = note: `#[warn(clippy::literal_string_with_formatting_args)]` on by default

I wonder why clippy is linting our clippy.toml 🤔

That's most likely #13885 (it's emitting a warning on a dummy span at position 0 which happens to be where clippy.toml is located in the source map)

[y21]

cc @GuillaumeGomez (lint author). It seems unfortunate that users of several popular crates that happen to share syntax with that of format strings can run into false positives with this and have to add #![allow]s (and it's also a shame because I could see the lint be very useful possibly if it was less eager and that it could catch real errors).

If there's no trivial or obvious fix, we might just want to (temporarily) move the lint to nursery, just to have more time on this before it makes it to stable because the lint is already on beta. We'll also probably want to backport a fix, which a category change would likely be the easiest.

[GuillaumeGomez]

There is a fix waiting for review/approval open at #13953. It's ready and fixes all issues listed in this is issue and in #13885.

[y21]

Ah... I think I misunderstood this issue. I thought the issue here would be different from #13885 in that the lint thinks that the #[post("/path/{variable:.*}")] route string (which is in user-written code, so unrelated to dummy spans) looks like a format string and lints that string, and I thought it would affect most users of actix_web that use these macros.

Looking closer at the repro in the OP though (specifically the span of the warning and what it points at; it doesn't cover the whole {} part of the string) I guess the dummy span of a different expression just happens to be there coincidentally, so it probably is another instance of #13885. (Or is that just a manually constructed warning since the OP says "roughly" and it actually does cover the whole {variable:.*}?)

I also couldn't really repro the warning for actix_web in the OP locally (after having fixed some of the type errors in the snippet).

There are two other comments here where I'm not quite sure if they're the same or the issue that I described though (and it's a bit hard to tell because they don't have a reproducer). So yeah, if that fixes all issues, that should be fine, then. Bit of a confusing situation though ^^

[jcdyer]

This is a little more obscure, perhaps, but seed 0.9.2's log! macro also runs afoul of this lint.

Would it make sense to be able to configure a list of known_formatting_macros?

Edit: I just updated my rustc, and see this on the following version:

$ cargo --version
cargo 1.85.0-beta.5 (d73d2caf9 2024-12-31)

Specifically, I get:

$ cargo clippy
warning: this looks like a formatting argument but it is not part of a formatting macro
   --> datagen-client/src/update/project_reading.rs:304:56
    |
304 |             ::seed::log!("Error getting media devices: {:?}", sopt);
    |                                                        ^^^^
    |
    = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#literal_string_with_formatting_args
    = note: `#[warn(clippy::literal_string_with_formatting_args)]` on by default