When building an extension with rust-numpy and ndarray on the MSRV of
1.41 with complex numbers. The num-complex crate version needs to be
0.2 which was the pinned version as of ndarray 0.13.1 which was the last
release of ndarray that supported building with rust 1.41. However, the
pyo3 pinned version of 0.4 is incompatible with this and will cause an
error when building because of the version mismatch. To fix this This
commit expands the supported versions for num-complex to match what
rust-numpy uses [1] so that we can build pyo3, numpy, ndarray, and
num-complex in an extension with rust 1.41.
Fixes#1798
[1] https://github.com/PyO3/rust-numpy/blob/v0.14.1/Cargo.toml#L19
The setter function will receive a NULL value on deletion requests.
This wasn't properly handled before, leading to a panic.
The new code raises AttributeError in this scenario instead.
A test for the behavior has been added. Documentation has also
been updated to reflect the behavior.
The field wasn't defined previously. And the enum wasn't defined as
`[repr(C)]`.
This missing field could result in memory corruption if a Rust-allocated
`PyStatus` was passed to a Python API, which could perform an
out-of-bounds write. In my code, the out-of-bounds write corrupted a
variable on the stack, leading to a segfault due to illegal memory
access. However, this crash only occurred on Rust 1.54! So I initially
mis-attribted it as a compiler bug / regression. It appears that a
low-level Rust change in 1.54.0 changed the LLVM IR in such a way to
cause LLVM optimization passes to produce sufficiently different
assembly code, tickling the crash. See
https://github.com/rust-lang/rust/issues/87947 if you want to see
the wild goose chase I went on in Rust / LLVM land to potentially
pin this on a compiler bug.
Lessen learned: Rust crashes are almost certainly due to use of
`unsafe`.
GILGuard::acquire() cannot be called during multi-phase Python
interpreter initialization because it calls Py_IsInitialized(),
which doesn't report the interpreter as initialized until all
phases of initialization have completed.
PyOxidizer uses the multi-phase initialization API and needs to
interact with pyo3's high-level APIs (not the FFI bindings) after
partial interpreter initialization, before the interpreter is fully
initialized. Attempts to use GILGuard::acquire() result in a panic
due to the aforementioned Py_IsInitialized() check failing.
This commit refactors the GILGuard logic into a function that
obtains the actual GILGuard and another function to perform
checks before calling the aforementioned functions.
A new unsafe `Python::with_gil_unchecked()` has been defined
to acquire the GIL via the unchecked code path so we may obtain
a `Python` during multi-phase initialization (and possibly other
scenarios).
* Add support to IndexMap
* Fix indexmap version to 1.6.2
* Remove code duplication by mistake
* Fix ambiguity in test
* Minor change for doc.rs
* Add to lib.rs docstring
* Add indexmap to conversion table
* Add indexmap flag in docs.rs action
* Add indexmap feature to CI
* Add note in changelog
* Use with_gil in tests
* Move code to src/conversions/indexmap.rs
* Add PR number to CHANGELOG
Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com>
* Add round trip test
* Fix issue in MSRV Ubuntu build
* Fix Github workflow syntax
* Yet Another Attempt to Fix MSRV Ubuntu build
* Specify hashbrown to avoid ambiguity in CI
* Add suggestions
* More flexible version for indexmap
* Add documentation
* Address PR comments
* Export indexmap for docs
Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com>
Peter Schafhalter