There is precedent for allowing strings containing digits where numbers are expected,
and so this extends that to also allow for boolean values to be given as strings.
This applies only to callers going through the decoder API. Direct access via the AST
will reflect exactly what was given in the input configuration.
This was allowing very strange input to be allowed through to Terraform
since some encryped output will contain null characters (such as from
git crypt).
Fixes https://github.com/hashicorp/terraform/issues/8886
While parsing JSON, an empty list value would be assumed to be a
non-existent list of objects, and would be removed from the result. This
may have never been the correct behavior but always worked okay because
we previously didn't support lists as first class types.
With the support of lists, we need to actually return the empty list as
the type. If we return nothing, then projects like Terraform will think
that the value was never set, which is false.
A single json object with nested objects is flattened by the json parser
to a list of objects sharing the parent key. If we're decoding into
struct this was likely a mistake, and we need to re-expand the ast.
At some point we ignored the " in interpolations. We do this for HCL and
it is correct but this is invalid JSON syntax and for JSON we've always
had the stance that we have to escape them.
When decoding an object into a struct where the object structure doesn't
match the Go struct structure, the case tested here would panic. This
introduces additional checks to guard against the edge case being hit to
avoid the panic.
The specific checks being added are: if an item being decoded into a
struct is a literal type, the item to be decoded must be non-nil in
order to use it. This isn't super clear and to be honest I also don't
fully understand it but this fixes the problem without introducing any
more test failures and without significant code complexity.
This allows multiline strings to be parsed in order to make HIL
interpolations nicer in Terraform:
```
my_complex_thing = "${merge(var.list1,
var.list2,
var.list3)}"
```
a.k.a lists of maps
Implementation was pretty straightforward - I had to tweak the `needsComma`
handling since it was stuck inside literal parsing. It happens out front
now. I also promoted the `assign_deep.hcl` parser test to a decoder
test that passes, since it was testing for an error to occur but now it
works! :)
Additionally we make ObjectLists support being comma-delimited, which
enables maps to defined inline like `{one = 1, two = 2}`.
Refs https://github.com/hashicorp/terraform/issues/7142
When we switched to the current edition of the HCL parser, we
inadvertently broke some undocumented behavior where users could
successfully used escaped double quotes in a nested interpolation like
this:
foo = "${somefunc(\"somearg\")}"
The proper syntax here is:
foo = "${somefunc("somearg")}"
Because once you are inside the interpolation braces, the "quoting
context" is different.
At the time, while we didn't like the fact that the non-standard syntax
was in the wild, we didn't want to break BC, so we treated it as a bug
and fixed it in #62.
Now that we are at the moment of a major Terraform release, we can yank
the BC compatible behavior, which fixes a currently broken use case -
there is no way to express strings with double quotes in them from
inside interpolation braces.
foo = "${somefunc("\"inquotes\"")}"
After merge and a dep upgrade, this will take care of
https://github.com/hashicorp/terraform/issues/5550
Fixes https://github.com/hashicorp/terraform/issues/6359 and several
related issues by unescaping a double backslash within braces to a
single backslash.
This bumps into the bit of HIL that still hangs out in HCL - for values
that aren't interpolated, like Terraform's variable defaults - users
were unable to get a backslash to show up within `${}`.
That's because `${}` is handled specially to allow for, e.g., double
quotes inside of braces.
Here, we add `\\` as a special cased escape (along with `\"`) so users
can get backslashes in these scenarios by doubling them up.
This commit adds support for removing a hanging indent from HEREDOC
token contents if the marker is prefixed with <<-. For example, given
the HCL definition:
my_long_var_name = <<-EOF
{
"key": "value"
}
EOF
The value of the HEREDOC will be:
{
"key": "value"
}
This is useful for use cases where indentation or leading whitespace
is important.
The rule applied is that the prefix on the terminating marker will be
removed from each each line in the HEREDOC, providing all the lines have
that prefix (i.e. every line is at least as indented as the terminating
marker, and using the same mechanism of tabs vs spaces).
This PR adds support for the style of HEREDOC often used in Ruby which
allows the terminating marker to be indented if the HEREDOC is started
with the sequence "<<-" rather than the usual "<<". This allows users to
express documents with more natural indentation:
resource "template_file" "test" {
template = <<-HEREDOC
First Line
Second Line
HEREDOC
}
Note that this does not attempt to add any semantics around removing
hanging indent from the actual text of the document, so extra
indentation would still be present. We could make use of the canonical
style for HCL herre to remove the hanging indent in the style of Ruby
which would probably be more predictable for users.
This now gives an error instead of a panic when encountering
configuration such as described in hashicorp/terraform#5740:
```
resource "aws" "web" {
provider = "aws" {
region = "us-west-2"
}
}
```
We now return an error message - "hcl object keys must be a string"
instead of crashing.
Fixeshashicorp/terraform#5740.
Before the parser rewrite, HCL would silently convert `\"` within
interpolation braces to `"`.
After the conversion, this became a syntax error.
We've found several instances of Terraform configs in the wild using
this syntax. It results in a hard "syntax error" message during config
parsing. While avoiding the extra escape on double quotes within
interpolations is definitely preferred, the UX of the syntax error feels
harsh enough to be worth inserting this backwards compatibility for now,
leaving us the option of deprecating it with a warning down the line.
