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

Partial expression evaluation #339

Open
wata727 opened this issue Aug 3, 2024 · 0 comments
Open

Partial expression evaluation #339

wata727 opened this issue Aug 3, 2024 · 0 comments
Labels
enhancement New feature or request

Comments

@wata727
Copy link
Member

wata727 commented Aug 3, 2024

See also terraform-linters/tflint-ruleset-terraform#199

Sometimes a ruleset developer wants to walk every expression and evaluate it. This can be easily achieved using the WalkExpressions and EvaluateExpr APIs.

However, some expressions depend on the context around them, and this approach can cause errors when evaluated. Some examples that are currently known are:

  • for Expressions
    • Because a for expression has its own scope, the expression inside may not be uniquely determined unless the for expression is expanded. For example, it is not possible to evaluate only "value is ${x}" in for x in [1, 2]: "value is ${x}".
  • ignore_changes
    • The ignore_changes cannot be evaluated because it is a special reference that is different from other expressions. Something similar is the provider reference.

There are other expressions that are not statically determined, such as self references and count/each, but these are already treated as unknown by TFLint, so no error occurs. Only references that do not contain periods, such as x and tags (in other words, references that are not treated as valid by ReferencesInExpr), will cause an error.

The simplest solution would be to just treat any reference that does not contain a period as an unknown value, but this has the problem of being too permissive compared to the Terraform language evaluation system, since this is an expression that should result in an error in a typical expression evaluation context.

Anyway, somehow we eliminate these unevaluable expression patterns and make all partial expression evaluation possible.

@wata727 wata727 added the enhancement New feature or request label Aug 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Development

No branches or pull requests

1 participant