stdlib: SetProductFunc doesn't seem to handle refinements quite right about go-cty HOT 2 CLOSED

This doesn't seem to be directly related to refinements because the following is the line blamed in the Terraform stack traces:

However, it does still seem like something's not quite right here, because all of the successful return paths in Type return collection types so it's not clear how a non-collection type would end up as retType in the Impl function. Further investigation required!

from go-cty.

This is now fixed in v1.13.1.

The problem wasn't refinements directly, but it arose because I weakened the constraints on the parameters to this function to allow it to handle unknown values itself, so that the Impl function could produce refined unknown results. That then exposed a previously-hidden bug where the function package was still calling Impl even after short-circuiting Type, causing this function to be asked to produce a cty.DynamicPseudoType result even though it had never promised it could.

The fix then was to make the function system respect its own rule that Impl will only be called if Type was called and it succeeded. Passing a cty.DynamicVal into SetProductFunc (or any of the other functions that got similar treatment in v1.13.0) will now immediately return cty.DynamicVal as before, rather than panicking after calling its Impl function with an unsupported type.

from go-cty.