Support operator expressions (+, -, !=, !...) and parentheses

[radeksimko]

Background

Terraform supports a number of operators, which can be combined with other expressions, for example:

• -42
• !var.bool
• 1 + 2 * 3
• (1 + 2) * 3
• var.number * 2

Language server currently doesn't support any of these operators, which in practice means that e.g.

• no completion is provided on either side of binary operator (e.g. before or after +), nor near unary operator (e.g. after !)
• no data is provided on hover over any expression on any side of an operator
• no expressions are highlighted as tokens when part of operator expression - e.g. var.bool is not reported as traversal if there is ! in the front

Proposal

Completion

TODO

• completion for number references and functions is provided on the RHS from -
• completion for bool references and functions is provided on the RHS from !

Hover

TODO

• hovering over negative number is equivalent to hover over a number
• hovering over negated bool is equivalent to hover over a bool

Semantic Tokens

TODO

• negative number is highlighted as number
• negated bool is highlighted as bool

[xiehan]

Need to research what happens if you e.g. try to + a string, and where that logic lives

[radeksimko]

There is a decent documentation in the form of code here: https://github.com/hashicorp/hcl/blob/31e2c60c39cb2464101d7ad49b9be15442785aa9/hclsyntax/expression_ops.go#L18-L121

[apparentlymart]

I think the discussion above is asking how the Terraform language treats addition of non-numeric types, which I can answer!

The direct answer to that question is: Terraform tries to convert both operands to numbers in the same way that the tonumber function would, and then if successful adds the results together. If unsuccessful, Terraform returns an error.

> "1" + "3"
4
> "1" + "elephant"
╷
│ Error: Invalid operand
│ 
│   on <console-input> line 1:
│   (source code not available)
│ 
│ Unsuitable value for right operand: a number is required.
╵

---

A more general answer:

In HCL, most of the operators are specified to take operands of a particular type only. (== and != are the only exceptions; they apply to all types.)

As a general rule, the operators will try to convert their operands to the prescribed type and then act on the result, just as we saw for numbers above.

For example, && expects boolean operands, and so it implicitly converts to boolean, like tobool, and returns an error only if the conversion fails.

> "true" && "true"
true
> "true" && "elephant"
╷
│ Error: Invalid operand
│ 
│   on <console-input> line 1:
│   (source code not available)
│ 
│ Unsuitable value for right operand: a bool is required.
╵

The operators are actually implemented as just function calls with a special syntax, so the automatic type conversion behavior is the same as for function calls where the underlying function has parameters with type constraints.

Those functions are not exposed as normal named functions so the built-in operators are the only way to access them, but their implementations are written using the same approach as for the more conventional functions accessible using the function call syntax. Because of that, it might be possible to reuse some existing logic for providing completion for function arguments, although of course only for semantics and not for syntax since the syntax is different.

The functions themselves actually belong to my underlying cty library rather than to HCL itself. The Impl field on each of the Operation objects in the code Radek linked to refers to the function underlying each of the supported operators. The mapping from the syntax to the Operation objects is not exported in the HCL API, but the objects themselves are exported so terraform-ls could in principle refer to them to avoid hard-coding anything except the syntax-level handling.

[radeksimko]

@apparentlymart Thanks, that is helpful, although in the context of LS we more often deal with situations where we either lack values or we just cannot or do not evaluate it (since we'd effectively have to re-implement pretty much the whole DAG inside LS, which is a problem of its own), so we are more often left with just types.

With that in mind, while we could be "smarter" and could avoid e.g. completing var.foo below, we may have to apply a more cautious approach and complete it.

variable "foo" {
  default = "not-a-number"
}
locals {
  baz = 42 + var. # HERE
}

This will be fine for smaller configurations but it will get less helpful with larger ones where the user will have to spend more time either typing or scrolling.

I am hopeful that we can at least start filtering the simplest of cases, e.g. variable defaults, which are resolvable without further context (i.e. without DAG) but I am not too optimistic about the other ones.

Either way I admit this (convertibility based on values) is not a new problem - we face it when filtering references and functions, whether or not operators are involved.

[radeksimko]

Support for unary and binary operators was added in hashicorp/hcl-lang#320 but parentheses (i.e. ParenthesesExpr) are yet to be implemented.

[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.