Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rename extension_reqs to runtime_reqs #1734

Closed
Tracked by #426
aborgna-q opened this issue Dec 2, 2024 · 0 comments · Fixed by #1776
Closed
Tracked by #426

Rename extension_reqs to runtime_reqs #1734

aborgna-q opened this issue Dec 2, 2024 · 0 comments · Fixed by #1776
Assignees

Comments

@aborgna-q
Copy link
Collaborator

aborgna-q commented Dec 2, 2024

Rename extension_reqs to runtime_reqs as this is a different measurement to static requirements (which extensions we need to have declarations of, i.e. type-checking info in the ExtensionRegistry)

@aborgna-q aborgna-q changed the title Rename extension_reqs to runtime_reqs as this is a different measurement to static requirements (which extensions we need to have declarations of, i.e. type-checking info in the ExtensionRegistry) Rename extension_reqs to runtime_reqs Dec 2, 2024
github-merge-queue bot pushed a commit that referenced this issue Dec 3, 2024
When we do a serialization roundtrip on a hugr, its custom optypes are
downgraded to `OpaqueOp`s and its `CustomType`s lose the weak link to
their extension.

This PR moves the pre-existing `OpaqueOp` resolution into a new
`crate::extension::resolution` module and expands it to also update the
custom type pointers. This can be run via the new
`Hugr::resolve_extension_defs` method (currently called by
`update_validate`).
In addition, we accumulate the exact list of extensions required to
define the hugr (this will be necessary for #1613).

Note that this will probably be no longer necessary after we stabilize
`hugr-model`, as we manually build the hugr when importing the model so
the extensions should already be present at that point.

In contrast to extension inference, this detects extensions needed to
_define_ a hugr (vs runtime requirements). The inference one will be
renamed as per #1734.

A big chunk of this PR is fixing tests that used `finish_prelude_hugr`
even though they required more extensions -.-'
Look at the first commit for the actual changes.

BREAKING CHANGE: Removed `resolve_opaque_op` and
`resolve_extension_ops`. Use `Hugr::resolve_extension_defs` instead.
@aborgna-q aborgna-q self-assigned this Dec 4, 2024
@aborgna-q aborgna-q added this to the hugr-rs 0.14 / hugr-py 0.10 milestone Dec 9, 2024
github-merge-queue bot pushed a commit that referenced this issue Dec 10, 2024
…1738)

Closes #1613. Depends on #1739.

Hugrs now keep an `Extensions` registry that is automatically computed
when using the builder or deserializing from json (using the new
`Hugr::load_json`).
This set can contain unneeded extensions, but it should always be
sufficient to validate the HUGR definition. Note that this is **not**
runtime extensions (see #426, #1734).

A big chunk of the diff is removing the extension registry when
finishing building a hugr. The extension tracking is now done
automatically while adding operations.

drive-by: Remove unneeded `set_num_ports` call in
`insert_hugr_internal`.

BREAKING CHANGE: Removed `update_validate`. The hugr extensions should
be resolved at load time, so we can use `validate` instead.
BREAKING CHANGE: The builder `finish_hugr` function family no longer
takes a registry as parameter, and the `_prelude` variants have been
removed.
@ss2165 ss2165 assigned ss2165 and unassigned aborgna-q Dec 12, 2024
github-merge-queue bot pushed a commit that referenced this issue Dec 12, 2024
Closes #1734
CustomConst::extension_reqs not renamed because they still refer to the
extensions where they are defined. this should be updated to references
to match ops and types #1775

BREAKING CHANGE: `extension_reqs` field in FunctionType and Extension
renamed to `runtime_reqs`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants