Avoid 'Collection was modified' InvalidOperationException - #6935
Conversation
Fixes dotnet#6929 Ensure that we do not perform any state updates to the dataflow CoreAnalysisData inside the loop for the method `ClearOverlappingAnalysisDataForIndexedEntity`. We instead collect the key-value pairs to be updated in the loop, and perform these updates after the loop. I haven't been able to come up with a minimal repro case that reproduces this exception, but the loop for which exception was generated can no longer perform any state updates, so we can be quite certain the underlying exception can no longer be thrown.
carlossanlop
left a comment
There was a problem hiding this comment.
LGTM.
FYI we recently enabled the backporting bot for this repo: #6892 so that an 8.0 PR gets autocreated for you. You only need to write this comment in this PR:
/backport to release/8.0.1xx
|
/backport to release/8.0.1xx |
|
Started backporting to release/8.0.1xx: https://github.com/dotnet/roslyn-analyzers/actions/runs/6180952187 |
|
@mavasani an error occurred while backporting to release/8.0.1xx, please check the run log for details! Error: @mavasani is not a repo collaborator, backporting is not allowed. If you're a collaborator please make sure your dotnet team membership visibility is set to Public on https://github.com/orgs/dotnet/people?query=mavasani |
|
/backport to release/8.0.1xx |
|
Started backporting to release/8.0.1xx: https://github.com/dotnet/roslyn-analyzers/actions/runs/6180962334 |
FYI @Youssef1313 This is probably the reason why my PRs were getting marked with community label. I have made this fix now. We can probably close out #6372 |
Fixes #6929
Ensure that we do not perform any state updates to the dataflow CoreAnalysisData inside the loop for the method
ClearOverlappingAnalysisDataForIndexedEntity. We instead collect the key-value pairs to be updated in the loop, and perform these updates after the loop.I haven't been able to come up with a minimal repro case that reproduces this exception, but the loop for which exception was generated can no longer perform any state updates, so we can be quite certain the underlying exception can no longer be thrown.