Commit Graph

13 Commits

Author SHA1 Message Date
Martin Atkins 606e7c991f flatmap: be resilient to lying "foo.#" key
We use the .# key primarily as a hint that we have a list, but its value
describes how many items the writer thinks were in the list.

Since this information is redundant with the _actual_ data, it's
potentially useful as a form of corrupted data detection but this function
isn't equipped to actually report on such a problem (no error return
value, and not in a good place for UI feedback anyway), so instead we'll
largely ignore this value and just go by the number of items we
encounter.

The result of this is that when the counts mismatch we will go by the
number of items actually holding the prefix, rather than panicking as
we would've before.

This fixes the crashes in #15300, #15135 and #15334, though it does not
address any root-cause for the count to be incorrect in the first place,
so there may be something to fix here somewhere else.
2017-06-23 14:47:36 -07:00
Edward Betts be265479a9 correct spelling mistakes (#13979) 2017-04-27 02:10:04 +12:00
James Bardin f7adde0c44 remove maps with empty counts during expand
When we encounter maps with empty counts, remove them from the expansion
to prevent already empty sub-elements from being retained.

Convert TestExpand to subtests for easier debugging.
2017-04-14 16:33:31 -04:00
Sander van Harmelen 3d0073e05c core: fix a crash by suggesting a different approach to solve #11170 (#13541)
* Revert #11245, #11321, #11498 and #11757

These PR’s are all related to issue #11170 for which I would like to propose a different solution then the one currently implemented.

* A different approach to solve #11170

This approach has (IMHO) a few advantages with regards to the solution currently implemented. I will elaborate on this in the PR.
2017-04-14 22:32:30 +02:00
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.
2017-03-01 13:28:02 -05:00
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.
2017-02-23 10:03:59 -08:00
James Bardin ba60fd12ae Add another comment for reference 2017-01-09 09:43:45 -05:00
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.
2017-01-04 16:03:24 -05:00
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.
2016-12-23 23:37:03 +00:00
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.
2016-12-16 10:36:26 -05:00
Mitchell Hashimoto 308b88a8d8 flatmap: never auto-convert ints 2014-07-24 11:41:01 -07:00
Mitchell Hashimoto 1277c324d0 flatmap: deeper nesting tests 2014-07-08 13:57:55 -07:00
Mitchell Hashimoto ad2f448911 flatmap: expand 2014-07-01 13:25:54 -07:00