Generalize the idea of using [*] in traversals to describe "traversal patterns" - #6
Conversation
Our current hcl.AbsTraversalForExpr function and our planned future hcl.AbsTraversalPatternForExpr depend on the overall shape of AST that the parser produces for certain combinations of traversal and splat expressions, so this test is intended to ensure we preserve those AST shapes under future changes to the parser, and doubles as a set of examples for which AST shapes we're intending to support in this way. Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
|
The linting errors seem to be for code that predates this PR, and I don't intend to fix them because this set of commits is intended to exactly match what we initially submitted upstream. The copyright headers check is just completely broken at this point, but if it had run then it presumably would also have rejected the comments I had to include here to satisfy the latest version of copywrite running in the HCL repository and so I don't intend to do anything about that here either. We are planning to replace our use of copywrite across all repositories with a new solution, but it's debatable whether this repository in particular -- which aspires to match upstream HCL as closely as possible -- should be subjected to OpenTofu's copyright comments rules at all. |
The hclsyntax.ParseTraversalPartial function previously introduced the idea of using the splat expression syntax to represent a wildcard index, exploiting the accidentally-left-over hcl.TraverseSplat traverser type to represent the wildcard steps. But that idea wasn't previously generalized to work with expressions that appear as part of a configuration file or expression. This retroactively adopts the term "traversal pattern" to describe this special kind of hcl.Traversal that has at least one TraverseSplat step, renames the existing function to hclsyntax.ParseTraversalAbsPattern to reflect that new nomenclature, and then introduces hcl.AbsTraversalPatternForExpr as the corresponding companion to hcl.AbsTraversalForExpr, so that expression types can have their own rules for whether and how they can be interpreted as traversal patterns. This commit does not yet include any implementations of AsTraversalPattern. Those will follow in subsequent commits. Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
Previously there was no explicit representation of what kind of splat we had parsed and instead it was just implied by the shape of the AST, which varies due to attribute-only splat having different precedence relative to the index operator. Now we'll make that explicit as a new field. We're not using that field yet here, but a future commit will use it to support treating a splat expression as a "traversal pattern", but only when using the modern splat syntax because attribute-only splat's precedence isn't appropriate for being treated as a step in a traversal. Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
Implementing the AsTraversalPattern method makes SplatExpr eligible to be interpreted as a "traversal pattern" as long as everything nested inside it can be suitably flattened into a series of traversal steps. This must be AsTraversalPattern rather than just AsTraversal because this particular expression type causes hcl.TraverseSplat steps to be included, which makes the result a traversal pattern rather than a concrete traversal. The test added here is more general, also covering various expressions that don't include SplatExpr but are nonetheless eligible to be treated as traversal patterns. The ones without SplatExpr actually return concrete traversals rather than traversal patterns, but all concrete traversals can be used as patterns that match exactly one traversal. Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
This makes expressions from JSON source files be compatible with the recently-added hcl.AbsTraversalPatternForExpr, following the same principle as how we've previously been handling hcl.AbsTraversalForExpr: the JSON representation is a JSON string containing a traversal pattern in HCL native syntax. Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
This repository's checking tool is written under the assumption that only IBM contributes to this repository and so expects the copyright year associated with that company to be updated on every change. The changes that prompted this update (the previous five commits) are actually Copyright 2026 Spacelift, Inc, but contributed to HCL under the terms of the Mozilla public license. Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
30fb444 to
3c70b76
Compare
|
I'm going to merge this now so we can proceed with the work that depends on this, but with the caveat that if some details of this change during upstream review then we'll eventually be adopting the upstream version in this fork, even if that means we also have to change the OpenTofu code that calls it. |
This is a rebased version of hashicorp#805 targeting OpenTofu's local fork of HCL.
Right now our hope is that upstream will accept something like this, possibly with some changes based on feedback, and then we'd drop these commits from our fork and adapt OpenTofu's callers to expect the finalized API from upstream instead.
But we've not yet heard from upstream on whether they're interested in this new functionality, so it's also possible that these commits will become just another permanent part of OpenTofu's fork.