Open joshlf opened 1 year ago
@Kestrer, do you know if it's sufficient to instead emit ::zerocopy
? My assumption is that, even if zerocopy is reexported by another crate, it still has to be available to rustc
at compile time. I assume there's an issue with this approach since it's not the approach that Serde takes, but I'd be curious to know what the issue is.
Another approach that occurred to me - which I suspect also won't work for some reason - is to emit extern crate zerocopy
in the generated code.
@djkoloski Flagging this in case you'd be interested in it - specifically the #[zerocopy(crate = "...")]
annotation.
do you know if it's sufficient to instead emit
::zerocopy
?
This should be the default option, since in most cases it works. However, it fails in the following cases:
zerocopy
to something else, e.g. if they do foobar = { package = "zerocopy", version = "0.6.3" }
in their Cargo.toml
zerocopy
itself, but rather imports it through some other crate — e.g. foobar
has pub use zerocopy;
in its crate root, and the user’s crate tries #[derive(foobar::zerocopy::AsBytes)]
.Supporting these cases is the motivation for adding a #[zerocopy(crate = path::to::zerocopy)]
annotation.
Another approach that occurred to me - which I suspect also won't work for some reason - is to emit
extern crate zerocopy
in the generated code.
I believe that also fails in the two cases listed above.
Status
core
items are referenced as::core::xxx
rather thancore::xxx
233
#[zerocopy(crate = "...")]
annotationCrate name annotation
Sometimes, our derives will be used in a context in which
zerocopy
isn't calledzerocopy
. For example, this might happen if zerocopy itself is re-exported from another crate, or if a crate wishes to support deriving zerocopy traits from multiple zerocopy versions (see e.g. #557).We can take inspiration from Serde, which defines the
crate
attribute option:In other words, we can do:
However, this isn't enough. For users who wish to invoke derives from multiple versions of zerocopy-derive at once, we need a way of disambiguating which attributes are meant to be consumed by which version of zerocopy-derive. We could provide a disambiguation option like so:
This would let us write code like the following (from #557):
In this example, each
zerocopy-derive
would usederive-version
to filter out attributes not meant for that version.Simpler alternative
The above-described design is a bit complex, and requires users to add a new attribute for each zerocopy version. This is especially painful for crates like libc who will have hundreds of uses.
An alternative is to not permit the user to specify the name of the crate, but instead only support a single naming scheme:
This has the same semantics as the preceding example, but it assumes that for zerocopy-derive 0.X.Y, the
zerocopy
crate is imported aszerocopy_X_Y
, and for zerocopy-derive X.Y.Z, thatzerocopy
is imported aszerocopy_X
.Core re-export
We can't rely on
core
being in scope (or referring to the "real"core
crate). However, we can rely onzerocopy
being in scope (possibly renamed, as described above). If we re-exportcore
fromzerocopy
, then we can emit code that doesn't refer to::core
, but instead refers to::zerocopy::core_reexport
.