Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
build(deps): bump github.com/zclconf/go-cty from 1.13.2 to 1.15.1 in …
…/pkg (#1490) Bumps [github.com/zclconf/go-cty](https://github.com/zclconf/go-cty) from 1.13.2 to 1.15.1. <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/zclconf/go-cty/blob/main/CHANGELOG.md">github.com/zclconf/go-cty's changelog</a>.</em></p> <blockquote> <h1>1.15.1 (November 26, 2024)</h1> <ul> <li><code>function</code>: Function calls can now return more mark-related information when called with unknown values when neither <code>AllowMarks</code> nor <code>AllowUnknown</code> are set for a particular parameter. (<a href="https://redirect.github.com/zclconf/go-cty/pull/196">#196</a>)</li> </ul> <h1>1.15.0 (July 15, 2024)</h1> <ul> <li><code>function/stdlib</code>: The <code>element</code> function now accepts negative indices, extending the illusion of an infinitely-long list into the negative direction too.</li> <li><code>cty</code>: The various "transform" functions were previously incorrectly propagating marks from a parent object down to attribute values when calling the caller-provided transform functions. The marks will now no longer be propagated downwards, which is consistent with the treatment of collection and tuple elements. If your transform function needs to take into account context about marks of upstream containers then you can maintain a stack of active marks in your <code>Transformer</code> implementation, pushing in <code>Enter</code> and popping in <code>Exit</code>. (<a href="https://redirect.github.com/zclconf/go-cty/pull/185">#185</a>)</li> </ul> <h1>1.14.4 (March 20, 2024)</h1> <ul> <li><code>msgpack</code>: Now uses string encoding instead of float encoding for a whole number that is too large to fit in any of MessagePack's integer types.</li> <li><code>function/stdlib</code>: Type conversion functions (constructed with <code>MakeToFunc</code>) can now convert null values of unknown type into null values of the target type, rather than returning an unknown value in that case.</li> <li><code>json</code>: Will now correctly reject attempts to encode <code>cty.DynamicVal</code>, whereas before it would just produce an invalid JSON document without any error. (This is invalid because JSON encoding cannot support unknown values at all; <code>cty.DynamicVal</code> is a special case of unknown value where even the <em>type</em> isn't known.)</li> </ul> <h1>1.14.3 (February 29, 2024)</h1> <ul> <li><code>msgpack</code>: Fixed edge-case bug that could cause loss of floating point precision when round-tripping due to incorrectly using a MessagePack integer to represent a large non-integral number. <a href="https://redirect.github.com/zclconf/go-cty/pull/176">#176</a></li> <li><code>cty</code>: Fixed some false-negative numeric equality test results by comparing numbers as integers when possible. <a href="https://redirect.github.com/zclconf/go-cty/pull/176">#176</a></li> </ul> <h1>1.14.2 (January 23, 2024)</h1> <ul> <li><code>convert</code>: Converting from an unknown map value to an object type now correctly handles the situation where the map element type disagrees with an <em>optional</em> 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. (<a href="https://redirect.github.com/zclconf/go-cty/pull/175">#175</a>)</li> </ul> <h1>1.14.1 (October 5, 2023)</h1> <ul> <li> <p><code>cty</code>: It's now valid to use the <code>Refine</code> method on <code>cty.DynamicVal</code>, although all refinements will be silently discarded. This replaces the original behavior of panicking when trying to refine <code>cty.DynamicVal</code>.</p> </li> <li> <p><code>cty</code>: <code>Value.Range</code> 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 <code>ValueRange</code> functions are able to propagate marks into their return values, due to returning Go primitive types instead of new <code>cty.Value</code> results.</p> <p>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.</p> </li> </ul> <h1>1.14.0 (August 30, 2023)</h1> <p>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.</p> <p>If you use <code>cty</code> in an application that cares about consistent Unicode support, you should upgrade to Go 1.21 at the same time as updating to <code>cty</code> v1.14, because that will then also update the Unicode tables embedded in the Go standard library (used for case folding, etc).</p> <ul> <li><code>cty</code>: The <code>cty.String</code> type will now normalize incoming string values using the Unicode 15 normalization rules.</li> <li><code>function/stdlib</code>: 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.</li> </ul> <h1>1.13.3 (August 24, 2023)</h1> <ul> <li> <p><code>msgpack</code>: 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. (<a href="https://redirect.github.com/zclconf/go-cty/pull/167">#167</a>)</p> <p>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.</p> </li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/zclconf/go-cty/commit/3149f9d71235e7f745ab0a8429dba3c362408c06"><code>3149f9d</code></a> Prepare for v1.15.1 release</li> <li><a href="https://github.com/zclconf/go-cty/commit/63279be090d7ca5fd01e5ecb7f02ac5f0c273ef2"><code>63279be</code></a> Update CHANGELOG.md</li> <li><a href="https://github.com/zclconf/go-cty/commit/da16ad4791eda831a83c2f336863ba12fb8c264c"><code>da16ad4</code></a> function: include marks when returning early with an unknown value</li> <li><a href="https://github.com/zclconf/go-cty/commit/ea922e7a95ba2be57897697117f318670e066d22"><code>ea922e7</code></a> Add GitHub's "funding" metadata file</li> <li><a href="https://github.com/zclconf/go-cty/commit/7313684bb2bf6ec4a464f3def8d60c23bb51123a"><code>7313684</code></a> function/stdlib: Even more Distinct tests</li> <li><a href="https://github.com/zclconf/go-cty/commit/b84388474441497515a24c6e5e94b9d32673a59e"><code>b843884</code></a> function/stdlib: unit tests for Distinct function</li> <li><a href="https://github.com/zclconf/go-cty/commit/0b7ccb8423606ba894cc0e3b71375386e4d564de"><code>0b7ccb8</code></a> docs: fix little typo in value marks</li> <li><a href="https://github.com/zclconf/go-cty/commit/9a4ed1eca4e031e6fc36475d3f3cfb861c7be2d6"><code>9a4ed1e</code></a> Prepare for possible future v1.15.1 release</li> <li><a href="https://github.com/zclconf/go-cty/commit/d4f26339594ac24f77ff96b3f1eb0fc5f31c0a5a"><code>d4f2633</code></a> v1.15.0 release</li> <li><a href="https://github.com/zclconf/go-cty/commit/0cccfb9e9a8d1377cb50b6608f43d609376ccf80"><code>0cccfb9</code></a> Update CHANGELOG.md</li> <li>Additional commits viewable in <a href="https://github.com/zclconf/go-cty/compare/v1.13.2...v1.15.1">compare view</a></li> </ul> </details> <br /> [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) 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-automerge-start) [//]: # (dependabot-automerge-end) --- <details> <summary>Dependabot commands and options</summary> <br /> 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) </details> Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
- Loading branch information
1 parent
eb31dd9
commit b76c0d1