Make zerocopy-derive an optional dependency#176
Conversation
|
Some issues to address before it's ready for review/merge, but the numbers look great! In my cloud VM, compiling without zerocopy-derive is ~20x faster: cc @djkoloski |
401d345 to
f02025b
Compare
|
@djkoloski You might have ideas here. While all of the types with trait impls use EDIT: Here's one possible idea. We could introduce a macro which spits out code in all cases. When the derive is not used, it emits the impls. When the derive is used, it emits validation code like: trait IsFromBytes: FromBytes {}
impl<T: SomeBound> IsFromBytes for Foo<T> {}The idea here is that if the type parameter bounds (in this case, Here's a prototype that demonstrates the idea working. |
87a909e to
dd7876a
Compare
|
Am I understanding correctly that you want to use
That could very easily be overengineering it though. |
|
Yeah specifically I want to make sure that we're able to rely on the derive to do the soundness analysis for us. I'd like to keep the amount of manually verified unsafe code as small as possible. |
dd7876a to
9ba47b3
Compare
|
Okay, the latest version contains a macro - #[cfg(not(any(feature = "derive", test)))]
impl_or_verify!(T => FromZeroes for Unalign<T>);...which would only compile the impls, but would not compile when the derive was used, and thus wouldn't perform its verification function. I'll try to figure out how to plug this hole, but a) I suspect it may be hard to do ergonomically and, b) I consider it a pretty minor risk. |
11a1e77 to
add56b1
Compare
add56b1 to
fca8e50
Compare
097d542 to
cddee17
Compare
This requires a few changes to accomodate: - We still want to be able to derive zerocopy traits on our own types so that we can rely on it to validate the soundness of those impls for us. That means that, when the `derive` feature is enabled, we still use custom derives, but when it's disabled, we implement traits manually. However, we also need to ensure that our manual trait impls have the correct bounds required in order for those impls to be sound. In order to ensure this, we introduce an `impl_or_verify!` macro which, when building with `derive` enabled, verifies that the manual impl matches the one emitted by our custom derive. - Since some doc examples use custom derives, we can no longer run doc tests unconditionally in CI - when the `derive` feature is disabled, doc tests fail. Instead, we disable doc tests by default (in order to run them, `cargo test` must be run with the `--doc` flag). We introduce a separate "Run doc tests" step in CI - this step only runs when the `derive` feature is enabled. Closes #169
cddee17 to
f66dd2a
Compare
This requires a few changes to accomodate: - We still want to be able to derive zerocopy traits on our own types so that we can rely on it to validate the soundness of those impls for us. That means that, when the `derive` feature is enabled, we still use custom derives, but when it's disabled, we implement traits manually. However, we also need to ensure that our manual trait impls have the correct bounds required in order for those impls to be sound. In order to ensure this, we introduce an `impl_or_verify!` macro which, when building with `derive` enabled, verifies that the manual impl matches the one emitted by our custom derive. - Since some doc examples use custom derives, we can no longer run doc tests unconditionally in CI - when the `derive` feature is disabled, doc tests fail. Instead, we disable doc tests by default (in order to run them, `cargo test` must be run with the `--doc` flag). We introduce a separate "Run doc tests" step in CI - this step only runs when the `derive` feature is enabled. Closes #169
This requires a few changes to accomodate: - We still want to be able to derive zerocopy traits on our own types so that we can rely on it to validate the soundness of those impls for us. That means that, when the `derive` feature is enabled, we still use custom derives, but when it's disabled, we implement traits manually. However, we also need to ensure that our manual trait impls have the correct bounds required in order for those impls to be sound. In order to ensure this, we introduce an `impl_or_verify!` macro which, when building with `derive` enabled, verifies that the manual impl matches the one emitted by our custom derive. - Since some doc examples use custom derives, we can no longer run doc tests unconditionally in CI - when the `derive` feature is disabled, doc tests fail. Instead, we disable doc tests by default (in order to run them, `cargo test` must be run with the `--doc` flag). We introduce a separate "Run doc tests" step in CI - this step only runs when the `derive` feature is enabled. Closes #169
The 'derive' feature now is optional and requires to be enabled explicitly [1]. [1] google/zerocopy#176 Signed-off-by: Bo Chen <chen.bo@intel.com>
The 'derive' feature of `zerocopy` crate now is optional and requires to be enabled explicitly [1]. Also, a version bump on `acpi_tables` is needed to reply on a single version of `zerocopy` to avoid compilation errors. [1] google/zerocopy#176 Signed-off-by: Bo Chen <chen.bo@intel.com>
The 'derive' feature of `zerocopy` crate now is optional and requires to be enabled explicitly [1]. Also, a version bump on `acpi_tables` is needed to reply on a single version of `zerocopy` to avoid compilation errors. [1] google/zerocopy#176 Signed-off-by: Bo Chen <chen.bo@intel.com>
This requires a few changes to accomodate:
that we can rely on it to validate the soundness of those impls for
us. That means that, when the
derivefeature is enabled, we stilluse custom derives, but when it's disabled, we implement traits
manually. However, we also need to ensure that our manual trait impls
have the correct bounds required in order for those impls to be sound.
In order to ensure this, we introduce an
impl_or_verify!macrowhich, when building with
deriveenabled, verifies that the manualimpl matches the one emitted by our custom derive.
tests unconditionally in CI - when the
derivefeature is disabled,doc tests fail. Instead, we disable doc tests by default (in order to
run them,
cargo testmust be run with the--docflag). Weintroduce a separate "Run doc tests" step in CI - this step only runs
when the
derivefeature is enabled.Closes #169