meithecatte/enumflags2

Supporting reexporting enumflags2::bitflags macro

PPakalns opened this issue · 2 comments

PPakalns commented

Macro can not find enumflags2 crate if enumflags2 is reexported (pub use).

A lot of projects use one main crate to organize all crates that all crates in workspace may use.

If enumflags2 is used with this approach following errors are raised:

error[E0432]: unresolved import `enumflags2`
   --> simulation/src/blocks.rs:584:1
    |
584 | #[enumflags2::bitflags]
    | ^^^^^^^^^^^^^^^^^^^^^^^ help: a similar path exists: `self::enumflags2`
    |
    = note: this error originates in the attribute macro `enumflags2::bitflags` (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0433]: failed to resolve: could not find `enumflags2` in the list of imported crates
   --> simulation/src/blocks.rs:584:1
    |
584 | #[enumflags2::bitflags]
    | ^^^^^^^^^^^^^^^^^^^^^^^ could not find `enumflags2` in the list of imported crates
    |
    = note: this error originates in the attribute macro `enumflags2::bitflags` (in Nightly builds, run with -Z macro-backtrace for more info)

Other crates try to fix this by introducing additional macro attributes that defines how to access the crate in that context.

For example strum crate requires additional attribute:

#[strum(crate = "strum")]
meithecatte commented

A lot of projects use one main crate to organize all crates that all crates in workspace may use.

Wouldn't it be easier to use Cargo's support for workspace dependencies?

meithecatte commented

@ozaner Just noticed your commits referencing this issue. I find your crate to be a compelling usecase for fixing this, though I don't think the solution currently being proposed would be any more convenient than what your README currently proposes.

If you're aware of any way for a proc macro to hygienically refer to its "parent" crate, please let me know!

  • 👀1