-
Notifications
You must be signed in to change notification settings - Fork 36
Optimizes how rehierarch_from_type_blocks is implemented. Fixes tests. #516
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
base: master
Are you sure you want to change the base?
Optimizes how rehierarch_from_type_blocks is implemented. Fixes tests. #516
Conversation
Codecov Report
@@ Coverage Diff @@
## master #516 +/- ##
===========================================
- Coverage 100.00% 99.70% -0.30%
===========================================
Files 59 57 -2
Lines 19874 19728 -146
===========================================
- Hits 19874 19669 -205
- Misses 0 59 +59
📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good; just one suggestion.
I now recall that the old behavior, keeping labels in their first-observed order but making them hierarchable (in the old sense) was a feature. I am not sure that global sorting is what we always want to do. Lets consider that before merging this change. Also: does this approach require labels per depth to be sortable? If the previous approach did not require labels to be sortable, we might prefer it. |
@flexatone I can't remember what we were doing with this PR. Did we come to any conclusions, namely, either merge, merge with changes, or abandon entirely? |
@chaburkland : As discussed above, I think retaining ordering in rehierarching is important. Does this retain order, or do a full lex sort on all depths? |
No description provided.