feat!: Remove extension sets from hugr-core.
#2081
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #2081 +/- ##
==========================================
- Coverage 83.09% 83.05% -0.04%
==========================================
Files 219 219
Lines 41918 41112 -806
Branches 37993 37260 -733
==========================================
- Hits 34830 34146 -684
+ Misses 5278 5168 -110
+ Partials 1810 1798 -12
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
This PR contains breaking changes to the public Rust API. cargo-semver-checks summary |
`insert_hugr`, `insert_from_view`, and `insert_subgraph` were written before we made `Node` a type generic, and incorrectly assumed the return type maps were always `hugr::Node`s. The methods were either unusable or incorrect when using generic `HugrView`s source/targets with non-base node types. This PR fixes that, and additionally allows us us to have `SiblingSubgraph::extract_subgraph` work for generic `HugrViews`. BREAKING CHANGE: Added Node type parameters to extraction operations in `HugrMut`.
`HugrMutInternals` is part of the semi-private traits defined in `hugr-core`. While most things get re-exported in `hugr`, we `*Internal` traits require you to explicitly declare a dependency on the `-core` package (as we don't want most users to have to interact with them). For some reason there was a public re-export of the trait in a re-exported module, so it ended up appearing in `hugr` anyways. BREAKING CHANGE: Removed public re-export of `HugrMutInternals` from `hugr`.
#2027 ended up being breaking due to adding a new variant to an error enum missing the `non_exhaustive` marker. This (breaking) PR makes sure all error enums have the flag. BREAKING CHANGE: Marked all Error enums as `non_exhaustive`
* PartialValue now has a LoadedFunction variant, created by LoadFunction nodes (only, although other analyses are able to create PartialValues if they want) * This requires adding a type parameter to PartialValue for the type of Node, which gets everywhere :-(. * Use this to handle CallIndirects *with known targets* (it'll be a single known target or none at all) just like other Calls to the same function * deprecate (and ignore) `value_from_function` * Add a new trait `AsConcrete` for the result type of `PartialValue::try_into_concrete` and `PartialSum::try_into_sum` Note almost no change to constant folding (only to drop impl of `value_from_function`) BREAKING CHANGE: in dataflow framework, PartialValue now has additional variant; `try_into_concrete` requires the target type to implement AsConcrete.
Adds a generic node type to the `NodeHandle` type. This is a required change for #2029. drive-by: Implement the "Link the NodeHandles to the OpType" TODO
Closes #1595 BREAKING CHANGE: `values` field in `Extension` and `ExtensionValue` struct/class removed in rust and python. Use 0-input ops that return constant values.
CodSpeed Performance ReportMerging #2081 will improve performances by 20.17%Comparing Summary
Benchmarks breakdown
|
Currently We have several "passes": monomorphization, dead function removal, constant folding. Each has its own code to allow setting a validation level (before and after that pass). This PR adds the ability chain (sequence) passes;, and to add validation before+after any pass or sequence; and commons up validation code. The top-level `constant_fold_pass` (etc.) functions are left as wrappers that do a single pass with validation only in test. I've left ConstFoldPass as always including DCE, but an alternative could be to return a sequence of the two - ATM that means a tuple `(ConstFoldPass, DeadCodeElimPass)`. I also wondered about including a method `add_entry_point` in ComposablePass (e.g. for ConstFoldPass, that means `with_inputs` but no inputs, i.e. all Top). I feel this is not applicable to *all* passes, but near enough. This could be done in a later PR but `add_entry_point` would need a no-op default for that to be a non-breaking change. So if we wouldn't be happy with the no-op default then I could just add it here... Finally...docs are extremely minimal ATM (this is hugr-passes), I am hoping that most of this is reasonably obvious (it doesn't really do a lot!), but please flag anything you think is particularly in need of a doc comment! BREAKING CHANGE: quite a lot of calls to current pass routines will break, specific cases include (a) `with_validation_level` should be done by wrapping a ValidatingPass around the receiver; (b) XXXPass::run() requires `use ...ComposablePass` (however, such calls will cease to do any validation). closes #1832
…eady in the Hugr (#2094) There are two issues: * Errors. The previous NodeTemplates still always work, but the Call one can fail if the Hugr doesn't contain the target function node. ATM there is no channel for reporting that error so I've had to panic. Otherwise it's an even-more-breaking change to add an error type to `NodeTemplate::add()` and `NodeTemplate::add_hugr()`. Should we? (I note `HugrMut::connect` panics if the node isn't there, but could make the `NodeTemplate::add` builder method return a BuildError...and propagate that everywhere of course) * There's a big limitation in `linearize_array` that it'll break if the *element* says it should be copied/discarded via a NodeTemplate::Call, as `linearize_array` puts the elementwise copy/discard function into a *nested Hugr* (`Value::Function`) that won't contain the function. This could be fixed via lifting those to toplevel FuncDefns with name-mangling, but I'd rather leave that for #2086 .... BREAKING CHANGE: Add new variant NodeTemplate::Call; LinearizeError no longer derives Eq.
- Allows `HugrMut` to be implemented for `HugrView`s with arbitrary node types - Removes `HugrMutInternals::hugr_mut(&mut self) -> &mut Hugr`, it can be implemented for more complex types. This is required for #1926, but I haven't touched the read-only side yet. - Added a `Node` associated type to `Rewrite`. All existing rewrites only implement `Rewrite<Node = Node>` for now, expanding their type is left for a separate PR. drive-by: Fix a couple bugs in rewrite implementations that assumed that `SiblingMut` contained transitive children. BREAKING CHANGE: `HugrMut` is now implemented generically for any `HugrView::Node` type. BREAKING CHANGE: `SiblingMut` has a new type parameter for the wrapped hugr type.
zrho
force-pushed
the
zrho/ext-set-core
branch
2 times, most recently
from
1231e57 to
f16df5a
Compare
Re-created from #2113, targeting the release branch instead. BREAKING CHANGE: Downstream crates need to remove the model_unstable feature flag when referencing hugr or hugr-core. --------- Co-authored-by: Lukas Heidemann <[email protected]>
Closes #2077 BREAKING CHANGE: Removed `RootTagged` trait. Now `RootChecked` is a non-hugrview wrapper only used to verify inputs where appropriate.
This PR splits the `Rewrite` trait into two (three) traits: - a `VerifyPatch` trait that has the `fn verify` and `fn invalidation_set` functions - a `ApplyPatch` trait that has the `fn apply` function. This inherits `VerifyPatch` and is the "rewriting" trait that should be used in most scenarios. In addition, there is a third trait `ApplyPatchHugrMut` that can be implemented by any patches that can be applied to _any_ `HugrMut` (as opposed to a specific type `H`). This is strictly stronger than `ApplyPatch` and should be implemented instead of `ApplyPatch` where possible (see the docs of the traits). closes #588 closes #2052 BREAKING CHANGE: Replaced the `Rewrite` trait with `Patch`. `Rewrite::ApplyResult` is now `Patch::Outcome`. `Rewrite::verify` was split into a separate trait, and is now `PatchVerification::verify`. BREAKING CHANGE: Renamed `hugr.rewrite` module to `hugr.patch`. BREAKING CHANGE: Changed the type `OutlineCfg::ApplyResult` (now `OutlineCfg::Outcome`) from `(Node, Node)` to `[Node; 2]`. --------- Co-authored-by: Alan Lawrence <[email protected]> Co-authored-by: Alan Lawrence <[email protected]>
Bumps the minimum supported rust version to 1.85, ~and migrates to the 2024 edition~. Most of the changes here are automated. The diff is quite noisy due to some changes in formatting, and me using this opportunity to auto--fix some optional clippy lints. It may be easier to check the changes per-commit. EDIT: Edition change has been left for a separate PR, as it's quite noisy. BREAKING CHANGE: Bumped MSRV to 1.85
Moves some methods around in `HugrInternals` / `HugrView` that we'll require for #1926 and #2029. Notable changes: - Adds a `hierarchy` method to `HugrInternals` that replaces most calls to `base_hugr`. - `HugrInternals::base_hugr` is now deprecated. It's only used by `Sibling/DescendantGraph`, `validate` and a random use in `DeadCodeElimPass`. - Adds a `HugrInternals::region_portgraph` method that returns a `FlatRegion` portgraph wrapper, and a `HugrView::descendants` call. These lets us replace most uses of `SiblingGraph` and `DescendantGraph`. - Renamed `HugrInternals::{get_pg_index,get_node}` to `to_portgraph_node` and `from_portgraph_node`. This requires some new changes in `portgraph`. I'll make a minor release and update it here before merging. We should be able to remove `base_hugr` after #2029. The deprecation warning here is only temporary. BREAKING CHANGE: Modified multiple core `HugrView` and `HugrInternals` trait methods. See #2126.
Oupsie, during one of the merge conflict resolutions I must have forgotten to remove the old `rewrite.rs` file. As you can see in the `hugr-core/src/hugr.rs` file, this is no longer a module and thus the file should be deleted. It has been renamed to `patch.rs` in #2070
Closed
croyzor
reviewed
Apr 30, 2025
croyzor
requested changes
Apr 30, 2025
|
This PR contains a breaking change and is targeting the Breaking changes are currently not allowed to be merged into Please update your PR to target the appropriate branch. |
|
Closed in favour of #2145, retargeting to the release branch. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR removes (runtime) extension sets from
hugr-coreandhugr-py(see #1906).BREAKING CHANGE: Functions that manipulate runtime extension sets have been removed from the Rust and Python code. Extension set parameters were removed from operations.
Closes #1906