Releases: hashicorp/hcl
Releases Β· hashicorp/hcl
v2.16.1
v2.16.0
Enhancements
-
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. (#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. (#576)
-
hclsyntax: Simplify the AST for certain string expressions. (#584)
Bugs Fixed
- hclwrite: Fix data race in formatSpaces. (#511)
v2.15.0
Bugs Fixed
- ext/typeexpr: Skip null objects when applying defaults. This prevents crashes when null objects are creating inside collections, and stops incomplete objects being created with only optional attributes set. (#567)
- ext/typeexpr: Ensure default values do not have optional metadata attached. This prevents crashes when default values are inserted into concrete go-cty values that have also been stripped of their optional metadata. (#568)
Enhancements
- ext/typeexpr: With the go-cty upstream depenendency updated to v1.12.0, the
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) - ext/typeexpr: With the go-cty upstream depenendency updated to v1.12.0, users should now apply the go-cty convert functionality before setting defaults on a given
cty.Value
, rather than after, if they require a specificcty.Type
. (#564)
v2.14.1
v2.14.0
Enhancements
- ext/typeexpr: Added support for optional object attributes to
TypeConstraint
. Attributes can be wrapped in the specialoptional(β¦)
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) - ext/typeexpr: New function:
TypeConstraintWithDefaults
. In this mode, theoptional(β¦)
modifier accepts a second argument which can be used as the default value for omitted object attributes. The function returns both acty.Type
and associatedDefaults
, the latter of which has anApply
method to apply defaults to a given value. (#549)
v2.12.0
Enhancements
- hclsyntax: Evaluation of conditional expressions will now produce more precise error messages about inconsistencies between the types of the true and false result expressions, particularly in cases where both are of the same structural type kind but differ in their nested elements. (#530)
- hclsyntax: The lexer will no longer allocate a small object on the heap for each token. Instead, in that situation it will allocate only when needed to return a diagnostic message with source location information. (#490)
- hclwrite: New functions
TokensForTuple
,TokensForObject
, andTokensForFunctionCall
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) - json: New functions
IsJSONExpression
andIsJSONBody
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)
Bugs Fixed
- gohcl: Fix docs about supported types for blocks. (#507)
v2.11.1
v2.11.0
v2.11.0
Enhancements
- hclsyntax: Various error messages related to unexpectedly reaching end of file while parsing a delimited subtree will now return specialized messages describing the opening tokens as "unclosed", instead of returning a generic diagnostic that just happens to refer to the empty source range at the end of the file. This gives better feedback when error messages are being presented alongside a source code snippet, as is common in HCL-based applications, because it shows which innermost container the parser was working on when it encountered the error. (#492)
Bugs Fixed
- hclsyntax: Upgrading an unknown single value to a list using a splat expression must return unknown (#493)
v2.10.1
v2.10.1 (July 21, 2021)
- dynblock: Decode unknown dynamic blocks in order to obtain any diagnostics even though the decoded value is not used (#476)
- hclsyntax: Calling functions is now more robust in the face of an incorrectly-implemented function which returns a
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) - hclsyntax: Ensure marks on unknown values are maintained when processing string templates. (#478)
- hcl: Improved error messages for various common error situtions in
hcl.Index
andhcl.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)
v2.10.0
v2.10.0 (April 20, 2021)
Enhancements
- dynblock,hcldec: Using dynblock in conjunction with hcldec can now decode blocks with unknown dynamic for_each arguments as entirely unknown values (#461)
- hclsyntax: Some syntax errors during parsing of the inside of
${
...}
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)