Repository navigation
Path not accepted in "crate" parameter #10
Description
Activity
Thanks, I would accept a PR to fix this.
I cannot run into this issue (I am using
rustc 1.42.0andinventory 0.1.6);$crateseems 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.rsandfoo/tests/main.rs
::foo::submit! { ::foo::Entry } fn main () {}
-
Fixed in #22 once that gets pulled.
I am still confused,
$cratedid work fine in my example: could there be some kind of integration test showcasing the difference in behaviour introduced by #22 (besides non$cratepaths)?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::inventoryyou would only passmy_crate. However now, since you can pass paths there's a few new things you can do:- pass the absolute path to
my_crateby doing::my_crate, which will resolve to::my_crate::inventory(this is useful in the cases in whichmy_cratemight be imported into scope under another name) - 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::inventorywould be allowed by passingmy_crate::reexports
(I think you get the gist)
- pass the absolute path to
Ok I looked into your example and, from what I can tell, I'm getting the same result. It seems like
$cratecan be coerced into an ident somehow...?Like I think this was a Rust change at some point to allow passing
$crateas 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::footo#![crate = ::foo]directly or via a proc-macro, it raises an error.Maybe rust-lang/rust#56647 ?
From my tests some time ago (I don't have the examples nearby),
$cratecan 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.
Reacted by jam1garnerOkay, so the
$cratecoercing to a singleIdentmay 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!Reacted by jam1garnerClosing as there is no longer a "crate" parameter in inventory 0.2.
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.