Handle move blocks within a module which is changing the index #30232
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.
When a move statement is only changing the index of a module, any moves within that module would result in cycles, because both the absolute
From
andTo
addresses would match both of the parent module'sFrom
andTo
address.For example, changing the index of a module named
count
results in a afrom->to
of:And changing the count of a resource nested within
module.count
results in:Because
module.count[*]
matches both theFrom
andTo
addresses of the parent, the edges would be added in both directions resulting in a cycle.The graph we actually want in this case looks like
with a connection only from the inner move to the outer move, which matches the same order of operations when the outer module is changing the name entirely. We achieve this by checking if the dependent move statement is only changing the module index with a new
from.MoveModuleReIndex(to)
method, and skip adding the graph edge.Fixes #30208
While not contributing to the cycle, it was noticed in #30208 that
impliedMoveStatements
was not correctly calling itself recursively, which is also fixed and tested by this PR.