Skip to content

Add call nodes to QuantumFunction - #16931

Open
Ian Hincks (ihincks) wants to merge 1 commit into
ihincks/qp-06-quantum-programfrom
ihincks/qp-06a-call-nodes
Open

Add call nodes to QuantumFunction#16931
Ian Hincks (ihincks) wants to merge 1 commit into
ihincks/qp-06-quantum-programfrom
ihincks/qp-06a-call-nodes

Conversation

@ihincks

Copy link
Copy Markdown
Contributor

This PR adds the ability for a function to call another function by function ID.
See also #16922 and $16924.

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) requested a review from a team as a code owner September 3, 2026 22:13
@ihincks
Ian Hincks (ihincks) requested review from Raynel Sanchez (raynelfss) and removed request for a team September 3, 2026 22:13
@qiskit-bot

Copy link
Copy Markdown
Collaborator

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

  • @Qiskit/terra-core

1 similar comment
@qiskit-bot

Copy link
Copy Markdown
Collaborator

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

  • @Qiskit/terra-core

@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 34398812923

Warning

No base build found for commit 9a432c6 on ihincks/qp-06-quantum-program.
Coverage changes can't be calculated without a base build.
If a base build is processing, this comment will update automatically when it completes.

Coverage: 88.079%

Details

  • Patch coverage: 14 uncovered changes across 2 files (591 of 605 lines covered, 97.69%).

Uncovered Changes

File Changed Covered %
crates/providers/src/program/quantum_program.rs 352 344 97.73%
crates/providers/src/program/program_function.rs 210 204 97.14%
Total (4 files) 605 591 97.69%

Coverage Regressions

Requires a base build to compare against. How to fix this →


Coverage Stats

Coverage Status
Relevant Lines: 135657
Covered Lines: 119485
Line Coverage: 88.08%
Coverage Strength: 963686.37 hits per line

💛 - Coveralls

A call instruction names a function by `FunctionId` and computes nothing itself, so one
stored body serves however many sites invoke it. `InstructionRole::Call` is the fourth role,
and the only one besides the two boundary roles that carries no `ProgramOp`.

A call may only name a function defined before the one holding it. The call graph is
therefore acyclic structurally, with nothing to traverse, and a callee is in bounds without
a separate check. A function has no identifier until a program holds it, so `add_call` takes
the callee's signature from its caller and checks the operands against it, and
`QuantumProgram::new` verifies the recorded types against the function actually named.
Nothing about the callee is stored: a call instruction's operand types and its own result
types are the contract as it was checked. Every function the program holds is verified, not
only those the entry point reaches, so evaluation resolves a call with no error path of its
own. A function the entry point cannot reach is accepted, and removing one is a pass rather
than a validity rule.

Both checks compare a declared type against an offered one, which `TensorType::admits`
answers: it is `Tensor::matches` with a type in place of the tensor, so a bounded axis
admits any size within its bound. The per-axis rule the two share moves onto `Dim::admits`.
A result a call declares must admit what its callee produces, because the instructions
reading that result were type-checked against the declared type.

A call instruction reports no built-in implementation, so a function holding one is not
locally evaluable by itself, and the program-level question walks the reachable functions
instead. `QuantumProgram::eval` settles that for every reachable function before anything
runs, then resolves each call against the program's functions as it walks. A function
reached through a call reports its failure through `FunctionEvalError::CallFailed`, whose
chain leads from the entry point to the instruction that failed.
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