feat: ReplaceTypes: recursively replace on types too #2442
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 Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #2442 +/- ##
==========================================
+ Coverage 83.41% 83.48% +0.06%
==========================================
Files 262 262
Lines 51176 51395 +219
Branches 46737 46956 +219
==========================================
+ Hits 42689 42907 +218
+ Misses 6109 6108 -1
- Partials 2378 2380 +2
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:
|
acl-cqc
force-pushed
the
acl/replace_recursive2
branch
from
58a05b1 to
1c9857f
Compare
acl-cqc
commented
Nov 5, 2025
| } | ||
|
|
||
| /// Options for how the replacement for an op is processed. | ||
| // TODO also need to apply to replacement consts: |
There was a problem hiding this comment.
Or do we, see description
acl-cqc
commented
Nov 6, 2025
| for region_root in regions { | ||
| for n in hugr.descendants(*region_root).collect::<Vec<_>>() { | ||
| changed |= self.change_node(hugr, n)?; | ||
| if n != hugr.entrypoint() && changed { |
There was a problem hiding this comment.
Note this is clearly wrong - it means linearization applies to the first node that changes and all nodes coming after that (!)
acl-cqc
commented
Nov 6, 2025
| for n in hugr.descendants(root).collect::<Vec<_>>() { | ||
| if self.change_node(hugr, n)? { | ||
| changed = true; | ||
| } else if !linearize_unchanged_ops { |
There was a problem hiding this comment.
This should fix the "bug" in the other comment but tests are now breaking!
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.
The goal here is to improve compositionality - if you configure ReplaceTypes to convert type A to type B, and also type B to type C, then if it sees an A it "should" produce a C. (This is not the case at present, you'll get a B.) Likewise for op-replacements containing ops that themselves would be replaced - so this is a step towards addressing #2668 (via the second route therein).
I'd kinda like to turn this option on by default, but that would be a behaviour-breaking change (very breaking if you e.g. replaced
boolbyEither<bool, Future>- thankfully we replacetket::boolwith...bool_tso that one would be ok - or an op with a DFG containing that op, say; such cases would infinite-loop). There are a couple of possible ways of doing this:replace_(parametrized_)type_recursive(likely 4 methods) as the new "Options-less" methods (i.e. which we consider the "default" methods)...that name's not good thoReplacementOptions::without_recursion()(whereReplacementOptions::default()includes recursion). But that's not really "on by default"....A second consideration is whether we should have methods for consts that take ReplacementOptions too. This is not strictly necessary: unlike replacing types/ops, the callback for replacing consts is given the
&ReplaceTypes(it has to, as the framework cannot see include CustomConsts, whereas it can for custom types or ops). So a const callback can call the ReplaceTypes again when it's done (if it's changed the outermost type constructor); but that seems a hard ask for callback authors to remember....Thoughts on both?