chore(deps): update module github.com/hashicorp/hcl to v2 #139
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR contains the following updates:
v1.0.0
->v2.18.0
Release Notes
hashicorp/hcl (github.com/hashicorp/hcl)
v2.18.0
Compare Source
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
Compare Source
Enhancements
https://
at the start of a URL known to use that scheme. (#617)Bugs Fixed
any
keyword, avoiding an incorrect panic at runtime. (#625)v2.17.0
Compare Source
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.v2.16.2
Compare Source
Bugs Fixed
v2.16.1
Compare Source
Bugs Fixed
Range.End
forFunctionCall
with incomplete argument (#588)v2.16.0
Compare Source
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
formatSpaces
. (#511)v2.15.0
Compare Source
Bugs Fixed
Enhancements
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 specificcty.Type
. (#564)v2.14.1
Compare Source
Bugs Fixed
v2.14.0
Compare Source
Enhancements
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)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.13.0
Compare Source
Enhancements
hcl.Diagnostic
now has an additional fieldExtra
which is intended for carrying arbitrary supporting data ("extra information") related to the diagnostic message, intended to allow diagnostic renderers to optionally tailor the presentation of messages for particular situations. (#539)error
value without any post-processing. (#539)Bugs Fixed
hclwrite.Format
runs concurrently with itself. (#534)v2.12.0
Compare Source
Enhancements
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)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
v2.11.1
Compare Source
Bugs Fixed
v2.11.0
Compare Source
Enhancements
Bugs Fixed
v2.10.1
Compare Source
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
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
Compare Source
Enhancements
${
...}
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)v2.9.1
Compare Source
Bugs Fixed
v2.9.0
Compare Source
Enhancements
v2.8.2
Compare Source
Bugs Fixed
for
expression marked conditional. (#438)v2.8.1
Compare Source
Bugs Fixed
v2.8.0
Compare Source
Enhancements
Bugs Fixed
(
and)
tokens when an expression is surrounded by parentheses. Previously it would incorrectly recognize those tokens as being extraneous tokens outside of the expression. (#426)!
(unary boolean "not") operator and its subsequent operand. (#403)v2.7.2
Compare Source
Bugs Fixed
null[*]
was previously always returning an unknown value, even though the rules for[*]
normally call for it to return an empty tuple when applied to a null. As well as being a surprising result, it was particularly problematic because it violated the rule that a calling application may assume that an expression result will always be known unless the application itself introduces unknown values via the evaluation context.null[*]
will now produce an empty tuple. (#416)v2.7.1
Compare Source
Bugs Fixed
v2.7.0
Compare Source
Enhancements
ParseWithStartPos
, which allows overriding the starting position for parsing in case the given JSON bytes are a fragment of a larger document, such as might happen when decoding withencoding/json
into ajson.RawMessage
. (#389)ParseExpression
, which allows parsing a JSON string directly in expression mode, whereas previously it was only possible to parse a JSON string in body mode. (#381)Block
type now supportsSetType
andSetLabels
, allowing surgical changes to the type and labels of an existing block without having to reconstruct the entire block. (#340)Bugs Fixed
v2.6.0
Compare Source
Enhancements
Spec
,ValidateSpec
, which allows custom validation of values at decode-time. (#387)Bugs Fixed
v2.5.1
Compare Source
Bugs Fixed
foo.*
) (#374)v2.5.0
Compare Source
Enhancements
v2.4.0
Compare Source
Enhancements
Bugs Fixed
v2.3.0
Compare Source
Enhancements
try
andcan
to include in yourhcl.EvalContext
when evaluating expressions, which allow users to make decisions based on the success of expressions. (#330)convert
which you can include in yourhcl.EvalContext
when evaluating expressions, allowing users to convert values to specific type constraints using the type constraint expression syntax. (#330)cty
capsule typetypeexpr.TypeConstraintType
which, when used as either a type constraint for a function parameter or as a type constraint for ahcldec
attribute specification will cause the given expression to be interpreted as a type constraint expression rather than a value expression. (#330)hcldec
attribute specifications. (#330)cty
capsuletypescustomdecode.ExpressionType
andcustomdecode.ExpressionClosureType
which, when used as either a type constraint for a function parameter or as a type constraint for ahcldec
attribute specification will cause the given expression (and, for the closure type, also thehcl.EvalContext
it was evaluated in) to be captured for later analysis, rather than immediately evaluated. (#330)v2.2.0
Compare Source
Enhancements
AttrSpec
orBlockAttrsSpec
) now captures expression evaluation metadata in any errors it produces during type conversions, allowing for better feedback in calling applications that are able to make use of this metadata when printing diagnostic messages. (#329)Bugs Fixed
IndexExpr
,SplatExpr
, andRelativeTraversalExpr
will now report a source range that covers all of their child expression nodes. Previously they would report only the operator part, such as["foo"]
,[*]
, or.foo
, which was problematic for callers using source ranges for code analysis. (#328)v2.1.0
Compare Source
Enhancements
json.Unmarshal
in the Go standard library.Bugs Fixed
Body.Blocks
method was returing the blocks in an indefined order, rather than preserving the order of declaration in the source input. (#313)TokensForTraversal
function (and thus in turn theBody.SetAttributeTraversal
method) was not correctly handling index steps in traversals, and thus producing invalid results. (#319)v2.0.0
Compare Source
Initial release of HCL 2, which is a new implementating combining the HCL 1
language with the HIL expression language to produce a single language
supporting both nested configuration structures and arbitrary expressions.
HCL 2 has an entirely new Go library API and so is not a drop-in upgrade
relative to HCL 1. It's possible to import both versions of HCL into a single
program using Go's semantic import versioning mechanism:
Prior to v2.0.0 there was not a curated changelog. Consult the git history
from the latest v1.x.x tag for information on the changes to HCL 1.
Configuration
📅 Schedule: Branch creation - "before 4am on Monday" (UTC), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR has been generated by Renovate Bot.