Bump github.com/zclconf/go-cty from 1.8.3 to 1.13.2

[dependabot[bot]]

Bumps github.com/zclconf/go-cty from 1.8.3 to 1.13.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.

v1.9.1

No release notes provided.

Changelog

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

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

• Refinements: cty will can track a refined range for some unknown values and will take those into account when evaluating certain operations, thereby allowing a "more known" result than before. (#153)

• function/stdlib: The FormatDate and TimeAdd functions in previous releases were accidentally more liberal than intended in their interpretation of timestamp strings documented as requiring RFC3339. (#152)

  Those functions are now corrected to use a stricter RFC3339 parser, meaning that they will now reject some inputs that were previously accepted but were not valid per the RFC3339 syntax rules. The documentation for these functions already specified that RFC3339 syntax was required and so this is a fix to a defect rather than a breaking change, but calling applications which embed these functions may wish to pass on an upgrade note about this behavior difference in their own releaase notes after upgrading.

1.12.1 (November 8, 2022)

• convert: Will now produce correct type constraints when the input value is an empty collection and the target element type has optional attributes. In this case the conversion process must remove the optional attribute annotations because those are only for type conversion purposes and have no meaning when used in the type constraint for an empty collection. (#143)
• convert: Will now prefer to retain a concrete type in the input value when the input is either null or unknown and the target type is cty.DynamicPseudoType, which represents "any type". (#144)

1.12.0 (October 27, 2022)

• function: Each function can now have an English-language description summarizing its behavior. This is intended as a default string to use when an application wants to provide code hover tips or similar development aids. However, these descriptions are basic and only available in English, so applications may still prefer to provide their own descriptions and ignore those encoded in this module. (#137)

• convert: When running in "unsafe mode" (which allows additional conversions that can potentially fail with certain input values), we'll now allow converting from a map type to an object type with optional attributes as long as all of the present map elements are compatible with their corresponding optional attributes.

  It's still a dynamic error to convert a map whose element type is incompatible with any of the attributes that do have corresponding keys in the given map. (#139)

• convert: Will now produce correct type constraints when the input value is null and the target type has optional attributes. In this case the conversion process must remove the optional attribute annotations because those are only for type conversion purposes and have no meaning when used in the type constraint for a null or unknown value. (#140, #141)

1.11.1 (October 17, 2022)

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

1.11.0 (August 22, 2022)

Upgrade Notes

... (truncated)

Commits

• 1f21780 v1.13.2 release
• bf2d095 cty: Path.Apply should not panic with marked collections
• 2d47ad3 Prepare for possible future v1.13.2 release
• 180e0b5 Release v1.13.1
• e9ad14f function: Don't call function Impl if we didn't call Type
• 0401e09 Release v1.13.0
• 8ccd2dd build(deps): bump golang.org/x/text from 0.3.7 to 0.3.8
• 8d61143 Update CHANGELOG.md
• 2d9df4d Value Refinements
• 007cb63 docs: An explicit policy for what "backward compatible" means
• Additional commits viewable in compare view

You can trigger a rebase of this PR 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 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)

Note Automatic rebases have been disabled on this pull request as it has been open for over 30 days.

[suzuki-shunsuke]

@dependabot rebase

[dependabot[bot]]

Superseded by #112.