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).
The way that the contents of an object (objectList()) was parsed before
was weirdly implicit in expecting RBRACE as the ending token. This makes
that expectation explicit, which fixes a parse error that could occur
with an object that ends in an empty assign to an RBRACE.
Before this, the parser would accept this as expected behavior because
the object "ended" since the unexpected token was an RBRACE.
The way the scanner works '/ foo' was actually valid comment syntax.
This obviously is not what we want. This modifies the scanner to verify
that '//' comments in fact have the second '/'.
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
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.