rust: macros: vtable: fix `HAS_*` redefinition (`gen_const_name`)

If we define the same function name twice in a trait (using `#[cfg]`),
the `vtable` macro will redefine its `gen_const_name`, e.g. t

rust: macros: vtable: fix `HAS_*` redefinition (`gen_const_name`)

If we define the same function name twice in a trait (using `#[cfg]`),
the `vtable` macro will redefine its `gen_const_name`, e.g. this will
define `HAS_BAR` twice:

#[vtable]
pub trait Foo {
#[cfg(CONFIG_X)]
fn bar();

#[cfg(not(CONFIG_X))]
fn bar(x: usize);
}

Fixes: b44becc5ee80 ("rust: macros: add `#[vtable]` proc macro")
Signed-off-by: Qingsong Chen <[email protected]>
Reviewed-by: Andreas Hindborg <[email protected]>
Reviewed-by: Gary Guo <[email protected]>
Reviewed-by: Sergio González Collado <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Miguel Ojeda <[email protected]>

show more ...

rust: macros: add `#[vtable]` proc macro

This procedural macro attribute provides a simple way to declare
a trait with a set of operations that later users can partially
implement, providing compile

rust: macros: add `#[vtable]` proc macro

This procedural macro attribute provides a simple way to declare
a trait with a set of operations that later users can partially
implement, providing compile-time `HAS_*` boolean associated
constants that indicate whether a particular operation was overridden.

This is useful as the Rust counterpart to structs like
`file_operations` where some pointers may be `NULL`, indicating
an operation is not provided.

For instance:

#[vtable]
trait Operations {
fn read(...) -> Result<usize> {
Err(EINVAL)
}

fn write(...) -> Result<usize> {
Err(EINVAL)
}
}

#[vtable]
impl Operations for S {
fn read(...) -> Result<usize> {
...
}
}

assert_eq!(<S as Operations>::HAS_READ, true);
assert_eq!(<S as Operations>::HAS_WRITE, false);

Signed-off-by: Gary Guo <[email protected]>
Reviewed-by: Sergio González Collado <[email protected]>
[Reworded, adapted for upstream and applied latest changes]
Signed-off-by: Miguel Ojeda <[email protected]>

show more ...