You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
If a user labels subroutine parameters in a program as both xyz and xyz_, where xyz is some reserved word (like qubit or bit), this may lead to unexpected behavior, as the xyz gets automatically renamed to xyz_ during the transpilation process.
To reproduce
Create an aq.subroutine with parameters named qubit and qubit_. Note that AutoQASM tries to generate a subroutine with two parameters named qubit_, which causes an error.
Expected behavior
If the Python variable names are different, then we should ensure that the resulting OpenQASM variable names do not conflict.
We could also potentially add a comment (using /* */) in the generated OpenQASM when a variable name is modified, to be super clear to the user about how we have changed the program.
The text was updated successfully, but these errors were encountered:
Describe the bug
If a user labels subroutine parameters in a program as both
xyz
andxyz_
, wherexyz
is some reserved word (likequbit
orbit
), this may lead to unexpected behavior, as thexyz
gets automatically renamed toxyz_
during the transpilation process.See this comment thread for more details: https://github.com/amazon-braket/autoqasm/pull/28/files#r1635398668
To reproduce
Create an
aq.subroutine
with parameters namedqubit
andqubit_
. Note that AutoQASM tries to generate a subroutine with two parameters namedqubit_
, which causes an error.Expected behavior
If the Python variable names are different, then we should ensure that the resulting OpenQASM variable names do not conflict.
We could also potentially add a comment (using
/* */
) in the generated OpenQASM when a variable name is modified, to be super clear to the user about how we have changed the program.The text was updated successfully, but these errors were encountered: