ResiLien
/
terraform
2
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
terraform/internal/lang/funcs/conversion_test.go

283 lines
6.2 KiB
Go
Raw Normal View History

lang/funcs: Type conversion functions It's not normally necessary to make explicit type conversions in Terraform because the language implicitly converts as necessary, but explicit conversions are useful in a few specialized cases: - When defining output values for a reusable module, it may be desirable to force a "cleaner" output type than would naturally arise from a computation, such as forcing a string containing digits into a number. - Our 0.12upgrade mechanism will use some of these to replace use of the undocumented, hidden type conversion functions in HIL, and force particular type interpretations in some tricky cases. - We've found that type conversion functions can be useful as _temporary_ workarounds for bugs in Terraform and in providers where implicit type conversion isn't working correctly or a type constraint isn't specified precisely enough for the automatic conversion behavior. These all follow the same convention of being named "to" followed by a short type name. Since we've had a long-standing convention of running all the words together in lowercase in function names, we stick to that here even though some of these names are quite strange, because these should be rarely-used functions anyway.
2019-01-17 18:11:48 +01:00
package funcs
import (
"fmt"
"testing"
lang/funcs: add (console-only) TypeFunction (#28501) * lang/funcs: add (console-only) TypeFunction The type() function, which is only available for terraform console, prints out the type of a given value. This is mainly intended for debugging - it's nice to be able to print out terraform's understanding of a complex variable. This introduces a new field for Scope: ConsoleMode. When ConsoleMode is true, any additional functions intended for use in the console (only) may be added.
2021-04-23 16:29:50 +02:00
"github.com/google/go-cmp/cmp"
remove IsMarked and ContainsMarked calls Make sure sensitivity checks are looking for specific marks rather than any marks at all.
2021-06-25 20:13:57 +02:00
"github.com/hashicorp/terraform/internal/lang/marks"
lang/funcs: Type conversion functions It's not normally necessary to make explicit type conversions in Terraform because the language implicitly converts as necessary, but explicit conversions are useful in a few specialized cases: - When defining output values for a reusable module, it may be desirable to force a "cleaner" output type than would naturally arise from a computation, such as forcing a string containing digits into a number. - Our 0.12upgrade mechanism will use some of these to replace use of the undocumented, hidden type conversion functions in HIL, and force particular type interpretations in some tricky cases. - We've found that type conversion functions can be useful as _temporary_ workarounds for bugs in Terraform and in providers where implicit type conversion isn't working correctly or a type constraint isn't specified precisely enough for the automatic conversion behavior. These all follow the same convention of being named "to" followed by a short type name. Since we've had a long-standing convention of running all the words together in lowercase in function names, we stick to that here even though some of these names are quite strange, because these should be rarely-used functions anyway.
2019-01-17 18:11:48 +01:00
"github.com/zclconf/go-cty/cty"
)
func TestTo(t *testing.T) {
tests := []struct {
Value cty.Value
TargetTy cty.Type
Want cty.Value
Err string
}{
{
cty.StringVal("a"),
cty.String,
cty.StringVal("a"),
``,
},
{
cty.UnknownVal(cty.String),
cty.String,
cty.UnknownVal(cty.String),
``,
},
{
cty.NullVal(cty.String),
cty.String,
cty.NullVal(cty.String),
``,
},
lang/funcs: Conversion functions can handle sensitive values In order to avoid updating every one of our existing functions with explicit support for sensitive values, there's a default rule in the functions system which makes the result of a function sensitive if any of its arguments contain sensitive values. We were applying that default to the various type conversion functions, like tomap and tolist, which meant that converting a complex-typed value with a sensitive value anywhere inside it would result in a wholly-sensitive result. That's unnecessarily conservative because the cty conversion layer (which these functions are wrapping) already knows how to handle sensitivity in a more precise way. Therefore we can opt in to handling marked values (which Terraform uses for sensitivity) here and the only special thing we need to do is handle errors related to sensitive values differently, so we won't print their values out literally in case of an error (and so that the attempt to print them out literally won't panic trying to extract the marked values).
2021-04-19 19:13:08 +02:00
{
cty.StringVal("a").Mark("boop"),
cty.String,
cty.StringVal("a").Mark("boop"),
``,
},
{
cty.NullVal(cty.String).Mark("boop"),
cty.String,
cty.NullVal(cty.String).Mark("boop"),
``,
},
lang/funcs: Type conversion functions It's not normally necessary to make explicit type conversions in Terraform because the language implicitly converts as necessary, but explicit conversions are useful in a few specialized cases: - When defining output values for a reusable module, it may be desirable to force a "cleaner" output type than would naturally arise from a computation, such as forcing a string containing digits into a number. - Our 0.12upgrade mechanism will use some of these to replace use of the undocumented, hidden type conversion functions in HIL, and force particular type interpretations in some tricky cases. - We've found that type conversion functions can be useful as _temporary_ workarounds for bugs in Terraform and in providers where implicit type conversion isn't working correctly or a type constraint isn't specified precisely enough for the automatic conversion behavior. These all follow the same convention of being named "to" followed by a short type name. Since we've had a long-standing convention of running all the words together in lowercase in function names, we stick to that here even though some of these names are quite strange, because these should be rarely-used functions anyway.
2019-01-17 18:11:48 +01:00
{
cty.True,
cty.String,
cty.StringVal("true"),
``,
},
{
cty.StringVal("a"),
cty.Bool,
cty.DynamicVal,
`cannot convert "a" to bool; only the strings "true" or "false" are allowed`,
},
lang/funcs: Conversion functions can handle sensitive values In order to avoid updating every one of our existing functions with explicit support for sensitive values, there's a default rule in the functions system which makes the result of a function sensitive if any of its arguments contain sensitive values. We were applying that default to the various type conversion functions, like tomap and tolist, which meant that converting a complex-typed value with a sensitive value anywhere inside it would result in a wholly-sensitive result. That's unnecessarily conservative because the cty conversion layer (which these functions are wrapping) already knows how to handle sensitivity in a more precise way. Therefore we can opt in to handling marked values (which Terraform uses for sensitivity) here and the only special thing we need to do is handle errors related to sensitive values differently, so we won't print their values out literally in case of an error (and so that the attempt to print them out literally won't panic trying to extract the marked values).
2021-04-19 19:13:08 +02:00
{
cty.StringVal("a").Mark("boop"),
cty.Bool,
cty.DynamicVal,
remove IsMarked and ContainsMarked calls Make sure sensitivity checks are looking for specific marks rather than any marks at all.
2021-06-25 20:13:57 +02:00
`cannot convert "a" to bool; only the strings "true" or "false" are allowed`,
},
{
cty.StringVal("a").Mark(marks.Sensitive),
cty.Bool,
cty.DynamicVal,
lang/funcs: Conversion functions can handle sensitive values In order to avoid updating every one of our existing functions with explicit support for sensitive values, there's a default rule in the functions system which makes the result of a function sensitive if any of its arguments contain sensitive values. We were applying that default to the various type conversion functions, like tomap and tolist, which meant that converting a complex-typed value with a sensitive value anywhere inside it would result in a wholly-sensitive result. That's unnecessarily conservative because the cty conversion layer (which these functions are wrapping) already knows how to handle sensitivity in a more precise way. Therefore we can opt in to handling marked values (which Terraform uses for sensitivity) here and the only special thing we need to do is handle errors related to sensitive values differently, so we won't print their values out literally in case of an error (and so that the attempt to print them out literally won't panic trying to extract the marked values).
2021-04-19 19:13:08 +02:00
`cannot convert this sensitive string to bool`,
},
lang/funcs: Type conversion functions It's not normally necessary to make explicit type conversions in Terraform because the language implicitly converts as necessary, but explicit conversions are useful in a few specialized cases: - When defining output values for a reusable module, it may be desirable to force a "cleaner" output type than would naturally arise from a computation, such as forcing a string containing digits into a number. - Our 0.12upgrade mechanism will use some of these to replace use of the undocumented, hidden type conversion functions in HIL, and force particular type interpretations in some tricky cases. - We've found that type conversion functions can be useful as _temporary_ workarounds for bugs in Terraform and in providers where implicit type conversion isn't working correctly or a type constraint isn't specified precisely enough for the automatic conversion behavior. These all follow the same convention of being named "to" followed by a short type name. Since we've had a long-standing convention of running all the words together in lowercase in function names, we stick to that here even though some of these names are quite strange, because these should be rarely-used functions anyway.
2019-01-17 18:11:48 +01:00
{
cty.StringVal("a"),
cty.Number,
cty.DynamicVal,
`cannot convert "a" to number; given string must be a decimal representation of a number`,
},
lang/funcs: Conversion functions can handle sensitive values In order to avoid updating every one of our existing functions with explicit support for sensitive values, there's a default rule in the functions system which makes the result of a function sensitive if any of its arguments contain sensitive values. We were applying that default to the various type conversion functions, like tomap and tolist, which meant that converting a complex-typed value with a sensitive value anywhere inside it would result in a wholly-sensitive result. That's unnecessarily conservative because the cty conversion layer (which these functions are wrapping) already knows how to handle sensitivity in a more precise way. Therefore we can opt in to handling marked values (which Terraform uses for sensitivity) here and the only special thing we need to do is handle errors related to sensitive values differently, so we won't print their values out literally in case of an error (and so that the attempt to print them out literally won't panic trying to extract the marked values).
2021-04-19 19:13:08 +02:00
{
cty.StringVal("a").Mark("boop"),
cty.Number,
cty.DynamicVal,
remove IsMarked and ContainsMarked calls Make sure sensitivity checks are looking for specific marks rather than any marks at all.
2021-06-25 20:13:57 +02:00
`cannot convert "a" to number; given string must be a decimal representation of a number`,
},
{
cty.StringVal("a").Mark(marks.Sensitive),
cty.Number,
cty.DynamicVal,
lang/funcs: Conversion functions can handle sensitive values In order to avoid updating every one of our existing functions with explicit support for sensitive values, there's a default rule in the functions system which makes the result of a function sensitive if any of its arguments contain sensitive values. We were applying that default to the various type conversion functions, like tomap and tolist, which meant that converting a complex-typed value with a sensitive value anywhere inside it would result in a wholly-sensitive result. That's unnecessarily conservative because the cty conversion layer (which these functions are wrapping) already knows how to handle sensitivity in a more precise way. Therefore we can opt in to handling marked values (which Terraform uses for sensitivity) here and the only special thing we need to do is handle errors related to sensitive values differently, so we won't print their values out literally in case of an error (and so that the attempt to print them out literally won't panic trying to extract the marked values).
2021-04-19 19:13:08 +02:00
`cannot convert this sensitive string to number`,
},
lang/funcs: Type conversion functions It's not normally necessary to make explicit type conversions in Terraform because the language implicitly converts as necessary, but explicit conversions are useful in a few specialized cases: - When defining output values for a reusable module, it may be desirable to force a "cleaner" output type than would naturally arise from a computation, such as forcing a string containing digits into a number. - Our 0.12upgrade mechanism will use some of these to replace use of the undocumented, hidden type conversion functions in HIL, and force particular type interpretations in some tricky cases. - We've found that type conversion functions can be useful as _temporary_ workarounds for bugs in Terraform and in providers where implicit type conversion isn't working correctly or a type constraint isn't specified precisely enough for the automatic conversion behavior. These all follow the same convention of being named "to" followed by a short type name. Since we've had a long-standing convention of running all the words together in lowercase in function names, we stick to that here even though some of these names are quite strange, because these should be rarely-used functions anyway.
2019-01-17 18:11:48 +01:00
{
cty.NullVal(cty.String),
cty.Number,
cty.NullVal(cty.Number),
``,
},
{
cty.UnknownVal(cty.Bool),
cty.String,
cty.UnknownVal(cty.String),
``,
},
{
cty.UnknownVal(cty.String),
cty.Bool,
cty.UnknownVal(cty.Bool), // conversion is optimistic
``,
},
{
cty.TupleVal([]cty.Value{cty.StringVal("hello"), cty.True}),
cty.List(cty.String),
cty.ListVal([]cty.Value{cty.StringVal("hello"), cty.StringVal("true")}),
``,
},
{
cty.TupleVal([]cty.Value{cty.StringVal("hello"), cty.True}),
cty.Set(cty.String),
cty.SetVal([]cty.Value{cty.StringVal("hello"), cty.StringVal("true")}),
``,
},
{
cty.ObjectVal(map[string]cty.Value{"foo": cty.StringVal("hello"), "bar": cty.True}),
cty.Map(cty.String),
cty.MapVal(map[string]cty.Value{"foo": cty.StringVal("hello"), "bar": cty.StringVal("true")}),
``,
},
lang/funcs: Conversion functions can handle sensitive values In order to avoid updating every one of our existing functions with explicit support for sensitive values, there's a default rule in the functions system which makes the result of a function sensitive if any of its arguments contain sensitive values. We were applying that default to the various type conversion functions, like tomap and tolist, which meant that converting a complex-typed value with a sensitive value anywhere inside it would result in a wholly-sensitive result. That's unnecessarily conservative because the cty conversion layer (which these functions are wrapping) already knows how to handle sensitivity in a more precise way. Therefore we can opt in to handling marked values (which Terraform uses for sensitivity) here and the only special thing we need to do is handle errors related to sensitive values differently, so we won't print their values out literally in case of an error (and so that the attempt to print them out literally won't panic trying to extract the marked values).
2021-04-19 19:13:08 +02:00
{
cty.ObjectVal(map[string]cty.Value{"foo": cty.StringVal("hello"), "bar": cty.StringVal("world").Mark("boop")}),
cty.Map(cty.String),
cty.MapVal(map[string]cty.Value{"foo": cty.StringVal("hello"), "bar": cty.StringVal("world").Mark("boop")}),
``,
},
{
cty.ObjectVal(map[string]cty.Value{"foo": cty.StringVal("hello"), "bar": cty.StringVal("world")}).Mark("boop"),
cty.Map(cty.String),
cty.MapVal(map[string]cty.Value{"foo": cty.StringVal("hello"), "bar": cty.StringVal("world")}).Mark("boop"),
``,
},
{
cty.TupleVal([]cty.Value{cty.StringVal("hello"), cty.StringVal("world").Mark("boop")}),
cty.List(cty.String),
cty.ListVal([]cty.Value{cty.StringVal("hello"), cty.StringVal("world").Mark("boop")}),
``,
},
{
cty.TupleVal([]cty.Value{cty.StringVal("hello"), cty.StringVal("world")}).Mark("boop"),
cty.List(cty.String),
cty.ListVal([]cty.Value{cty.StringVal("hello"), cty.StringVal("world")}).Mark("boop"),
``,
},
lang/funcs: Type conversion functions It's not normally necessary to make explicit type conversions in Terraform because the language implicitly converts as necessary, but explicit conversions are useful in a few specialized cases: - When defining output values for a reusable module, it may be desirable to force a "cleaner" output type than would naturally arise from a computation, such as forcing a string containing digits into a number. - Our 0.12upgrade mechanism will use some of these to replace use of the undocumented, hidden type conversion functions in HIL, and force particular type interpretations in some tricky cases. - We've found that type conversion functions can be useful as _temporary_ workarounds for bugs in Terraform and in providers where implicit type conversion isn't working correctly or a type constraint isn't specified precisely enough for the automatic conversion behavior. These all follow the same convention of being named "to" followed by a short type name. Since we've had a long-standing convention of running all the words together in lowercase in function names, we stick to that here even though some of these names are quite strange, because these should be rarely-used functions anyway.
2019-01-17 18:11:48 +01:00
{
cty.EmptyTupleVal,
cty.String,
cty.DynamicVal,
`cannot convert tuple to string`,
},
{
cty.UnknownVal(cty.EmptyTuple),
cty.String,
cty.DynamicVal,
`cannot convert tuple to string`,
},
{
cty.EmptyObjectVal,
cty.Object(map[string]cty.Type{"foo": cty.String}),
cty.DynamicVal,
`incompatible object type for conversion: attribute "foo" is required`,
},
}
for _, test := range tests {
t.Run(fmt.Sprintf("to %s(%#v)", test.TargetTy.FriendlyNameForConstraint(), test.Value), func(t *testing.T) {
f := MakeToFunc(test.TargetTy)
got, err := f.Call([]cty.Value{test.Value})
if test.Err != "" {
if err == nil {
t.Fatal("succeeded; want error")
}
if got, want := err.Error(), test.Err; got != want {
t.Fatalf("wrong error\ngot: %s\nwant: %s", got, want)
}
return
} else if err != nil {
t.Fatalf("unexpected error: %s", err)
}
if !got.RawEquals(test.Want) {
t.Errorf("wrong result\ngot: %#v\nwant: %#v", got, test.Want)
}
})
}
}
lang/funcs: add (console-only) TypeFunction (#28501) * lang/funcs: add (console-only) TypeFunction The type() function, which is only available for terraform console, prints out the type of a given value. This is mainly intended for debugging - it's nice to be able to print out terraform's understanding of a complex variable. This introduces a new field for Scope: ConsoleMode. When ConsoleMode is true, any additional functions intended for use in the console (only) may be added.
2021-04-23 16:29:50 +02:00
func TestType(t *testing.T) {
tests := []struct {
Input cty.Value
Want string
}{
// Primititves
{
cty.StringVal("a"),
"string",
},
{
cty.NumberIntVal(42),
"number",
},
{
cty.BoolVal(true),
"bool",
},
// Collections
{
cty.EmptyObjectVal,
`object({})`,
},
{
cty.EmptyTupleVal,
`tuple([])`,
},
{
cty.ListValEmpty(cty.String),
`list(string)`,
},
{
cty.MapValEmpty(cty.String),
`map(string)`,
},
{
cty.SetValEmpty(cty.String),
`set(string)`,
},
{
cty.ListVal([]cty.Value{cty.StringVal("a")}),
`list(string)`,
},
{
cty.ListVal([]cty.Value{cty.ListVal([]cty.Value{cty.NumberIntVal(42)})}),
`list(list(number))`,
},
{
cty.ListVal([]cty.Value{cty.MapValEmpty(cty.String)}),
`list(map(string))`,
},
{
cty.ListVal([]cty.Value{cty.ObjectVal(map[string]cty.Value{
"foo": cty.StringVal("bar"),
})}),
"list(\n object({\n foo: string,\n }),\n)",
},
// Unknowns and Nulls
{
cty.UnknownVal(cty.String),
"string",
},
{
cty.NullVal(cty.Object(map[string]cty.Type{
"foo": cty.String,
})),
"object({\n foo: string,\n})",
},
{ // irrelevant marks do nothing
cty.ListVal([]cty.Value{cty.ObjectVal(map[string]cty.Value{
"foo": cty.StringVal("bar").Mark("ignore me"),
})}),
"list(\n object({\n foo: string,\n }),\n)",
},
}
for _, test := range tests {
got, err := Type([]cty.Value{test.Input})
if err != nil {
t.Fatalf("unexpected error: %s", err)
}
// The value is marked to help with formatting
got, _ = got.Unmark()
if got.AsString() != test.Want {
t.Errorf("wrong result:\n%s", cmp.Diff(got.AsString(), test.Want))
}
}
}