62 Commits (ccf19fbf5e2b61ba62efd1ac47a3a3fd3917d494)

Author	SHA1	Message	Date
Martin Atkins	ae3c0c6a4a	lang/funcs: Remove the deprecated "list" and "map" functions ... Prior to Terraform 0.12 these two functions were the only way to construct literal lists and maps (respectively) in HIL expressions. Terraform 0.12, by switching to HCL 2, introduced first-class syntax for constructing tuple and object values, which can then be converted into list and map values using the tolist and tomap type conversion functions. We marked both of these functions as deprecated in the Terraform v0.12 release and have since then mentioned in the docs that they will be removed in a future Terraform version. The "terraform 0.12upgrade" tool from Terraform v0.12 also included a rule to automatically rewrite uses of these functions into equivalent new syntax. The main motivation for removing these now is just to get this change made prior to Terraform 1.0. as we'll be doing with various other deprecations. However, a specific reason for these two functions in particular is that their existence is what caused us to invent the idea of a "type expression" as a distinct kind of expression in Terraform v0.12, and so removing them now would allow potentially unifying type expressions with value expressions in a future release. We do not have any current specific plans to make that change, but one potential motivation for doing so would be to take another attempt at a generalized "convert" function which takes a type as one of its arguments. Our previous attempt to implement such a function was foiled by the fact that Terraform's expression validator doesn't have any way to know to treat one argument of a particular function as special, and so it was generating incorrect error messages. We won't necessarily do that, but having these "list" and "map" functions out of the way leaves the option open.	6 years ago
Arthur Burkart	d4716a69e1	lang/funcs: "anytrue" function ... This is an analog to the "alltrue" function, using OR as the reduce operator rather than AND. This also includes some simplification of the "alltrue" implementation to implement it similarly as a sort of reduce operation with AND as the reduce operator, but with the same effective behavior.	6 years ago
OwenTuz	bb39fafbe5	lang/funcs: lookup() will only treat map as unknown if it is wholly unknown (#26427) ... Fix for issue #26320 - this allows us to derive known values from partially known maps where we can, and may prevent unnecessary destroy/rebuild cycles during apply in some cases.	6 years ago
Arthur Burkart	6ed47c7241	lang/funcs: Add "alltrue" function (#25656) ... This commit adds an `alltrue` function to Terraform configuration. A reason we might want this function is because it will enable more powerful custom variable validations. For example: ```hcl variable "amis" { type = list(object({ id = string })) validation { condition = (alltrue([ for a in var.amis : length(a.id) > 4 && substr(a.id, 0, 4) == "ami-" ])) error_message = "The ID of at least one AMI was invalid." } } ```	6 years ago
Noah Mercado	d4d8812afa	Feature: Sum Function (#24666) ... The sum function takes a list or set of numbers and returns the sum of those numbers.	6 years ago
Alisdair McDiarmid	37006c5841	lang: Fix non-string key panics in map function ... The map function assumed that the key arguments were strings, and would panic if they were not. After this commit, calling `map(1, 2)` will result in a map `{"1" = 1}`, and calling `map(null, 1)` will result in a syntax error. Fixes #23346, fixes #23043	6 years ago
James Bardin	d999d43483	remove old funcs code	6 years ago
James Bardin	529271e0be	update merge docs to match behavior	6 years ago
James Bardin	f5bf9aa55d	make the merge function more precise ... This PR implements 2 changes to the merge function. - Rather than always defining the merge return type as dynamic, return a precise type when all argument types match, or all possible object attributes are known. - Always return a value containing all keys when the keys are known. This allows the use of merge output in for_each, even when keys are yet to be determined.	6 years ago
Parviz	6eaf1c23f9	lang/funcs: don't panic when transpose produces empty result	7 years ago
Kristin Laemmert	2b14a6b332	lang/funcs: lookup() can work with maps of lists, maps and objects (#22269) ... * lang/funcs: lookup() can work with maps of lists, maps and objects lookup() can already handle aribtrary objects of (whatever) and should handle maps of (whatever) similarly.	7 years ago
Radek Simko	5c30bafee0	Merge pull request #22119 from hashicorp/b-chunklist-empty-list ... lang/funcs: Pass through empty list in chunklist	7 years ago
Radek Simko	736fda1613	lang/funcs: Pass through empty list in chunklist	7 years ago
Saverio Miroddi	983af7a183	Allow null values in Compact function ... The function would previously panic when one or more null values were among the arguments. The new behavior treats nulls as empty strings, therefore, it removes them.	7 years ago
Pam Selle	1255ad6722	Don't allow nulls in calls to merge	7 years ago
Kristin Laemmert	30a924e162	lang/funcs: `matchkeys` - unify type for keys and searchset ... Added higher-level test for matchkeys to exercise mixing types in searchset. This had to be in the functions tests so the HCL auto conversion from tuple to list would occur.	7 years ago
Kristin Laemmert	f2a14d7c18	lang/funcs: fix error when `matchkeys` encountered a variable ... `matchkeys` was returning a (false) error if the searchset was a variable, since then the type of the keylist and searchset parameters would not match. This does slightly change the behavior: previously matchkeys would produce an error if the parameters were not of the same type, for e.g. if searchset was a list of strings and keylist was a list of integers. This no longer produces an error.	7 years ago
Martin Atkins	55794eb658	lang/funcs: Don't panic when distinct called with empty list	7 years ago
Martin Atkins	742deca3e9	lang/funcs: Short-circuit if start or end index is unknown ... Previously the type-selection codepath for an input tuple referred unconditionally to the start and end index values. In the Type callback, only the types of the arguments are guaranteed to be known, so any access to the values must be guarded with an .IsKnown check, or else the function will not short-circuit properly when an unknown value is passed. Now we will check the start and end indices are in range when we have enough information to do so, but we'll return an approximate result if either is unknown.	7 years ago
James Bardin	3ab496d4b1	allow sets and tuples in contains function ... Sets are no longer going to be automatically converted, so we need to handle those in contains.	7 years ago
James Bardin	19bddee11b	more precise types handling in coalescelist ... coalescelist should accept lists and tuples, and return a dynamic types when the arguments are not homogeneous.	7 years ago
James Bardin	359f057a16	allow chunklist to handle unknowns ... Chunklist should be able to return chunks containing unknown values.	7 years ago
James Bardin	93ef015336	more precise type handling in flatten ... FlattenFunc can return lists and tuples when individual elements are unknown. Only return an unknown tuple if the number of elements cannot be determined because it contains an unknown series. Make sure flatten can handle non-series elements, which were previously lost due to passing a slice value as the argument.	7 years ago
James Bardin	81e04c3050	more precise type handling in slice ... When slicing a list containing unknown values, the list itself is known, and slice should return the proper slice of that list. Make SliceFunc return the correct type for slices of tuples, and disallow slicing sets.	7 years ago
Kristin Laemmert	8520f4e4a5	* lang/funcs/flatten: accept sets and tuples, return tuples ... * lang/funcs: flatten should handle sets and tuples * flatten now returns a tuple	7 years ago
Martin Atkins	6adcc7ab73	vendor: go get github.com/zclconf/go-cty@master ... cty now guarantees that sets of primitive values will iterate in a reasonable order. Previously it was the caller's responsibility to deal with that, but we invariably neglected to do so, causing inconsistent ordering. Since cty prioritizes consistent behavior over performance, it now imposes its own sort on set elements as part of iterating over them so that calling applications don't have to worry so much about it. This change also causes cty to consistently push unknown and null values in sets to the end of iteration, where before that was undefined. This means that our diff output will now consistently list additions before removals when showing sets, rather than the ordering being undefined as before. The ordering of known, non-null, non-primitive values is still not contractually fixed but remains consistent for a particular version of cty.	7 years ago
Kristin Laemmert	d4669246c7	funcs/coalesce: return the first non-null, non-empty-string element from a sequence (#21002) ... * funcs/coalesce: return the first non-null, non-empty element from a sequence. The go-cty coalesce function, which was originally used here, returns the first non-null element from a sequence. Terraform 0.11's coalesce, however, returns the first non-empty string from a list of strings. This new coalesce function aims to preserve terraform's documented functionality while adding support for additional argument types. The tests include those in go-cty and adapted tests from the 0.11 version of coalesce. * website/docs: update coalesce function document	7 years ago
Martin Atkins	096b1bb87b	lang/funcs: Port the "reverse" function from the old functions set ... This has the same functionality as the "reverse" function that was implemented in the "config" package, but adapted to the new language type system.	7 years ago
Martin Atkins	edb5f82de1	lang/funcs: Convert the "setproduct" function to the new approach ... In our new world it produces either a set of a tuple type or a list of a tuple type, depending on the given argument types. The resulting collection's element tuple type is decided by the element types of the given collections, allowing type information to propagate even if unknown values are present.	7 years ago
Martin Atkins	30497bbfb7	lang/funcs: zipmap accepts tuple of values and produces object ... Now that our language supports tuple/object types in addition to list/map types, it's convenient for zipmap to be able to produce an object type given a tuple, since this makes it symmetrical with "keys" and "values" such the the following identity holds for any map or object value "a" a == zipmap(keys(a), values(a)) When the values sequence is a tuple, the result has an object type whose attribute types correspond to the given tuple types. Since an object type has attribute names as part of its definition, there is the additional constraint here that the result has an unknown type (represented by the dynamic pseudo-type) if the given values is a tuple and the given keys contains any unknown values. This isn't true for values as a list because we can predict the resulting map element type using just the list element type.	7 years ago
Martin Atkins	ecc42b838c	lang/funcs: Fix crash and improve precision of keys/values functions ... The "values" function wasn't producing consistently-ordered keys in its result, leading to crashes. This fixes #19204. While working on these functions anyway, this also improves slightly their precision when working with object types, where we can produce a more complete result for unknown values because the attribute names are part of the type. We can also produce results for known maps that have unknown elements; these unknowns will also appear in the values(...) result, allowing them to propagate through expressions. Finally, this adds a few more test cases to try different permutations of empty and unknown values.	8 years ago
Martin Atkins	8c01cf7293	lang/funcs: Fix broken test for lookup function ... When the value we're looking in has an object type, we need to know the key in order to decide the result type. Therefore an object lookup with an unknown key must produce cty.DynamicVal, not an unknown value with a known type.	8 years ago
Martin Atkins	8f578c365f	lang/funcs: Permit object types in the "length" function ... The implementation already allowed this, so this was just an oversight in the type checking function. This fixes #19278.	8 years ago
Radek Simko	4856d81300	lang: Fix crash in lookup function	8 years ago
Kristin Laemmert	fd77e56fd6	lookup will return a tuple type when passed an object	8 years ago
Kristin Laemmert	f54ee830d3	lang/funcs: update values to accept object types	8 years ago
Kristin Laemmert	d1d0ede069	lang/funcs: return default value if provided when object lookup fails to find attr	8 years ago
Kristin Laemmert	46e168a682	lang/funcs: update lookup() to accept object-typed values for "map" arg	8 years ago
Martin Atkins	c990c9f36d	lang/funcs: Don't panic if coalescelist gets an unknown list	8 years ago
Martin Atkins	db58b88c2d	lang/funcs: short-circuit with unknown index and tuple collection ... Since we need to know the index to know the result type for a tuple, we need a special case here to deal with that situation and return cty.DynamicVal; we can't predict the result type exactly until we know the element type.	8 years ago
Kristin Laemmert	c23a971ed1	minor fixes	8 years ago
Kristin Laemmert	a213c4a648	functions: add tests and support for unknown values	8 years ago
Kristin Laemmert	d802d5c624	functions: pr feedback fixes	8 years ago
Kristin Laemmert	ff4b3d763b	functions: fix lookup()'s handling of numberical defaults	8 years ago
Kristin Laemmert	4f5c03339a	functions: ZipmapFunc	8 years ago
Kristin Laemmert	605e23db6b	various code review fixes	8 years ago
Kristin Laemmert	6463dd90e9	functions: TransposeFunc, SliceFunc	8 years ago
Kristin Laemmert	30671d85ad	functions: MergeFunc	8 years ago
Kristin Laemmert	aecd7b2e62	functions: LookupFunc	8 years ago
Kristin Laemmert	4d8c398f8e	functions: KeysFunc	8 years ago