-
Notifications
You must be signed in to change notification settings - Fork 81
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make derive macros hygienic #11
Comments
TODO: - What does doing `::core` buy us over `core`? - Doesn't seem like we can do `::zerocopy` since zerocopy itself defines a `zerocopy` module at the top level which is meant to mimic the `zerocopy` that the emitted code expects; however, are we losing anything by not doing `::zerocopy`? Part of #11
@Kestrer, do you know if it's sufficient to instead emit Another approach that occurred to me - which I suspect also won't work for some reason - is to emit |
@djkoloski Flagging this in case you'd be interested in it - specifically the |
This should be the default option, since in most cases it works. However, it fails in the following cases:
Supporting these cases is the motivation for adding a
I believe that also fails in the two cases listed above. |
Turns out `rkyv` is more for defining a new binary encoding scheme rather than reusing an existing one (which is the main purpose of zorua). So, replacing it with the `zerocopy` crate. - Reexported items from the zerocopy crate for to/from bytes traits. - Also reexported endian-aware int/float types via the byteorder feature of zerocopy. - Unfortunately, until google/zerocopy#11 is resolved, downstream must also import the zerocopy crate (ideally of the same minor version).
Turns out `rkyv` is more for defining a new binary encoding scheme rather than reusing an existing one (which is the main purpose of zorua). So, replacing it with the `zerocopy` crate. - Reexported items from the zerocopy crate for to/from bytes traits. - Also reexported endian-aware int/float types via the byteorder feature of zerocopy. - Unfortunately, until google/zerocopy#11 is resolved, downstream must also import the zerocopy crate (ideally of the same minor version).
Turns out `rkyv` is more for defining a new binary encoding scheme rather than reusing an existing one (which is the main purpose of zorua). So, replacing it with the `zerocopy` crate. - Reexported items from the zerocopy crate for to/from bytes traits. - Also reexported endian-aware int/float types via the byteorder feature of zerocopy. - Unfortunately, until google/zerocopy#11 is resolved, downstream must also import the zerocopy crate (ideally of the same minor version).
Turns out `rkyv` is more for defining a new binary encoding scheme rather than reusing an existing one (which is the main purpose of zorua). So, replacing it with the `zerocopy` crate. - Reexported items from the zerocopy crate for to/from bytes traits. - Also reexported endian-aware int/float types via the byteorder feature of zerocopy. - Unfortunately, until google/zerocopy#11 is resolved, downstream must also import the zerocopy crate (ideally of the same minor version).
This has the effect of ensuring that derive-emitted code will fail to compile if it spuriously relies on certain identifiers being in scope - namely, identifiers which are part of the prelude. Disabling the prelude surfaced a few bugs which are also fixed in this commit. Makes progress on #11
This has the effect of ensuring that derive-emitted code will fail to compile if it spuriously relies on certain identifiers being in scope - namely, identifiers which are part of the prelude. Disabling the prelude surfaced a few bugs which are also fixed in this commit. Makes progress on #11
This has the effect of ensuring that derive-emitted code will fail to compile if it spuriously relies on certain identifiers being in scope - namely, identifiers which are part of the prelude. Disabling the prelude surfaced a few bugs which are also fixed in this commit. Makes progress on #11
This has the effect of ensuring that derive-emitted code will fail to compile if it spuriously relies on certain identifiers being in scope - namely, identifiers which are part of the prelude. Disabling the prelude surfaced a few bugs which are also fixed in this commit. Makes progress on #11
This has the effect of ensuring that derive-emitted code will fail to compile if it spuriously relies on certain identifiers being in scope - namely, identifiers which are part of the prelude. Disabling the prelude surfaced a few bugs which are also fixed in this commit. Makes progress on #11
This has the effect of ensuring that derive-emitted code will fail to compile if it spuriously relies on certain identifiers being in scope - namely, identifiers which are part of the prelude. Disabling the prelude surfaced a few bugs which are also fixed in this commit. Makes progress on #11
This has the effect of ensuring that derive-emitted code will fail to compile if it spuriously relies on certain identifiers being in scope - namely, identifiers which are part of the prelude. Disabling the prelude surfaced a few bugs which are also fixed in this commit. Makes progress on #11
This has the effect of ensuring that derive-emitted code will fail to compile if it spuriously relies on certain identifiers being in scope - namely, identifiers which are part of the prelude. Disabling the prelude surfaced a few bugs which are also fixed in this commit. Makes progress on google#11
Turns out `rkyv` is more for defining a new binary encoding scheme rather than reusing an existing one (which is the main purpose of zorua). So, replacing it with the `zerocopy` crate. - Reexported items from the zerocopy crate for to/from bytes traits. - Also reexported endian-aware int/float types via the byteorder feature of zerocopy. - Unfortunately, until google/zerocopy#11 is resolved, downstream must also import the zerocopy crate (ideally of the same minor version).
Turns out `rkyv` is more for defining a new binary encoding scheme rather than reusing an existing one (which is the main purpose of zorua). So, replacing it with the `zerocopy` crate. - Reexported items from the zerocopy crate for to/from bytes traits. - Also reexported endian-aware int/float types via the byteorder feature of zerocopy. - Unfortunately, until google/zerocopy#11 is resolved, downstream must also import the zerocopy crate (ideally of the same minor version).
Status
core
items are referenced as::core::xxx
rather thancore::xxx
#[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:#[serde(crate = "...")]
In other words, we can do:
#[zerocopy(crate = "...")]
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:
#[zerocopy(crate = "...", derive-version = "...")]
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.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
.The text was updated successfully, but these errors were encountered: