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.
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.
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.
It was unclear how nested object example in hcl would map to json.
README now updated to include an example of the son equivalent
to a hcl nested object.
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.
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 '/'.
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.
