The name `__initXXXXXXX` is defined multiple times

[stijnh]

I have a usecase where the same object is submitted multiple times to inventory. See the following minimal example (my actual application is more complex and the duplicates are the results of several macro expansion).

struct Foo(i32);
inventory::collect!(Foo);
inventory::submit!(Foo(123));
inventory::submit!(Foo(123));

This gives the following error:

error[E0428]: the name `__init6561350217902411997` is defined multiple times
  --> src/main.rs:3:1
   |
 3 | inventory::submit!(Foo(123));
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ `__init6561350217902411997` redefined here
 4 | inventory::submit!(Foo(123));
   | ----------------------------- previous definition of the value `__init6561350217902411997` here
   |
   = note: `__init6561350217902411997` must be defined only once in the value namespace of this module
   = note: this error originates in a macro outside of the current crate (in Nightly builds, run with -Z external-macro-backtrace for more info)

Is this fundamental limitation of using ctor's or is there some work-around available? Thanks for the awesome crate and your work!

[dtolnay]

This is a consequence of every top-level item in module scope (the things in https://docs.rs/syn/0.15/syn/enum.Item.html) requiring to have a unique name. Currently we hash the input tokens as a way to come up with a unique name for whatever is emitted.

rust-lang/rust#54912 will allow fixing this once stable.

Is there any unique id that your macros would be able to provide? If so, you could have them expand to:

const __uniqueID: () = {
    inventory::submit!(Foo(123));
};

Or you could include some unique id in the macro input:

inventory::submit! {
    let __uniqueID;
    Foo(123)
};

[stijnh]

Thank you, it is clear. Hopefully rust-lang/rust#54912 will get fixed soon. For now I will use the work-around of wrapping everything in a const __uniqueID: () = { ... }

Edit: For future readers, in the end I managed to get work this problem by submitting one big object to inventory::submit! instead of expanding all the macros into tiny calls inventory::submit!.

[dtolnay]

This is fixed in inventory 0.2.