Bump github.com/zclconf/go-cty from 1.10.0 to 1.14.2

[dependabot]

Bumps github.com/zclconf/go-cty from 1.10.0 to 1.14.2.

Release notes

Sourced from github.com/zclconf/go-cty's releases.

v1.13.2

• cty: IndexStep.Apply will no longer panic if given a marked collection to traverse through. (#160).

v1.13.1

No release notes provided.

v1.13.0

No release notes provided.

v1.12.2

• cty: IndexStep.Apply will no longer panic if given a marked collection to traverse through. (#160).

v1.11.1

• convert: Fix for error when converting empty sets and lists with nested optional attributes by explicitly removing optional attribute information from collections.

Changelog

Sourced from github.com/zclconf/go-cty's changelog.

1.14.2 (January 23, 2024)

• convert: Converting from an unknown map value to an object type now correctly handles the situation where the map element type disagrees with an optional attribute of the target type, since when a map value is unknown we don't yet know which keys it has and thus cannot predict what subset of the elements will get converted as attributes in the resulting object. (#175)

1.14.1 (October 5, 2023)

• cty: It's now valid to use the Refine method on cty.DynamicVal, although all refinements will be silently discarded. This replaces the original behavior of panicking when trying to refine cty.DynamicVal.

• cty: Value.Range will now return a clearer panic message if called on a marked value. The "value range" concept is only applicable to unmarked values because not all of the ValueRange functions are able to propagate marks into their return values, due to returning Go primitive types instead of new cty.Value results.

  Callers that use marks must, as usual, take care to unmark them before exporting values into "normal" Go types, and then explicitly re-apply the marks to their result as appropriate. Applications that make no use of value marks, and library callers that exclude marked values from what they support, can safely ignore this requirement.

1.14.0 (August 30, 2023)

This release updates the supported version of Unicode from Unicode 13 to Unicode 15. This is a backwards-compatible change that means that cty supports normalization and segmentation of strings containing new Unicode characters. The algorithms for normalization and segmentation themselves are unchanged.

If you use cty in an application that cares about consistent Unicode support, you should upgrade to Go 1.21 at the same time as updating to cty v1.14, because that will then also update the Unicode tables embedded in the Go standard library (used for case folding, etc).

• cty: The cty.String type will now normalize incoming string values using the Unicode 15 normalization rules.
• function/stdlib: The various string functions which split strings into individual characters as part of their work will now use the Unicode 15 version of the text segmentation algorithm to do so.

1.13.3 (August 24, 2023)

• msgpack: As a compromise to avoid unbounded memory usage for a situation that some callers won't take advantage of anyway, the MessagePack decoder has a maximum length limit on encoded unknown value refinements. For consistency, the encoder will now truncate string prefix refinements if necessary to avoid making the encoded refinements too long. (#167)

  This is consistent with the documented conventions for serializing refinements -- that we can potentially lose detail through serialization -- but in this case we are still able to preserve shorter string prefixes, whereas other serializations tend to just discard refinement information altogether.

1.13.2 (May 22, 2023)

• cty: IndexStep.Apply will no longer panic if given a marked collection to traverse through. (#160).

1.13.1 (March 16, 2023)

• function: If a function parameter that doesn't declare AllowDynamicType: true recieves a cty.DynamicVal, the function system would previously just skip calling the function's Type callback and treat the result type as unknown. However, the Call method was then still calling a function's Impl callback anyway, which violated the usual contract that Type acts as a guard for Impl so Impl doesn't have to repeat type-checking already done in Type: it's only valid to call Impl if Type was previosly called and it succeeded.

  The function system will now skip calling Impl if it skips calling Type, immediately returning cty.DynamicVal in that case. Individual functions can opt out of this behavior by marking one or more of their parameters as AllowDynamicType: true and then handling that situation manually inside the Type and Impl callbacks.

  As a result of this problem, some of the function/stdlib functions were not correctly handling cty.DynamicVal arguments after being extended to support refinements in the v1.13.0 release, causing unexpected errors or panics when calling them. Those functions are fixed indirectly by this change, since their callbacks will no longer run at all in those cases, as was true before they were extended to support refinements.

1.13.0 (February 23, 2023)

Upgrade Notes

This release introduces a new concept called Refinements, which allow cty to constrain the range of an unknown value beyond just a type constraint and then make deductions about validity or result range based on those refinements.

These changes are consistent with the backward-compatibility policy but you may see some changed results in your unit tests of operations involving unknown values. If the new results don't seem like valid refinements of what was previously being returned in the v1.12 series, please open an issue to discuss that.

If the new results have a range that is a valid subset of the old results then that is expected behavior and you should update your tests as part of upgrading.

Other changes in this release

... (truncated)

Commits

• 5917c03 Prepare for v1.14.2 release.
• 72902f2 Update CHANGELOG.md
• 864b88d convert: prevent invalid types in dynamicReplace
• d279406 Prepare for a possible future v1.14.2 release
• 7152062 Release v1.14.1
• b868a8d cty: Silently ignore refinements of cty.DynamicVal
• ab81272 cty: Explicit panic when using Value.Range with marked value
• 3071166 Prepare for a possible future v1.14.1 release
• d0dc388 v1.14.0 release
• b22c792 Use Unicode 15 tables
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[dfroberg]

@dependabot rebase