equivalent of `$crate` in custom derive paths

[dhardy]

With declarative macros I can use $crate to specify fully-qualified paths in a way that works both in the parent crate and when exported to other crates. Is there an equivalent for procedural macros?

::mylib::MyType doesn't work within mylib. Before "edition 2018", a workaround like this would probably have been possible, but I don't believe it is any longer:

// in crate root:
mod mylib {
    pub use super::*;
}

Considering that these macros must currently be defined in another crate it is of course more complicated; a simple $crate would expand to the wrong thing.

[dtolnay]

I don't know of a 2018 workaround for this. Your mylib crate may need to remain on 2015 edition until this is supported. The macro would be able to reference items from mylib like this:

{
    use mylib as _mylib;
    _mylib::MyType
}

This is what Diesel does.
https://github.com/diesel-rs/diesel/blob/42d5b831ac6b407c74a3659653f5b9d171730851/diesel/src/lib.rs#L358-L360

[dtolnay]

@alexcrichton any ideas for how to make this work when mylib is on 2018 edition?

[alexcrichton]

Hm I may be missing something, but why doesn't the mod mylib { ... } trick work in 2018?

[dtolnay]

You can't refer to items from mod mylib in a unified way that works both in downstream crates as well as inside of mylib. In 2018, the first segment of a use statement always identifies a crate. So within mylib it would only work if the procedural macro expands to use crate::mylib::MyType while in downstream crates it would only work as use mylib::MyType.

[alexcrichton]

Ah right yes, ::mylib::MyType only works in 2018 if mylib is a crate.

It's possible to have the same procedural macro do something like __flag_im_in_my_own_crate!() which sets some sort of global variable which causes all path emissions to use crate::... instead of just ::.... That's pretty awful though and I wouldn't necessarily recommend it.

All in all, sounds like we don't have a solution right now and these crates need to stay on the 2015 edition.

[eddyb]

The global variable thing isn't even guaranteed to work - expansion order is unspecified.
(also unspecified: whether global/thread-local variables are preserved across invocations)

[dtolnay]

Closing in favor of rust-lang/rust#54647 to keep the discussion in one place.