Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reflect convertible types in type comparison #583

Closed
1 of 3 tasks
radeksimko opened this issue Jul 8, 2021 · 2 comments
Closed
1 of 3 tasks

Reflect convertible types in type comparison #583

radeksimko opened this issue Jul 8, 2021 · 2 comments

Comments

@radeksimko
Copy link
Member

radeksimko commented Jul 8, 2021

Use-cases

Whenever we semantically highlight type-aware reference addresses, we compare types strictly (minus unknown/dynamic type which is handled as edge case).

Some types are however convertible to another, e.g. bool/number is convertible to string, as per https://www.terraform.io/docs/language/expressions/types.html#type-conversion

This leads e.g. to the following (valid config):

Screenshot 2021-07-08 at 11 46 56

where var.test is not recognized as valid because access_token is expected to be string.

Proposal

hcl-lang

  • Reflect convertible types when completing within expressions (such as when function returns number and is enclosed by something that expects string, or when any string-convertible type is used in template expression)
  • Reflect convertible types when comparing origins and targets

Implementation Notes

The go-cty convert package contains the logic which is used by Terraform/HCL in this context:
https://pkg.go.dev/github.com/zclconf/[email protected]/cty/convert

@radeksimko
Copy link
Member Author

We now consider "convertability" when comparing constraints with reference targets and function return types, 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.

The above example now works, i.e. var.test is recognised even though it's number in string constrained attribute.

Screenshot 2023-04-25 at 16 42 41

Other future expressions will account for this individually when implemented, e.g. #529 will likely imply cty.Number constraint for either side of - or + and cty.Bool for ! etc. but in reality allow other primitive types in both cases, since they're convertible to that type.

Origin constraint type comparison is a question to follow-up on more generally as part of hashicorp/hcl-lang#269

@github-actions
Copy link

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.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators May 26, 2023
@xiehan xiehan removed this from the v0.35.0 (tentative) milestone Jul 25, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants