Commit Graph

12 Commits

Author SHA1 Message Date
Martin Atkins 4faac6ee43 core: Record move result information in the plan
Here we wire through the "move results" into the graph walk data
structures so that all of the the nodes which produce
plans.ResourceInstanceChange values can capture the "PrevRunAddr" for
each resource instance.

This doesn't actually quite work yet, because the logic in Context.Plan
isn't actually correct and so the updated state from
refactoring.ApplyMoves isn't actually visible as the "previous run state".
For that reason, the context test in this commit is currently skipped,
with the intent of re-enabling it once the updated state is properly
propagating into the plan graph walk and thus we can actually react to
the result of the move while choosing actions for those addresses.
2021-08-30 13:59:14 -07:00
James Bardin 30afb492ab fix ApplyMove test with nested modules working
The addrs package can now correctly handle the combinations of nested
module endpoints, which fixes these 2 tests.
2021-08-20 15:17:06 -04:00
James Bardin 553d6525d2 more move tests 2021-08-19 12:05:53 -04:00
James Bardin 493ec4e6c5 correct the direction and walk order of the graph 2021-08-10 10:12:39 -04:00
James Bardin 08edb02270 MoveStatement.Name()
makes the graph printable for debugging
2021-08-10 10:11:57 -04:00
James Bardin 789317dc05 additional test 2021-08-10 10:11:57 -04:00
James Bardin 6401022bc8 don't take the address of a range variable 2021-08-10 10:11:57 -04:00
James Bardin 09ab952683 fix ApplyMoves tests
Add empty result value, since ApplyMoves does not return nil.
Fix the desired addresses for moves.
2021-08-02 17:23:35 -04:00
Martin Atkins aa414f3ab3 refactoring: First round of ValidateMoves rules
This is a first pass at implementing refactoring.ValidateMoves, covering
the main validation rules.

This is not yet complete. A couple situations not yet covered are
represented by commented test cases in TestValidateMoves, although that
isn't necessarily comprehensive. We'll do a further pass of filling this
out with any other subtleties before we ship this feature.
2021-07-29 12:29:36 -07:00
Martin Atkins f76a3467dc core: Call into refactoring.ValidateMoves after creating a plan
As of this commit, refactoring.ValidateMoves doesn't actually do anything
yet (always returns nil) but the goal here is to wire in the set of all
declared instances so that refactoring.ValidateMoves will then have all
of the information it needs to encapsulate our validation rules.

The actual implementation of refactoring.ValidateMoves will follow in
subsequent commits.
2021-07-28 13:54:10 -07:00
Martin Atkins 3e5bfa7364 refactoring: Stubbing of the logic for handling moves
This is a whole lot of nothing right now, just stubbing out some control
flow that ultimately just leads to TODOs that cause it to do nothing at
all.

My intent here is to get this cross-cutting skeleton in place and thus
make it easier for us to collaborate on adding the meat to it, so that
it's more likely we can work on different parts separately and still get
a result that tessellates.
2021-07-14 17:37:48 -07:00
Martin Atkins 22eee529e3 addrs: MoveEndpointInModule
We previously built out addrs.UnifyMoveEndpoints with a different
implementation strategy in mind, but that design turns out to not be
viable because it forces us to move to AbsMoveable addresses too soon,
before we've done the analysis required to identify chained and nested
moves.

Instead, UnifyMoveEndpoints will return a new type MoveEndpointInModule
which conceptually represents a matching pattern which either matches or
doesn't match a particular AbsMoveable. It does this by just binding the
unified relative address from the MoveEndpoint to the module where it
was declared, and thus allows us to distinguish between the part of the
module path which applies to any instances of the given modules vs. the
user-specified part which must identify particular module instances.
2021-07-14 17:37:48 -07:00