-
Notifications
You must be signed in to change notification settings - Fork 164
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
Add custom derive for Yokeable and ZCF #847
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cool!
// This is for when we're implementing Yoke on a complex type such that it's not | ||
// obvious to the compiler that the lifetime is covariant |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Suggestion (optional): Is it possible to export this, requiring that it be wrapped in unsafe {}
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd rather not: Everyone else should use the custom derive, we're doing this because we're implementing the trait on types we do not own.
|
||
// This is for when we're implementing Yoke on a complex type such that it's not | ||
// obvious to the compiler that the lifetime is covariant | ||
macro_rules! unsafe_complex_yoke_impl { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Question: Can this impl be used on ZeroMap?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ZeroMap's weird.
@@ -36,7 +36,7 @@ icu_locid = { version = "0.2", path = "../../components/locid" } | |||
tinystr = "0.4.5" | |||
writeable = { version = "0.2", path = "../../utils/writeable" } | |||
thiserror = "1.0" | |||
yoke = { version = "0.2", path = "../../utils/yoke", features = ["serde"] } | |||
yoke = { version = "0.2", path = "../../utils/yoke", features = ["serde", "derive"] } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Discussion: should we make the , "derive"
be an optional feature, so we don't pull in syn
? If every data struct effectively requires the custom derive, though, maybe this is unavoidable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah everything needs the derive anyway. I guess utility crates could avoid it but I don't see much of a benefit
<K as ZeroMapKV<'static>>::Container: for<'b> ZeroCopyFrom<<K as ZeroMapKV<'b>>::Container>, | ||
<V as ZeroMapKV<'static>>::Container: for<'b> ZeroCopyFrom<<V as ZeroMapKV<'b>>::Container>, | ||
<K as ZeroMapKV<'static>>::Container: | ||
for<'b> Yokeable<'b, Output = <K as ZeroMapKV<'b>>::Container>, | ||
<V as ZeroMapKV<'static>>::Container: | ||
for<'b> Yokeable<'b, Output = <V as ZeroMapKV<'b>>::Container>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Question: Did you check that this impl compiles at the call site and doesn't hit rust-lang/rust#85636?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It does, at least in the ways I'm trying it. That bug is pretty subtle; if you tweak things a little bit it stops occurring (and more tweaks make it recur).
But also I don't think this matters until we try to use this; I'm just fixing up the impl early. There's more work to be done for ZeroMap in (non cloning) ZCF derives
docstest isn't happy:
|
fascinating; I realized it was because my cloning_zcf impl was not quite correct; however I'm not sure how it leaked out that far implicitly. My current assumption is that DataPayload relies on ZCF in complicated ways and my broken impl affected the variance of DataPayload (and thus ZonedDateTimeFormat) somehow |
Codecov Report
@@ Coverage Diff @@
## main #847 +/- ##
==========================================
- Coverage 74.62% 74.37% -0.26%
==========================================
Files 202 206 +4
Lines 12841 13032 +191
==========================================
+ Hits 9583 9692 +109
- Misses 3258 3340 +82
Continue to review full report at Codecov.
|
I added a |
Notice: the branch changed across the force-push!
~ Your Friendly Jira-GitHub PR Checker Bot |
oops, shouldn't have force-pushed. but it's only on the latest commits |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great work!
Fixes #761
This doesn't add the DataStruct custom derive, but it comes close.
In the interest of not moving all of our source to pure-zerocopy datastructures, I've included a
#[yoke(CloningZCF)]
attribute which, when used, implemends ZCF using.clone()
instead of the right way. Over time we should be getting rid of these attributes, any instance of this attribute means that the ZCF is not actually zero-copy.I have left #844 as a followup; right now the
derive(Yokeable)
derives its safety from getting the compiler to prove covariance.ZeroMap
is not designed in a way that lets the compiler prove covariance, and for such types the custom derive will need to be a little different.cc @shadaj