8 Commits (6440c839474f052d8997bb5cec19c2743e5108e6)

Author	SHA1	Message	Date
Alisdair McDiarmid	13ed5af5c8	configs: Deprecate nested redundant interpolations ... Previous deprecations only included direct assignment of template-only expressions to arguments. That is, this was not deprecated: locals { foo = ["${var.foo}"] } This commit uses hclsyntax.VisitAll to detect and show deprecations for all template-only expressions, no matter how deep they are in a given expression.	6 years ago
Martin Atkins	91752f02da	configs: Warn for deprecated interpolation and quoted type constraints ... Following on from de652e22a2, this introduces deprecation warnings for when an attribute value expression is a template with only a single interpolation sequence, and for variable type constraints given in quotes. As with the previous commit, we allowed these deprecated forms with no warning for a few releases after v0.12.0 to ensure that folks who need to write cross-compatible modules for a while during upgrading would be able to do so, but we're now marking these as explicitly deprecated to guide users towards the new idiomatic forms. The "terraform 0.12upgrade" tool would've already updated configurations to not hit these warnings for those who had pre-existing configurations written for Terraform 0.11. The main target audience for these warnings are newcomers to Terraform who are learning from existing examples already published in various spots on the wider internet that may be showing older Terraform syntax, since those folks will not be running their configurations through the upgrade tool. These warnings will hopefully guide them towards modern Terraform usage during their initial experimentation, and thus reduce the chances of inadvertently adopting the less-readable legacy usage patterns in greenfield projects.	7 years ago
Martin Atkins	79dc808614	configs: Emit warnings for deprecated quoted references/keywords ... Terraform 0.12.0 removed the need for putting references and keywords in quotes, but we disabled the deprecation warnings for the initial release in order to avoid creating noise for folks who were intentionally attempting to maintain modules that were cross-compatible with both Terraform 0.11 and Terraform 0.12. However, with Terraform 0.12 now more widely used, the lack of these warnings seems to be causing newcomers to copy the quoted versions from existing examples on the internet, which is perpetuating the old and confusing quoted form in newer configurations. In preparation for phasing out these deprecated forms altogether in a future major release, and for the shorter-term benefit of giving better feedback to newcomers when they are learning from outdated examples, we'll now re-enable those deprecation warnings, and be explicit that the old forms are intended for removal in a future release. In order to properly test this, we establish a new set of test configurations that explicitly mark which warnings they are expecting and verify that they do indeed produce those expected warnings. We also verify that the "success" tests do _not_ produce warnings, while removing the ones that were previously written to succeed but have their warnings ignored.	7 years ago
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	1f859ba8d4	configs: Handle object constructor keys when shimming traversals ... This is important in particular for shimming the "providers" map in module blocks: providers = { "aws" = "aws.foo" } We call this shim for both the key and the value here, and the value would previously have worked. However, the key is wrapped up by the parser in an ObjectConsKeyExpr container, which deals with the fact that in normal use an object constructor key that is just a bare identifier is actually interpreted as a string. We don't care about that interpretation for our shimming purposes, and so we can just unwrap it here.	8 years ago
Martin Atkins	c05a1050fc	configs: Disable deprecation warning for quoted keywords/references ... Although we do still consider these deprecated for 0.12, we'll defer actually generating warnings for them until a later minor release so that module authors can retain their quoted identifiers for a period after 0.12 release for backward-compatibility with Terraform 0.11.	8 years ago
Martin Atkins	4fa8c16ead	configs: support ignore_changes wildcards ... The initial pass of implementation here missed the special case where ignore_changes can, in the old parser, be set to ["*"] to ignore changes to all attributes. Since that syntax is awkward and non-obvious, our new decoder will instead expect ignore_changes = all, using HCL2's capability to interpret an expression as a literal keyword. For compatibility with old configurations we will still accept the ["*"] form but emit a deprecation warning to encourage moving to the new form.	8 years ago
Martin Atkins	36fb5b52e7	configs: quoted keywords/references are warnings, not errors ... In our new loader we are changing certain values in configuration to be naked keywords or references rather than quoted strings as before. Since many of these have been shown in books, tutorials, and our own documentation we will make the old forms generate deprecation warnings rather than errors so that newcomers starting from older documentation can be eased into the new syntax, rather than getting blocked. This will also avoid creating a hard compatibility wall for reusable modules that are already published, allowing them to still be used in spite of these warnings and then fixed when the maintainer is able.	8 years ago