standard gates in qiskit in its own inc file

[1ucian0]

Fixes #4312

The qiskit/qasm/libs/qelib1.inc library is defined in the OpenQASM specification (p.10). The file qiskit/qasm/libs/standard_gates.inc is created with the gates in Qiskit.

Because u is not part of the original qelib1.inc, the trick if aliasing U to u from #6077 had to be readjusted. Also swap is not part of the original qelib1.inc, so many tests need include "standard_gates.inc"; instead.

[francabrera]

@1ucian0 is this a breaking change? If a user had something like:

from qiskit import QuantumCircuit
qasm = """
OPENQASM 2.0;
include "qelib1.inc";

qreg q[3];

p(pi/2) q[0];

"""
circuit = QuantumCircuit.from_qasm_str(qasm)

would this break in the next version?

If so, in addition to Qiskit users this would also be a breaking change for the IBM Quantum Composer, old previous saved circuits will stop working. The composer is relying in the qelib1.inc provided in Qiskit. The same would happen for users of the ibm-quantum-widgets.

I'm wondering, does it make sense to introduce this breaking change now that the new version of OpenQasm 3.0 is already out?

[1ucian0]

There are two paths:

• qelib1.inc is static: therefore this PR should be merged to fix the fact it was not static.
• qelib1.inc is not static: therefore IBM Quantum Experience should have keep a copy or a version of the file with the QASM source, since there are not guarantee the code works with a different library.

If "qelib1.inc is static" (which I think it should), the answer to "would this break in the next version?" is yes, since the previous code was based on the wrong assumptions. We can think in a way to solve that in IBM Quantum Composer and ibm-quantum-widgets in their own issue trackers.

[francabrera]

We can think in a way to solve that in IBM Quantum Composer and ibm-quantum-widgets in their own issue trackers.

both are Qiskit users (Qiskit services in the cloud) so it would be a breaking change the same it would be for regular Qiskit users with the snippet above.

[1ucian0]

okey... let's dump the summary of the off-the-band discussion:

• qelib1.inc needs to go back to the paper state, no more additions. Same for the QASM3 equivalent stdgates.inc.
• No need for a mutable standard_gates.inc. If Qiskit serialilzes a circuit with a gate out of the standard library, the dumper needs to add the gate declaration based on the gate definition.
• As a consequence of the previous point, all gates in Qiskit should have definition.
• The way the parser is going to handle current QASM2 code with gates out of the qelib1.inc is by raising a warning to tell the user to change the include line with qiskitlib1.inc. In the beginning, we can do that implicit change at parsing time. After some unspecified period of time, the warning will be removed and the parse will fail.
• qiskitlib1.inc, following the same criteria than the other inc files, is immutable.
• We thought about using stdgates.inc instead of qiskitlib1.inc. However, stdgates.inc is not QASM2 compatible (ctrl in the definitions, for example. And unicode!)

The ToDo for this PR is implementing the warning with the implicit include change and renaming standard_gates.inc as qiskitlib1.inc. Am I missing something @francabrera @ajavadia ?

[1ucian0]

deprecation warning added in 79907ee. Ready for review again.

[1ucian0]

I think this can be closed for now, in the light of the discussion in #10737