Remove all references to dead vertices in ZX extraction #1690
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.
Description
During extraction, vertices are gradually removed from a ZX graph as we extract gates. Some additional tracking info is maintained via sets and maps of vertices. When vertices are removed, this shouldn't cause issues with looking up remaining vertices in these sets and maps.
HOWEVER, if needed it will perform an input extension which adds new vertices to the graph. Depending on how boost is feeling with memory management, it may reuse the memory locations of removed vertices for these new ones. Because the vertex descriptors are void* pointers under the hood, this clash of memory locations means we can get false positives when looking up vertices in the sets/maps.
#1566 and a related circuit found internally were shown to hit errors during extraction which at first seemed device-dependent, but was found to just be non-deterministic on any device. These were due to one of these false positive lookups which cause some vertices to be ignored when looking for a flow (hence the error message
Error during extraction from ZX diagram: diagram does not have gflow
).Given the bug only occurs with some probability (that may be device-dependent), the tests for this fix run the circuits a bunch of times to reduce the likelihood of a false positive for CI.
Related issues
Closes #1566
Checklist