On Thu, 12 Mar 2026 20:20:10 +0100, Miguel Ojeda wrote:
> Was the patch tested with Clippy? It has several issues.
>
> The worst news is that it seems the "supposed to be `unsafe` block"
> does not count as one for Clippy, i.e.:
>
> let list = clist_create!(unsafe { head, Item, SampleItemC, link });
>
> So we get:
>
> error: statement has unnecessary safety comment
>
> For this, we could write them as a `// SAFETY*: ` comment or similar,
> to make progress for now, but it would best to request upstream Clippy
> to detect this or to rework the macro to force the `unsafe` block
> outside.
Used `// SAFETY*:` for now as you suggested.
> error: unsafe block missing a safety comment
> --> rust/kernel/interop/list.rs:357:17
> |
> 357 | |p| unsafe { &raw const (*p).$($field).+ };
>
> So this needs a `// SAFETY:` comment on top of the closure.
Fixed. Added:
// SAFETY: `p` is a valid pointer to `$c_type`.
> error: this macro expands metavariables in an unsafe block
> --> rust/kernel/interop/list.rs:362:9
> |
> 362 | unsafe { $crate::interop::list::CList::<$rust_type,
> OFFSET>::from_raw($head) }
>
> For this one, to begin with, do we expect to have actual expressions
> for $head, or could we constrain it for now to an identifier for
> instance?
>
> With an identifier there is no issue then -- the example currently has
> just an identifier anyway.
Yes, identifier should be Ok. Changed to it.
thanks,
--
Joel Fernandes
