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
The current OpenQASM specification is version 3.1, and the version string section defines the OPENQASM M.m; header where the minor version is optional.
pyqasm hard-codes the accepted set to {"2", "2.0", "3", "3.0"}, so any program declaring
itself as 3.1 is refused before analysis begins.
Example QASM failure
OPENQASM 3.1;
include"stdgates.inc";
qubit[1] q;
h q[0];
The identical program with OPENQASM 3.0; validates and unrolls without issue, so nothing
beyond the header check is involved.
Change Requested
Accept 3.1 alongside 3 and 3.0.
Prefer a comparison over an enumerated set: accept any 3.x and reject 4.x and above with
a message that names the highest supported major version. That way the next minor release
does not require another patch.
Preserve the declared version through dumps() — a program that comes in as 3.1 must go out
as 3.1, since the existing "preserve QASM version" behaviour ([FEATURE] Preserve QASM version #36) is relied on downstream.
Update the README and docs, which currently state OpenQASM 3.0 support.
Implementation Details
The check is in src/pyqasm/entrypoint.py:158, against the SUPPORTED_QASM_VERSIONS
constant.
The module classes in src/pyqasm/modules/ (qasm2.py, qasm3.py) dispatch on the parsed
version; confirm that a 3.1 header routes to Qasm3Module and that the version string is
stored verbatim for serialisation rather than normalised to 3.0.
Worth stating explicitly in the issue resolution: accepting the 3.1 header does not by itself
mean full 3.1 semantic coverage. This change removes a blanket rejection so that 3.1-tagged
programs can be analysed; the remaining coverage gaps are tracked in the companion issues
filed alongside this one.
Tests: tests/test_entrypoint.py — OPENQASM 3.1; loads, unrolls, and round-trips with the
version preserved; OPENQASM 4.0; still raises a ValidationError.
Limitation
The current OpenQASM specification is version 3.1, and the
version string section defines the
OPENQASM M.m;header where the minor version is optional.pyqasmhard-codes the accepted set to{"2", "2.0", "3", "3.0"}, so any program declaringitself as 3.1 is refused before analysis begins.
Example QASM failure
The identical program with
OPENQASM 3.0;validates and unrolls without issue, so nothingbeyond the header check is involved.
Change Requested
3.1alongside3and3.0.3.xand reject4.xand above witha message that names the highest supported major version. That way the next minor release
does not require another patch.
dumps()— a program that comes in as 3.1 must go outas 3.1, since the existing "preserve QASM version" behaviour ([FEATURE] Preserve QASM version #36) is relied on downstream.
Implementation Details
src/pyqasm/entrypoint.py:158, against theSUPPORTED_QASM_VERSIONSconstant.
src/pyqasm/modules/(qasm2.py,qasm3.py) dispatch on the parsedversion; confirm that a
3.1header routes toQasm3Moduleand that the version string isstored verbatim for serialisation rather than normalised to
3.0.mean full 3.1 semantic coverage. This change removes a blanket rejection so that 3.1-tagged
programs can be analysed; the remaining coverage gaps are tracked in the companion issues
filed alongside this one.
tests/test_entrypoint.py—OPENQASM 3.1;loads, unrolls, and round-trips with theversion preserved;
OPENQASM 4.0;still raises aValidationError.