reference: Update type matching to align w/ Terraform's

[radeksimko]

Terraform itself basically doesn't use cty's TestConformance, but instead uses the convert.Convert function. This makes the type comparison a lot more lenient, where it accepts basically any primitive type for any other. It does however reject mismatch between complex types.

Other products / language servers may benefit from the stricter comparison (as implemented by TestConformance) but we do not have enough data to understand this problem space and so we optimise for Terraform for now. This should not hurt other products unless they have a lot of references to filter. At worst they'll get more completion items and hover/semtokens for references which are not relevant, but should still get the ones which are relevant. They may also happen to implement type comparison same way as Terraform. 🤷🏻

Why now?

Because #232 is introducing support for functions and needs to decide how to compare constraints with return types, which is a similar problem to comparing references and so I believe the two places should agree on how to do this.

The alternative would be reusing the strict TestConformance there, which is what I first attempted, but it had some other odd edge cases, where cty.DynamicPseudoType [function return type] is considered mismatch for cty.String constraint.

Example

variable "test" {
  type    = string
  default = "42"
}

output "test" {
  value = abs(var.test)
}

^ this is valid configuration which produces 42 (number)

---

There is a wider conversation to have about promoting best practice by suppressing (but accepting) patterns which do not follow best practice. This could mean not providing completion for examples such as the one above, but providing hover, semantic tokens, go-to-* etc. This has two pre-requisites though:

• We'd have to use different matching logic for completion than for all other methods
• We should have other (more obvious and visible) ways to communicate this, rather than just suppressing completion items.
  • This could be addressed as part of decoder: Introduce ValidateFilePerSchema() #57 but we'll need to make sure we fully understand the impact of precise comparisons there and the edge cases (e.g. by running a lot of existing configuration through the validation logic).

[dbanck]

👍 LGTM, thanks for the in-depth explanation