Re: [PATCH RFC 09/11] rust: print: enable dynamic debug for pr_debug!()

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] rust: print: pr_debug() expands to multiple statements without a block
- [High] rust: print: pr_debug() argument evaluation inside closure breaks control flow
- [Medium] rust: dynamic_debug: __format_string() rejects macro-generated format strings
--

commit 0f009656f0da58d6ed039063d8a722503a6cbfbf
Author: Thomas Weißschuh [off-list ref]

rust: print: enable dynamic debug for pr_debug!()

This commit wires up dynamic debug support for the pr_debug!() macro.

[ ... ]

[Severity: High]
Does this expansion cause syntax errors when pr_debug!() is used in an
expression context?

The pr_debug!() macro is documented to mimic std::print!(), which evaluates to
() and can be used in expression positions like match arms or tail expressions.

Because this macro expands using ( ... ) instead of a { ... } block, it
exposes multiple #[cfg(...)] gated items and a trailing semicolon directly to
the call site's AST.

If a driver calls let _ = pr_debug!(...);, won't the Rust parser fail
expecting a single expression, returning an error about ignoring the semicolon
and following tokens?

[Severity: Medium]
Will this break if the format string is generated by another macro?

The user-provided arguments are passed to __format_string!():

rust/kernel/dynamic_debug.rs:
macro_rules! __format_string {
    ($fmt:literal) => {
        $fmt
    };
...

Because __format_string!() strictly expects a literal token, if a driver
calls pr_debug!(concat!("a", "b")), won't it fail to match the literal pattern
and cause a compile error? Standard Rust formatting macros typically allow
macro-generated format strings.

[Severity: High]
Can evaluating the arguments inside this closure silently break control flow?

The user-provided arguments $($arg)* are expanded inside the || { ... }
closure.

If a caller uses a control-flow operator in their arguments, such as
pr_debug!("Result: {}", do_something()?);, won't the ? operator attempt to
return from the closure instead of the caller's function?

This would either cause a type mismatch error because the closure returns (),
or silently return from the print closure while the outer function continues
executing unexpectedly.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261011-rust-dyndbg-v1-0-832e4039b71f@weissschuh.net?part=9