mirror of https://github.com/Qiskit/qiskit.git
ddb802506a
Normally creating a custom gate class that overloads the name of a Qiskit defined operation is not valid and not allowed. The names have meaning and are often used as identifiers and this overloading the name will prevent Qiskit from correctly identifying an operation. However as was discovered in #14103 there are some paths available around serialization and I/O where Qiskit does this itself. For example, qasm (both 2 and 3) is a lossy serialization format and qasm2 doesn't have a representation of a UnitaryGate. So when the qasm2 exporter encounteres a `UnitaryGate` it is serialized as a custom gate definition with the name "unitary" in the output qasm2 and the definition is a decomposition of the unitary from the `UnitaryGate`. When that qasm2 program is subsequently deserialized by qiskit parser the custom gate named "unitary" is added as a `_DefinedGate` subclass which includes an `__array__` implementation which computes the unitary from the definition using the quantum info Operator class. This makes the custom gate parsed from qasm2 look like a `UnitaryGate` despite not actually one so this is typically fine for most use cases. However, since #13759 trying to add that not `UnitaryGate` object named "unitary" would cause the Python -> Rust translation to panic (which happens as part of qasm2 desierailzation). because the conversion was expecting a gate named `unitary` to be a `UnitaryGate` as is prescribed by the data model. This commit fixes this by gracefully handling the lack of a matrix parameter as it not actually being a `UnitaryGate` and instead the object gets treated as a `PyGate` in rust which is the expected behavior. Related to #14103 |
||
|---|---|---|
| .. | ||
| __init__.py | ||
| test_arxiv_examples.py | ||
| test_circuit_methods.py | ||
| test_export.py | ||
| test_expression.py | ||
| test_lexer.py | ||
| test_parse_errors.py | ||
| test_structure.py | ||