It is cleaner to have a single inner attribute rather than needing
several hidden lines to wrap the macro invocations.

Thus simplify them.

Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
---
 rust/kernel/std_vendor.rs | 8 ++------
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/rust/kernel/std_vendor.rs b/rust/kernel/std_vendor.rs
index 8b4872b48e97..8f27d447a7fc 100644
--- a/rust/kernel/std_vendor.rs
+++ b/rust/kernel/std_vendor.rs
@@ -73,8 +73,7 @@
 /// Naive factorial implementation:
 ///
 /// ```rust
-/// # #[expect(clippy::disallowed_macros)]
-/// # {
+/// # #![expect(clippy::disallowed_macros)]
 /// fn factorial(n: u32) -> u32 {
 ///     if dbg!(n <= 1) {
 ///         dbg!(1)
@@ -84,7 +83,6 @@
 /// }
 ///
 /// dbg!(factorial(4));
-/// # }
 /// ```
 ///
 /// This prints to the kernel log:
@@ -129,11 +127,9 @@
 /// invocations. You can use a 1-tuple directly if you need one:
 ///
 /// ```
-/// # #[expect(clippy::disallowed_macros)]
-/// # {
+/// # #![expect(clippy::disallowed_macros)]
 /// 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
-- 
2.46.0

On Wed Sep 4, 2024 at 10:43 PM CEST, Miguel Ojeda wrote:
> It is cleaner to have a single inner attribute rather than needing
> several hidden lines to wrap the macro invocations.
>
> Thus simplify them.
>
> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
> ---

Reviewed-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>

On Wed, Sep 4, 2024 at 10:45 PM Miguel Ojeda <ojeda@kernel.org> wrote:
>
> It is cleaner to have a single inner attribute rather than needing
> several hidden lines to wrap the macro invocations.
>
> Thus simplify them.
>
> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>

Are we ok with changing std_vendor?

Alice

On Thu, Sep 5, 2024 at 10:19 AM Alice Ryhl <aliceryhl@google.com> wrote:
>
> Are we ok with changing std_vendor?

Yeah, to some degree, i.e. the code is already adapted slightly (it is
not intended to be a 1:1 copy). As long as we keep it more or less in
sync with upstream, it should be fine.

Even if we had to diverge, it should not be a big deal, but it would
be nice to be able to pick up improvements if any, e.g. there is `let
else` being used now upstream, which we could replicate (I will create
a "good first issue" for that).

(These allows/expects are not there in the original anyway, for that reason)

Cheers,
Miguel

On Thu, Sep 5, 2024 at 11:27 AM Miguel Ojeda
<miguel.ojeda.sandonis@gmail.com> wrote:
>
> On Thu, Sep 5, 2024 at 10:19 AM Alice Ryhl <aliceryhl@google.com> wrote:
> >
> > Are we ok with changing std_vendor?
>
> Yeah, to some degree, i.e. the code is already adapted slightly (it is
> not intended to be a 1:1 copy). As long as we keep it more or less in
> sync with upstream, it should be fine.
>
> Even if we had to diverge, it should not be a big deal, but it would
> be nice to be able to pick up improvements if any, e.g. there is `let
> else` being used now upstream, which we could replicate (I will create
> a "good first issue" for that).
>
> (These allows/expects are not there in the original anyway, for that reason)
>
> Cheers,
> Miguel

Reviewed-by: Alice Ryhl <aliceryhl@google.com>