Add method to add instructions to a DAGCircuit from an iterator of PackedInstruction

[raynelfss]

Solves #13003

Summary

Tracked by #13001 and preceeded by #12975
The following commits aim to add a DAGCircuit::extend() to add a chain of DAGOpNodes to the DAGCircuit based on a sequence of PackedInstruction.

Details and comments

These commits add the following two methods:

• DAGCircuit::extend() to add a sequence of PackedInstruction continously avoiding having to re-add each bit/var's output node each time an instruction is added. The addition of the output node is only performed once all instructions have been added correctly to the DAGCircuit.

Known issues:

• At the moment, I'm still thinking of ways of handling vars correctly as we need to keep track of each bit/var's output node and vars are currently represented as PyObject which are not hashable.
  • One possible solution would be to use a PyDict however the structures that are being stored within this mapping are rust-native (NodeIndex, Wire).
  • Another solution would be to somehow internalize these structures, which I'm still thinking on how to do.
• Feel free to comment with any ideas.

Blockers

• Implement a capacity-allocated constructor for DAGCircuit in Rust. #12975 (will rebase once merged)
• [DAGCircuit Oxidation] Port DAGCircuit to Rust #12550

[coveralls]

Pull Request Test Coverage Report for Build 10740673998

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

• 104 of 111 (93.69%) changed or added relevant lines in 1 file are covered.
• 106 unchanged lines in 10 files lost coverage.
• Overall coverage increased (+0.008%) to 89.155%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
crates/circuit/src/dag_circuit.rs	104	111	93.69%

Files with Coverage Reduction	New Missed Lines	%
qiskit/transpiler/passes/optimization/split_2q_unitaries.py	1	96.77%
qiskit/transpiler/passes/routing/stochastic_swap.py	1	95.39%
crates/accelerate/src/synthesis/clifford/utils.rs	1	78.06%
crates/circuit/src/dag_node.rs	3	81.2%
crates/qasm2/src/lex.rs	3	93.23%
crates/circuit/src/packed_instruction.rs	11	93.08%
crates/circuit/src/circuit_instruction.rs	12	82.93%
crates/circuit/src/operations.rs	13	88.67%
crates/accelerate/src/results/marginalization.rs	17	90.17%
crates/circuit/src/dag_circuit.rs	44	88.92%

Totals
Change from base Build 10720509731:	0.008%
Covered Lines:	72737
Relevant Lines:	81585

---

💛 - Coveralls

[qiskit-bot]

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

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

[ElePT]

I believe that the PR doesn't have any open blocker. I will remove the on hold label. Let me know if I missed something.

[raynelfss]

I believe that the PR doesn't have any open blocker. I will remove the on hold label. Let me know if I missed something.

I was about to do that :) Thank you

[ElePT]

Thanks @raynelfss! This PR is quite useful for transpiler passes that build new instructions (like unitary synthesis). I have been using these changes in my PR and everything has worked as expected so far, so you can have that as a "unit test" data point. I might be overseeing something but I would approve this PR after addressing a few minor (and quite superficial) comments.

[ElePT]

LGTM

[ElePT]

Actually, I think I have found an issue when trying to add instructions that have no clbits. When I initialize a packed instruction with clbits: target_dag.cargs_interner.get_default(), I then get a the caller is responsible for only using interner keys from the correct interner error. I will try to come up with a minimal example that reproduces the problem.

I want to make sure there are no issues for the case with empty clbits

[ElePT]

The issue was fixed by #13092, it was unrelated to the changes in this PR :)

[kevinhartman]

I can give this a quick look as well if it's helpful (I see it is not in the merge queue yet)

[kevinhartman]

This is looking good, thanks for adding this @raynelfss!

The one larger point I think we should start to be weary of is introducing new methods that aren't covered by any of our existing testing. We've operated in a bit of a free-for-all the last few months while porting things to Rust, under the assumption that our existing Python test code would provide sufficient coverage.

IMO, this new method is sufficiently complex and should be unit tested. I'm not sure if we've decided on an approach to exercise the Rust-only API of our pyclasss. Perhaps @mtreinish has opinions / suggestions?

[mtreinish]

IMO, this new method is sufficiently complex and should be unit tested. I'm not sure if we've decided on an approach to exercise the Rust-only API of our pyclasss. Perhaps @mtreinish has opinions / suggestions?

In general having rust unit tests is possible and we have them already in place where it is possible/makes sense for PRs like this with new rust specific functionality. See: 86c63eb for a recent example (which is already setup to run in CI: https://dev.azure.com/qiskit-ci/qiskit/_build/results?buildId=60452&view=logs&j=b9878877-bc64-52fc-fc03-577dd0aa7cb4&t=2cc4852e-f347-585e-188c-b93a0bf20b0f&l=363 ). But what we will struggle with here is that this new method takes a py token and we don't have a mechanism to interact with python via rust unit tests.

I would agree we should have this exercised somehow in an ideal world. But I think we probably are ok to let this slide if we can't come up with a solution for unit testing with a python dependency. Given that there are several PRs actively based on top of this and those are exercising the code and tested via Python AFAICT.

[kevinhartman]

LGTM, thanks for the changes!