Commit Graph

66 Commits

Author SHA1 Message Date
Kristin Laemmert b34588ffca lang/funcs: TransposeFunc Tests
This commit adds test cases to TestTranspose to document how this function handles marks.

The short version is that any marks anywhere will be applied to the return value, be they marks on the input map or marks on elements (either the entire list of strings, or individual elemnets of those lists).
2021-04-21 16:09:09 -04:00
Martin Atkins 140c613ae8 lang/funcs: "one" function
In the Terraform language we typically use lists of zero or one values in
some sense interchangably with single values that might be null, because
various Terraform language constructs are designed to work with
collections rather than with nullable values.

In Terraform v0.12 we made the splat operator [*] have a "special power"
of concisely converting from a possibly-null single value into a
zero-or-one list as a way to make that common operation more concise.

In a sense this "one" function is the opposite operation to that special
power: it goes from a zero-or-one collection (list, set, or tuple) to a
possibly-null single value.

This is a concise alternative to the following clunky conditional
expression, with the additional benefit that the following expression is
also not viable for set values, and it also properly handles the case
where there's unexpectedly more than one value:

    length(var.foo) != 0 ? var.foo[0] : null

Instead, we can write:

    one(var.foo)

As with the splat operator, this is a tricky tradeoff because it could be
argued that it's not something that'd be immediately intuitive to someone
unfamiliar with Terraform. However, I think that's justified given how
often zero-or-one collections arise in typical Terraform configurations.
Unlike the splat operator, it should at least be easier to search for its
name and find its documentation the first time you see it in a
configuration.

My expectation that this will become a common pattern is also my
justification for giving it a short, concise name. Arguably it could be
better named something like "oneornull", but that's a pretty clunky name
and I'm not convinced it really adds any clarity for someone who isn't
already familiar with it.
2021-04-12 15:32:03 -07:00
Alisdair McDiarmid f27dae2ab7 lang: Improved robustness of sum function
Fixes error when calling sum with values not known until apply time.
Also allows sum to cope with numbers too large to represent in float64,
along with correctly handling errors when trying to sum opposing
infinities.
2020-12-10 17:13:56 -05:00
Alisdair McDiarmid df626e898c lang/funcs: Fix alltrue/anytrue with unknowns
The alltrue/anytrue functions did not correctly handle unknown values.
This commit changes these functions so that the result is unknown if:

- The list argument is unknown
- For alltrue: any elements are unknown
- For anytrue: any elements are unknown and no known elements are true

The last change is a little subtle, so there are test cases to cover it
specifically. Examples:

- anytrue(unknown) -> unknown
- anytrue(false, unknown) -> unknown
- anytrue(false, unknown, true) -> true
2020-12-10 11:36:14 -05:00
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.
2020-11-04 17:05:59 -08:00
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.
2020-10-23 13:52:48 -07:00
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.
2020-10-05 08:48:49 -04:00
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."
  }
}
```
2020-09-22 09:06:42 -04:00
Noah Mercado d4d8812afa
Feature: Sum Function (#24666)
The sum function takes a list or set of numbers and returns the sum of those
numbers.
2020-04-15 14:27:06 -04:00
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
2020-03-04 10:54:55 -05:00
James Bardin d999d43483 remove old funcs code 2020-03-03 15:23:58 -05:00
James Bardin 529271e0be update merge docs to match behavior 2020-02-05 15:47:36 -05:00
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.
2020-02-05 13:46:08 -05:00
Parviz 6eaf1c23f9 lang/funcs: don't panic when transpose produces empty result 2019-11-08 09:40:39 -08:00
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.
2019-08-01 15:52:52 -04:00
Radek Simko 5c30bafee0
Merge pull request #22119 from hashicorp/b-chunklist-empty-list
lang/funcs: Pass through empty list in chunklist
2019-07-18 20:59:47 +01:00
Radek Simko 736fda1613
lang/funcs: Pass through empty list in chunklist 2019-07-18 15:01:00 +01:00
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.
2019-07-11 20:16:24 +02:00
Pam Selle 1255ad6722 Don't allow nulls in calls to merge 2019-06-14 15:26:24 -04:00
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.
2019-06-04 08:57:02 -04:00
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.
2019-06-03 18:00:53 -04:00
Martin Atkins 55794eb658 lang/funcs: Don't panic when distinct called with empty list 2019-05-31 11:44:31 -05:00
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.
2019-05-17 08:48:02 -07:00
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.
2019-05-01 18:13:06 -04:00
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.
2019-05-01 18:03:10 -04:00
James Bardin 359f057a16 allow chunklist to handle unknowns
Chunklist should be able to return chunks containing unknown values.
2019-05-01 16:57:31 -04:00
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.
2019-05-01 16:57:31 -04:00
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.
2019-05-01 16:57:02 -04:00
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
2019-05-01 10:19:40 -04:00
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.
2019-04-30 15:49:28 -07:00
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
2019-04-12 13:57:52 -04:00
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.
2019-03-19 17:32:19 -07:00
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.
2019-01-16 09:57:16 -08:00
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.
2018-11-28 07:45:43 -08:00
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.
2018-11-06 08:33:49 -08:00
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.
2018-11-06 08:33:49 -08:00
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.
2018-11-06 08:33:49 -08:00
Radek Simko 4856d81300
lang: Fix crash in lookup function 2018-10-22 12:58:47 +02:00
Kristin Laemmert fd77e56fd6 lookup will return a tuple type when passed an object 2018-10-16 19:14:54 -07:00
Kristin Laemmert f54ee830d3 lang/funcs: update values to accept object types 2018-10-16 19:14:54 -07:00
Kristin Laemmert d1d0ede069 lang/funcs: return default value if provided when object lookup fails to find attr 2018-10-16 19:14:54 -07:00
Kristin Laemmert 46e168a682 lang/funcs: update lookup() to accept object-typed values for "map" arg 2018-10-16 19:14:54 -07:00
Martin Atkins c990c9f36d lang/funcs: Don't panic if coalescelist gets an unknown list 2018-10-16 19:14:11 -07:00
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.
2018-10-16 19:14:11 -07:00
Kristin Laemmert c23a971ed1 minor fixes 2018-10-16 18:49:20 -07:00
Kristin Laemmert a213c4a648 functions: add tests and support for unknown values 2018-10-16 18:49:20 -07:00
Kristin Laemmert d802d5c624 functions: pr feedback fixes 2018-10-16 18:49:20 -07:00
Kristin Laemmert ff4b3d763b functions: fix lookup()'s handling of numberical defaults 2018-10-16 18:49:20 -07:00
Kristin Laemmert 4f5c03339a functions: ZipmapFunc 2018-10-16 18:49:20 -07:00
Kristin Laemmert 605e23db6b various code review fixes 2018-10-16 18:49:20 -07:00