Fix passing a whole qvector to multi-qubit custom operations in C++ frontend - #4990
Fix passing a whole qvector to multi-qubit custom operations in C++ frontend#4990arcusbuilds wants to merge 1 commit into
Conversation
github-actions
Bot
added
c++ bridge
schweitzpgi
left a comment
schweitzpgi
left a comment
There was a problem hiding this comment.
Broadcasting is only supported for operations on a single qubit because it can be inferred from the types.
We do not allow calling ops with more than one qubit with qvectors that will get magically expanded in C++. If the op takes
|
The desired fix is to disallow qvectors to be passed as argument to custom ops unless the op's arity is 1. The user should get a compiler error on such input (instead of the broken behavior obviously). Any arity |
|
@schweitzpgi, Thanks, that makes sense. A qvector can't really be type-checked anyway when its size is only known at runtime. I'll update the PR to keep the single-qubit broadcast, reject qvectors for anything with arity > 1 with a clear compile error, and fix up the tests to match. |
Passing a whole qvector to a custom operation with more than one target was accepted by the C++ frontend and only failed later, during verification, with an opaque error. Broadcasting is only defined for single-qubit operations, where the target count can be inferred from the types. For an operation of arity greater than one, require the caller to enumerate the target qubits explicitly and emit a compile-time diagnostic otherwise. The check covers controlled invocations as well, so a qvector target is rejected whether or not a control modifier is present; control arguments themselves may still be a qvector. Signed-off-by: Srijan Keshri <srijankeshri007@gmail.com>
953bb2e to
983a808
Compare
|
@schweitzpgi Following up on this one. Is anything still needed from me? I think the workflows need a maintainer to approve a run before CI can report, but happy to make changes if something else is expected. |
2 participants
Fixes #4961.
Passing a
qvectorto a multi-qubit custom operation crashed nvq++ deep in the verifierwith
Invalid matrix size, required 2^N * 2^N for N-qubit operation. The lowering treateda lone
veqargument as a broadcast target no matter what arity the operation had.Per the review discussion, broadcasting only makes sense for single-qubit custom
operations, so the broadcast path is now gated on arity 1. Any other argument shape
(a
qvectorwhere individual qubits are required, or the wrong number of qubits) isrejected at compile time with
custom operation requires N individual qubit argument(s).Testing: a new AST-error test (
custom_op_invalid_argument.cpp) covers too many and toofew qubits, a whole qvector (the reproducer from the issue), and a qubit followed by a
qvector. Existing custom-operation tests pass unchanged.