Distinguish identity views from single-target views (backport #4186) #4189
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 is a minor overhaul of DataViews internals that make the various use cases of what were previously referred to as "1-1 views" more clear. This incidentally fixes an issue with bulk connections and views.
While for users this is just a bug fix, this has larger implications for developers. This replaces
reifySingleData
with two more precise functions:reifyIdentityView
- Fast, used for things like Probe legality (which by having pointer semantics, only really works with identity views).reifySingleTarget
- Slow, used for legacy annotation support which was, and remains, iffy for views.A subtle but critical aspect of this PR is that
reifyIdentityView
works in cases when thereifySingleData
did not. It is properly hierarchical: e.g. if you have an Aggregate that is a child of a non-identity view parent yet the child itself is an identity view, it will return the target for that child. This is critical for use cases like FlatIO where the parent Bundle isn't an identity but every single child is.One negative of this PR is that it makes the awkward "unnamed rename map" logic slower. I benchmarked this on a large design (that uses lots of views) and it's such a small piece of the overall runtime that it's okay (~1%). Regardless that logic is ludicrously slow and is a complete waste. I am thinking about ways to get rid of it but this PR has scope creeped enough. I think we just have to change the annotation API so it's really about coming up with the best way to do it.
This PR actually fixes several bugs, I will file them separately as they illustrate all of the weird corner cases this PR cleans up.
Contributor Checklist
docs/src
?Type of Improvement
Desired Merge Strategy
Release Notes
Fixes #4185, Fixes #4187
Reviewer Checklist (only modified by reviewer)
3.6.x
,5.x
, or6.x
depending on impact, API modification or big change:7.0
)?Enable auto-merge (squash)
, clean up the commit message, and label withPlease Merge
.Create a merge commit
.This is an automatic backport of pull request #4186 done by [Mergify](https://mergify.com).