[BUG] dumps() emits extern calls without a semicolon, producing unparsable QASM
维护者通常 1 天内回复
评估
调研方向
The extern call is appended unwrapped in _handle_extern_function_cleanup in src/pyqasm/visitor.py (around line 591), so start there and check where the extern statement list is assembled. Reproduce with the snippet in the issue and inspect [type(s).__name__ for s in m.unrolled_ast.statements]. Done means the call is wrapped in qasm3_ast.ExpressionStatement and openqasm3.parse(pyqasm.dumps(m)) succeeds for the extern fixtures. Note that PR #450 is open against this issue and #446 was closed unmerged, so check with maintainers before starting.
由索引模型根据 Issue 内容生成。
描述
Environment
- pyqasm version: 1.2.0 (
main@ 036ad4d) - Python version: 3.12
- Operating system: macOS 15
What happened?
dumps() emits an extern function call without its terminating semicolon, so the generated
program is not valid OpenQASM and will not reparse.
import openqasm3, pyqasm
m = pyqasm.loads("""OPENQASM 3.0;
extern my_extern(int);
my_extern(3);
""")
m.unroll()
out = pyqasm.dumps(m)
print(out)
openqasm3.parse(out)
OPENQASM 3.0;
extern my_extern(int);
my_extern(3)
openqasm3.parser.QASM3ParsingError
With any statement following the call, the two run together on one line:
qubit[1] q;
my_extern(3)x q[0]; # line 5:12 no viable alternative at input 'my_extern(3)'
The cause is the node type, not the printer. The unrolled AST holds a bare FunctionCall
where a statement belongs:
>>> [type(s).__name__ for s in m.unrolled_ast.statements]
['ExternDeclaration', 'FunctionCall']
FunctionCall is an expression node, so openqasm3.printer renders it as an expression —
no semicolon, no line break. It should be wrapped in an ExpressionStatement.
Scope is narrow: only extern calls are affected. Subroutine calls and builtin calls both
round-trip correctly.
extern call QASM3ParsingError tail: ['qubit[1] q;', 'my_extern(3)x q[0];']
extern, no follow QASM3ParsingError tail: ['qubit[1] q;', 'my_extern(3)']
subroutine call reparses OK tail: ['x q[0];', 'x q[0];']
builtin call reparses OK tail: ['qubit[1] q;', 'x q[0];']
Suggestions (Optional)
Wrap the call in qasm3_ast.ExpressionStatement before it is appended to the output
statements — _handle_extern_function_cleanup (src/pyqasm/visitor.py:591) is where the
extern statement list is assembled.
Worth a round-trip assertion in the tests either way: openqasm3.parse(pyqasm.dumps(m)) over
the existing extern fixtures would have caught this, and would catch the same class of bug for
any other node that reaches the statement list unwrapped.
Found while reviewing #425, which touches the expression-statement path but does not cause or
fix this — it reproduces identically on main.
- 主要语言
- Python
- 星标
- 29
- 派生
- 33
- 平均合并
- 2 天 4 小时
- 30 天内合并 PR
- 15
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
qBraid/pyqasm 的其他 Issue
-
难度 2/5 1-3 小时 新手友好度 63/100
维护者通常 1 天内回复
-
enhancement error-handling program-validation
难度 2/5 1-3 小时 新手友好度 65/100
维护者通常 1 天内回复
-
Move the QASM 2 printer and its branch pre-processing out of qasm2.py可能已有人在做 @danielgaskins 于 11 天前认领。 未关闭enhancement qasm2
难度 4/5 3-5 天 新手友好度 22/100
维护者通常 1 天内回复
-
Parse failures raise ValidationError with an empty message; the ANTLR diagnostic is lost可能已有人在做 @tonycoder-hub 于 13 天前认领。 未关闭bug
难度 2/5 1-3 小时 新手友好度 22/100
维护者通常 1 天内回复
-
`extern port` / `extern frame` in `cal` blocks fail to parse, blocking nearly every spec OpenPulse example可能已有人在做 @Riiocodee 于 6 天前认领。 未关闭bug llm-assisted qasm3 qasm3-coverage
难度 4/5 3-5 天 新手友好度 35/100
维护者通常 1 天内回复
相似的 Issue
-
intake mcp-intake needs-ac needs-human-review priority:medium
难度 2/5 1-3 小时 新手友好度 67/100
Ikalus1988/MisakaNet#3848 · 2 条评论 ·
维护者通常 1 天内回复
-
难度 1/5 1 小时以内 新手友好度 75/100
521xueweihan/HelloGitHub#4105 ·
-
难度 2/5 1-3 小时 新手友好度 75/100
igormcsouza/bookloud#54 ·
-
难度 1/5 1 小时以内 新手友好度 90/100
aws-samples/sample-per-model-bedrock#526 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 78/100
ok-oldking/ok-wuthering-waves#1802 ·
维护者通常 2 天内回复