5 Commits (653a819cc3a2d2c7fb3f6a26b03f4e8a95e4d585)

Author	SHA1	Message	Date
Martin Atkins	39e609d5fd	vendor: switch to HCL 2.0 in the HCL repository ... Previously we were using the experimental HCL 2 repository, but now we'll shift over to the v2 import path within the main HCL repository as part of actually releasing HCL 2.0 as stable. This is a mechanical search/replace to the new import paths. It also switches to the v2.0.0 release of HCL, which includes some new code that Terraform didn't previously have but should not change any behavior that matters for Terraform's purposes. For the moment the experimental HCL2 repository is still an indirect dependency via terraform-config-inspect, so it remains in our go.sum and vendor directories for the moment. Because terraform-config-inspect uses a much smaller subset of the HCL2 functionality, this does still manage to prune the vendor directory a little. A subsequent release of terraform-config-inspect should allow us to completely remove that old repository in a future commit.	7 years ago
Martin Atkins	bb118c37a2	configs: Handle "dynamic" blocks as special during override merging ... Previously we were treating "dynamic" blocks in configuration the same as any other block type when merging config bodies, so that dynamic blocks in the override would override any dynamic blocks present in the base, without considering the dynamic block type. It's more useful and intuitive for us to treat dynamic blocks as if they are instances of their given block type for the purpose of overriding. That means a foo block can be overridden by a dynamic "foo" block and vice-versa, and dynamic blocks of different types do not interact at all during overriding. This requires us to recognize dynamic blocks and treat them specially during decoding of a merged body. We leave them unexpanded here because this package is not responsible for dynamic block expansion (that happens in the sibling "lang" package) but we do decode them enough to recognize their labels so we can treat them as if they were blocks of the labelled type.	7 years ago
Martin Atkins	5dd6b839d0	configs: Export MergeBodies and new SynthBody function ... We have a few special use-cases in Terraform where an object is constructed from a mixture of different sources, such as a configuration file, command line arguments, and environment variables. To represent this within the HCL model, we introduce a new "synthetic" HCL body type that just represents a map of values that are interpreted as attributes. We then export the previously-private MergeBodies function to allow the synthetic body to be used as an override for a "real" body, which then allows us to combine these various sources together while still retaining the proper source location information for each individual attribute. Since a synthetic body doesn't actually exist in configuration, it does not produce source locations that can be turned into source snippets but we can still use placeholder strings to help the user to understand which of the many different sources a particular value came from.	8 years ago
Martin Atkins	cc38e91612	configs: Implementation of mergeBody ... mergeBody is a hcl.Body implementation that deals with our override file merging behavior for the portions of the configuration that are not processed until full eval time. Mimicking the behavior of our old config merge implementation from the "config" package, the rules here are: - Attributes in the override body hide attributes of the same name in the base body. - Any block in the override body hides all blocks with the same type name that appear in the base body. This is tested by a new test for the overriding of module arguments, which asserts the correct behavior of the merged body as part of its work.	8 years ago
Martin Atkins	4e5efa498a	configs: Parser.LoadConfigDir ... This method wraps LoadConfigFile to load all of the .tf and .tf.json files in a given directory and then bundle them together into a Module object. This function also deals with the distinction between primary and override files, first appending together the primary files in lexicographic order by filename, and then merging in override files in the same order. The merging behavior is not fully implemented as of this commit, and so will be expanded in future commits.	8 years ago