rust: clean Rust 1.88.0's `clippy::uninlined_format_args` lint

Starting with Rust 1.88.0 (expected 2025-06-26) [1], `rustc` may move
back the `uninlined_format_args` to `style` from `pedantic` (it w

rust: clean Rust 1.88.0's `clippy::uninlined_format_args` lint

Starting with Rust 1.88.0 (expected 2025-06-26) [1], `rustc` may move
back the `uninlined_format_args` to `style` from `pedantic` (it was
there waiting for rust-analyzer suppotr), and thus we will start to see
lints like:

warning: variables can be used directly in the `format!` string
--> rust/macros/kunit.rs:105:37
|
105 | let kunit_wrapper_fn_name = format!("kunit_rust_wrapper_{}", test);
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#uninlined_format_args
help: change this to
|
105 - let kunit_wrapper_fn_name = format!("kunit_rust_wrapper_{}", test);
105 + let kunit_wrapper_fn_name = format!("kunit_rust_wrapper_{test}");

There is even a case that is a pure removal:

warning: variables can be used directly in the `format!` string
--> rust/macros/module.rs:51:13
|
51 | format!("{field}={content}\0", field = field, content = content)
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#uninlined_format_args
help: change this to
|
51 - format!("{field}={content}\0", field = field, content = content)
51 + format!("{field}={content}\0")

The lints all seem like nice cleanups, thus just apply them.

We may want to disable `allow-mixed-uninlined-format-args` in the future.

Cc: [email protected] # Needed in 6.12.y and later (Rust is pinned in older LTSs).
Link: https://github.com/rust-lang/rust-clippy/pull/14160 [1]
Acked-by: Benno Lossin <[email protected]>
Reviewed-by: Tamir Duberstein <[email protected]>
Reviewed-by: Alice Ryhl <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Miguel Ojeda <[email protected]>

show more ...

rust: macros: enable paste! use from macro_rules!

According to the rustdoc for the proc_macro crate[1], tokens captured
from a "macro variable" (e.g. from within macro_rules!) may be delimited
by in

rust: macros: enable paste! use from macro_rules!

According to the rustdoc for the proc_macro crate[1], tokens captured
from a "macro variable" (e.g. from within macro_rules!) may be delimited
by invisible tokens and be contained within a proc_macro::Group.

Previously, this scenario was not handled by macros::paste, which caused
a proc-macro panic when the corresponding tests are enabled. Enable the
tests, and handle this case by making macros::paste::concat recursive.

Link: https://doc.rust-lang.org/stable/proc_macro/enum.Delimiter.html [1]
Signed-off-by: Ethan D. Twardy <[email protected]>
Reviewed-by: Alice Ryhl <[email protected]>
Link: https://github.com/Rust-for-Linux/linux/issues/1076
Link: https://lore.kernel.org/r/[email protected]
[ Rebased (one fix was already applied) and reworded. Remove unneeded
`rust` as language in examples. - Miguel ]
Signed-off-by: Miguel Ojeda <[email protected]>

show more ...

rust: macros: update 'paste!' macro to accept string literals

Enable combining identifiers with literals in the 'paste!' macro. This
allows combining user-specified strings with affixes to create
na

rust: macros: update 'paste!' macro to accept string literals

Enable combining identifiers with literals in the 'paste!' macro. This
allows combining user-specified strings with affixes to create
namespaced identifiers.

This sample code:

macro_rules! m {
($name:lit) => {
paste!(struct [<_some_ $name _struct_>] {})
}
}

m!("foo_bar");

Would previously cause a compilation error. It will now generate:

struct _some_foo_bar_struct_ {}

Signed-off-by: Trevor Gross <[email protected]>
Reviewed-by: Martin Rodriguez Reboredo <[email protected]>
Reviewed-by: Vincenzo Palazzo <[email protected]>
Reviewed-by: Alice Ryhl <[email protected]>
Reviewed-by: Benno Lossin <[email protected]>
Reviewed-by: Gary Guo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
[ Added `:` before example block. ]
Signed-off-by: Miguel Ojeda <[email protected]>

show more ...

rust: macros: add `paste!` proc macro

This macro provides a flexible way to concatenated identifiers together
and it allows the resulting identifier to be used to declare new items,
which `concat_id

rust: macros: add `paste!` proc macro

This macro provides a flexible way to concatenated identifiers together
and it allows the resulting identifier to be used to declare new items,
which `concat_idents!` does not allow. It also allows identifiers to be
transformed before concatenated.

The `concat_idents!` example

let x_1 = 42;
let x_2 = concat_idents!(x, _1);
assert!(x_1 == x_2);

can be written with `paste!` macro like this:

let x_1 = 42;
let x_2 = paste!([<x _1>]);
assert!(x_1 == x_2);

However `paste!` macro is more flexible because it can be used to create
a new variable:

let x_1 = 42;
paste!(let [<x _2>] = [<x _1>];);
assert!(x_1 == x_2);

While this is not possible with `concat_idents!`.

This macro is similar to the `paste!` crate [1], but this is a fresh
implementation to avoid vendoring large amount of code directly. Also, I
have augmented it to provide a way to specify span of the resulting
token, allowing precise control.

For example, this code is broken because the variable is declared inside
the macro, so Rust macro hygiene rules prevents access from the outside:

macro_rules! m {
($id: ident) => {
// The resulting token has hygiene of the macro.
paste!(let [<$id>] = 1;)
}
}

m!(a);
let _ = a;

In this version of `paste!` macro I added a `span` modifier to allow
this:

macro_rules! m {
($id: ident) => {
// The resulting token has hygiene of `$id`.
paste!(let [<$id:span>] = 1;)
}
}

m!(a);
let _ = a;

Link: http://docs.rs/paste/ [1]
Signed-off-by: Gary Guo <[email protected]>
Reviewed-by: Björn Roy Baron <[email protected]>
Reviewed-by: Benno Lossin <[email protected]>
Reviewed-by: Alice Ryhl <[email protected]>
Reviewed-by: Martin Rodriguez Reboredo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
[ Added SPDX license identifier as discussed in the list and fixed typo. ]
Signed-off-by: Miguel Ojeda <[email protected]>

show more ...