3 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
Radek Simko	5b9f2fafc8	Standardise directory name for test data	7 years ago
Martin Atkins	b0215fcd0f	config: HCL2 config loader ... This loader uses the HCL2 parser and decoder to process a config file, and then transforms the result into the same shape as would be produced by the HCL config loader. To avoid making changes to the existing config structures (which are depended on across much of the codebase) we first decode into a set of HCL2-tailored structs and then process them into the public-facing structs that a loader is expected to return. This is a compromise to keep the config package API broadly unchanged for now. Once we're ready to remove the old HCL loader (which implies that we're ready to support HCL2 natively elsewhere in the codebase) we will be able to simplify this quite considerably. Due to some mismatches of abstraction between HCL/HIL and HCL2, some shimming is required to get the required result.	9 years ago