Path not accepted in "crate" parameter

[Frizi]

It seems like the crate name can only be provided as an direct identifier. Trying to use submit! in macro_rules in an robust way is impossible as crate cannot be specified correctly.

$crate::inventory::submit! {
    #![crate = $crate]
    ...
}

[dtolnay]

Thanks, I would accept a PR to fix this.

[danielhenrymantilla]

I cannot run into this issue (I am using rustc 1.42.0 and inventory 0.1.6);$crate seems to be a (correctly-spanned) Identifier:

foo/src/lib.rs

#[doc(hidden)]
pub use ::inventory;

pub struct Entry;

::inventory::collect!(Entry);

#[macro_export]
macro_rules! submit { ($expr:expr) => (
    $crate::inventory::submit! {
        #![crate = $crate]
        $expr
    }
)}

submit! {
    Entry
}

foo/dependency/src/main.rs

• (which depends on foo)

• also tested with foo/src/main.rs and foo/tests/main.rs

::foo::submit! {
    ::foo::Entry
}

fn main ()
{}

[jam1garner]

Fixed in #22 once that gets pulled.

[danielhenrymantilla]

I am still confused, $crate did work fine in my example: could there be some kind of integration test showcasing the difference in behaviour introduced by #22 (besides non $crate paths)?

[jam1garner]

Not a terrible idea, but the difference is essentially: before you could only pass an ident as the crate. For example if inventory is re-exported as my_crate::inventory you would only pass my_crate. However now, since you can pass paths there's a few new things you can do:

1. pass the absolute path to my_crate by doing ::my_crate, which will resolve to ::my_crate::inventory (this is useful in the cases in which my_crate might be imported into scope under another name)
2. pass a path to a module that re-exports inventory, allowing you to export it somewhere other than the top level of your crate, so my_crate::reexports::inventory would be allowed by passing my_crate::reexports

(I think you get the gist)

[jam1garner]

Ok I looked into your example and, from what I can tell, I'm getting the same result. It seems like $crate can be coerced into an ident somehow...?

Like I think this was a Rust change at some point to allow passing $crate as an ident? It seems special cased. If I expand $crate, it results in ::foo, which is clearly not an ident, yet I can pass it as an ident playground link. If I pass ::foo to #![crate = ::foo] directly or via a proc-macro, it raises an error.

Maybe rust-lang/rust#56647 ?

[Frizi]

From my tests some time ago (I don't have the examples nearby), $crate can indeed be coerced into "ident", but only in simple cases. Once the macro is being reexported through another crate, it no longer works as simple ident and can only be treated as path.

Anyway, I believe that #22 should indeed fix that. I don't have the capacity at the moment to test that myself though, but I'd be happy to close this issue if somebody else would check that macro reexport case.

[danielhenrymantilla]

Okay, so the $crate coercing to a single Ident may not be a reliable thing to have, that was what I was suspecting but wanted some confirmation (since in my simple example I failed to hit that limitation). Thanks for the info!

[dtolnay]

Closing as there is no longer a "crate" parameter in inventory 0.2.