Fail gracefully on bad SabreDAG construction

[jakelishman]

Summary

This is a private, internal Rust type, but it doesn't cost us anything (meaningful) to bounds-check the accessors and ensure we fail gracefully rather than panicking if we ever make a mistake in Python space. This more faithfully fulfills the return value of SabreDAG::new, which previously was an effectively infallible Result.

Details and comments

Stems from #10712 (comment). We might not need to bother with this, but if we did, this is probably what it'd look like.

The extra test shim stuff is just because PyO3/Rust can't link statically against CPython for the test suite; usually extension-modules link dynamically against Python with the particular shared library getting linked during Python's initialisation of the module.

[qiskit-bot]

One or more of the the following people are requested to review this:

• @Eric-Arellano
• @Qiskit/terra-core
• @kevinhartman
• @mtreinish

[kevinhartman]

Looks great.

Is this the first bit of Rust-based unit testing we've got in accelerate?

[jakelishman]

It is the first bit of testing (I didn't want to write a Python test that's testing an internal Rust interface), but weirdly it works completely fine locally for me and fails in CI. I'll have to look into the setup.

[jakelishman]

On closer inspection of that error message, I'm guessing/hoping the problem is just that Azure's setup Python action doesn't add Python's dynamic libraries path to the default linker path, but if we get to that point from within a Python interpreter session then it's obviously already loaded into memory.

[jakelishman]

Alright, the issue in the end was that PyO3 was finding the correct place to link in the library and on Linux (or at least the CI machines) that's a dynamic library. However, for reasons that I don't fully understand, it doesn't write out the library path into the rpath of the test executable, so dlopen subsequently fails to load it during the execution.

Since I don't 100% understand why PyO3 doesn't write out the rpath in this case, and that's presumably a deliberate decision on their part, I elected not to do weird hacky build overrides that might have an impact on developers, and instead just made sure that a suitable dynamic library is locatable when loading the executable.

[coveralls]

Pull Request Test Coverage Report for Build 6025520902

• 0 of 0 changed or added relevant lines in 0 files are covered.
• 11 unchanged lines in 3 files lost coverage.
• Overall coverage decreased (-0.004%) to 87.246%

---

Files with Coverage Reduction	New Missed Lines	%
crates/qasm2/src/expr.rs	1	93.76%
qiskit/extensions/quantum_initializer/squ.py	2	80.0%
crates/accelerate/src/sabre_swap/sabre_dag.rs	8	86.21%

Totals
Change from base Build 6023513300:	-0.004%
Covered Lines:	74367
Relevant Lines:	85238

---

💛 - Coveralls

[kevinhartman]

LGTM. Thanks for enabling Rust-only testing 😄.

[jakelishman]

In retrospect, I'm fairly sure that PyO3 doesn't automatically write out the path of the dynamic Python library detected during the build into the rpath because that would couple the output executable to the directory structure of the machine that built it, which isn't useful during packaging as that's not a fixed point. So what I did of ensuring that the library path is set up correctly during the run is (I think) the correct thing to do.