ResiLien
/
terraform
2
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
terraform/configs/configupgrade/testdata/valid/funcs-replaced/input/funcs-replaced.tf

27 lines
1.0 KiB
Terraform
Raw Normal View History

configs/configupgrade: Replace calls to list() and map() We now have native language features for declaring tuples and objects, which are the idiomatic way to construct sequence and mapping values that can then be converted to list, set, and map types as needed.
2018-12-01 03:23:09 +01:00
locals {
list = "${list("a", "b", "c")}"
list_concat = "${concat(list("a", "b"), list("c"))}"
list_empty = "${list()}"
map = "${map("a", "b", "c", "d")}"
map_merge = "${merge(map("a", "b"), map("c", "d"))}"
map_empty = "${map()}"
map_invalid = "${map("a", "b", "c")}"
list_of_map = "${list(map("a", "b"))}"
map_of_list = "${map("a", list("b"))}"
configs/configupgrade: Replace lookup(...) with index syntax If lookup is being used with only two arguments then it is equivalent to index syntax and more readable that way, so we'll replace it. Ideally we'd do similarly for element(...) here but sadly we cannot because we can't prove in static analysis that the user is not relying on the modulo wraparound behavior of that function.
2018-12-01 03:29:56 +01:00
lookup_literal = "${lookup(map("a", "b"), "a")}"
lookup_ref = "${lookup(local.map, "a")}"
configs/configupgrade: Fix up internal HIL conversion functions HIL implemented its type conversions by rewriting its AST to include calls to some undocumented builtin functions. Unfortunately those functions were still explicitly callable if you could figure out the name for them, and so they may have been used in the wild. In particular, __builtin_StringToFloat was used as part of a workaround for a HIL design flaw where it would prefer to convert strings to integers rather than floats when performing arithmetic operations. This issue was, indeed, the main reason for unifying int ant float into a single number type in HCL. Since we published that as a suggested workaround, the upgrade tool ought to fix it up. The other cases have never been documented as a workaround, so they are less likely to appear in the wild, but we might as well fix them up anyway since we already have the conversion functions required to get the same result in the new language. To be safe/conservative, most of these convert to _two_ function calls rather than just one, which ensures that these new expressions retain the behavior of implicitly converting to the source type before running the conversion. The new conversion functions only specify target type, and so cannot guarantee identical results if the argument type does not exactly match what was previously given as the parameter type in HIL.
2019-02-20 21:53:12 +01:00
# Undocumented HIL implementation details that some users nonetheless relied on.
conv_bool_to_string = "${__builtin_BoolToString(true)}"
conv_float_to_int = "${__builtin_FloatToInt(1.5)}"
conv_float_to_string = "${__builtin_FloatToString(1.5)}"
conv_int_to_float = "${__builtin_IntToFloat(1)}"
conv_int_to_string = "${__builtin_IntToString(1)}"
conv_string_to_int = "${__builtin_StringToInt("1")}"
conv_string_to_float = "${__builtin_StringToFloat("1.5")}"
conv_string_to_bool = "${__builtin_StringToBool("true")}"
configs/configupgrade: Replace calls to list() and map() We now have native language features for declaring tuples and objects, which are the idiomatic way to construct sequence and mapping values that can then be converted to list, set, and map types as needed.
2018-12-01 03:23:09 +01:00
}