Can't use derive macros when bytemuck is re-exported from another crate.

[GlennFolker]

error[E0433]: failed to resolve: could not find `bytemuck` in the list of imported crates
  --> crates\avocado_winit\src\render\graph.rs:65:31
   |
65 |         #[derive(Copy, Clone, Pod, Zeroable)]
   |                               ^^^ could not find `bytemuck` in the list of imported crates
   |
   = note: this error originates in the derive macro `Pod` (in Nightly builds, run with -Z macro-backtrace for more info)

This is probably because bytemuck's proc macro crate uses ::bytemuck::* instead of bytemuck::* here.

[Lokathor]

Using the :: prefix is the standard way to write proc-macros that impl unsafe traits. I asked on the discord and others agreed that it should stay.

If an alternative prefix is desired to be supported we'd have to expand the derive to accept a dummy attribute letting you specify the prefix, or something like that.

In general, proc-macros just aren't the best with re-exports.

[elast0ny]

I've been running into this issue also 👍

Trying to reduce the number of duplicated dependencies in a project becomes much harder if bytemuck doesn't support being re-exported. I like your idea of adding another derive attribute so users could provide the path to bytemuck if they want.

[leod]

I need this in order to use #[derive(Pod)] on structs that are generated in a derive crate of mine, without the user of that derive crate having to add bytemuck as a dependency themselves. I'll admit that this is a rare situation as far as usages of bytemuck go.

I have a branch of bytemuck that seems to do the trick: main...leod:bytemuck:specify_crate_in_derive. It follows the approach suggested by @Lokathor. If folks agree that this is worth upstreaming, I'd be happy to clean it up (and maybe rename the attribute?) and create a PR.

Example usage:

mod custom_mod {
  pub use ::bytemuck;
}

#[derive(Copy, Clone, Pod, Zeroable)]
#[repr(C)]
#[bytemuck_crate(custom_mod::bytemuck)]
struct TestWithCrateAttribute {
  a: u16,
  b: u16,
}

FWIW, as @Lokathor pointed out, this is a general issue with derive macros. I wonder if there already is a pattern recognized by the Rust community that we could follow here.