Update to PyO3 0.27

[jakelishman]

Summary

This small chain of commits follows the steps in the PyO3 migration guide to update from 0.26 to 0.27.

The main change is around the new FromPyObject signature.

The new form of the trait uses Borrowed, causing it to need another lifetime parameter, and an explicit Error type. Where appropriate / easy, I switched the error types away from the complete PyErr, even if most of our handling of those errors does eventually convert them into PyErr for now.

In places where extraction delegates to other methods, particularly where those methods are logical mirrors to FromPyObject, this commit also updates the signatures to use Borrowed instead of &Bound.

In a couple of places, the extraction being in terms of Borrowed meant that trait implementations that are only accessible on Bound (for example impl IntoIterator for &Bound<PyDict>) needed some dereferencing inserted to re-satisfy the bounds.

Details and comments

The downgrade of one particular instance of [email protected] to 0.15.5 is slightly coincidental - I had to undo some of the changes cargo applied while bumping PyO3, and apparently I was slightly overzealous. It's actually better to have slightly fewer builds of it, though, and we largely need things to be aligned since hashbrown frequently leaks out in interfaces between Qiskit, rustworkx and (conversion traits in) PyO3.

Blocked on PyO3/rust-numpy#515 for now.

The lint failure is caused by the bug fixed in PyO3/pyo3#5538, which should be backported in PyO3 0.27.1 in a day or so. If we want to merge this sooner, we can workspace-allow clippy::declare_interior_mutable_const in the root Cargo.toml.

See PyO3 0.27's migration guide for more information on some of the changes in here.

[qiskit-bot]

One or more of the following people are relevant to this code:

• @Qiskit/terra-core

[coveralls]

Pull Request Test Coverage Report for Build 18885640393

Warning: This coverage report may be inaccurate.

This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

• For more information on this, see Tracking coverage changes with pull request builds.
• To avoid this issue with future PRs, see these Recommended CI Configurations.
• For a quick fix, rebase this PR at GitHub. Your next report should be accurate.

Details

• 264 of 289 (91.35%) changed or added relevant lines in 52 files are covered.
• 36 unchanged lines in 5 files lost coverage.
• Overall coverage decreased (-0.02%) to 88.168%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
crates/circuit/src/packed_instruction.rs	5	6	83.33%
crates/circuit/src/parameter_table.rs	1	2	50.0%
crates/qasm3/src/build.rs	0	1	0.0%
crates/qasm3/src/lib.rs	1	2	50.0%
crates/transpiler/src/passes/asap_schedule_analysis.rs	1	2	50.0%
crates/transpiler/src/equivalence.rs	3	5	60.0%
crates/circuit/src/circuit_instruction.rs	11	15	73.33%
crates/circuit/src/dag_circuit.rs	40	45	88.89%
crates/circuit/src/circuit_data.rs	25	34	73.53%

Files with Coverage Reduction	New Missed Lines	%
crates/circuit/src/circuit_data.rs	1	89.91%
crates/qasm2/src/expr.rs	1	93.82%
crates/qasm2/src/lex.rs	7	91.26%
crates/cext/src/transpiler/transpile_function.rs	9	59.52%
crates/qasm2/src/parse.rs	18	95.68%

Totals
Change from base Build 18848756770:	-0.02%
Covered Lines:	93638
Relevant Lines:	106204

---

💛 - Coveralls

[jakelishman]

Ok, I think this should be working now, with the release of rust-numpy 0.27 and pyo3 0.27.1. It was a bit of effort unifying the hashbrown versions between indexmap, rustworkx-core, pyo3 and qiskit, but I think I've got there now.

[mtreinish]

Overall this LGTM. As you described in the PR summary this is mostly about adapting to the new FromPyObject trait which for the most part is pretty straightforward. I just had two small questions inline.

[mtreinish]

This is a different error message. I assume this was intentional because the Display return isn't as nice looking here?

[jakelishman]

ob changed from being Bound to Borrowed, and lost its Display impl. Using repr seemed more like what we intended than swapping to Debug, although:

1. looking now, Bound<'_, T>::fmt used str
2. it's maybe a PyO3 oversight that Borrowed doesn't have the same Display impl anyway.

I can swap to str if you prefer?

[mtreinish]

Yeah I guess that probably would make more sense here. I guess I was just wondering what would be more natural here. But it's not a huge deal either way

[jakelishman]

I changed it to ob.to_owned() in b0db82a, which will cause it to use exactly the same handling as before, since it'll then go down the Bound as Display path.

[mtreinish]

Is this a normal pattern for discarding the error here? I probably have done something like:

Ok(extract().unwrap())

or something like that

[jakelishman]

I did my way so the unwrap/expect will become a compilation error (unhandled match variants) if we change the error type and forget to update the handling. In nightly there's a Result::into_ok that would be clearer, but no date yet for a release of that.

[jakelishman]

Is this a normal pattern for discarding the error here?

Just to be clear, this doesn't discard the error - it completely handles all variants. It's just that the error is uninhabitable. If the error were any type (even ()) then my code would be a compile-time error.