[frozen-multimap] Add support for erasing once we have finished constructing the map. #31378
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
…ructing the map. I implemented this in a similar way to the way blotting is implemented in a blot map vector: 1. I changed this to store (Key, Optional<Value>) pairs. 2. I made it so that once frozen, we can "erase" things from the multimap by setting all Optional<Value> to none. 3. I changed the range we vend to be an OptionalTransformRange instead of just a TransformRange so we skip all keys with .none values, meaning that a user will get the nice behavior that getRange() still works after erasing. One interesting thing to note is that one /cannot/ erase elements when initializing the frozen multi-map since we haven't sorted it yet. At first this seems weird, but it actually fits with the use case of this data structure: building up state by processing IR in a readonly way and then later working with it in a worklist like way (and perhaps checking for unhandled cases at the end of processing). The nice thing additional thing is that I was able to ensure that the actual exposed API did not change in terms of how one uses it. I just changed the underlying iterators/etc.
|
@swift-ci test |
|
@swift-ci asan test |
|
Build failed |
|
@swift-ci smoke test OS X platform |
|
The OS X failure was one of the spurious: 17:22:20 lldb-api :: lang/swift/unknown_self/TestSwiftUnknownSelf.py that we have been seeing recently. It isn't from this commit. |
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.
I implemented this in a similar way to the way blotting is implemented in a blot
map vector:
I changed this to store (Key, Optional) pairs.
I made it so that once frozen, we can "erase" things from the multimap by
setting all Optional to none.
I changed the range we vend to be an OptionalTransformRange instead of just a
TransformRange so we skip all keys with .none values, meaning that a user will
get the nice behavior that getRange() still works after erasing.
One interesting thing to note is that one /cannot/ erase elements when
initializing the frozen multi-map since we haven't sorted it yet. At first this
seems weird, but it actually fits with the use case of this data structure:
building up state by processing IR in a readonly way and then later working with
it in a worklist like way (and perhaps checking for unhandled cases at the end
of processing).
The nice thing additional thing is that I was able to ensure that the actual
exposed API did not change in terms of how one uses it. I just changed the
underlying iterators/etc.
I tested my tests locally with ASAN, but I am going to do an additional ASAN test as well just to be careful.