Skip to content

Conversation

rmshaffer
Copy link
Contributor

Issue #, if available:
#240

Description of changes:
Starting with the changes from #258 and performing the additional work required to merge to main.

The biggest outstanding items are:

  • Refactor the new logic in functions.py into a separate helper function, for readability. See this comment thread.
  • Expand unit tests to ensure correctness of implementation. See this comment thread.
  • Discuss among maintainers to ensure that the new behavior is actually in line with how we want to support OpenQASM in the default simulator (since the OpenQASM spec isn't entirely clear on all of this).

Testing done:
tox

Merge Checklist

Put an x in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your pull request.

General

Tests

  • I have added tests that prove my fix is effective or that my feature works (if appropriate)
  • I have checked that my tests are not configured for a specific region or account (if appropriate)

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Fixes bug [#240] by casting node.size into IntegerLiteral
@EuGig
Copy link

EuGig commented Jun 19, 2024

@rmshaffer, @DanBlackwell
Maybe we should rethink the following case test:

bit[3] b;
qubit["10"] r1;
h r1["01" << "01"];

In this regard the spec explicitly states that shifting, either right or left, is supported by an unsigned integer (https://openqasm.com/language/classical.html#classical-bits-and-registers).
Shifting by a bitstring causes a strange behaviour in case its length does not match the length of the specified qbuit array:

bit[3] b;
qubit[3] r1;
h r1["01" << "01"];
IndexError: boolean index did not match indexed array along dimension 0; dimension is 3 but corresponding boolean dimension is 2

Since we are enabling registers sizes to be specified also as bitstring, maybe we should raise an error if the LHS is also a bitstring.
This influences the refactoring since, it pertains code regarding shifting operations.

@DanBlackwell
Copy link

Maybe slightly related, but I found the following here the other day:

image

I'm not sure whether this is implying that it is valid to cast an array of bits into int and vice versa; but in that case I think that when applying any ops (+ - << >> | & ^ etc) to an 'array of bits' (which a 'bit string literal' is afaik) the best approach is to cast to 'int' rather than reimplement them (and cast back if required). I'm not sure how integer over- and underflows are meant to be handled though.

Copy link

codecov bot commented Sep 10, 2025

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 100.00%. Comparing base (95b1b3c) to head (521708d).

Additional details and impacted files
@@            Coverage Diff            @@
##              main      #263   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           48        48           
  Lines         4067      4071    +4     
  Branches       440       441    +1     
=========================================
+ Hits          4067      4071    +4     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

AttributeError: 'ArrayLiteral' object has no attribute 'value'.

4 participants