QASM 2 and 3 exporters do not handle parameterised gates correctly

[jakelishman]

Environment

• Qiskit Terra version: 0.19.dev @ 2c402dd
• Python version: any
• Operating system: any

What is happening?

The QASM3 exporter (and the QASM2 exporter) does not handle arbitrary parameterised gates correctly. It emits a gate definition which includes parameters in the signature, but hardcodes them in the body to the first instance of the gate it found. This is because there's currently no way in Terra to get from a gate with its parameters assigned back to the fully parameterised version.

How can we reproduce the issue?

In [1]: import qiskit.qasm3
   ...: qc = qiskit.QuantumCircuit(2, 2)
   ...: qc.rzx(0.2, 0, 1)
   ...: qc.rzx(0.3, 0, 1)
   ...:
   ...: print(qiskit.qasm3.dumps(qc))
OPENQASM 3;
include "stdgates.inc";
gate rzx(_gate_p_0) _gate_q_0, _gate_q_1 {
  h _gate_q_1;
  cx _gate_q_0, _gate_q_1;
  rz(0.2) _gate_q_1;
  cx _gate_q_0, _gate_q_1;
  h _gate_q_1;
}
bit[2] c;
qubit[2] _all_qubits;
let q = _all_qubits[0:1];
rzx(0.2) q[0], q[1];
rzx(0.3) q[0], q[1];

The two rzx calls have different parameters, but the parameter is hardcoded to 0.2 in the actual definition.

What should happen?

A full fix of this issue will have the rz line in the rzx gate definition use the gate parameter.

Any suggestions?

As a temporary measure before the 0.19 release, we can hack the exporter to always output a new declaration for each instance of every gate that is not in the include files. This is pretty awful, and the output QASM won't correctly represent the structure of the program with re-used gates, but it will at least produce the correct behaviour.

[mtreinish]

I've changed the milestone here to 0.20.0 as the workaround for 0.19.0 has merged and the proper fix will be for the next release.

[jakelishman]

Changing the milestone to 0.21 because this issue is tied to work in #7624, which also got shifted.

[jakelishman]

This was fixed on the OpenQASM 2 side by #9953 (for Qiskit standard-library gates), and will be fixed in the same manner for OpenQASM 3 by #12776.

There's still a problem with non-standard-library gates whose definitions have bound parameters, but that's generally a problem in Qiskit's data model.