-
Notifications
You must be signed in to change notification settings - Fork 893
refactor OkWrap to not call .into_py(py)
#3595
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
This file was deleted.
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -33,7 +33,7 @@ fn test_compile_errors() { | |
| t.compile_fail("tests/ui/invalid_pymethod_receiver.rs"); | ||
| t.compile_fail("tests/ui/missing_intopy.rs"); | ||
| // adding extra error conversion impls changes the output | ||
| #[cfg(all(target_os = "linux", not(any(feature = "eyre", feature = "anyhow"))))] | ||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Why this modification? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It's a bit of a drive-by but I was working on macOS today and I broke CI in the first attempt because this UI test regressed. Turns out the macos and linux outputs are the same. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. (I think) I added this because the output is different on Windows. The error message for this lists all the variants, and windows has additional error classes. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yep that's what I recall too, which is the why I left windows in the |
||
| #[cfg(not(any(windows, feature = "eyre", feature = "anyhow")))] | ||
| t.compile_fail("tests/ui/invalid_result_conversion.rs"); | ||
| t.compile_fail("tests/ui/not_send.rs"); | ||
| t.compile_fail("tests/ui/not_send2.rs"); | ||
|
|
||
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.
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 guess it's a bit of a style thing, I slightly prefer the combinators over
?in these one-line implementations.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.
The suggestion is not about the
?but usingResult<T, E>instead ofPyResult<T>. If you usemap_errinstead of?, you can in fact relax the bound toE: Into<PyErr>instead ofPyErr: From<E>, and that's maybe better (I should also relax the bound in async support implementation by the way)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.
Ah I see. I take your point (and I did initially accept
Result<T, E>) but having theE: Into<PyErr>bound introduced on this function and doing.map_errin here instead of directly in the macro generated code means this internal functionmap_result_into_ptrappears in the compiler error.I didn't think that was useful (that was the UI test regression noted in the comment below) so I kept with just
PyResultfor now as all we need.I nearly changed the async support but actually I think it's better if I don't touch that in this PR so that it conflicts less with what you've got stacked up.
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.
Makes sense indeed.