Bot releases are hidden (Show)
Published by liamcervante 4 months ago
ParseTraversalPartial
, which allows traversals that include the splat ([*]
) index operator. (#673)for_each
, and will transfer those marks (as much as technically possible) to values in the generated blocks. (#679)Published by jbardin 8 months ago
Full Changelog: https://github.com/hashicorp/hcl/compare/v2.19.1...v2.20.0
Published by jbardin almost 1 year ago
Full Changelog: https://github.com/hashicorp/hcl/compare/v2.19.0...v2.19.1
Published by apparentlymart about 1 year ago
HCL now uses the tables from Unicode 15 when performing string normalization and character segmentation. HCL was previously using the Unicode 13 tables.
For calling applications where consistent Unicode support is important, consider also upgrading to Go 1.21 at the same time as adopting HCL v2.18.0 so that the standard library unicode tables (used for case folding, etc) will also be from Unicode 15.
Published by apparentlymart about 1 year ago
https://
at the start of a URL known to use that scheme. (#617)any
keyword, avoiding an incorrect panic at runtime. (#625)HCL now uses a newer version of the upstream cty
library which has improved treatment of unknown values: it can now track additional optional information that reduces the range of an unknown value, which allows some operations against unknown values to return known or partially-known results. (#590)
Note: This change effectively passes on cty
's notion of backward compatibility whereby unknown values can become "more known" in later releases. In particular, if your caller is using cty.Value.RawEquals
in its tests against the results of operations with unknown values then you may see those tests begin failing after upgrading, due to the values now being more "refined".
If so, you should review the refinements with consideration to the cty
refinements docs and update your expected results to match only if the reported refinements seem correct for the given situation. The RawEquals
method is intended only for making exact value comparisons in test cases, so main application code should not use it; use Equals
instead for real logic, which will take refinements into account automatically.
Published by alisdair over 1 year ago
ext/typeexpr: Modify the Defaults functionality to implement additional flexibility. HCL will now upcast lists and sets into tuples, and maps into objects, when applying default values if the applied defaults cause the elements within a target collection to have differing types. Previously, this would have resulted in a panic, now HCL will return a modified overall type. (https://github.com/hashicorp/hcl/pull/574)
Users should return to the advice provided by v2.14.0, and apply the go-cty convert functionality after setting defaults on a given cty.Value, rather than before.
hclfmt: Avoid rewriting unchanged files. (https://github.com/hashicorp/hcl/pull/576)
hclsyntax: Simplify the AST for certain string expressions. (https://github.com/hashicorp/hcl/pull/584)
Published by liamcervante almost 2 years ago
Defaults
struct and associated functions can apply additional and more flexible 'unsafe' conversions (examples include tuples into collections such as lists and sets, and additional safety around null and dynamic values). (#564)cty.Value
, rather than after, if they require a specific cty.Type
. (#564)Published by alisdair about 2 years ago
TypeConstraint
. Attributes can be wrapped in the special optional(…)
modifier, allowing the attribute to be omitted while still meeting the type constraint. For more information, cty's documentation on conversion between object types. (#549)TypeConstraintWithDefaults
. In this mode, the optional(…)
modifier accepts a second argument which can be used as the default value for omitted object attributes. The function returns both a cty.Type
and associated Defaults
, the latter of which has an Apply
method to apply defaults to a given value. (#549)Published by apparentlymart over 2 years ago
TokensForTuple
, TokensForObject
, and TokensForFunctionCall
allow for more easily constructing the three constructs which are supported for static analysis and which HCL-based languages typically use in contexts where an expression is used only for its syntax, and not evaluated to produce a real value. For example, these new functions together are sufficient to construct all valid type constraint expressions from the Type Expressions Extension, which is the basis of variable type constraints in the Terraform language at the time of writing. (#502)IsJSONExpression
and IsJSONBody
to determine if a given expression or body was created by the JSON syntax parser. In normal situations it's better not to worry about what syntax a particular expression/body originated in, but this can be useful in some trickier cases where an application needs to shim for backwards-compatibility or for static analysis that needs to have special handling of the JSON syntax's embedded expression/template conventions. (#524)Published by jbardin almost 3 years ago
Published by jbardin about 3 years ago
function.ArgError
whose argument index is out of range for the length of the arguments. Previously this would often lead to a panic, but now it'll return a less-precice error message instead. Functions that return out-of-bounds argument indices still ought to be fixed so that the resulting error diagnostics can be as precise as possible. (#472)hcl.Index
and hcl.GetAttr
. These are part of the implementation of indexing and attribute lookup in the native syntax expression language too, so the new error messages will apply to problems using those operators. (#474)Published by jbardin over 3 years ago
${
... }
template interpolation sequences will now produce an extra hint message about the need to escape as $${
when trying to include interpolation syntax for other languages like shell scripting, AWS IAM policies, etc. (#462)