7 Commits (c23a7fce4e0a4faebe8a4fe4ca2ad6e6eea68e40)

Author	SHA1	Message	Date
Martin Atkins	ae2c93f255	addrs: All AbsMovable implementations implement UniqueKeyer	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
Martin Atkins	f3a57db293	addrs: UniqueKey and UniqueKeyer ... Many times now we've seen situations where we need to use addresses as map keys, but not all of our address types are comparable and thus we tend to end up using string representations as keys instead. That's problematic because conversion to string uses type information and some of the address types have string representations that are ambiguous with one another. UniqueKey therefore represents an opaque key that is unique for each functionally-distinct address across all types that implement UniqueKeyer. For this initial commit I've implemented UniqueKeyer only for the Referenceable family of types. These are an easy case because they were all already comparable (intentionally) anyway. Later commits can implement UniqueKeyer for other types that are not naturally comparable, such as any which include a ModuleInstance. This also includes a new type addrs.Set which wraps a map as a set of addresses, using the unique keys to ensure that there can be only one element for each distinct address.	5 years ago
Martin Atkins	4cbe6cabfc	addrs: AbsMoveable, ConfigMoveable, and MoveableEndpoint ... These three types represent the three different address representations we need to represent different stages of analysis for "moved" blocks in the configuration. The goal here is to encapsulate all of the static address wrangling inside these types so that users of these types elsewhere would have to work pretty hard to use them incorrectly. In particular, the MovableEndpoint type intentionally fully encapsulates the weird relative addresses we use in configuration so that code elsewhere in Terraform can never end up holding an address of a type that suggests absolute when it's actually relative. That situation only occurs in the internals of MoveableEndpoint where we use not-really-absolute AbsMoveable address types to represent the not-yet-resolved relative addresses. This only takes care of the static address wrangling. There's lots of other rules for what makes a "moved" block valid which will need to be checked elsewhere because they require more context than just the content of the address itself.	5 years ago
Martin Atkins	3212f6f367	addrs: AbsModuleCall type ... Our documentation for ModuleCall originally asserted that we didn't need AbsModuleCall because ModuleInstance captured the same information, but when we added count and for_each for modules we introduced ModuleCallInstance to represent a reference to an instance of a local module call, and now _that_ is the type whose absolute equivalent is ModuleInstance. We previously had no absolute representation of the call itself, without any particular instance. That's what AbsModuleCall now represents, allowing us to be explicit about when we're talking about the module block vs. instances it declares, which is the same distinction represented by AbsResource vs. AbsResourceInstance. Just like with AbsResource and AbsResourceInstance though, there is syntactic ambiguity between a no-key call instance and a whole module call, and so some codepaths might accept both to start and then use other context to dynamically choose a particular interpretation, in which case this distinction becomes meaningful in representing the result of that decision.	5 years ago
Martin Atkins	ab350289ab	addrs: Rename AbsModuleCallOutput to ModuleCallInstanceOutput ... The previous name didn't fit with the naming scheme for addrs types: The "Abs" prefix typically means that it's an addrs.ModuleInstance combined with whatever type name appears after "Abs", but this is instead a ModuleCallOutput combined with an InstanceKey, albeit structured the other way around for convenience, and so the expected name for this would be the suffix "Instance". We don't have an "Abs" type corresponding with this one because it would represent no additional information than AbsOutputValue.	5 years ago
Martin Atkins	b9a93a0fe7	Move addrs/ to internal/addrs/ ... This is part of a general effort to move all of Terraform's non-library package surface under internal in order to reinforce that these are for internal use within Terraform only. If you were previously importing packages under this prefix into an external codebase, you could pin to an earlier release tag as an interim solution until you've make a plan to achieve the same functionality some other way.	5 years ago