Recognize expressions fully in JSON configs

[radeksimko]

Use-cases

Validity of References

When collecting reference addresses (traversals) throughout a module, we also collect "constraints" based on where these references appear. This allows us to tell the difference between a scope-only and a type-aware reference, i.e. depends_on = [aws_instance.example] and output "example" { value = aws_instance.example }.

This allows us to make accurate decisions about what is or isn't a valid reference in any particular context.

For example this means we can tell that this is not a valid reference:

variable "example" {
  type = list(string)
}

resource "aws_vpc" "example" {
  cidr_block = var.example
}

but this is

variable "example" {
  type = list(string)
}

resource "aws_vpc" "example" {
  cidr_block = one(var.example)
}

In JSON however expressions are not "walkable" in the same way as plain HCL expressions (hcl.Expression)
https://github.com/hashicorp/hcl/blob/e84201c45df4fce4e9dfaba9e8aaa8730d24dd25/json/structure.go#L23-L27

We therefore cannot tell where exactly does a reference appear in the expression (e.g. whether it's wrapped in a function call or any other expression). Therefore it is impossible to accurately evaluate valid references.

Addressable attributes of complex types

In both HCL and JSON configs there can be situations where values nested within complex expression types (such as object, list, set, or map) are addressable.

Fox example in HCL:

obj_attribute = {
  inner_attr = "foobar"
}

Here the foobar string is addressable as obj_attribute.inner_attr. It is possible to assign an address to that inner attribute because in HCL we can walk through the hclsyntax.Expression and detect *hclsyntax.TupleConsExpr. In JSON all expression types are unexported, so this is not possible.

So we cannot assign address to the same value in a comparable JSON config as shown below.

{
  "obj_attribute": {
    "inner_attr": "foobar"
  }
}

The example illustrates just object, but exact same problem applies also to all other complex types.

Attempted Solutions

We collect references in JSON without any constraints, which can overestimate the number of references to a particular block or attribute.

We also don't collect references to any data within attributes of complex types in JSON configs.

Proposal

TODO

[radeksimko]

We now collect targets and origins in JSON, as a result of various recent PRs (#1237, hashicorp/hcl-lang#232, hashicorp/hcl-lang#203, hashicorp/hcl-lang#199, hashicorp/hcl-lang#186, hashicorp/hcl-lang#185, hashicorp/hcl-lang#184) which are all part of the latest stable release v0.31.0.

We are also tracking a follow-up issue which concerns origin constraints in hashicorp/hcl-lang#269

Example UX Before

Example UX After

[github-actions]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.