Support standalone Var throughout transpiler

[jakelishman]

Summary

This adds the missing pieces to fully support standalone Var nodes through every part of the transpiler (that I could detect). It's quite possible there's some problem in a more esoteric non-preset pass somewhere, but I couldn't spot them.

For the most part there were very few changes needed to the actual passes, and only one place in QuantumCircuit that had previously been missed. Most of the commit is updating passes to correctly pass inline_captures=True when appropriate for dealing with DAGCircuit.compose, and making sure that any place that needed to build a raw DAGCircuit for a rebuild without using DAGCircuit.copy_empty_like made sure to correctly add in the variables.

This commit adds specific tests for every pass that I touched, plus the general integration tests that we have for the transpiler to make sure that OQ3 and QPY serialisation work afterwards.

Details and comments

Close #10931.

This is the top of the stack and depends on #12215 and #12308 (the latter of which depends on #12307, though those could be merged together).

I'll write the full release note as a full PR after the tagging of rc1.

[qiskit-bot]

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

• @Eric-Arellano
• @enavarro51
• @Cryoris
• @Qiskit/terra-core
• @ajavadia
• @kevinhartman
• @mtreinish

[coveralls]

Pull Request Test Coverage Report for Build 8923296656

Details

• 26 of 29 (89.66%) changed or added relevant lines in 10 files are covered.
• 3 unchanged lines in 2 files lost coverage.
• Overall coverage increased (+0.06%) to 89.599%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
qiskit/transpiler/passes/layout/apply_layout.py	5	6	83.33%
qiskit/transpiler/passes/layout/sabre_layout.py	5	6	83.33%
qiskit/transpiler/passes/routing/stochastic_swap.py	8	9	88.89%

Files with Coverage Reduction	New Missed Lines	%
crates/qasm2/src/expr.rs	1	94.03%
crates/qasm2/src/lex.rs	2	92.37%

Totals
Change from base Build 8917584107:	0.06%
Covered Lines:	61660
Relevant Lines:	68818

---

💛 - Coveralls

[jakelishman]

Now rebased over #12308 (speculatively assuming the merge-queue commit passes CI).

[mtreinish]

This LGTM, this was much easier to integrate than I expected. Before we merge though I had one question about treating store as a directive for backends that don't have any dynamic circuits capabilities and won't support Vars at all.

[mtreinish]

I'm fine with this, but this basically means we're treating this as always supported through the transpiler regardless of what the target says. Is that the correct behavior for this? I'm mostly wondering for backends that don't have any classical logic support, and how we intend to indicate this to backends. For other control flow operations they have to be explicitly in the target to work. Is the answer just documentation?

[jakelishman]

Short of adding more magic fields to supported_instruction Target, which could never really capture all the constraints of dynamic-circuits requirements already, or some sort of global flag on Target/BackendV2 that we haven't really prepared to put in place, I think documentation is the answer.

Dynamic circuits have always been tricky through these tests, because there's so much that's never really been possible to represent as a restriction to the transpiler (nesting can only be to n levels, max of m blocks, switches must have a default, etc etc).

[mtreinish]

Let just go with documenting this for now as part of the 1.1.x final documentation, I'll convert this into an issue to track. Both as an upgrade note in the final release notes and also as a guidance in the writing a backend section of the docs.

I think for 1.2.x we can look at adding a global flag in the target for something like supports store, etc to provide a high level indicator for this kind of capability above the per instruction look ups. We'd probably need to do this into an opt-in way (so it defaults true) but I think having the capability to express this in the target is what we'll want longer term.

[mtreinish]

You could assert the stores are preserved and present in the qasm string independent of the transpilers optimization or something I guess. But yeah it probably just makes more sense to wait for the parser to gain support for this.

[jakelishman]

This comment is basically just copied from the tests above from when we added the enhanced conditions to control flow.

[jakelishman]

I'll try closing and re-opening this to see if that triggers GH to recalculate the merge base.

[mtreinish]

This LGTM, I'm still mildly concerned about how we handling Store for the target/backends, but I'm fine documenting it. Realistically I feel like this will be an uncommon use case in practice and the only people using it to start will know the backend is capable of supporting it. We can look at evolving our target model to better account for this in 1.2.0