Previously we allowed adding both attributes and blocks, and we allowed
updating attributes, but we had no mechanism to surgically remove
attributes and blocks altogether.
In previous versions we had some bugs around template sequence escapes.
These tests show that they no longer seem to be present, and should
hopefully avoid them regressing in future.
Our error message for the ambiguous situation recommends doing this, but
the parser didn't actually previously allow it. Now we'll accept the form
that the error message recommends.
As before, we also accept a template with an interpolation sequence as
a disambiguation, but the error message doesn't mention that because it's
no longer idiomatic to use an inline string template containing just a
single interpolation sequence.
We remove properties whose values are null by default in order to produce
output that is more convenient to consume in the common case.
However, sometimes those nulls are significant, so we'll allow the user
to opt in to retaining them, at the expense of producing a result that is
more noisy if the spec contains lots of optional attributes that are not
set.
The separate "spectests" directory was an artifact of our former nesting
of the main package under a "hcl" directory. However, it was confusing
to have both specsuite and spectests directories at the top level, so
instead we'll just conflate these two by putting the automatic Go testing
helper into the specsuite directory.
These grammar files are not yet feature-complete and so we'll remove them
for now until such time that we're ready to support them.
The main blocker here is in lacking a good testing procedure for updates
to these. While in principle they can be loaded into a number of different
text editors, that is a very manual process that often requires a high
degree of familiarity with the extension API. In order to support these
properly we'd instead need some sort of automatic test suite which can
run various inputs through these rulesets and check that the resulting
tokenization.
This experimental extension is not ready to be included in a release. It
ought to be reworked so that "include" blocks get replaced with what they
include _in-place_, preserving the relative ordering of blocks.
However, there is no application making use of this yet and so we'll defer
that work until there's a real use-case to evaluate it with.
This package remains highly experimental, and so we'll remove it for now
and consider spinning it off into its own repository for further iteration
if the direction seems promising.
This is the first step in bringing HCL 2 into the main HCL repository.
Subsequent commits will prune and reorganize this in preparation for
an initial tagged HCL 2 release.
When I tried a spec with quoted types, I got this error:
`A type is required, not string.`
Later in the document, the types don’t have quotes, so I figured that’s what’s expected.
If an expression in a conditional contains a DynamicVal, we know that
the opposing condition can pass through with no conversion since
converting to a DynamicPseudoType is a noop. We can also just pass
through the Dynamic val, since it is unknown and can't be converted.
The type unification done when evaluating a conditional normally needs
to return a DynamicPseudoType when either condition is dynamic. However,
a null dynamic value represents a known value of the desired type rather
than an unknown type, and we can be certain that it is convertible to
the desired type during the final evaluation. Rather than unifying
types against nulls, directly assign the needed conversion when
evaluating the conditional.
A sequence like "foo" is represented in the AST as a TemplateExpr with a
single string literal inside rather than as a string literal node
directly, so we need to recognize that situation during parsing and treat
it as a special case so we can get the intended behavior of representing
that index as a traversal step rather than as a dynamic index operation.
Most of the time this distinction doesn't matter, but it's important for
static analysis use-cases. In particular, hcl.AbsTraversalForExpr will now
accept an expression like foo["bar"] where before it would've rejected it.
This also includes a better error message for when an expression cannot be
recognized as a single traversal. There isn't really any context here to
return a direct reference to the construct that was problematic, which is
what we'd ideally do, but at least this new message includes a summary
of what is allowed and some examples of things that are not allowed as an
aid to understanding what "static variable reference" means.
Fix a bug where diagnostics found when evaluating array individual
elements are ignored, resulting in suppressed errors.
Nomad observed this issue in https://github.com/hashicorp/nomad/issues/5694.
John Flores
Martin Atkins
Masayuki Morita
Boris Schrijver
Radek Simko
Kazuma Watanabe
Aaron Gallagher
nozaq
Antti Kupila
Buck Doyle
James Bardin
Mahmood Ali
Lang Martin