Add test case to validate the rust->Python gate conversion

[mtreinish]

Summary

This commit adds a test to the test_rust_equivalence module to assert that the Python gate objects returned from the Rust CircuitData is the correct type.

Details and comments

[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 9604586227

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• 10 unchanged lines in 2 files lost coverage.
• Overall coverage remained the same at 89.74%

---

Files with Coverage Reduction	New Missed Lines	%
crates/qasm2/src/lex.rs	4	91.86%
crates/qasm2/src/parse.rs	6	97.61%

Totals
Change from base Build 9602245093:	0.0%
Covered Lines:	63573
Relevant Lines:	70841

---

💛 - Coveralls

[ElePT]

I think that the test is not behaving as intended, shouldn't it fail without fixing the wrong import paths we currently have for the T gates? (I did check it out locally and there it fails as expected). Maybe something related to the test config in CI?

[mtreinish]

There is a path where those imports don't get executed: https://github.com/Qiskit/qiskit/blob/main/crates/circuit/src/circuit_instruction.rs#L743-L785 If a TGate python object is added to any circuit directly then we get the mapping automatically from that for all future uses of StandardGate::TGate from the class attribute. Those import paths are just a fallback that gets executed if we don't go through python on the construction side and we need to generate the py gate from something that was created directly from rust space. I think in the case of TGate and TdgGate we are unconditionally adding them to circuits here: https://github.com/Qiskit/qiskit/blob/main/qiskit/circuit/library/standard_gates/equivalence_library.py#L136-L145 when we do import qiskit.

[ElePT]

Ok, so we might not be able to catch the fallback path on CI but the test is still good to have. I guess the best we can do in this case is keep this in mind and run the test locally when relevant.

[ElePT]

I removed the PR from the queue because, if I'm not mistaken, it would fail if #12646 got merged. So maybe we can wait until all gates have been added to merge the test.

[mtreinish]

I removed the PR from the queue because, if I'm not mistaken, it would fail if #12646 got merged. So maybe we can wait until all gates have been added to merge the test.

I think it actually would be fine, because the test only validates if the python side class attribute _standard_gate is set. So for the placeholder gates we've not done that and it'll be a skip. But lets wait for #12646 to merge first and then test my hypothesis, rather than potentially blocking #12646.

[coveralls]

Pull Request Test Coverage Report for Build 9652865752

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• 18 unchanged lines in 2 files lost coverage.
• Overall coverage decreased (-0.01%) to 89.742%

---

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

Totals
Change from base Build 9650973845:	-0.01%
Covered Lines:	63765
Relevant Lines:	71054

---

💛 - Coveralls

[coveralls]

Pull Request Test Coverage Report for Build 9679858189

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• 7 unchanged lines in 1 file lost coverage.
• Overall coverage increased (+0.009%) to 89.769%

---

Files with Coverage Reduction	New Missed Lines	%
crates/qasm2/src/lex.rs	7	91.86%

Totals
Change from base Build 9676629284:	0.009%
Covered Lines:	63792
Relevant Lines:	71062

---

💛 - Coveralls

[ElePT]

Looks to be working!