swift
[move-only] Fix a thinko in FieldSensitivePrunedLiveBlocks::updateForUse
#66065
Merged
Merged
[move-only] Fix a thinko in FieldSensitivePrunedLiveBlocks::updateForUse #66065
gottesmm
merged
1 commit into
swiftlang:main
from
gottesmm:pr-415aafa0f5636321e5435cb5f9c8bb95a8138613
gottesmm2 years ago
@swift-ci smoke test
gottesmm2 years ago
@swift-ci smoke test
kavon
approved these changes
on 2023-05-22
Conversation is marked as resolved
[move-only] Fix a thinko in FieldSensitivePrunedLiveBlocks::updateFor…
5bef851d
gottesmm2 years ago
@swift-ci smoke test
Login to write a write a comment.
I think this was a mistake from when I changed implementations to use pure scalar bit processing rather than processing all at once. Instead of just updating the internal found resulting uses array, we were appending to it.
Some notes:
This actually did not break anything semantically in the move checker since we do not use this array in the caller in anyway. We just use it internally in the routine to first lookup the current state which we then process in the routine. That being said, this API is written such that a user /could/ do that and we want to allow for users to be able to do that so that we match what PrunedLiveness does.
This could cause memory corruption due to iterator invalidation if by appending we caused the SmallVector to reallocate as we iterated over the array.
So to fix this I did the following:
a. I changed the push_back to be an assignment.
b. I removed llvm::enumerate just out of paranoia if the assignment could
potentially cause iterator invalidation.
The given test exercises this code path and with the old behavior would crash with asan or guard malloc.
rdar://109673338