[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20231025201445.497f6ef4.gary@garyguo.net>
Date: Wed, 25 Oct 2023 20:14:45 +0100
From: Gary Guo <gary@...yguo.net>
To: Benno Lossin <benno.lossin@...ton.me>
Cc: Miguel Ojeda <ojeda@...nel.org>,
Wedson Almeida Filho <wedsonaf@...il.com>,
Alex Gaynor <alex.gaynor@...il.com>,
Boqun Feng <boqun.feng@...il.com>,
Björn Roy Baron <bjorn3_gh@...tonmail.com>,
Alice Ryhl <aliceryhl@...gle.com>,
Andreas Hindborg <nmi@...aspace.dk>,
rust-for-linux@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] rust: macros: improve `#[vtable]` documentation
On Tue, 24 Oct 2023 14:43:30 +0000
Benno Lossin <benno.lossin@...ton.me> wrote:
> On 24.10.23 13:24, Gary Guo wrote:
> > On Thu, 19 Oct 2023 17:15:53 +0000
> > Benno Lossin <benno.lossin@...ton.me> wrote:
>
> [...]
>
> >> -/// This attribute is intended to close the gap. Traits can be declared and
> >> -/// implemented with the `#[vtable]` attribute, and a `HAS_*` associated constant
> >> -/// will be generated for each method in the trait, indicating if the implementor
> >> -/// has overridden a method.
> >> +/// This attribute closes that gap. A trait can be annotated with the `#[vtable]` attribute.
> >> +/// Implementers of the trait will then also have to annotate the trait with `#[vtable]`. This
> >> +/// attribute generates a `HAS_*` associated constant bool for each method in the trait that is set
> >> +/// to true if the implementer has overridden the associated method.
> >> +///
> >> +/// For a function to be optional, it must have a default implementation. But this default
> >> +/// implementation will never be executed, since these functions are exclusively called from
> >> +/// callbacks from the C side. This is because the vtable will have a `NULL` entry and the C side
> >> +/// will execute the default behavior. Since it is not maintainable to replicate the default
> >> +/// behavior in Rust, the default implementation should be:
> >> +///
> >> +/// ```compile_fail
> >> +/// # use kernel::error::VTABLE_DEFAULT_ERROR;
> >> +/// kernel::build_error(VTABLE_DEFAULT_ERROR)
> >
> > Note that `build_error` function is considered impl detail and is
> > hidden.
>
> I see, we should mention that in the docs on `build_error`.
Well, it's marked as `#[doc(hidden)]`...
>
> > This should use the macro version instead:
> >
> > kernel::build_error!(VTABLE_DEFAULT_ERROR)
>
> Is there a reason that it is a macro? Why is it re-exported in the
> kernel crate? The macro could just use `::bulid_error::build_error()`.
The original intention is to allow format strings, but Rust const
panic is not powerful enough to support it at the moment. Macro
allows higher flexibility.
It's re-exported so the macro can reference them (note that downstream
crates can't reference build_error directly). Perhaps I should put it
inside __private_reexport or something instead.
Powered by blists - more mailing lists