8 Commits (c23a7fce4e0a4faebe8a4fe4ca2ad6e6eea68e40)

Author	SHA1	Message	Date
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