9 Commits (ca517543f266d0dfb67fcddbb68e4bae54d55078)

Author	SHA1	Message	Date
James Bardin	057941ce18	make flatmap.Expand understand computed sets ... For historical reasons, sets are represented as sparse lists in a flatmap, however a computed set does not have a numeric index. Strip the `~` flag from a computed set's index during expansion, and add it back in the prefix after sorting.	9 years ago
Mitchell Hashimoto	c6d0333dc0	flatmap: mark computed list as a computed value in Expand ... Fixes #12183 The fix is in flatmap for this but the entire issue is a bit more complex. Given a schema with a computed set, if you reference it like this: lookup(attr[0], "field") And "attr" contains a computed set within it, it would panic even though "field" is available. There were a couple avenues I could've taken to fix this: 1.) Any complex value containing any unknown value at any point is entirely unknown. 2.) Only the specific part of the complex value is unknown. I took route 2 so that the above works without any computed (since "name" is not computed but something else is). This may actually have an effect on other parts of Terraform configs, however those similar configs would've simply crashed previously so it shouldn't break any pre-existing configs.	9 years ago
James Bardin	ba60fd12ae	Add another comment for reference	9 years ago
James Bardin	85d8fba3bd	Minor fixups to expandArray ... Find the index keys by comparing the strings directly, so we don't need to worry about the prefix value altering the regex.	9 years ago
Andrew Garrett	497010ce42	Fix string representation of sets during interpolation ... The change in #10787 used flatmap.Expand to fix interpolation of nested maps, but it broke interpolation of sets such that their elements were not represented. For example, the expected string representation of a splatted aws_network_interface.whatever.*.private_ips should be: ``` [{Variable (TypeList): [{Variable (TypeString): 10.41.17.25}]} {Variable (TypeList): [{Variable (TypeString): 10.41.22.236}]}] ``` But instead it became: ``` [{Variable (TypeList): [{Variable (TypeString): }]} {Variable (TypeList): [{Variable (TypeString): }]}] ``` This is because the expandArray function of expand.go treated arrays to exclusively be lists, e.g. not sets. The old code used to match for numeric keys, so it would work for sets, whereas expandArray just assumed keys started at 0 and ascended incrementally. Remember that sets' keys are numeric, but since they are hashes, they can be any integer. The result of assuming that the keys start at 0 led to the recursive call to flatmap.Expand not matching any keys of the set, and returning nil, which is why the above example has nothing where the IP addresses used to be. So we bring back that matching behavior, but we move it to expandArray instead. We've modified it to not reconstruct the data structures like it used to when it was in the Interpolator, and to use the standard int sorter rather than implementing a custom sorter since a custom one is no longer necessary thanks to the use of flatmap.Expand. Fixes #10908, and restores the viability of the workaround I posted in #8696. Big thanks to @jszwedko for helping me with this fix. I was able to diagnose the problem along, but couldn't fix it without his help.	9 years ago
James Bardin	5b5e892d4b	fix flatmap.Expand ... flatmap.Expand was adding `%` as a value in nested maps. Removing that allows us properly expand objects other than a simple map.	9 years ago
Mitchell Hashimoto	308b88a8d8	flatmap: never auto-convert ints	12 years ago
Mitchell Hashimoto	1277c324d0	flatmap: deeper nesting tests	12 years ago
Mitchell Hashimoto	ad2f448911	flatmap: expand	12 years ago