Skip to content

Add QuantumProgram to providers crate - #16924

Open
Ian Hincks (ihincks) wants to merge 1 commit into
ihincks/qp-05-arity-macrofrom
ihincks/qp-06-quantum-program
Open

Add QuantumProgram to providers crate#16924
Ian Hincks (ihincks) wants to merge 1 commit into
ihincks/qp-05-arity-macrofrom
ihincks/qp-06-quantum-program

Conversation

@ihincks

@ihincks Ian Hincks (ihincks) commented Sep 3, 2026

Copy link
Copy Markdown
Contributor

This PR adds the QuantumProgram struct with owns a vector of QuantumFunction.

The QuantumProgram has some well-typedness/type safety requirements. These requirements
ultimately stem from the expense of quantum compute resources: we never want to end
up in a situation where a program fails and quantum resources are effectively wasted
because the program was somehow malformed and a runtime error occurs during the classical
parts of a program. We want every instruction to have a well-defined result type, and the that
the validitiy of and result type of every operation is determined statically from the IR
itself.

To this end, the QuantumProgram enforces several structural invariants intended to prevent malformed programs from reaching execution time. In particular, the IR maintains:

  • SSA discipline: every value has a single definition.
  • Static type discipline: every instruction has a well-defined result type, and instruction validity can be checked during construction.
  • Monomorphism: every instruction instance has a concrete output type.

Notably, some operations permit implicit type promotion (e.g. combining i32 and f64). However, the resulting type is still determined statically and recorded in the IR.

On construction, each function is traversed looking for function call instructions.
All function calls must point at a function that exists at a (strictly) previous
location in the list, and the type signature must be correct. If it is not, then
program construction fails. Functions are already checked for self-consistency during their construction.

As a result of the function call rule, we use the convention that the last function in
a program is its entry point; code after this is by construction dead code.
We also assign DataTree<TensorType> structures to both the input and output of the
entry function. These are zipped against the positional slots of the function's inputs
and ouputs in the DFS order defined by the data tree API. These data trees are for
the convenience of users who want to format the stucture of their data, or assign names
to them.

AI/LLM disclosure

  • No part of this submission is LLM generated.
  • Some written text was generated by:
  • Some submitted code was generated by: claude opus 5

Stack created with GitHub Stacks CLIGive Feedback 💬

@ihincks Ian Hincks (ihincks) added the mod: providers Related to the backend and job abstractions label Sep 3, 2026
@ihincks Ian Hincks (ihincks) added this to the 2.6.0 milestone Sep 3, 2026
@github-project-automation github-project-automation Bot moved this to Ready in Qiskit 2.6 Sep 3, 2026
@coveralls

Coveralls (coveralls) commented Sep 3, 2026

Copy link
Copy Markdown

Coverage Report for CI Build 34398812926

Coverage increased (+0.02%) to 88.045%

Details

  • Coverage increased (+0.02%) from the base build.
  • Patch coverage: 10 uncovered changes across 1 file (303 of 313 lines covered, 96.81%).
  • 10 coverage regressions across 2 files.

Uncovered Changes

File Changed Covered %
crates/providers/src/program/quantum_program.rs 293 283 96.59%
Total (2 files) 313 303 96.81%

Coverage Regressions

10 previously-covered lines in 2 files lost coverage.

File Lines Losing Coverage Coverage
crates/qasm2/src/lex.rs 8 91.52%
crates/circuit/src/parameter/symbol_expr.rs 2 81.74%

Coverage Stats

Coverage Status
Relevant Lines: 135090
Covered Lines: 118940
Line Coverage: 88.05%
Coverage Strength: 967488.84 hits per line

💛 - Coveralls

@ihincks
Ian Hincks (ihincks) marked this pull request as ready for review September 3, 2026 23:28
@ihincks
Ian Hincks (ihincks) requested a review from a team as a code owner September 3, 2026 23:28
@qiskit-bot

Copy link
Copy Markdown
Collaborator

One or more of the following people are relevant to this code:

  • @Qiskit/terra-core

A quantum program is a collection of program functions, the last of which is its
entry point, together with one input structure and one output structure. A
caller hands over a data tree of inputs arranged as the program declares and
receives a tree of outputs arranged the same way, so an answer arrives organised
the way it was asked for. Everything between those two boundaries stays
positional, since the structures are where all naming lives.

The structures describe the entry point, because the entry point is what a caller
invokes, so a program carries one pair and a function carries none. Assembling one
checks that there is a function to enter at — every accessor reads through the last
one — and then that each structure has as many leaves as the entry point has
parameter and result instructions. Correspondence between a structure's leaves and
a function's slots rests on order, and that leaf count is the only structural check
there is: nothing maps between the two, so whoever builds a program adds its
boundary instructions in the order its structures declare.

Evaluating checks the supplied arrangement against the declared one before
computing anything, and reports both structures whole, so that a caller sees the
arrangement that was wanted beside the one it supplied. Rendering a structure as a
skeleton, `[counts: [_, _], shots: _]`, is what makes that message legible.

The declared type of every input and output is available without evaluating,
arranged in the structure it belongs to, and `DataTree::dotted_paths` addresses
each output from the output structure. The structure is the thing worth keeping,
since a set of paths cannot reconstruct it: an empty branch contributes no leaves,
and so no path.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

mod: providers Related to the backend and job abstractions

Projects

Status: Ready

Development

Successfully merging this pull request may close these issues.

4 participants