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:

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

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

Changelog:
----------
v1 -> v2:
- Use `BTreeSet` and existing `consts` as suggested by Alice and Gary.
- Reword commit messages as suggested by Miguel.
====================

Fixes: b44becc5ee80 ("rust: macros: add `#[vtable]` proc macro")
Signed-off-by: Qingsong Chen <changxian.cqs@antgroup.com>
---
 rust/macros/vtable.rs | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/rust/macros/vtable.rs b/rust/macros/vtable.rs
index 34d5e7fb5768..8a1baedcc280 100644
--- a/rust/macros/vtable.rs
+++ b/rust/macros/vtable.rs
@@ -1,7 +1,7 @@
 // SPDX-License-Identifier: GPL-2.0
 
 use proc_macro::{Delimiter, Group, TokenStream, TokenTree};
-use std::collections::HashSet;
+use std::collections::BTreeSet;
 use std::fmt::Write;
 
 pub(crate) fn vtable(_attr: TokenStream, ts: TokenStream) -> TokenStream {
@@ -28,7 +28,7 @@ pub(crate) fn vtable(_attr: TokenStream, ts: TokenStream) -> TokenStream {
 
     let mut body_it = body.stream().into_iter();
     let mut functions = Vec::new();
-    let mut consts = HashSet::new();
+    let mut consts = BTreeSet::new();
     while let Some(token) = body_it.next() {
         match token {
             TokenTree::Ident(ident) if ident.to_string() == "fn" => {
@@ -74,6 +74,7 @@ pub(crate) fn vtable(_attr: TokenStream, ts: TokenStream) -> TokenStream {
                 const {gen_const_name}: bool = false;",
             )
             .unwrap();
+            consts.insert(gen_const_name);
         }
     } else {
         const_items = "const USE_VTABLE_ATTR: () = ();".to_owned();
-- 
2.40.1

On Thu, 03 Aug 2023 22:09:23 +0800
"Qingsong Chen" <changxian.cqs@antgroup.com> wrote:

> 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:
> 
> ```rust
>     #[vtable]
>     pub trait Foo {
>         #[cfg(CONFIG_X)]
>         fn bar();
> 
>         #[cfg(not(CONFIG_X))]
>         fn bar(x: usize);
>     }
> ```
> 
> Changelog:
> ----------
> v1 -> v2:
> - Use `BTreeSet` and existing `consts` as suggested by Alice and Gary.
> - Reword commit messages as suggested by Miguel.
> ====================
> 
> Fixes: b44becc5ee80 ("rust: macros: add `#[vtable]` proc macro")
> Signed-off-by: Qingsong Chen <changxian.cqs@antgroup.com>
> ---
>  rust/macros/vtable.rs | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/rust/macros/vtable.rs b/rust/macros/vtable.rs
> index 34d5e7fb5768..8a1baedcc280 100644
> --- a/rust/macros/vtable.rs
> +++ b/rust/macros/vtable.rs
> @@ -1,7 +1,7 @@
>  // SPDX-License-Identifier: GPL-2.0
>  
>  use proc_macro::{Delimiter, Group, TokenStream, TokenTree};
> -use std::collections::HashSet;
> +use std::collections::BTreeSet;
>  use std::fmt::Write;
>  
>  pub(crate) fn vtable(_attr: TokenStream, ts: TokenStream) -> TokenStream {
> @@ -28,7 +28,7 @@ pub(crate) fn vtable(_attr: TokenStream, ts: TokenStream) -> TokenStream {
>  
>      let mut body_it = body.stream().into_iter();
>      let mut functions = Vec::new();
> -    let mut consts = HashSet::new();
> +    let mut consts = BTreeSet::new();

I don't think this is actually necessary because `consts` is never
iterated on.

>      while let Some(token) = body_it.next() {
>          match token {
>              TokenTree::Ident(ident) if ident.to_string() == "fn" => {
> @@ -74,6 +74,7 @@ pub(crate) fn vtable(_attr: TokenStream, ts: TokenStream) -> TokenStream {
>                  const {gen_const_name}: bool = false;",
>              )
>              .unwrap();
> +            consts.insert(gen_const_name);
>          }
>      } else {
>          const_items = "const USE_VTABLE_ATTR: () = ();".to_owned();

On 8/3/23 11:09, Qingsong Chen wrote:
> 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:
> 
> ```rust
>      #[vtable]
>      pub trait Foo {
>          #[cfg(CONFIG_X)]
>          fn bar();
> 
>          #[cfg(not(CONFIG_X))]
>          fn bar(x: usize);
>      }
> ```
> 
> Changelog:
> ----------
> v1 -> v2:
> - Use `BTreeSet` and existing `consts` as suggested by Alice and Gary.
> - Reword commit messages as suggested by Miguel.
> ====================
> 
> Fixes: b44becc5ee80 ("rust: macros: add `#[vtable]` proc macro")
> Signed-off-by: Qingsong Chen <changxian.cqs@antgroup.com>
> ---
> [...]
Reviewed-by: Martin Rodriguez Reboredo <yakoyoku@gmail.com>

On 8/3/23 16:09, Qingsong Chen wrote:
> 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:
> 
> ```rust
>      #[vtable]
>      pub trait Foo {
>          #[cfg(CONFIG_X)]
>          fn bar();
> 
>          #[cfg(not(CONFIG_X))]
>          fn bar(x: usize);
>      }
> ```
> 
> Changelog:
> ----------
> v1 -> v2:
> - Use `BTreeSet` and existing `consts` as suggested by Alice and Gary.
> - Reword commit messages as suggested by Miguel.
> ====================
> 
> Fixes: b44becc5ee80 ("rust: macros: add `#[vtable]` proc macro")
> Signed-off-by: Qingsong Chen <changxian.cqs@antgroup.com>

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

On Thu, Aug 3, 2023 at 4:10 PM Qingsong Chen <changxian.cqs@antgroup.com> wrote:
>
> ```rust
>     #[vtable]
>     pub trait Foo {
>         #[cfg(CONFIG_X)]
>         fn bar();
>
>         #[cfg(not(CONFIG_X))]
>         fn bar(x: usize);
>     }
> ```

I forgot to mention this in v1: the code does not need to be indented,
since it is in a ``` block. Or you could remove the block, and keep
the indentation. Both ways are fine.

> Changelog:
> ----------
> v1 -> v2:
> - Use `BTreeSet` and existing `consts` as suggested by Alice and Gary.
> - Reword commit messages as suggested by Miguel.
> ====================

The changelog for a patch should be placed after the `---` line below
the Signed-off-by. That means it will not be part of the commit
message that will land in Git. See e.g. how Martin did it here:
https://lore.kernel.org/rust-for-linux/20230520231701.46008-1-yakoyoku@gmail.com/

No need to send a v3 for these two nits: I can fix it on my side when
I apply it if others are happy with this version of the patch.

Thanks!

Cheers,
Miguel