Fixing definition method for PyGate and PyInstruction

[alexanderivrii]

Summary

This commit fixes a problem when calling definition for a PyGate or a PyInstruction from within Rust space.

Details and comments

I have stumbled on this problem while working on porting HighLevelSynthesis to Rust, with the definition method for a custom gate incorrectly returning None (instead of the expected CircuitData), e.g., on the following circuit:

qc_inner = QuantumCircuit(3)
qc_inner.cx(0, 2)
qc_inner.h(1)

qc = QuantumCircuit(5)
qc.x(0)
qc.append(qc_inner.to_gate(), [1, 4, 2])

Looking at the code for PyGate

match self.gate.getattr(py, intern!(py, "definition")) {
    Ok(definition) => {
        let res: Option<PyObject> = definition.call0(py).ok()?.extract(py).ok();
        ...

the problem is that circuit.definition [in the Python space] is a QuantumCircuit and not a callable, with definition.call0(...) returning precisely this error message.

The only question is how can I add a test for this fix? I don't see how I can add something to the Rust space and I don't see how I can add it to the Python space.

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

Details

• 0 of 4 (0.0%) changed or added relevant lines in 1 file are covered.
• 2 unchanged lines in 1 file lost coverage.
• Overall coverage increased (+0.02%) to 88.683%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
crates/circuit/src/operations.rs	0	4	0.0%

Files with Coverage Reduction	New Missed Lines	%
crates/qasm2/src/lex.rs	2	93.23%

Totals
Change from base Build 13154732632:	0.02%
Covered Lines:	78966
Relevant Lines:	89043

---

💛 - Coveralls

[Cryoris]

Going via QuantumCircuitData seems like it would work (though I would ask whether the case of definition being None still returns None with this new solution?) but this will populate a lot fields we don't return in the end (since we only return .data but e.g. .qregs and many others are being built).

Couldn't we fix the previous code by removing the .call0 and directly trying to cast the definition into a CircuitData? This way we'd only build the data we actually return from the function.