Custom `dbg!` macros for `dbg_macro` lint #11303

ojeda · 2023-08-08T08:15:29Z

Back in Rust 1.60.0 we added -Wclippy::dbg_macro to the Linux kernel compilation flags, which worked great with our custom dbg! macro (essentially the std one but calling the kernel printing facilities).

However, in the next version (1.61.0), as well as the current stable (1.80.0) and the current nightly (1.83.0-nightly (bd53aa3 2024-09-02)), it does not work. Thus only the first of the following lines emit a warning:

echo 'macro_rules! dbg { () => {} } fn main() { dbg!(); }' | rustup run  1.60.0 clippy-driver -Wclippy::dbg_macro -
echo 'macro_rules! dbg { () => {} } fn main() { dbg!(); }' | rustup run  1.61.0 clippy-driver -Wclippy::dbg_macro -
echo 'macro_rules! dbg { () => {} } fn main() { dbg!(); }' | rustup run  1.80.0 clippy-driver -Wclippy::dbg_macro -
echo 'macro_rules! dbg { () => {} } fn main() { dbg!(); }' | rustup run nightly clippy-driver -Wclippy::dbg_macro -

Is the lint intended to work only with the standard library dbg macro? I imagine that is the case, given the move to diagnostic items in #7466, but it is not entirely clear from the lint description.

A workaround is to use disallowed_macros, but that does not have a specialized diagnostic message nor has the nice help: suggestion. Another is to use rustc_attrs, but I imagine that is not going to be stable.

Thus, instead, could the dbg_macro lint take a configuration with paths to dbg! macros (like disallowed_macros) or, even better, could there be an attribute that users could apply to their dbg! macro (like rustc_diagnostic_item)?

Cc @xFrednet and @Alexendoo who both seemed to work on this in the past.

The text was updated successfully, but these errors were encountered:

Centri3 · 2023-08-08T15:48:56Z

I'd assume it was this PR which changed it from a simple path check to a diagnostic item: #8411

The lint's purpose is only the dbg! macro, nothing more. Instead of making it work on arbitrary macros, we should probably enhance the diagnostics from disallowed_macros. Maybe we can add an option for "this macro invocation just repeats its input, so suggest to remove it entirely"? As that's what dbg! does already. We can probably also add an option to not show the "use of a disallowed macro" part and allow the user to set the message arbitrarily.

ojeda · 2023-08-08T18:14:53Z

If one gets that level of customization, then it would be fine. Though if we wanted it to be as flexible, we would also need to be able to customize the lint level per path (which may be desirable anyway -- filled #11307), since right now a project may put a different level to dbg_macro vs. disallowed_macros.

Back when we used Rust 1.60.0 (before Rust was merged in the kernel), we added `-Wclippy::dbg_macro` to the compilation flags. This worked great with our custom `dbg!` macro (vendored from `std`, but slightly modified to use the kernel printing facilities). However, in the very next version, 1.61.0, it stopped working [1] since the lint started to use a Rust diagnostic item rather than a path to find the `dbg!` macro [1]. This behavior remains until the current nightly (1.83.0). Therefore, currently, the `dbg_macro` is not doing anything, which explains why we can invoke `dbg!` in samples/rust/rust_print.rs`, as well as why changing the `#[allow()]`s to `#[expect()]`s in `std_vendor.rs` doctests does not work since they are not fulfilled. One possible workaround is using `rustc_attrs` like the standard library does. However, this is intended to be internal, and we just started supporting several Rust compiler versions, so it is best to avoid it. Therefore, instead, use `disallowed_macros`. It is a stable lint and is more flexible (in that we can provide different macros), although its diagnostic message(s) are not as nice as the specialized one (yet), and does not allow to set different lint levels per macro/path [2]. In turn, this requires allowing the (intentional) `dbg!` use in the sample, as one would have expected. Finally, in a single case, the `allow` is fixed to be an inner attribute, since otherwise it was not being applied. Link: rust-lang/rust-clippy#11303 [1] Link: rust-lang/rust-clippy#11307 [2] Signed-off-by: Miguel Ojeda <[email protected]>

Back when we used Rust 1.60.0 (before Rust was merged in the kernel), we added `-Wclippy::dbg_macro` to the compilation flags. This worked great with our custom `dbg!` macro (vendored from `std`, but slightly modified to use the kernel printing facilities). However, in the very next version, 1.61.0, it stopped working [1] since the lint started to use a Rust diagnostic item rather than a path to find the `dbg!` macro [1]. This behavior remains until the current nightly (1.83.0). Therefore, currently, the `dbg_macro` is not doing anything, which explains why we can invoke `dbg!` in samples/rust/rust_print.rs`, as well as why changing the `#[allow()]`s to `#[expect()]`s in `std_vendor.rs` doctests does not work since they are not fulfilled. One possible workaround is using `rustc_attrs` like the standard library does. However, this is intended to be internal, and we just started supporting several Rust compiler versions, so it is best to avoid it. Therefore, instead, use `disallowed_macros`. It is a stable lint and is more flexible (in that we can provide different macros), although its diagnostic message(s) are not as nice as the specialized one (yet), and does not allow to set different lint levels per macro/path [2]. In turn, this requires allowing the (intentional) `dbg!` use in the sample, as one would have expected. Finally, in a single case, the `allow` is fixed to be an inner attribute, since otherwise it was not being applied. Link: rust-lang/rust-clippy#11303 [1] Link: rust-lang/rust-clippy#11307 [2] Tested-by: Gary Guo <[email protected]> Reviewed-by: Gary Guo <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Miguel Ojeda <[email protected]>

commit 8577c9d upstream. Back when we used Rust 1.60.0 (before Rust was merged in the kernel), we added `-Wclippy::dbg_macro` to the compilation flags. This worked great with our custom `dbg!` macro (vendored from `std`, but slightly modified to use the kernel printing facilities). However, in the very next version, 1.61.0, it stopped working [1] since the lint started to use a Rust diagnostic item rather than a path to find the `dbg!` macro [1]. This behavior remains until the current nightly (1.83.0). Therefore, currently, the `dbg_macro` is not doing anything, which explains why we can invoke `dbg!` in samples/rust/rust_print.rs`, as well as why changing the `#[allow()]`s to `#[expect()]`s in `std_vendor.rs` doctests does not work since they are not fulfilled. One possible workaround is using `rustc_attrs` like the standard library does. However, this is intended to be internal, and we just started supporting several Rust compiler versions, so it is best to avoid it. Therefore, instead, use `disallowed_macros`. It is a stable lint and is more flexible (in that we can provide different macros), although its diagnostic message(s) are not as nice as the specialized one (yet), and does not allow to set different lint levels per macro/path [2]. In turn, this requires allowing the (intentional) `dbg!` use in the sample, as one would have expected. Finally, in a single case, the `allow` is fixed to be an inner attribute, since otherwise it was not being applied. Link: rust-lang/rust-clippy#11303 [1] Link: rust-lang/rust-clippy#11307 [2] Tested-by: Gary Guo <[email protected]> Reviewed-by: Gary Guo <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Miguel Ojeda <[email protected]>

commit 8577c9d upstream. Back when we used Rust 1.60.0 (before Rust was merged in the kernel), we added `-Wclippy::dbg_macro` to the compilation flags. This worked great with our custom `dbg!` macro (vendored from `std`, but slightly modified to use the kernel printing facilities). However, in the very next version, 1.61.0, it stopped working [1] since the lint started to use a Rust diagnostic item rather than a path to find the `dbg!` macro [1]. This behavior remains until the current nightly (1.83.0). Therefore, currently, the `dbg_macro` is not doing anything, which explains why we can invoke `dbg!` in samples/rust/rust_print.rs`, as well as why changing the `#[allow()]`s to `#[expect()]`s in `std_vendor.rs` doctests does not work since they are not fulfilled. One possible workaround is using `rustc_attrs` like the standard library does. However, this is intended to be internal, and we just started supporting several Rust compiler versions, so it is best to avoid it. Therefore, instead, use `disallowed_macros`. It is a stable lint and is more flexible (in that we can provide different macros), although its diagnostic message(s) are not as nice as the specialized one (yet), and does not allow to set different lint levels per macro/path [2]. In turn, this requires allowing the (intentional) `dbg!` use in the sample, as one would have expected. Finally, in a single case, the `allow` is fixed to be an inner attribute, since otherwise it was not being applied. Link: rust-lang/rust-clippy#11303 [1] Link: rust-lang/rust-clippy#11307 [2] Tested-by: Gary Guo <[email protected]> Reviewed-by: Gary Guo <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Miguel Ojeda <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 8577c9d upstream. Back when we used Rust 1.60.0 (before Rust was merged in the kernel), we added `-Wclippy::dbg_macro` to the compilation flags. This worked great with our custom `dbg!` macro (vendored from `std`, but slightly modified to use the kernel printing facilities). However, in the very next version, 1.61.0, it stopped working [1] since the lint started to use a Rust diagnostic item rather than a path to find the `dbg!` macro [1]. This behavior remains until the current nightly (1.83.0). Therefore, currently, the `dbg_macro` is not doing anything, which explains why we can invoke `dbg!` in samples/rust/rust_print.rs`, as well as why changing the `#[allow()]`s to `#[expect()]`s in `std_vendor.rs` doctests does not work since they are not fulfilled. One possible workaround is using `rustc_attrs` like the standard library does. However, this is intended to be internal, and we just started supporting several Rust compiler versions, so it is best to avoid it. Therefore, instead, use `disallowed_macros`. It is a stable lint and is more flexible (in that we can provide different macros), although its diagnostic message(s) are not as nice as the specialized one (yet), and does not allow to set different lint levels per macro/path [2]. In turn, this requires allowing the (intentional) `dbg!` use in the sample, as one would have expected. Finally, in a single case, the `allow` is fixed to be an inner attribute, since otherwise it was not being applied. Link: rust-lang/rust-clippy#11303 [1] Link: rust-lang/rust-clippy#11307 [2] Tested-by: Gary Guo <[email protected]> Reviewed-by: Gary Guo <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Miguel Ojeda <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> (cherry picked from commit a01b7b2c1e9507ec2a1f735a2bc11e93f9a3230f) Signed-off-by: Jack Vogel <[email protected]>

…onfiguration Starting with Rust 1.88.0 (expected 2025-06-26) [1], Clippy may start warning about paths that do not resolve in the `disallowed_macros` configuration: warning: `kernel::dbg` does not refer to an existing macro --> .clippy.toml:10:5 | 10 | { path = "kernel::dbg", reason = "the `dbg!` macro is intended as a debugging tool" }, | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This is a lint we requested at [2], due to the trouble debugging the lint due to false negatives (e.g. [3]), which we use to emulate `clippy::dbg_macro` [4]. See commit 8577c9d ("rust: replace `clippy::dbg_macro` with `disallowed_macros`") for more details. Given the false negatives are not resolved yet, it is expected that Clippy complains about not finding this macro. Thus, until the false negatives are fixed (and, even then, probably we will need to wait for the MSRV to raise enough), use the escape hatch to allow an invalid path. Cc: [email protected] # Needed in 6.12.y and later (Rust is pinned in older LTSs). Link: rust-lang/rust-clippy#14397 [1] Link: rust-lang/rust-clippy#11432 [2] Link: rust-lang/rust-clippy#11431 [3] Link: rust-lang/rust-clippy#11303 [4] Signed-off-by: Miguel Ojeda <[email protected]>

…onfiguration Starting with Rust 1.88.0 (expected 2025-06-26) [1], Clippy may start warning about paths that do not resolve in the `disallowed_macros` configuration: warning: `kernel::dbg` does not refer to an existing macro --> .clippy.toml:10:5 | 10 | { path = "kernel::dbg", reason = "the `dbg!` macro is intended as a debugging tool" }, | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This is a lint we requested at [2], due to the trouble debugging the lint due to false negatives (e.g. [3]), which we use to emulate `clippy::dbg_macro` [4]. See commit 8577c9d ("rust: replace `clippy::dbg_macro` with `disallowed_macros`") for more details. Given the false negatives are not resolved yet, it is expected that Clippy complains about not finding this macro. Thus, until the false negatives are fixed (and, even then, probably we will need to wait for the MSRV to raise enough), use the escape hatch to allow an invalid path. Cc: [email protected] # Needed in 6.12.y and later (Rust is pinned in older LTSs). Link: rust-lang/rust-clippy#14397 [1] Link: rust-lang/rust-clippy#11432 [2] Link: rust-lang/rust-clippy#11431 [3] Link: rust-lang/rust-clippy#11303 [4] Reviewed-by: Alice Ryhl <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Miguel Ojeda <[email protected]>

ojeda mentioned this issue Aug 8, 2023

Clippy wanted features & bugfixes Rust-for-Linux/linux#349

Open

46 tasks

ojeda mentioned this issue Aug 18, 2023

Rust wanted features Rust-for-Linux/linux#354

Open

42 tasks

ojeda mentioned this issue Nov 18, 2024

Rust unstable features needed for the kernel Rust-for-Linux/linux#2

Open

95 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Custom `dbg!` macros for `dbg_macro` lint #11303

Custom `dbg!` macros for `dbg_macro` lint #11303

ojeda commented Aug 8, 2023 •

edited

Loading

Centri3 commented Aug 8, 2023 •

edited

Loading

ojeda commented Aug 8, 2023 •

edited

Loading

Custom dbg! macros for dbg_macro lint #11303

Custom dbg! macros for dbg_macro lint #11303

Comments

ojeda commented Aug 8, 2023 • edited Loading

Centri3 commented Aug 8, 2023 • edited Loading

ojeda commented Aug 8, 2023 • edited Loading

Custom `dbg!` macros for `dbg_macro` lint #11303

Custom `dbg!` macros for `dbg_macro` lint #11303

ojeda commented Aug 8, 2023 •

edited

Loading

Centri3 commented Aug 8, 2023 •

edited

Loading

ojeda commented Aug 8, 2023 •

edited

Loading