Add importer for OpenQASM 3

[jakelishman]

Summary

This adds an interface for importing OpenQASM 3 into Qiskit Terra. Right now, this is provided only as an optional dependency (the qasm3-import optional), using the package qiskit_qasm3_import, which in turn depends on the ANTLR runtime antlr4-python3-runtime.

The importer code may in the future be vendored into Terra, and will likely be replaced completely by a more efficient importer in the future, once a more concrete strategy has been decided for handling of classical components in quantum programs.

Details and comments

The added package this depends on was written entirely by me, and it's hosted here: https://github.com/jakelishman/qiskit-qasm3-import. That in turn depends on openqasm3, which is here: https://github.com/openqasm/openqasm/tree/main/source/openqasm (originally written by Li Chen and Yunong Shi at AWS with some help from me).

This adds the functionality as an optional dependency. At the moment, this to avoid adding additional dependencies on qiskit_qasm3_import and transitively on openqasm3 and antlr4-python3-runtime, as a courtesy to downstream consumers of Qiskit who may need to audit dependencies, since we may well not be sticking with ANTLR as the parsing strategy.

I could alternatively vendor all the code of qiskit_qasm3_import into Terra (there's no licensing issues, since I wrote that whole package anyway). Right now, I hard pin the dependency, so it is effectively like a vendoring, but with the ability to treat it as an optional dependency, but I could vendor the code, and do the import test on openqasm3 instead.

[qiskit-bot]

Thank you for opening a new pull request.

Before your PR can be merged it will first need to pass continuous integration tests and be reviewed. Sometimes the review process can be slow, so please be patient.

While you're waiting, please feel free to review other open PRs. While only a subset of people are authorized to approve pull requests for merging, everyone is encouraged to review open pull requests. Doing reviews helps reduce the burden on the core team and helps make the project's code better for everyone.

One or more of the the following people are requested to review this:

• @Qiskit/terra-core

[coveralls]

Pull Request Test Coverage Report for Build 3961426967

• 9 of 21 (42.86%) changed or added relevant lines in 3 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage decreased (-0.01%) to 84.927%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
qiskit/qasm3/init.py	6	18	33.33%

Totals
Change from base Build 3960963334:	-0.01%
Covered Lines:	66649
Relevant Lines:	78478

---

💛 - Coveralls

[taalexander]

I do not have any high-level disagreement with these function names on their own. It is however worth pointing out that this API breaks from the current OpenQASM2 APIs - https://qiskit.org/documentation/stubs/qiskit.qasm.Qasm.html#qiskit.qasm.Qasm.

I wonder if it might make sense to begin renaming the older API as qasm2 (with module deprecation paths) and to extend the QuantumCircuit methods for OpenQASM3 support?

This could be follow-up work.

[jakelishman]

While I was on holiday, I actually wrote a whole new OpenQASM 2 parser for Qiskit, with the majority in Rust. It was mostly for my own learning experience, but since it's like 10x faster than the current Qiskit one (with no external Python dependencies), I might make a PR changing it.

With or without though, though, I think we should move to a new qasm2 module with the names load, loads, dump and dumps. I'm not keen to add an extra method to QuantumCircuit because the class is already massively overloaded - I'd rather we keep things in separate packages. The load/dump terminology is the standard Python names (e.g. pickle.dump, json.dump, etc), and it's consistent with the currently existing qasm3.dump and qpy.dump as well - Qiskit is already semi-inconsistent, but really it's the old OQ2 handling that's inconsistent with the rest of the package direction.

[taalexander]

Thanks, Jake, I'd be hesitant to add more work and potential breaks to the existing QASM2 parser for those that are using it given we're planning on migrating away from it but the pathway suggested for the qasm2 module seems good.

[jakelishman]

Yeah, agree that there's no reason to break users' workflows. My rough intent was to keep QuantumCircuit.from_qasm_{str,file}, and just cause them to internally call qasm2.load and qasm2.loads as appropriate (assuming I do actually publish that parser and it's suitable for Terra).

[kdk]

The overall approach here LGTM, and leaving as an optional import to save requirements churn seems reasonable. One comment on noting the limited scope of OpenQASM3 in the release note.

[mtreinish]

Overall this LGTM, I just had 2 inline comments/questions one about docs and one about the requirements entry. But other than those I think we're ready to move forward here.

[mtreinish]

LGTM now, thanks for the quick updates.

[jlapeyre]

LGTM. I only found a minor suggested edit.

[jakelishman]

@jlapeyre: you'll need to give this your tick to override the "request changes" review you put on it, otherwise PR protection rules will prevent it from merging.

[jlapeyre]

A OK

Comments addressed