2022-11-10 16:41:35 +00:00
|
|
|
// SPDX-License-Identifier: Apache-2.0 OR MIT
|
|
|
|
|
rust: provide proper code documentation titles
Rust 1.82.0's Clippy is introducing [1][2] a new warn-by-default lint,
`too_long_first_doc_paragraph` [3], which is intended to catch titles
of code documentation items that are too long (likely because no title
was provided and the item documentation starts with a paragraph).
This lint does not currently trigger anywhere, but it does detect a couple
cases if checking for private items gets enabled (which we will do in
the next commit):
error: first doc comment paragraph is too long
--> rust/kernel/init/__internal.rs:18:1
|
18 | / /// This is the module-internal type implementing `PinInit` and `Init`. It is unsafe to create this
19 | | /// type, since the closure needs to fulfill the same safety requirement as the
20 | | /// `__pinned_init`/`__init` functions.
| |_
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#too_long_first_doc_paragraph
= note: `-D clippy::too-long-first-doc-paragraph` implied by `-D warnings`
= help: to override `-D warnings` add `#[allow(clippy::too_long_first_doc_paragraph)]`
error: first doc comment paragraph is too long
--> rust/kernel/sync/arc/std_vendor.rs:3:1
|
3 | / //! The contents of this file come from the Rust standard library, hosted in
4 | | //! the <https://github.com/rust-lang/rust> repository, licensed under
5 | | //! "Apache-2.0 OR MIT" and adapted for kernel use. For copyright details,
6 | | //! see <https://github.com/rust-lang/rust/blob/master/COPYRIGHT>.
| |_
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#too_long_first_doc_paragraph
Thus clean those two instances.
In addition, since we have a second `std_vendor.rs` file with a similar
header, do the same there too (even if that one does not trigger the lint,
because it is `doc(hidden)`).
Link: https://github.com/rust-lang/rust/pull/129531 [1]
Link: https://github.com/rust-lang/rust-clippy/pull/12993 [2]
Link: https://rust-lang.github.io/rust-clippy/master/index.html#/too_long_first_doc_paragraph [3]
Reviewed-by: Trevor Gross <tmgross@umich.edu>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Tested-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Gary Guo <gary@garyguo.net>
Link: https://lore.kernel.org/r/20240904204347.168520-15-ojeda@kernel.org
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-09-04 20:43:42 +00:00
|
|
|
//! Rust standard library vendored code.
|
|
|
|
//!
|
2022-11-10 16:41:35 +00:00
|
|
|
//! The contents of this file come from the Rust standard library, hosted in
|
|
|
|
//! the <https://github.com/rust-lang/rust> repository, licensed under
|
|
|
|
//! "Apache-2.0 OR MIT" and adapted for kernel use. For copyright details,
|
|
|
|
//! see <https://github.com/rust-lang/rust/blob/master/COPYRIGHT>.
|
|
|
|
|
|
|
|
/// [`std::dbg`], but using [`pr_info`] instead of [`eprintln`].
|
|
|
|
///
|
|
|
|
/// Prints and returns the value of a given expression for quick and dirty
|
|
|
|
/// debugging.
|
|
|
|
///
|
|
|
|
/// An example:
|
|
|
|
///
|
|
|
|
/// ```rust
|
|
|
|
/// let a = 2;
|
rust: start using the `#[expect(...)]` attribute
In Rust, it is possible to `allow` particular warnings (diagnostics,
lints) locally, making the compiler ignore instances of a given warning
within a given function, module, block, etc.
It is similar to `#pragma GCC diagnostic push` + `ignored` + `pop` in C:
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wunused-function"
static void f(void) {}
#pragma GCC diagnostic pop
But way less verbose:
#[allow(dead_code)]
fn f() {}
By that virtue, it makes it possible to comfortably enable more
diagnostics by default (i.e. outside `W=` levels) that may have some
false positives but that are otherwise quite useful to keep enabled to
catch potential mistakes.
The `#[expect(...)]` attribute [1] takes this further, and makes the
compiler warn if the diagnostic was _not_ produced. For instance, the
following will ensure that, when `f()` is called somewhere, we will have
to remove the attribute:
#[expect(dead_code)]
fn f() {}
If we do not, we get a warning from the compiler:
warning: this lint expectation is unfulfilled
--> x.rs:3:10
|
3 | #[expect(dead_code)]
| ^^^^^^^^^
|
= note: `#[warn(unfulfilled_lint_expectations)]` on by default
This means that `expect`s do not get forgotten when they are not needed.
See the next commit for more details, nuances on its usage and
documentation on the feature.
The attribute requires the `lint_reasons` [2] unstable feature, but it
is becoming stable in 1.81.0 (to be released on 2024-09-05) and it has
already been useful to clean things up in this patch series, finding
cases where the `allow`s should not have been there.
Thus, enable `lint_reasons` and convert some of our `allow`s to `expect`s
where possible.
This feature was also an example of the ongoing collaboration between
Rust and the kernel -- we tested it in the kernel early on and found an
issue that was quickly resolved [3].
Cc: Fridtjof Stoldt <xfrednet@gmail.com>
Cc: Urgau <urgau@numericable.fr>
Link: https://rust-lang.github.io/rfcs/2383-lint-reasons.html#expect-lint-attribute [1]
Link: https://github.com/rust-lang/rust/issues/54503 [2]
Link: https://github.com/rust-lang/rust/issues/114557 [3]
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Reviewed-by: Trevor Gross <tmgross@umich.edu>
Tested-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Gary Guo <gary@garyguo.net>
Link: https://lore.kernel.org/r/20240904204347.168520-18-ojeda@kernel.org
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-09-04 20:43:45 +00:00
|
|
|
/// # #[expect(clippy::disallowed_macros)]
|
2022-11-10 16:41:35 +00:00
|
|
|
/// let b = dbg!(a * 2) + 1;
|
2024-10-04 12:56:16 +00:00
|
|
|
/// // ^-- prints: [src/main.rs:3:9] a * 2 = 4
|
2022-11-10 16:41:35 +00:00
|
|
|
/// assert_eq!(b, 5);
|
|
|
|
/// ```
|
|
|
|
///
|
|
|
|
/// The macro works by using the `Debug` implementation of the type of
|
|
|
|
/// the given expression to print the value with [`printk`] along with the
|
|
|
|
/// source location of the macro invocation as well as the source code
|
|
|
|
/// of the expression.
|
|
|
|
///
|
|
|
|
/// Invoking the macro on an expression moves and takes ownership of it
|
|
|
|
/// before returning the evaluated expression unchanged. If the type
|
|
|
|
/// of the expression does not implement `Copy` and you don't want
|
|
|
|
/// to give up ownership, you can instead borrow with `dbg!(&expr)`
|
|
|
|
/// for some expression `expr`.
|
|
|
|
///
|
|
|
|
/// The `dbg!` macro works exactly the same in release builds.
|
|
|
|
/// This is useful when debugging issues that only occur in release
|
|
|
|
/// builds or when debugging in release mode is significantly faster.
|
|
|
|
///
|
|
|
|
/// Note that the macro is intended as a temporary debugging tool to be
|
|
|
|
/// used during development. Therefore, avoid committing `dbg!` macro
|
|
|
|
/// invocations into the kernel tree.
|
|
|
|
///
|
|
|
|
/// For debug output that is intended to be kept in the kernel tree,
|
|
|
|
/// use [`pr_debug`] and similar facilities instead.
|
|
|
|
///
|
|
|
|
/// # Stability
|
|
|
|
///
|
|
|
|
/// The exact output printed by this macro should not be relied upon
|
|
|
|
/// and is subject to future changes.
|
|
|
|
///
|
|
|
|
/// # Further examples
|
|
|
|
///
|
|
|
|
/// With a method call:
|
|
|
|
///
|
|
|
|
/// ```rust
|
rust: start using the `#[expect(...)]` attribute
In Rust, it is possible to `allow` particular warnings (diagnostics,
lints) locally, making the compiler ignore instances of a given warning
within a given function, module, block, etc.
It is similar to `#pragma GCC diagnostic push` + `ignored` + `pop` in C:
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wunused-function"
static void f(void) {}
#pragma GCC diagnostic pop
But way less verbose:
#[allow(dead_code)]
fn f() {}
By that virtue, it makes it possible to comfortably enable more
diagnostics by default (i.e. outside `W=` levels) that may have some
false positives but that are otherwise quite useful to keep enabled to
catch potential mistakes.
The `#[expect(...)]` attribute [1] takes this further, and makes the
compiler warn if the diagnostic was _not_ produced. For instance, the
following will ensure that, when `f()` is called somewhere, we will have
to remove the attribute:
#[expect(dead_code)]
fn f() {}
If we do not, we get a warning from the compiler:
warning: this lint expectation is unfulfilled
--> x.rs:3:10
|
3 | #[expect(dead_code)]
| ^^^^^^^^^
|
= note: `#[warn(unfulfilled_lint_expectations)]` on by default
This means that `expect`s do not get forgotten when they are not needed.
See the next commit for more details, nuances on its usage and
documentation on the feature.
The attribute requires the `lint_reasons` [2] unstable feature, but it
is becoming stable in 1.81.0 (to be released on 2024-09-05) and it has
already been useful to clean things up in this patch series, finding
cases where the `allow`s should not have been there.
Thus, enable `lint_reasons` and convert some of our `allow`s to `expect`s
where possible.
This feature was also an example of the ongoing collaboration between
Rust and the kernel -- we tested it in the kernel early on and found an
issue that was quickly resolved [3].
Cc: Fridtjof Stoldt <xfrednet@gmail.com>
Cc: Urgau <urgau@numericable.fr>
Link: https://rust-lang.github.io/rfcs/2383-lint-reasons.html#expect-lint-attribute [1]
Link: https://github.com/rust-lang/rust/issues/54503 [2]
Link: https://github.com/rust-lang/rust/issues/114557 [3]
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Reviewed-by: Trevor Gross <tmgross@umich.edu>
Tested-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Gary Guo <gary@garyguo.net>
Link: https://lore.kernel.org/r/20240904204347.168520-18-ojeda@kernel.org
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-09-04 20:43:45 +00:00
|
|
|
/// # #[expect(clippy::disallowed_macros)]
|
2022-11-10 16:41:35 +00:00
|
|
|
/// fn foo(n: usize) {
|
|
|
|
/// if dbg!(n.checked_sub(4)).is_some() {
|
|
|
|
/// // ...
|
|
|
|
/// }
|
|
|
|
/// }
|
|
|
|
///
|
|
|
|
/// foo(3)
|
|
|
|
/// ```
|
|
|
|
///
|
|
|
|
/// This prints to the kernel log:
|
|
|
|
///
|
|
|
|
/// ```text,ignore
|
2024-10-04 12:56:16 +00:00
|
|
|
/// [src/main.rs:3:8] n.checked_sub(4) = None
|
2022-11-10 16:41:35 +00:00
|
|
|
/// ```
|
|
|
|
///
|
|
|
|
/// Naive factorial implementation:
|
|
|
|
///
|
|
|
|
/// ```rust
|
2024-09-04 20:43:47 +00:00
|
|
|
/// # #![expect(clippy::disallowed_macros)]
|
2022-11-10 16:41:35 +00:00
|
|
|
/// fn factorial(n: u32) -> u32 {
|
|
|
|
/// if dbg!(n <= 1) {
|
|
|
|
/// dbg!(1)
|
|
|
|
/// } else {
|
|
|
|
/// dbg!(n * factorial(n - 1))
|
|
|
|
/// }
|
|
|
|
/// }
|
|
|
|
///
|
|
|
|
/// dbg!(factorial(4));
|
|
|
|
/// ```
|
|
|
|
///
|
|
|
|
/// This prints to the kernel log:
|
|
|
|
///
|
|
|
|
/// ```text,ignore
|
2024-10-04 12:56:16 +00:00
|
|
|
/// [src/main.rs:3:8] n <= 1 = false
|
|
|
|
/// [src/main.rs:3:8] n <= 1 = false
|
|
|
|
/// [src/main.rs:3:8] n <= 1 = false
|
|
|
|
/// [src/main.rs:3:8] n <= 1 = true
|
|
|
|
/// [src/main.rs:4:9] 1 = 1
|
|
|
|
/// [src/main.rs:5:9] n * factorial(n - 1) = 2
|
|
|
|
/// [src/main.rs:5:9] n * factorial(n - 1) = 6
|
|
|
|
/// [src/main.rs:5:9] n * factorial(n - 1) = 24
|
|
|
|
/// [src/main.rs:11:1] factorial(4) = 24
|
2022-11-10 16:41:35 +00:00
|
|
|
/// ```
|
|
|
|
///
|
|
|
|
/// The `dbg!(..)` macro moves the input:
|
|
|
|
///
|
|
|
|
/// ```ignore
|
|
|
|
/// /// A wrapper around `usize` which importantly is not Copyable.
|
|
|
|
/// #[derive(Debug)]
|
|
|
|
/// struct NoCopy(usize);
|
|
|
|
///
|
|
|
|
/// let a = NoCopy(42);
|
|
|
|
/// let _ = dbg!(a); // <-- `a` is moved here.
|
|
|
|
/// let _ = dbg!(a); // <-- `a` is moved again; error!
|
|
|
|
/// ```
|
|
|
|
///
|
|
|
|
/// You can also use `dbg!()` without a value to just print the
|
|
|
|
/// file and line whenever it's reached.
|
|
|
|
///
|
|
|
|
/// Finally, if you want to `dbg!(..)` multiple values, it will treat them as
|
|
|
|
/// a tuple (and return it, too):
|
|
|
|
///
|
|
|
|
/// ```
|
rust: start using the `#[expect(...)]` attribute
In Rust, it is possible to `allow` particular warnings (diagnostics,
lints) locally, making the compiler ignore instances of a given warning
within a given function, module, block, etc.
It is similar to `#pragma GCC diagnostic push` + `ignored` + `pop` in C:
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wunused-function"
static void f(void) {}
#pragma GCC diagnostic pop
But way less verbose:
#[allow(dead_code)]
fn f() {}
By that virtue, it makes it possible to comfortably enable more
diagnostics by default (i.e. outside `W=` levels) that may have some
false positives but that are otherwise quite useful to keep enabled to
catch potential mistakes.
The `#[expect(...)]` attribute [1] takes this further, and makes the
compiler warn if the diagnostic was _not_ produced. For instance, the
following will ensure that, when `f()` is called somewhere, we will have
to remove the attribute:
#[expect(dead_code)]
fn f() {}
If we do not, we get a warning from the compiler:
warning: this lint expectation is unfulfilled
--> x.rs:3:10
|
3 | #[expect(dead_code)]
| ^^^^^^^^^
|
= note: `#[warn(unfulfilled_lint_expectations)]` on by default
This means that `expect`s do not get forgotten when they are not needed.
See the next commit for more details, nuances on its usage and
documentation on the feature.
The attribute requires the `lint_reasons` [2] unstable feature, but it
is becoming stable in 1.81.0 (to be released on 2024-09-05) and it has
already been useful to clean things up in this patch series, finding
cases where the `allow`s should not have been there.
Thus, enable `lint_reasons` and convert some of our `allow`s to `expect`s
where possible.
This feature was also an example of the ongoing collaboration between
Rust and the kernel -- we tested it in the kernel early on and found an
issue that was quickly resolved [3].
Cc: Fridtjof Stoldt <xfrednet@gmail.com>
Cc: Urgau <urgau@numericable.fr>
Link: https://rust-lang.github.io/rfcs/2383-lint-reasons.html#expect-lint-attribute [1]
Link: https://github.com/rust-lang/rust/issues/54503 [2]
Link: https://github.com/rust-lang/rust/issues/114557 [3]
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Reviewed-by: Trevor Gross <tmgross@umich.edu>
Tested-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Gary Guo <gary@garyguo.net>
Link: https://lore.kernel.org/r/20240904204347.168520-18-ojeda@kernel.org
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-09-04 20:43:45 +00:00
|
|
|
/// # #![expect(clippy::disallowed_macros)]
|
2022-11-10 16:41:35 +00:00
|
|
|
/// assert_eq!(dbg!(1usize, 2u32), (1, 2));
|
|
|
|
/// ```
|
|
|
|
///
|
|
|
|
/// However, a single argument with a trailing comma will still not be treated
|
|
|
|
/// as a tuple, following the convention of ignoring trailing commas in macro
|
|
|
|
/// invocations. You can use a 1-tuple directly if you need one:
|
|
|
|
///
|
|
|
|
/// ```
|
2024-09-04 20:43:47 +00:00
|
|
|
/// # #![expect(clippy::disallowed_macros)]
|
2022-11-10 16:41:35 +00:00
|
|
|
/// assert_eq!(1, dbg!(1u32,)); // trailing comma ignored
|
|
|
|
/// assert_eq!((1,), dbg!((1u32,))); // 1-tuple
|
|
|
|
/// ```
|
|
|
|
///
|
|
|
|
/// [`std::dbg`]: https://doc.rust-lang.org/std/macro.dbg.html
|
|
|
|
/// [`eprintln`]: https://doc.rust-lang.org/std/macro.eprintln.html
|
2024-08-20 07:26:43 +00:00
|
|
|
/// [`printk`]: https://docs.kernel.org/core-api/printk-basics.html
|
rust: upgrade to Rust 1.68.2
This is the first upgrade to the Rust toolchain since the initial Rust
merge, from 1.62.0 to 1.68.2 (i.e. the latest).
# Context
The kernel currently supports only a single Rust version [1] (rather
than a minimum) given our usage of some "unstable" Rust features [2]
which do not promise backwards compatibility.
The goal is to reach a point where we can declare a minimum version for
the toolchain. For instance, by waiting for some of the features to be
stabilized. Therefore, the first minimum Rust version that the kernel
will support is "in the future".
# Upgrade policy
Given we will eventually need to reach that minimum version, it would be
ideal to upgrade the compiler from time to time to be as close as
possible to that goal and find any issues sooner. In the extreme, we
could upgrade as soon as a new Rust release is out. Of course, upgrading
so often is in stark contrast to what one normally would need for GCC
and LLVM, especially given the release schedule: 6 weeks for Rust vs.
half a year for LLVM and a year for GCC.
Having said that, there is no particular advantage to updating slowly
either: kernel developers in "stable" distributions are unlikely to be
able to use their distribution-provided Rust toolchain for the kernel
anyway [3]. Instead, by routinely upgrading to the latest instead,
kernel developers using Linux distributions that track the latest Rust
release may be able to use those rather than Rust-provided ones,
especially if their package manager allows to pin / hold back /
downgrade the version for some days during windows where the version may
not match. For instance, Arch, Fedora, Gentoo and openSUSE all provide
and track the latest version of Rust as they get released every 6 weeks.
Then, when the minimum version is reached, we will stop upgrading and
decide how wide the window of support will be. For instance, a year of
Rust versions. We will probably want to start small, and then widen it
over time, just like the kernel did originally for LLVM, see commit
3519c4d6e08e ("Documentation: add minimum clang/llvm version").
# Unstable features stabilized
This upgrade allows us to remove the following unstable features since
they were stabilized:
- `feature(explicit_generic_args_with_impl_trait)` (1.63).
- `feature(core_ffi_c)` (1.64).
- `feature(generic_associated_types)` (1.65).
- `feature(const_ptr_offset_from)` (1.65, *).
- `feature(bench_black_box)` (1.66, *).
- `feature(pin_macro)` (1.68).
The ones marked with `*` apply only to our old `rust` branch, not
mainline yet, i.e. only for code that we may potentially upstream.
With this patch applied, the only unstable feature allowed to be used
outside the `kernel` crate is `new_uninit`, though other code to be
upstreamed may increase the list.
Please see [2] for details.
# Other required changes
Since 1.63, `rustdoc` triggers the `broken_intra_doc_links` lint for
links pointing to exported (`#[macro_export]`) `macro_rules`. An issue
was opened upstream [4], but it turns out it is intended behavior. For
the moment, just add an explicit reference for each link. Later we can
revisit this if `rustdoc` removes the compatibility measure.
Nevertheless, this was helpful to discover a link that was pointing to
the wrong place unintentionally. Since that one was actually wrong, it
is fixed in a previous commit independently.
Another change was the addition of `cfg(no_rc)` and `cfg(no_sync)` in
upstream [5], thus remove our original changes for that.
Similarly, upstream now tests that it compiles successfully with
`#[cfg(not(no_global_oom_handling))]` [6], which allow us to get rid
of some changes, such as an `#[allow(dead_code)]`.
In addition, remove another `#[allow(dead_code)]` due to new uses
within the standard library.
Finally, add `try_extend_trusted` and move the code in `spec_extend.rs`
since upstream moved it for the infallible version.
# `alloc` upgrade and reviewing
There are a large amount of changes, but the vast majority of them are
due to our `alloc` fork being upgraded at once.
There are two kinds of changes to be aware of: the ones coming from
upstream, which we should follow as closely as possible, and the updates
needed in our added fallible APIs to keep them matching the newer
infallible APIs coming from upstream.
Instead of taking a look at the diff of this patch, an alternative
approach is reviewing a diff of the changes between upstream `alloc` and
the kernel's. This allows to easily inspect the kernel additions only,
especially to check if the fallible methods we already have still match
the infallible ones in the new version coming from upstream.
Another approach is reviewing the changes introduced in the additions in
the kernel fork between the two versions. This is useful to spot
potentially unintended changes to our additions.
To apply these approaches, one may follow steps similar to the following
to generate a pair of patches that show the differences between upstream
Rust and the kernel (for the subset of `alloc` we use) before and after
applying this patch:
# Get the difference with respect to the old version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
cut -d/ -f3- |
grep -Fv README.md |
xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > old.patch
git -C linux restore rust/alloc
# Apply this patch.
git -C linux am rust-upgrade.patch
# Get the difference with respect to the new version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
cut -d/ -f3- |
grep -Fv README.md |
xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > new.patch
git -C linux restore rust/alloc
Now one may check the `new.patch` to take a look at the additions (first
approach) or at the difference between those two patches (second
approach). For the latter, a side-by-side tool is recommended.
Link: https://rust-for-linux.com/rust-version-policy [1]
Link: https://github.com/Rust-for-Linux/linux/issues/2 [2]
Link: https://lore.kernel.org/rust-for-linux/CANiq72mT3bVDKdHgaea-6WiZazd8Mvurqmqegbe5JZxVyLR8Yg@mail.gmail.com/ [3]
Link: https://github.com/rust-lang/rust/issues/106142 [4]
Link: https://github.com/rust-lang/rust/pull/89891 [5]
Link: https://github.com/rust-lang/rust/pull/98652 [6]
Reviewed-by: Björn Roy Baron <bjorn3_gh@protonmail.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Reviewed-By: Martin Rodriguez Reboredo <yakoyoku@gmail.com>
Tested-by: Ariel Miculas <amiculas@cisco.com>
Tested-by: David Gow <davidgow@google.com>
Tested-by: Boqun Feng <boqun.feng@gmail.com>
Link: https://lore.kernel.org/r/20230418214347.324156-4-ojeda@kernel.org
[ Removed `feature(core_ffi_c)` from `uapi` ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2023-04-18 21:43:47 +00:00
|
|
|
/// [`pr_info`]: crate::pr_info!
|
|
|
|
/// [`pr_debug`]: crate::pr_debug!
|
2022-11-10 16:41:35 +00:00
|
|
|
#[macro_export]
|
|
|
|
macro_rules! dbg {
|
|
|
|
// NOTE: We cannot use `concat!` to make a static string as a format argument
|
|
|
|
// of `pr_info!` because `file!` could contain a `{` or
|
|
|
|
// `$val` expression could be a block (`{ .. }`), in which case the `pr_info!`
|
|
|
|
// will be malformed.
|
|
|
|
() => {
|
2024-04-14 13:19:28 +00:00
|
|
|
$crate::pr_info!("[{}:{}:{}]\n", ::core::file!(), ::core::line!(), ::core::column!())
|
2022-11-10 16:41:35 +00:00
|
|
|
};
|
|
|
|
($val:expr $(,)?) => {
|
|
|
|
// Use of `match` here is intentional because it affects the lifetimes
|
|
|
|
// of temporaries - https://stackoverflow.com/a/48732525/1063961
|
|
|
|
match $val {
|
|
|
|
tmp => {
|
2024-04-14 13:19:28 +00:00
|
|
|
$crate::pr_info!("[{}:{}:{}] {} = {:#?}\n",
|
|
|
|
::core::file!(), ::core::line!(), ::core::column!(),
|
|
|
|
::core::stringify!($val), &tmp);
|
2022-11-10 16:41:35 +00:00
|
|
|
tmp
|
|
|
|
}
|
|
|
|
}
|
|
|
|
};
|
|
|
|
($($val:expr),+ $(,)?) => {
|
|
|
|
($($crate::dbg!($val)),+,)
|
|
|
|
};
|
|
|
|
}
|