Restore compatibility with Rust 1.41(.1). #1421
Conversation
There was a problem hiding this comment.
Thanks! It's a shame to give up the ergonomics of the newer compiler. However I think making the adoption of cryptography into as many packaging solutions as possible is worth the (admittedly still small) costs to us.
Could you please add this into the CHANGELOG in a ## Packaging section at the top? (Similar to the 0.13 release ordering.)
pyo3-macros-backend/src/method.rs
Outdated
| @@ -115,6 +115,7 @@ pub fn parse_method_receiver(arg: &syn::FnArg) -> syn::Result<SelfType> { | |||
|
|
|||
| impl<'a> FnSpec<'a> { | |||
| /// Parser function signature and function attributes | |||
| #[allow(clippy::manual_strip)] // for strip_prefix replacement below | |||
There was a problem hiding this comment.
| #[allow(clippy::manual_strip)] // for strip_prefix replacement below | |
| #[allow(clippy::manual_strip)] // for strip_prefix replacement supporting rust < 1.45 |
README.md
Outdated
| @@ -18,7 +18,7 @@ A comparison with rust-cpython can be found [in the guide](https://pyo3.rs/maste | |||
|
|
|||
| ## Usage | |||
|
|
|||
| PyO3 supports Python 3.6 and up. The minimum required Rust version is 1.45.0. | |||
| PyO3 supports Python 3.6 and up. The minimum required Rust version is 1.41.1. | |||
There was a problem hiding this comment.
Imo patch releases probably aren't that interesting unless we do actually depend on the patch fix. Shall we just use major.minor here?
| PyO3 supports Python 3.6 and up. The minimum required Rust version is 1.41.1. | |
| PyO3 supports Python 3.6 and up. The minimum required Rust version is 1.41. |
|
Regarding UI tests, we use I suggest moving anything that doesn't pass on Rust 1.41 into a |
birkenfeld
force-pushed
the
rust1.41
branch
2 times, most recently
from
d4f3fc3
to
97264cc
Compare
This version is currently supported by Debian stable and Alpine Linux. Fixes PyO3#1420
| #[cfg(Py_3_8)] | ||
| if ffi::PyType_HasFeature(ty, ffi::Py_TPFLAGS_HEAPTYPE) != 0 { | ||
| ffi::Py_DECREF(ty as *mut ffi::PyObject); | ||
| if cfg!(Py_3_8) { |
There was a problem hiding this comment.
Why do you prefer this instead of if cfg!(Py_3_8) && .. ?
Or, if you want to avoid #[allow(clippy)] you can use
cfg_if::cfg_if! {
if #[cfg(Py_3_8)] {
if ffi::PyType_HasFeature(ty, ffi::Py_TPFLAGS_HEAPTYPE) != 0 {
ffi::Py_DECREF(ty as *mut ffi::PyObject);
}
}
}Though I'm not sure which is bettter.
There was a problem hiding this comment.
I was thinking of later, when the #[cfg] form can be used again, it is easier to replace this back.
In general I hate the "collapsible_if" lint, since it is in at least 50% of cases not an oversight and makes the code clearer.
| [modifier, char] | ||
| if (*modifier == b'=' | ||
| || *modifier == b'<' | ||
| || *modifier == b'>' | ||
| || *modifier == b'!') => | ||
| { |
There was a problem hiding this comment.
| [modifier, char] | |
| if (*modifier == b'=' | |
| || *modifier == b'<' | |
| || *modifier == b'>' | |
| || *modifier == b'!') => | |
| { | |
| [b'=', char] | [b'<', char] | [b'>', char] | [b'!', char] => { |
This version is currently supported by Debian stable and Alpine Linux.
Fixes #1420