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

Default graph builder nodes to open ext requirements, rather than empty #424

Closed
croyzor opened this issue Aug 21, 2023 · 0 comments · Fixed by #622
Closed

Default graph builder nodes to open ext requirements, rather than empty #424

croyzor opened this issue Aug 21, 2023 · 0 comments · Fixed by #622
Assignees

Comments

@croyzor
Copy link
Contributor

croyzor commented Aug 21, 2023

No description provided.

@croyzor croyzor changed the title Default graph builder nodes to open resources, rather than empty Default graph builder nodes to open ext requirements, rather than empty Aug 21, 2023
github-merge-queue bot pushed a commit that referenced this issue Aug 31, 2023
This does NOT resolve #424 (even just for DFGs) yet, but is a first step
towards doing so.
- In inference tests, when we want concrete resources we need to avoid
using builder methods.
- We should do inference on every kind of graph (instead of assuming
some kinds will be closed).
- Default _some_ DFG builder methods to instantiating nodes with open
resources (but not enough)
github-merge-queue bot pushed a commit that referenced this issue Sep 4, 2023
Another step towards #424 (but not all the way there yet)
@acl-cqc acl-cqc self-assigned this Oct 25, 2023
github-merge-queue bot pushed a commit that referenced this issue Oct 31, 2023
A lot of this is refactoring existing code that explicitly uses
`add_node_xxx(NodeType::open_extensions(...))` to `add_op_xxx(...)`, and
updating tests - in most cases just `validate` -> `update_validate`.

Algorithmically, there was only one change - in `infer.rs` - where
Functions, FuncDefs and Aliases are given the empty ExtensionSet if they
are open (otherwise these end up unsolved).

Also there are some gymnastics in a couple of the tests where we want
the correct error out of validation but can't do inference because the
Hugr is, well, invalid....so we use a couple of different techniques to
carry solutions from earlier, valid, Hugrs over to the invalid one.
 
closes #424
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