mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Gary Guo <gary@garyguo.net>
To: Benno Lossin <benno.lossin@proton.me>
Cc: "Miguel Ojeda" <ojeda@kernel.org>,
	"Wedson Almeida Filho" <wedsonaf@gmail.com>,
	"Alex Gaynor" <alex.gaynor@gmail.com>,
	"Boqun Feng" <boqun.feng@gmail.com>,
	"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
	"Alice Ryhl" <aliceryhl@google.com>,
	"Andreas Hindborg" <nmi@metaspace.dk>,
	rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] rust: macros: improve `#[vtable]` documentation
Date: Wed, 25 Oct 2023 20:14:45 +0100	[thread overview]
Message-ID: <20231025201445.497f6ef4.gary@garyguo.net> (raw)
In-Reply-To: <5c8b516d-323e-4a0b-8b8a-c0f0aec38b06@proton.me>

On Tue, 24 Oct 2023 14:43:30 +0000
Benno Lossin <benno.lossin@proton.me> wrote:

> On 24.10.23 13:24, Gary Guo wrote:
> > On Thu, 19 Oct 2023 17:15:53 +0000
> > Benno Lossin <benno.lossin@proton.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.

  reply	other threads:[~2023-10-25 19:14 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-19 17:15 Benno Lossin
2023-10-19 18:49 ` Ariel Miculas (amiculas)
2023-10-20  9:06 ` Andreas Hindborg (Samsung)
2023-10-21 13:16   ` Benno Lossin
2023-10-23  8:30     ` Andreas Hindborg (Samsung)
2023-10-23 17:19       ` Benno Lossin
2023-10-21 12:45 ` Alice Ryhl
2023-10-23  7:01   ` Benno Lossin
2023-10-25 13:29     ` Alice Ryhl
2023-10-24 11:24 ` Gary Guo
2023-10-24 14:43   ` Benno Lossin
2023-10-25 19:14     ` Gary Guo [this message]
2023-10-25 21:34       ` Benno Lossin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20231025201445.497f6ef4.gary@garyguo.net \
    --to=gary@garyguo.net \
    --cc=alex.gaynor@gmail.com \
    --cc=aliceryhl@google.com \
    --cc=benno.lossin@proton.me \
    --cc=bjorn3_gh@protonmail.com \
    --cc=boqun.feng@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nmi@metaspace.dk \
    --cc=ojeda@kernel.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=wedsonaf@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®