Bump github.com/zclconf/go-cty from 1.5.1 to 1.6.1

[dependabot]

Bumps github.com/zclconf/go-cty from 1.5.1 to 1.6.1.

Changelog

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

1.6.1 (September 2, 2020)

• Fix a regression from 1.6.0 where Value.RawEqual no longer returned the correct result given a pair of sets containing partially-unknown values. (#64)

1.6.0 (August 30, 2020)

• Fixed various defects in the handling of sets containing unknown values. This will cause unknown values to now be returned in more situations, whereas before cty would often return incorrect results when working with sets containing unknown values. The list of defects fixed in this release includes:

  • cty: The length of a set containing unknown values, as defined by Value.Length, is itself unknown, reflecting the fact that unknown values may be placeholders for values that are equal to other values in the set, which would thus coalesce into a single value.
  • cty: Converting a set with unknown values to a list produces an unknown value, because type conversion can't predict which indices each element of the set should take (the unknown elements could appear anywhere in the sort order) or the length of the resulting list.
  • function/stdlib: the LengthFunc and ToList functions wrap the behaviors described in the previous two items and are therefore also fixed in the same way.
  • function/stclib: FormatListFunc depends on knowing the length of all of its sequence arguments (which includes support for sets), so it will return an unknown result if given a set with an unknown length.
  • function/stdlib: The various set operation functions were previously producing incorrect results if one of their given sets contained unknown values, because they didn't consider that unknown values on one set may be placeholders for values that are equal to elements of the other set. For example, SetSubtractFunc now produces a wholly-unknown result if either of its arguments contains an unknown element, because it can't predict whether that unknown element represents a value equal to an element in the other set.
  • cty: The Value.Equal function would previously incorrectly return a known cty.False if one of the given sets contained an unknown value. It will now return cty.UnknownVal(cty.Bool) in that case, reflecting that the result could be either cty.True or cty.False were the unknown values to be replaced with known values.
  • cty: The Value.LengthInt function was also returning incorrect results for sets containing unknown elements. However, given that it is commonly used in conjunction with ElementIterator to determine the capacity for a slice to append elements to, it is not fixed and is instead redefined to return the maximum possible length, which would result if all of the unknown values represent values that are not equal to any other set element. Applications that use Value.LengthInt to determine lengths to return to users who are working in the space of cty values should switch to using Value.Length instead and handle the possibility of the length being unknown, to avoid returning incorrect results for sets with unknown values.

  These are not classified as breaking changes because the previous behavior was defective per the design goals for unknown values. However, callers may notice their application behavior changes along with these fixes when upgrading. The new behaviors should all be more correct than the old; if you observe a change in behavior where there is now an incorrect result for sets containing unknown values (that is, where cty claims it knows an answer that it should not actually know), please report that in a GitHub issue.

  We advise callers which work with sets that may potentially contain unknown values to review their own set-handling functions to check if they too might be handling sets with unknown values incorrectly, particularly if they work with sets using integration methods rather than operation methods (for example, using Value.ValueList or Value.ValueSet to extract elements directly). It seems that incorrect handling of sets with unknown values has been a common hazard, particularly in codepaths that aim to treat lists and sets as being interchangable.

• function/stdlib: The element function will no longer panic if given a negative index. Instead, it will return a proper error. (#62)

• convert: Experimental support for annotating one or more attributes of an object type as "optional", which the convert package can then use to suppress the error that would normally be returned if the source type has no corresponding attribute, and can substitute a correctly-typed null value instead. This new behavior is subject to change even in minor release of cty, until it has been tested in experimental releases of downstream applications and potentially modified in response.

Commits

• 7c4f1e0 v1.6.1
• 9f97db4 cty: RawEquals correct behavior for sets with partially-unknown values
• f54e9ad build: remove go 1.11 and 1.12 from travis config
• 1f9c7f3 Prepare for a potential future 1.6.1 release
• afad738 v1.6.0
• 84d6039 Update CHANGELOG.md
• 88189cd cty: Fix various quirks of handling sets with unknown values
• b645bd6 dependencies: use major version 4 of the underlying msgpack library
• 39e851d Update CHANGELOG.md
• cd33c29 convert: Experimental optional object attributes
• 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 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)