Environment

• Qiskit version: 2.0.0rc1
• Python version: 3.13
• Operating system: Linux

What is happening?

When calling the commutation checker (via CommutativeCancellation typically) with a custom gate that uses a standard gate name that is in the set of specially handled rotation gates names for the commutation checker, but is not a standard gate instance this results in a panic with the message: "Supported gates are standard gates". The root cause is the rust code of the commutation checker is assuming if it gets a standard gate name for a gate in the circuit than it must be a standard gate and when it isn't it panics.

While it's true we make it explicit that the name is like the op code and the standard gates are reserved, this can come up not by user error necessarily, but because of #10737 when loading a qasm file for a gate that's in Qiskit's standard library but not qasm's. So we should be able to gracefully handle this case correctly by being resilient to this mismatch.

How can we reproduce the issue?

from qiskit.circuit import QuantumCircuit
from qiskit.transpiler import generate_preset_pass_manager, Target, CouplingMap

qasm_str = """OPENQASM 2.0;
include "qelib1.inc";
gate ryy(param0) q0,q1
{
 rx(pi/2) q0;
 rx(pi/2) q1;
 cx q0,q1;
 rz(0.37801308) q1;
 cx q0,q1;
 rx(-pi/2) q0;
 rx(-pi/2) q1;
}
qreg q0[2];
creg c0[2];
h q0[0];
ryy(1.2182379) q0[0],q0[1];
measure q0[0] -> c0[0];
measure q0[1] -> c0[1];
"""

qc = QuantumCircuit.from_qasm_str(qasm_str)
print(qc)


target = Target.from_configuration(["r", "cz", "measure"], num_qubits=5, coupling_map=CouplingMap.from_line(5))
pm = generate_preset_pass_manager(target)
print(pm.run(qc))

What should happen?

The code should not panic, the custom ryy gate resulting from the qasm loading should be either consistently be interpreted as the standard gate or not.

Any suggestions?

I actually caught this in my code review of the most recent change to the logic here: #13874 (review) but didn't think it would result in a panic/error and was just inefficient, I didn't consider overloaded gate names. We can do as I suggested though and use the rust StandardGate type to avoid the panic and handle it consistently in the commutation checker.