19 Commits (5848d8a2b4e0c500c384bcbdcc84b5feec3f6549)

Author	SHA1	Message	Date
hashicorp-copywrite[bot]	53c34ff49c	Update copyright file headers to BUSL-1.1	3 years ago
hashicorp-copywrite[bot]	325d18262e	[COMPLIANCE] Add Copyright and License Headers	3 years ago
kmoe	56a1e0d1c6	allow cross-package move statements (#31556)	4 years ago
James Bardin	75ef61c783	check for nested module index changes ... Changing only the index on a nested module will cause all nested moves to create cycles, since their full addresses will match both the From and To addresses. When building the dependency graph, check if the parent is only changing the index of the containing module, and prevent the backwards edge for the move.	4 years ago
James Bardin	346418e31f	IsModuleMoveReIndex ... Add a method for checking if the From and To addresses in a move statement are only changing the indexes of modules relative to the statement module. This is needed because move statement nested within the module will be able to match against both the From and To addresses, causing cycles in the order of move operations.	4 years ago
Katy Moe	4305271cff	remove occurrences of AbsMovable	5 years ago
Martin Atkins	ef5a1c9cfe	refactoring: ImpliedMoveStatements function ... This new function complements the existing function FindMoveStatements by potentially generating additional "implied" move statements that aren't written explicit in the configuration but that we'll infer by comparing the configuration and te previous run state. The goal here is to infer only enough to replicate the effect of the "count boundary fixup" graph node (terraform.NodeCountBoundary) that we currently use to deal with this concern of preserving the zero-instance when switching between "count" and not "count". This is just dead code for now. A subsequent commit will introduce this into the "terraform" package while also removing terraform.NodeCountBoundary, thus achieving the same effect as before but in a way that'll get reported in the UI as a move, using the same language that we'd use for an explicit move statement.	5 years ago
Martin Atkins	7f99a8802e	addrs: MoveEndpointInModule.SelectsResource ... This is similar to the existing SelectsModule method, returning true if the reciever selects either a particular resource as a whole or any of the instances of that resource. We don't need this test in the normal case, but we will need it in a subsequent commit when we'll be possibly generating _implied_ move statements between instances of resources, but only if there aren't explicit move statements mentioning those resources already.	5 years ago
James Bardin	bc60f7aae4	Extend CanChainFrom to handle relative modules ... CanChainFrom needs to be able to handle move statements from different relative modules, re-implementing with addrs.anyKey Add the anyKey InstanceKey value to the addrs package to simplify module path comparison. This allows all combinations of module path representation to be normalized into a ModuleInstance which can be compared directly, rather than dealing with multiple levels of different prefix types.	5 years ago
James Bardin	2dff0481c8	missed relMatch for AbsModuleCall in SelectsModule	5 years ago
James Bardin	6087b1bdb9	CanChainFrom and NestedWithin ... Add implementations of CanChainFrom and NestedWithin for MoveEndpointInModule. CanChainFrom allows the linking of move statements of the same address, which means the prior destination address must equal the following source address. If the destination and source addresses are of different types, they must be covered by NestedWithin rather than CanChainFrom. NestedWithin checks if the destination contains the source address. Any matching types would be covered by CanChainFrom.	5 years ago
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.	5 years ago
Martin Atkins	5a6d11e375	addrs: Factor out MoveEndpointInModule module prefix matching ... All of our MoveDestination methods have the common problem of deciding whether the receiver is even potentially in the scope of a particular MoveEndpointInModule, which requires that the receiver belong to an instance of the module where the move statement was found. Previously we had this logic inline in all three cases, but now we'll factor it out into a shared helper function. At first it seemed like there ought to be more factoring possible for the AbsResource vs. AbsResourceInstance implementations, since textually they look very similar, but in practice they only look similar because those two types have a lot of method names in common, but the Go compiler sees them as completely distinct and thus we must write the same logic out twice. I did try some further refactoring to address that but it made the resulting code significantly more complicated and, by my judgement, harder to follow. Consequently I decided that a little duplication was okay and warranted here because this logic is already quite fiddly to read through and isn't likely to change significantly once released (due to backward-compatibility promises).	5 years ago
Martin Atkins	45d16b4a2b	addrs: MoveDestination for AbsResourceInstance-based move endpoints ... Previously our MoveDestination methods only honored move statements whose endpoints were module calls, module instances, or resources. Now we'll additionally handle when the endpoints are individual resource instances. This situation only applies to AbsResourceInstance.MoveDestination because no other objects can be contained inside of a resource instance. This completes all of the MoveDestination cases for all supported move statement types and moveable object types.	5 years ago
Martin Atkins	5e86bab159	addrs: MoveDestination for AbsResource-based move endpoints ... Previously our MoveDestination methods only honored move statements whose endpoints were module calls or module instances. Now we'll additionally handle when the endpoints are whole resource addresses. This includes both renaming resource blocks and moving resource blocks into or out of child modules. This doesn't yet include endpoints that are specific resource _instances_, which will follow in a subsequent commit. For the moment that situation will always indicate a non-match.	5 years ago
Martin Atkins	994ee23c06	addrs: Module move support for AbsResource and AbsResourceInstance ... This is a subset of the MoveDestination behavior for AbsResource and AbsResourceInstance which deals with source and destination addresses that refer to module calls or module instances. They both work by delegating to ModuleInstance.MoveDestination and then applying the same resource or resource instance address to the newly-chosen module instance address, thus ensuring that when we move a module we also move all of the resources inside that module in the same way. This doesn't yet include support for moving between specific resource or resource instance addresses; that'll follow later. This commit should have enough logic to support moving between module names and module instance keys, including any module calls or resources nested within.	5 years ago
Martin Atkins	4d733b4d2d	addrs: Implement ModuleInstance.MoveDestination ... This method encapsulates the move-processing rules for applying move statements to ModuleInstance addresses. It honors both module call moves and module instance moves by trying to find a subsequence of the input that matches the "from" endpoint and then, if found, replacing it with the "to" endpoint while preserving the prefix and suffix around the match, if any.	5 years ago
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.	5 years ago
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.	5 years ago