Add Rust representation for XXMinusYYGate and XXPlusYYGate

[ElePT]

Summary

This PR adds some of the remaining gates from #12566 XXPlusYY and XXMinusYY. It also adds a multiply_param function that makes the parameter multiplication step a bit more ergonomic (it matches the parameter type and deals with the different logic depending on whether it's a float or a parameter expression). The RZGate definition has been updated to use this function too.

This PR also fixes an oversight in the import path of TGate and TdgGate, which we should add a unit test for.

Details and comments

I don't love having to pass the py token around, so I am open to suggestions to improve the implementation.

[jakelishman]

I'm slightly concerned that this didn't cause us test failures when the first PR merged; we're presumably missing coverage, because that import would have failed.

(Also, there's really no need for us to be importing all these from the specific modules; we could just import them from qiskit.circuit.library or at most qiskit.circuit.library.standard_gates.)

[ElePT]

I am not sure how we could test these. From Rust space, as we'd need the Python GIL, and from Python space, we always have a Python object to refer to, right?

What I guess we could do is expose get_std_gate_class to Python and test it there, but it doesn't sound like the greatest idea.

[mtreinish]

The easiest test we should write for this is to call the QuantumCircuit gate method for each gate which will only create a rust representation then just do QuantumCircuit.data[0].operation and compare it against the expected one. That should give us full path coverage of this conversion.

[mtreinish]

FWIW, looking through the code this never gets used because we're always adding a tgate by class to a circuit before needing to instantiate a python object from rust so we have the mapping already. I expect via the equivalence library on import. This is only used if we're in a call path where we end up with a StandardGate::TGate created in rust before it's ever added to a circuit via the python object to add a fallback import path. I wrote up the test case as I suggested above locally and it passes without this change.

[mtreinish]

I pushed up a test for this here: #12623

[coveralls]

Pull Request Test Coverage Report for Build 9585037750

Details

• 151 of 160 (94.38%) changed or added relevant lines in 4 files are covered.
• 15 unchanged lines in 2 files lost coverage.
• Overall coverage increased (+0.02%) to 89.785%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
crates/circuit/src/operations.rs	107	116	92.24%

Files with Coverage Reduction	New Missed Lines	%
crates/qasm2/src/lex.rs	3	92.37%
crates/qasm2/src/parse.rs	12	97.15%

Totals
Change from base Build 9578841868:	0.02%
Covered Lines:	63705
Relevant Lines:	70953

---

💛 - Coveralls

[qiskit-bot]

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

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

[Cryoris]

LGTM! The only question I have is whether changing the previous theta.clone_ref(py) to now theta.clone() has a performance difference. But we can still update this later if it is, and merge this to unblock other PRs that use parameters in gates 🙂