-
Notifications
You must be signed in to change notification settings - Fork 782
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
fix case of gil-refs feature breaking create_exception!
macro
#4589
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.
LGTM
impl<$($generics,)*> ::std::convert::AsRef<$crate::PyAny> for $name { | ||
#[inline] | ||
fn as_ref(&self) -> &$crate::PyAny { | ||
&self.0 | ||
} | ||
} | ||
|
||
impl<$($generics,)*> ::std::ops::Deref for $name { | ||
type Target = $crate::PyAny; | ||
|
||
#[inline] | ||
fn deref(&self) -> &$crate::PyAny { | ||
&self.0 | ||
} | ||
} |
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.
Are these any useful without gil-refs?
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 don't think so, in general I think it's helpful to not have the structure of the type objects be constrained by AsRef
/ Deref
.
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.
Oh I see what you mean, I've duplicated too much here. Will fix later!
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.
Actually we still have AsRef
/ Deref
here in this macro on main
, maybe we could remove later (i.e. in 0.23 or later) but I think we have to leave these here in this PR for the patch fix. AsPyPointer
(just below) should be removed though, I pushed that.
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.
Sure, removing them from main
makes sense. I don't think these can ever be used now, because there is no way to construct a literal PyAny
(or similar)
* fix case of gil-refs feature breaking `create_exception!` macro * remove `AsPyPointer` on non-gil-refs
Note: this is a patch fix for 0.22.4, the PR is targeting that branch, not
main
.Fixes #4562
The bug is that the macros to set up all the traits for native types expand to use
#[cfg(feature = "gil-refs")]
inside the expanded code, which doesn't work properly in downstream crates.The solution is to split the macro definitions so that they have gil-refs and non-gil-refs versions.
I verified this works manually; I couldn't think of a good testing strategy for the bug in question besides making yet another test crate. For a patch fix it didn't seem worth it.