Fix broadcasting behavior and log a warning for behavior change

[schweitzpgi]

This PR fixes the bug #875 in the C++ AST Bridge whereby any additional qubits passed to a call to a quantum operation were treated as a control qubits even if no ctrl template argument was provided.

Old behavior:

  cudaq::qreg qs(2);
  auto& q1 = qs.front();
  auto& q2 = qs.back();
  
  // this applies a controlled operation:
  x<cudaq::ctrl>(q1, q2); // cnot operation with q1 as the control qubit

  // this was also treated as a controlled operation:
  x(q1, q2);  // cnot operation with q1 as the control qubit
  
  // this was treated as broadcast
  x(qs); // applies x to both qubits

New behavior:

  cudaq::qreg qs(2);
  auto& q1 = qs.front();
  auto& q2 = qs.back();
  
  // this still applies a controlled operation:
  x<cudaq::ctrl>(q1, q2); // cnot operation with q1 as the control qubit

  // this is now treated as a broadcast
  x(q1, q2);  // gives a warning that the behavior changed

  // this is still treated as broadcast
  x(qs); // applies x to both qubits

[github-actions]

CUDA Quantum Docs Bot: A preview of the documentation can be found here.

[github-actions]

CUDA Quantum Docs Bot: A preview of the documentation can be found here.

[github-actions]

CUDA Quantum Docs Bot: A preview of the documentation can be found here.

[boschmitt]

Thanks Eric. Overall LGTM.

I think we should add more tests to see how the compiler is behaving with a wide variety of combinations. Some that I could think of (likely not comprehensive):

__qpu__ void example() {
  cudaq::qreg q(4);
  cudaq::qreg w(2);
  cudaq::qubit t;
  
  x(q[0], q[1], q[2]); // Broadcast
  x(q); // Broadcast
  x(q, t, w); // Broadcast?
  x<cudaq::ctrl>(q); // Error? Or controls: q[0], q[1], q[2], target: q[3]?
  x<cudaq::ctrl>(q, t); // controls: q[0], q[1], q[2], q[3] target: t
  x<cudaq::ctrl>(t, q); // Error?

  swap(w); // Ok
  swap(q[0], q[1]); // Ok
  swap(q[0], q[1], q[2]); // Error
  swap(q); // Error ? Broadcast (swap(q[0], q[1]) swap(q[2],q[3])?
  swap<cudaq::ctrl>(w); // Error?
  swap<cudaq::ctrl>(q[0], q[1], q[2]); // Error? Or control: q[0], targets: q[1], q[2]
  swap<cudaq::ctrl>(q, w); // controls: q, targets: w[0], w[1]
  swap<cudaq::ctrl>(w, q); // Error?
}

[schweitzpgi]

Thanks Eric. Overall LGTM.

I think we should add more tests to see how the compiler is behaving with a wide variety of combinations. Some that I could think of (likely not comprehensive):

__qpu__ void example() {
  cudaq::qreg q(4);
  cudaq::qreg w(2);
  cudaq::qubit t;
  
  x(q[0], q[1], q[2]); // Broadcast
  x(q); // Broadcast
  x(q, t, w); // Broadcast?
  x<cudaq::ctrl>(q); // Error? Or controls: q[0], q[1], q[2], target: q[3]?
  x<cudaq::ctrl>(q, t); // controls: q[0], q[1], q[2], q[3] target: t
  x<cudaq::ctrl>(t, q); // Error?

  swap(w); // Ok
  swap(q[0], q[1]); // Ok
  swap(q[0], q[1], q[2]); // Error
  swap(q); // Error ? Broadcast (swap(q[0], q[1]) swap(q[2],q[3])?
  swap<cudaq::ctrl>(w); // Error?
  swap<cudaq::ctrl>(q[0], q[1], q[2]); // Error? Or control: q[0], targets: q[1], q[2]
  swap<cudaq::ctrl>(q, w); // controls: q, targets: w[0], w[1]
  swap<cudaq::ctrl>(w, q); // Error?
}

Thanks for looking at this one, Bruno.

I agree that those are all good ideas and should be added to the tests.

It may not be completely obvious, but this particular PR is a one-off strictly for the 0.5.0 release branch. I think if we add more tests, they really belong on main via a different PR. So I'll make your suggestions an issue.

[github-actions]

CUDA Quantum Docs Bot: A preview of the documentation can be found here.

[schweitzpgi]

@bettinaheim to merge