Handle missing HCL expression types in Terraform parsing#249
Conversation
…for-loops render correctly across Terraform parsing paths.
|
🎯 Code Coverage (details) 🔗 Commit SHA: 22e1478 | Docs | Datadog PR Page | Give us feedback! |
… and nested traversals are rendered instead of collapsing to \${...}.
robertohuertasm-datadog
left a comment
There was a problem hiding this comment.
The PR does address its stated goal. For the common case, this is an improvement:
"%{for v in var.list}${v}%{endfor}"One edge case to consider: the existing ForExpr renderer appears to mishandle list-style for-expressions with two loop variables:
[for k, v in var.map : k]KeyExpr is nil for this form because it is a list/tuple comprehension, not an object comprehension, but KeyVar is still populated (k). The current rendering branch only writes ValVar, so it can produce:
[for v in var.map : k]That bug mostly pre-existed for direct ForExpr rendering. This PR makes it more visible because %{for ...} template directives now route through the same ForExpr renderer, so this template case inherits the issue too:
"%{for k, v in var.map}${k}%{endfor}"Check engine.go:122 and inspector.go:1598.
Could we preserve KeyVar in the tuple/list branch when it is set, and add a regression test for both direct [for k, v in ...] and template %{for k, v in ...} forms?
In theory this should be a small fix:
b.WriteString("[for ")
if e.KeyVar != "" {
b.WriteString(e.KeyVar)
b.WriteString(", ")
}
b.WriteString(e.ValVar)
b.WriteString(" in ")
Motivation
Terraform HCL parsing still had gaps for a few expression node types that appear in real modules. When those nodes were hit, splat traversals could lose their trailing path, template
%{for}blocks could not be rendered, and some synthetic or invalid-expression placeholders fell through to generic unsupported handling.Changes
Splat traversals
Splat expressions with a trailing attribute or index were truncated because the anonymous splat item in the AST was not handled.
Template for-loops
%{for}/%{endfor}template directives produce aTemplateJoinExprin the AST. That shape was unsupported in some parsing paths.Remaining HCL expression types
AnonSymbolExpr(the synthetic item insidevar.list[*].id) andExprSyntaxError(placeholder for invalid or incomplete expressions) now have explicit handling in the shared HCL expression visitor instead of falling through to the default fallback.Author Checklist
QA Instruction
go test ./pkg/hclexpr/... ./pkg/engine ./pkg/builder/engine/... ./pkg/parser/terraform/...var.list[*].idand confirm the rendered path isvar.list[*].id, notvar.list[*].%{for v in var.list}${v}%{endfor}and confirm it renders as[for v in var.list : v].Blast Radius
Datadog IaC Scanner Terraform parsing only: HCL expression rendering in the inspector, engine string conversion, module resolver, and shared
hclexprdispatch.Additional Notes
N/A
I submit this contribution under the Apache-2.0 license.