Releases: hashicorp/hcl
v2.22.0
v2.21.0
Enhancements
- Introduce
ParseTraversalPartial
, which allows traversals that include the splat ([*]
) index operator. (#673) - ext/dynblock: Now accepts marked values in
for_each
, and will transfer those marks (as much as technically possible) to values in the generated blocks. (#679)
Bugs Fixed
- Expression evaluation will no longer panic if the splat operator is applied to an unknown value that has cty marks. (#678)
v2.20.1
v2.20.0
What's Changed
- Namespaced functions by @jbardin in #639
- fix: fix NameRange for namespaced functions by @ansgarm in #651
- prefer iterator error over for_each by @DanielMSchmidt in #656
- Create an error type for unknown function diags by @jbardin in #657
- Typo fix in spec.md by @elliotbonneville in #652
- hclwrite: Fix formatting of namespaced functions by @radeksimko in #658
- Run unit tests on macOS by @radeksimko in #660
- Fix license headers by @radeksimko in #659
- Add make targets for common checks + fixes by @radeksimko in #661
- Use new make targets in CI by @radeksimko in #663
New Contributors
- @ansgarm made their first contribution in #651
- @DanielMSchmidt made their first contribution in #656
- @elliotbonneville made their first contribution in #652
Full Changelog: v2.19.1...v2.20.0
v2.19.1
v2.18.1
v2.18.0
Enhancements
-
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.
v2.17.1
Enhancements
- hclsyntax: When evaluating string templates that have a long known constant prefix, HCL will truncate the known prefix to avoid creating excessively-large refinements. String prefix refinements are intended primarily for relatively-short fixed prefixes, such as
https://
at the start of a URL known to use that scheme. (#617) - ext/tryfunc: The "try" and "can" functions now handle unknown values slightly more precisely, and so can return known values in more situations when given expressions referring to unknown symbols. (#622)
Bugs Fixed
- ext/typeexpr: Will no longer try to refine unknown values of unknown type when dealing with a user-specified type constraint containing the
any
keyword, avoiding an incorrect panic at runtime. (#625) - ext/typeexpr: Now correctly handles attempts to declare the same object type attribute multiple times by returning an error. Previously this could potentially panic by creating an incoherent internal state. (#624)
v2.17.0
Enhancements
-
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 usingcty.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. TheRawEquals
method is intended only for making exact value comparisons in test cases, so main application code should not use it; useEquals
instead for real logic, which will take refinements into account automatically.