-
Notifications
You must be signed in to change notification settings - Fork 238
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 From<UnexpectedUniFFICallbackError> optional #1790
Make From<UnexpectedUniFFICallbackError> optional #1790
Conversation
7f18b82
to
4ec2ec4
Compare
87629ca
to
c71c4f1
Compare
// Autoref-based specialization for converting UnexpectedUniFFICallbackError into error types. | ||
// | ||
// For more details, see: | ||
// https://github.com/dtolnay/case-studies/blob/master/autoref-specialization/README.md |
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.
far out, that's crazy :) Thanks for the link!
@@ -216,14 +216,33 @@ pub(crate) fn tagged_impl_header( | |||
} | |||
} | |||
|
|||
pub(crate) fn derive_ffi_traits(ty: &Ident, udl_mode: bool) -> TokenStream { | |||
pub(crate) fn derive_all_ffi_traits(ty: &Ident, udl_mode: bool) -> TokenStream { |
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.
These names kinda bother me a little - derive_all_ffi_traits
seems to be deriving for a single ident where as derive_ffi_traits
takes an array of identifiers. It would be great if you could maybe come up with alternatives to make this a little clearer?
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.
They both take a single type identifier, but derive_ffi_traits
also takes a list of trait names to derive. What about moving that param to the end, so it's more clear what's the same and what's different?
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 right, doh! Swapping those 2 args sounds great, thanks!
c71c4f1
to
19b44a7
Compare
This is in preparation of mozilla#1578 -- allowing foreign languages to implement traits. One issue there is that if we want to allow foreign languages to implement traits, then any Result return types need to implement `LiftReturn`, and that impl currently has a bound on `E: From<UnexpectedUniFFICallbackError`. IOW, it's only implemented for errors that can be converted from UnexpectedUniFFICallbackError. This makes sense when the trait is actually used by the foreign languages, however not all traits are intended for that use. For that matter, some libraries may be fine panicking in the the face of unexpected callback errors. By using the auto-ref specialization hack, we're able to convert the error if there's a `From<UnexpectedUniFFICallbackError>` impl, but use a panicking version if not. The trait bound is no longer required to implement `LiftReturn`.
19b44a7
to
3d58ae3
Compare
This is in preparation of #1578 -- allowing foreign languages to implement traits.
One issue there is that if we want to allow foreign languages to implement traits, then any Result return types need to implement
LiftReturn
, and that impl currently has a bound onE: From<UnexpectedUniFFICallbackError
. IOW, it's only implemented for errors that can be converted from UnexpectedUniFFICallbackError.This makes sense when the trait is actually used by the foreign languages, however some traits are only intended to be implemented by Rust code. For that matter, some libraries may be fine panicking in the the face of unexpected callback errors.
By using the auto-ref specialization hack, we're able to convert the error if there's a
From<UnexpectedUniFFICallbackError>
impl, but use a panicking version if not. The trait bound is no longer required to implementLiftReturn
.