ResiLien
/
terraform
2
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
terraform/lang/functions.go

170 lines
6.7 KiB
Go
Raw Normal View History

lang: new package for the runtime parts of the config language Whereas package "configs" deals with the static structure of the configuration language, this new package "lang" deals with the dynamic aspects such as expression evaluation. So far this mainly consists of populating a hcl.EvalContext that contains the values necessary to evaluate a block or an expression. There is also special handling here for dynamic block generation using the HCL "dynblock" extension, which is exposed in the public interface (rather than hiding it as an implementation detail of EvalBlock) so that the caller can then extract proper source locations for any result values using the expanded body. This also includes the beginnings of a replacement for the function table handling that currently lives in the old "config" package, but most of the functions are not yet ported and so this will expand in subsequent commits.
2018-04-04 03:11:28 +02:00
package lang
import (
"fmt"
lang: "try" and "can" functions These are intended to make it easier to work with arbitrary data structures whose shape might not be known statically, such as the result of jsondecode(...) or yamldecode(...) of data from a separate system. For example, in an object value which has attributes that may or may not be set we can concisely provide a fallback value to use when the attribute isn't set: try(local.example.foo, "fallback-foo") Using a "try to evaluate" model rather than explicit testing fits better with the usual programming model of the Terraform language where values are normally automatically converted to the necessary type where possible: the given expression is subject to all of the same normal type conversions, which avoids inadvertently creating a more restrictive evaluation model as might happen if this were handled using checks like a hypothetical isobject(...) function, etc.
2020-01-03 23:01:14 +01:00
"github.com/hashicorp/hcl/v2/ext/tryfunc"
lang: yamldecode and yamlencode functions These follow the same principle as jsondecode and jsonencode, but use YAML instead of JSON. YAML has a much more complex information model than JSON, so we can only support a subset of it during decoding, but hopefully the subset supported here is a useful one. Because there are many different ways to _generate_ YAML, the yamlencode function is forced to make some decisions, and those decisions are likely to affect compatibility with other real-world YAML parsers. Although the format here is intended to be generic and compatible, we may find that there are problems with it that'll we'll want to adjust for in a future release, so yamlencode is therefore marked as experimental for now until the underlying library is ready to commit to ongoing byte-for-byte compatibility in serialization. The main use-case here is met by yamldecode, which will allow reading in files written in YAML format by humans for use in Terraform modules, in situations where a higher-level input format than direct Terraform language declarations is helpful.
2019-05-26 19:25:18 +02:00
ctyyaml "github.com/zclconf/go-cty-yaml"
lang: new package for the runtime parts of the config language Whereas package "configs" deals with the static structure of the configuration language, this new package "lang" deals with the dynamic aspects such as expression evaluation. So far this mainly consists of populating a hcl.EvalContext that contains the values necessary to evaluate a block or an expression. There is also special handling here for dynamic block generation using the HCL "dynblock" extension, which is exposed in the public interface (rather than hiding it as an implementation detail of EvalBlock) so that the caller can then extract proper source locations for any result values using the expanded body. This also includes the beginnings of a replacement for the function table handling that currently lives in the old "config" package, but most of the functions are not yet ported and so this will expand in subsequent commits.
2018-04-04 03:11:28 +02:00
"github.com/zclconf/go-cty/cty"
"github.com/zclconf/go-cty/cty/function"
"github.com/zclconf/go-cty/cty/function/stdlib"
lang/funcs: port some of Terraform's built-in functions These implementations are adaptations of the existing implementations in config/interpolate_funcs.go, updated to work with the cty API. The set of functions chosen here was motivated mainly by what Terraform's existing context tests depend on, so we can get the contexts tests back into good shape before fleshing out the rest of these functions.
2018-05-22 02:39:26 +02:00
"github.com/hashicorp/terraform/lang/funcs"
lang: new package for the runtime parts of the config language Whereas package "configs" deals with the static structure of the configuration language, this new package "lang" deals with the dynamic aspects such as expression evaluation. So far this mainly consists of populating a hcl.EvalContext that contains the values necessary to evaluate a block or an expression. There is also special handling here for dynamic block generation using the HCL "dynblock" extension, which is exposed in the public interface (rather than hiding it as an implementation detail of EvalBlock) so that the caller can then extract proper source locations for any result values using the expanded body. This also includes the beginnings of a replacement for the function table handling that currently lives in the old "config" package, but most of the functions are not yet ported and so this will expand in subsequent commits.
2018-04-04 03:11:28 +02:00
)
var impureFunctions = []string{
cleanup comments for nicer godocs
2018-05-23 18:38:12 +02:00
"bcrypt",
lang: new package for the runtime parts of the config language Whereas package "configs" deals with the static structure of the configuration language, this new package "lang" deals with the dynamic aspects such as expression evaluation. So far this mainly consists of populating a hcl.EvalContext that contains the values necessary to evaluate a block or an expression. There is also special handling here for dynamic block generation using the HCL "dynblock" extension, which is exposed in the public interface (rather than hiding it as an implementation detail of EvalBlock) so that the caller can then extract proper source locations for any result values using the expanded body. This also includes the beginnings of a replacement for the function table handling that currently lives in the old "config" package, but most of the functions are not yet ported and so this will expand in subsequent commits.
2018-04-04 03:11:28 +02:00
"timestamp",
"uuid",
}
// Functions returns the set of functions that should be used to when evaluating
// expressions in the receiving scope.
func (s *Scope) Functions() map[string]function.Function {
s.funcsLock.Lock()
if s.funcs == nil {
lang/funcs: port some of Terraform's built-in functions These implementations are adaptations of the existing implementations in config/interpolate_funcs.go, updated to work with the cty API. The set of functions chosen here was motivated mainly by what Terraform's existing context tests depend on, so we can get the contexts tests back into good shape before fleshing out the rest of these functions.
2018-05-22 02:39:26 +02:00
// Some of our functions are just directly the cty stdlib functions.
// Others are implemented in the subdirectory "funcs" here in this
// repository. New functions should generally start out their lives
// in the "funcs" directory and potentially graduate to cty stdlib
// later if the functionality seems to be something domain-agnostic
// that would be useful to all applications using cty functions.
lang: new package for the runtime parts of the config language Whereas package "configs" deals with the static structure of the configuration language, this new package "lang" deals with the dynamic aspects such as expression evaluation. So far this mainly consists of populating a hcl.EvalContext that contains the values necessary to evaluate a block or an expression. There is also special handling here for dynamic block generation using the HCL "dynblock" extension, which is exposed in the public interface (rather than hiding it as an implementation detail of EvalBlock) so that the caller can then extract proper source locations for any result values using the expanded body. This also includes the beginnings of a replacement for the function table handling that currently lives in the old "config" package, but most of the functions are not yet ported and so this will expand in subsequent commits.
2018-04-04 03:11:28 +02:00
s.funcs = map[string]function.Function{
lang: New file-hashing functions In prior versions, we recommended using hash functions in conjunction with the file function as an idiom for detecting changes to upstream blobs without fetching and comparing the whole blob. That approach relied on us being able to return raw binary data from file(...). Since Terraform strings pass through intermediate representations that are not binary-safe (e.g. the JSON state), there was a risk of string corruption in prior versions which we have avoided for 0.12 by requiring that file(...) be used only with UTF-8 text files. The specific case of returning a string and immediately passing it into another function was not actually subject to that corruption risk, since the HIL interpreter would just pass the string through verbatim, but this is still now forbidden as a result of the stricter handling of file(...). To avoid breaking these use-cases, here we introduce variants of the hash functions a with "file" prefix that take a filename for a disk file to hash rather than hashing the given string directly. The configuration upgrade tool also now includes a rule to detect the documented idiom and rewrite it into a single function call for one of these new functions. This does cause a bit of function sprawl, but that seems preferable to introducing more complex rules for when file(...) can and cannot read binary files, making the behavior of these various functions easier to understand in isolation.
2019-01-25 18:16:43 +01:00
"abs": stdlib.AbsoluteFunc,
lang/funcs: add "abspath" function (#21409)
2019-07-02 14:30:30 +02:00
"abspath": funcs.AbsPathFunc,
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 15:06:42 +02:00
"alltrue": funcs.AllTrueFunc,
lang: New file-hashing functions In prior versions, we recommended using hash functions in conjunction with the file function as an idiom for detecting changes to upstream blobs without fetching and comparing the whole blob. That approach relied on us being able to return raw binary data from file(...). Since Terraform strings pass through intermediate representations that are not binary-safe (e.g. the JSON state), there was a risk of string corruption in prior versions which we have avoided for 0.12 by requiring that file(...) be used only with UTF-8 text files. The specific case of returning a string and immediately passing it into another function was not actually subject to that corruption risk, since the HIL interpreter would just pass the string through verbatim, but this is still now forbidden as a result of the stricter handling of file(...). To avoid breaking these use-cases, here we introduce variants of the hash functions a with "file" prefix that take a filename for a disk file to hash rather than hashing the given string directly. The configuration upgrade tool also now includes a rule to detect the documented idiom and rewrite it into a single function call for one of these new functions. This does cause a bit of function sprawl, but that seems preferable to introducing more complex rules for when file(...) can and cannot read binary files, making the behavior of these various functions easier to understand in isolation.
2019-01-25 18:16:43 +01:00
"basename": funcs.BasenameFunc,
"base64decode": funcs.Base64DecodeFunc,
"base64encode": funcs.Base64EncodeFunc,
"base64gzip": funcs.Base64GzipFunc,
"base64sha256": funcs.Base64Sha256Func,
"base64sha512": funcs.Base64Sha512Func,
"bcrypt": funcs.BcryptFunc,
lang: "try" and "can" functions These are intended to make it easier to work with arbitrary data structures whose shape might not be known statically, such as the result of jsondecode(...) or yamldecode(...) of data from a separate system. For example, in an object value which has attributes that may or may not be set we can concisely provide a fallback value to use when the attribute isn't set: try(local.example.foo, "fallback-foo") Using a "try to evaluate" model rather than explicit testing fits better with the usual programming model of the Terraform language where values are normally automatically converted to the necessary type where possible: the given expression is subject to all of the same normal type conversions, which avoids inadvertently creating a more restrictive evaluation model as might happen if this were handled using checks like a hypothetical isobject(...) function, etc.
2020-01-03 23:01:14 +01:00
"can": tryfunc.CanFunc,
convert cty func calls to stdlib
2020-02-24 15:29:04 +01:00
"ceil": stdlib.CeilFunc,
"chomp": stdlib.ChompFunc,
lang: New file-hashing functions In prior versions, we recommended using hash functions in conjunction with the file function as an idiom for detecting changes to upstream blobs without fetching and comparing the whole blob. That approach relied on us being able to return raw binary data from file(...). Since Terraform strings pass through intermediate representations that are not binary-safe (e.g. the JSON state), there was a risk of string corruption in prior versions which we have avoided for 0.12 by requiring that file(...) be used only with UTF-8 text files. The specific case of returning a string and immediately passing it into another function was not actually subject to that corruption risk, since the HIL interpreter would just pass the string through verbatim, but this is still now forbidden as a result of the stricter handling of file(...). To avoid breaking these use-cases, here we introduce variants of the hash functions a with "file" prefix that take a filename for a disk file to hash rather than hashing the given string directly. The configuration upgrade tool also now includes a rule to detect the documented idiom and rewrite it into a single function call for one of these new functions. This does cause a bit of function sprawl, but that seems preferable to introducing more complex rules for when file(...) can and cannot read binary files, making the behavior of these various functions easier to understand in isolation.
2019-01-25 18:16:43 +01:00
"cidrhost": funcs.CidrHostFunc,
"cidrnetmask": funcs.CidrNetmaskFunc,
"cidrsubnet": funcs.CidrSubnetFunc,
lang/funcs: cidrsubnets function This is a companion to cidrsubnet that allows bulk-allocation of multiple subnet addresses at once, with automatic numbering. Unlike cidrsubnet, cidrsubnets allows each of the allocations to have a different prefix length, and will pack the networks consecutively into the given address space. cidrsubnets can potentially create more complicated addressing schemes than cidrsubnet alone can, because it's able to take into account the full set of requested prefix lengths rather than just one at a time.
2019-09-20 04:06:15 +02:00
"cidrsubnets": funcs.CidrSubnetsFunc,
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 19:57:52 +02:00
"coalesce": funcs.CoalesceFunc,
convert cty func calls to stdlib
2020-02-24 15:29:04 +01:00
"coalescelist": stdlib.CoalesceListFunc,
"compact": stdlib.CompactFunc,
lang: New file-hashing functions In prior versions, we recommended using hash functions in conjunction with the file function as an idiom for detecting changes to upstream blobs without fetching and comparing the whole blob. That approach relied on us being able to return raw binary data from file(...). Since Terraform strings pass through intermediate representations that are not binary-safe (e.g. the JSON state), there was a risk of string corruption in prior versions which we have avoided for 0.12 by requiring that file(...) be used only with UTF-8 text files. The specific case of returning a string and immediately passing it into another function was not actually subject to that corruption risk, since the HIL interpreter would just pass the string through verbatim, but this is still now forbidden as a result of the stricter handling of file(...). To avoid breaking these use-cases, here we introduce variants of the hash functions a with "file" prefix that take a filename for a disk file to hash rather than hashing the given string directly. The configuration upgrade tool also now includes a rule to detect the documented idiom and rewrite it into a single function call for one of these new functions. This does cause a bit of function sprawl, but that seems preferable to introducing more complex rules for when file(...) can and cannot read binary files, making the behavior of these various functions easier to understand in isolation.
2019-01-25 18:16:43 +01:00
"concat": stdlib.ConcatFunc,
convert cty func calls to stdlib
2020-02-24 15:29:04 +01:00
"contains": stdlib.ContainsFunc,
lang: New file-hashing functions In prior versions, we recommended using hash functions in conjunction with the file function as an idiom for detecting changes to upstream blobs without fetching and comparing the whole blob. That approach relied on us being able to return raw binary data from file(...). Since Terraform strings pass through intermediate representations that are not binary-safe (e.g. the JSON state), there was a risk of string corruption in prior versions which we have avoided for 0.12 by requiring that file(...) be used only with UTF-8 text files. The specific case of returning a string and immediately passing it into another function was not actually subject to that corruption risk, since the HIL interpreter would just pass the string through verbatim, but this is still now forbidden as a result of the stricter handling of file(...). To avoid breaking these use-cases, here we introduce variants of the hash functions a with "file" prefix that take a filename for a disk file to hash rather than hashing the given string directly. The configuration upgrade tool also now includes a rule to detect the documented idiom and rewrite it into a single function call for one of these new functions. This does cause a bit of function sprawl, but that seems preferable to introducing more complex rules for when file(...) can and cannot read binary files, making the behavior of these various functions easier to understand in isolation.
2019-01-25 18:16:43 +01:00
"csvdecode": stdlib.CSVDecodeFunc,
"dirname": funcs.DirnameFunc,
convert cty func calls to stdlib
2020-02-24 15:29:04 +01:00
"distinct": stdlib.DistinctFunc,
"element": stdlib.ElementFunc,
"chunklist": stdlib.ChunklistFunc,
lang: New file-hashing functions In prior versions, we recommended using hash functions in conjunction with the file function as an idiom for detecting changes to upstream blobs without fetching and comparing the whole blob. That approach relied on us being able to return raw binary data from file(...). Since Terraform strings pass through intermediate representations that are not binary-safe (e.g. the JSON state), there was a risk of string corruption in prior versions which we have avoided for 0.12 by requiring that file(...) be used only with UTF-8 text files. The specific case of returning a string and immediately passing it into another function was not actually subject to that corruption risk, since the HIL interpreter would just pass the string through verbatim, but this is still now forbidden as a result of the stricter handling of file(...). To avoid breaking these use-cases, here we introduce variants of the hash functions a with "file" prefix that take a filename for a disk file to hash rather than hashing the given string directly. The configuration upgrade tool also now includes a rule to detect the documented idiom and rewrite it into a single function call for one of these new functions. This does cause a bit of function sprawl, but that seems preferable to introducing more complex rules for when file(...) can and cannot read binary files, making the behavior of these various functions easier to understand in isolation.
2019-01-25 18:16:43 +01:00
"file": funcs.MakeFileFunc(s.BaseDir, false),
"fileexists": funcs.MakeFileExistsFunc(s.BaseDir),
lang/funcs: Add fileset function Reference: https://github.com/hashicorp/terraform/issues/16697 Enumerates a set of regular file names from a given glob pattern. Implemented via the Go stdlib `path/filepath.Glob()` functionality. Notably, stdlib does not support `**` or `{}` extended patterns. See also: https://github.com/golang/go/issues/11862 To support the extended glob patterns, it will require adding a dependency on a third party library or adding our own matching code.
2019-08-20 10:50:01 +02:00
"fileset": funcs.MakeFileSetFunc(s.BaseDir),
lang: New file-hashing functions In prior versions, we recommended using hash functions in conjunction with the file function as an idiom for detecting changes to upstream blobs without fetching and comparing the whole blob. That approach relied on us being able to return raw binary data from file(...). Since Terraform strings pass through intermediate representations that are not binary-safe (e.g. the JSON state), there was a risk of string corruption in prior versions which we have avoided for 0.12 by requiring that file(...) be used only with UTF-8 text files. The specific case of returning a string and immediately passing it into another function was not actually subject to that corruption risk, since the HIL interpreter would just pass the string through verbatim, but this is still now forbidden as a result of the stricter handling of file(...). To avoid breaking these use-cases, here we introduce variants of the hash functions a with "file" prefix that take a filename for a disk file to hash rather than hashing the given string directly. The configuration upgrade tool also now includes a rule to detect the documented idiom and rewrite it into a single function call for one of these new functions. This does cause a bit of function sprawl, but that seems preferable to introducing more complex rules for when file(...) can and cannot read binary files, making the behavior of these various functions easier to understand in isolation.
2019-01-25 18:16:43 +01:00
"filebase64": funcs.MakeFileFunc(s.BaseDir, true),
"filebase64sha256": funcs.MakeFileBase64Sha256Func(s.BaseDir),
"filebase64sha512": funcs.MakeFileBase64Sha512Func(s.BaseDir),
"filemd5": funcs.MakeFileMd5Func(s.BaseDir),
"filesha1": funcs.MakeFileSha1Func(s.BaseDir),
"filesha256": funcs.MakeFileSha256Func(s.BaseDir),
"filesha512": funcs.MakeFileSha512Func(s.BaseDir),
convert cty func calls to stdlib
2020-02-24 15:29:04 +01:00
"flatten": stdlib.FlattenFunc,
"floor": stdlib.FloorFunc,
lang: New file-hashing functions In prior versions, we recommended using hash functions in conjunction with the file function as an idiom for detecting changes to upstream blobs without fetching and comparing the whole blob. That approach relied on us being able to return raw binary data from file(...). Since Terraform strings pass through intermediate representations that are not binary-safe (e.g. the JSON state), there was a risk of string corruption in prior versions which we have avoided for 0.12 by requiring that file(...) be used only with UTF-8 text files. The specific case of returning a string and immediately passing it into another function was not actually subject to that corruption risk, since the HIL interpreter would just pass the string through verbatim, but this is still now forbidden as a result of the stricter handling of file(...). To avoid breaking these use-cases, here we introduce variants of the hash functions a with "file" prefix that take a filename for a disk file to hash rather than hashing the given string directly. The configuration upgrade tool also now includes a rule to detect the documented idiom and rewrite it into a single function call for one of these new functions. This does cause a bit of function sprawl, but that seems preferable to introducing more complex rules for when file(...) can and cannot read binary files, making the behavior of these various functions easier to understand in isolation.
2019-01-25 18:16:43 +01:00
"format": stdlib.FormatFunc,
"formatdate": stdlib.FormatDateFunc,
"formatlist": stdlib.FormatListFunc,
convert cty func calls to stdlib
2020-02-24 15:29:04 +01:00
"indent": stdlib.IndentFunc,
"index": funcs.IndexFunc, // stdlib.IndexFunc is not compatible
"join": stdlib.JoinFunc,
lang: New file-hashing functions In prior versions, we recommended using hash functions in conjunction with the file function as an idiom for detecting changes to upstream blobs without fetching and comparing the whole blob. That approach relied on us being able to return raw binary data from file(...). Since Terraform strings pass through intermediate representations that are not binary-safe (e.g. the JSON state), there was a risk of string corruption in prior versions which we have avoided for 0.12 by requiring that file(...) be used only with UTF-8 text files. The specific case of returning a string and immediately passing it into another function was not actually subject to that corruption risk, since the HIL interpreter would just pass the string through verbatim, but this is still now forbidden as a result of the stricter handling of file(...). To avoid breaking these use-cases, here we introduce variants of the hash functions a with "file" prefix that take a filename for a disk file to hash rather than hashing the given string directly. The configuration upgrade tool also now includes a rule to detect the documented idiom and rewrite it into a single function call for one of these new functions. This does cause a bit of function sprawl, but that seems preferable to introducing more complex rules for when file(...) can and cannot read binary files, making the behavior of these various functions easier to understand in isolation.
2019-01-25 18:16:43 +01:00
"jsondecode": stdlib.JSONDecodeFunc,
"jsonencode": stdlib.JSONEncodeFunc,
convert cty func calls to stdlib
2020-02-24 15:29:04 +01:00
"keys": stdlib.KeysFunc,
lang: New file-hashing functions In prior versions, we recommended using hash functions in conjunction with the file function as an idiom for detecting changes to upstream blobs without fetching and comparing the whole blob. That approach relied on us being able to return raw binary data from file(...). Since Terraform strings pass through intermediate representations that are not binary-safe (e.g. the JSON state), there was a risk of string corruption in prior versions which we have avoided for 0.12 by requiring that file(...) be used only with UTF-8 text files. The specific case of returning a string and immediately passing it into another function was not actually subject to that corruption risk, since the HIL interpreter would just pass the string through verbatim, but this is still now forbidden as a result of the stricter handling of file(...). To avoid breaking these use-cases, here we introduce variants of the hash functions a with "file" prefix that take a filename for a disk file to hash rather than hashing the given string directly. The configuration upgrade tool also now includes a rule to detect the documented idiom and rewrite it into a single function call for one of these new functions. This does cause a bit of function sprawl, but that seems preferable to introducing more complex rules for when file(...) can and cannot read binary files, making the behavior of these various functions easier to understand in isolation.
2019-01-25 18:16:43 +01:00
"length": funcs.LengthFunc,
"list": funcs.ListFunc,
convert cty func calls to stdlib
2020-02-24 15:29:04 +01:00
"log": stdlib.LogFunc,
lang: New file-hashing functions In prior versions, we recommended using hash functions in conjunction with the file function as an idiom for detecting changes to upstream blobs without fetching and comparing the whole blob. That approach relied on us being able to return raw binary data from file(...). Since Terraform strings pass through intermediate representations that are not binary-safe (e.g. the JSON state), there was a risk of string corruption in prior versions which we have avoided for 0.12 by requiring that file(...) be used only with UTF-8 text files. The specific case of returning a string and immediately passing it into another function was not actually subject to that corruption risk, since the HIL interpreter would just pass the string through verbatim, but this is still now forbidden as a result of the stricter handling of file(...). To avoid breaking these use-cases, here we introduce variants of the hash functions a with "file" prefix that take a filename for a disk file to hash rather than hashing the given string directly. The configuration upgrade tool also now includes a rule to detect the documented idiom and rewrite it into a single function call for one of these new functions. This does cause a bit of function sprawl, but that seems preferable to introducing more complex rules for when file(...) can and cannot read binary files, making the behavior of these various functions easier to understand in isolation.
2019-01-25 18:16:43 +01:00
"lookup": funcs.LookupFunc,
"lower": stdlib.LowerFunc,
"map": funcs.MapFunc,
"matchkeys": funcs.MatchkeysFunc,
"max": stdlib.MaxFunc,
"md5": funcs.Md5Func,
convert cty func calls to stdlib
2020-02-24 15:29:04 +01:00
"merge": stdlib.MergeFunc,
lang: New file-hashing functions In prior versions, we recommended using hash functions in conjunction with the file function as an idiom for detecting changes to upstream blobs without fetching and comparing the whole blob. That approach relied on us being able to return raw binary data from file(...). Since Terraform strings pass through intermediate representations that are not binary-safe (e.g. the JSON state), there was a risk of string corruption in prior versions which we have avoided for 0.12 by requiring that file(...) be used only with UTF-8 text files. The specific case of returning a string and immediately passing it into another function was not actually subject to that corruption risk, since the HIL interpreter would just pass the string through verbatim, but this is still now forbidden as a result of the stricter handling of file(...). To avoid breaking these use-cases, here we introduce variants of the hash functions a with "file" prefix that take a filename for a disk file to hash rather than hashing the given string directly. The configuration upgrade tool also now includes a rule to detect the documented idiom and rewrite it into a single function call for one of these new functions. This does cause a bit of function sprawl, but that seems preferable to introducing more complex rules for when file(...) can and cannot read binary files, making the behavior of these various functions easier to understand in isolation.
2019-01-25 18:16:43 +01:00
"min": stdlib.MinFunc,
convert cty func calls to stdlib
2020-02-24 15:29:04 +01:00
"parseint": stdlib.ParseIntFunc,
lang: New file-hashing functions In prior versions, we recommended using hash functions in conjunction with the file function as an idiom for detecting changes to upstream blobs without fetching and comparing the whole blob. That approach relied on us being able to return raw binary data from file(...). Since Terraform strings pass through intermediate representations that are not binary-safe (e.g. the JSON state), there was a risk of string corruption in prior versions which we have avoided for 0.12 by requiring that file(...) be used only with UTF-8 text files. The specific case of returning a string and immediately passing it into another function was not actually subject to that corruption risk, since the HIL interpreter would just pass the string through verbatim, but this is still now forbidden as a result of the stricter handling of file(...). To avoid breaking these use-cases, here we introduce variants of the hash functions a with "file" prefix that take a filename for a disk file to hash rather than hashing the given string directly. The configuration upgrade tool also now includes a rule to detect the documented idiom and rewrite it into a single function call for one of these new functions. This does cause a bit of function sprawl, but that seems preferable to introducing more complex rules for when file(...) can and cannot read binary files, making the behavior of these various functions easier to understand in isolation.
2019-01-25 18:16:43 +01:00
"pathexpand": funcs.PathExpandFunc,
convert cty func calls to stdlib
2020-02-24 15:29:04 +01:00
"pow": stdlib.PowFunc,
lang: "range" function This is similar to the function of the same name in Python, generating a sequence of numbers as a list that can then be used in other sequence-oriented operations. The primary use-case for it is to turn a count expressed as a number into a list of that length, which can then be iterated over or passed to a collection function to produce that number of something else, as shown in the example at the end of its documentation page.
2019-05-26 22:09:44 +02:00
"range": stdlib.RangeFunc,
lang: "regex" and "regexall" functions These existing upstream cty functions allow matching strings against regular expression patterns, which can be useful if you need to consume a non-standard string format that Terraform doesn't (and can't) have a built-in function for.
2019-08-06 17:21:22 +02:00
"regex": stdlib.RegexFunc,
"regexall": stdlib.RegexAllFunc,
lang: New file-hashing functions In prior versions, we recommended using hash functions in conjunction with the file function as an idiom for detecting changes to upstream blobs without fetching and comparing the whole blob. That approach relied on us being able to return raw binary data from file(...). Since Terraform strings pass through intermediate representations that are not binary-safe (e.g. the JSON state), there was a risk of string corruption in prior versions which we have avoided for 0.12 by requiring that file(...) be used only with UTF-8 text files. The specific case of returning a string and immediately passing it into another function was not actually subject to that corruption risk, since the HIL interpreter would just pass the string through verbatim, but this is still now forbidden as a result of the stricter handling of file(...). To avoid breaking these use-cases, here we introduce variants of the hash functions a with "file" prefix that take a filename for a disk file to hash rather than hashing the given string directly. The configuration upgrade tool also now includes a rule to detect the documented idiom and rewrite it into a single function call for one of these new functions. This does cause a bit of function sprawl, but that seems preferable to introducing more complex rules for when file(...) can and cannot read binary files, making the behavior of these various functions easier to understand in isolation.
2019-01-25 18:16:43 +01:00
"replace": funcs.ReplaceFunc,
convert cty func calls to stdlib
2020-02-24 15:29:04 +01:00
"reverse": stdlib.ReverseListFunc,
lang: New file-hashing functions In prior versions, we recommended using hash functions in conjunction with the file function as an idiom for detecting changes to upstream blobs without fetching and comparing the whole blob. That approach relied on us being able to return raw binary data from file(...). Since Terraform strings pass through intermediate representations that are not binary-safe (e.g. the JSON state), there was a risk of string corruption in prior versions which we have avoided for 0.12 by requiring that file(...) be used only with UTF-8 text files. The specific case of returning a string and immediately passing it into another function was not actually subject to that corruption risk, since the HIL interpreter would just pass the string through verbatim, but this is still now forbidden as a result of the stricter handling of file(...). To avoid breaking these use-cases, here we introduce variants of the hash functions a with "file" prefix that take a filename for a disk file to hash rather than hashing the given string directly. The configuration upgrade tool also now includes a rule to detect the documented idiom and rewrite it into a single function call for one of these new functions. This does cause a bit of function sprawl, but that seems preferable to introducing more complex rules for when file(...) can and cannot read binary files, making the behavior of these various functions easier to understand in isolation.
2019-01-25 18:16:43 +01:00
"rsadecrypt": funcs.RsaDecryptFunc,
"setintersection": stdlib.SetIntersectionFunc,
convert cty func calls to stdlib
2020-02-24 15:29:04 +01:00
"setproduct": stdlib.SetProductFunc,
lang: add setsubtract function (#23424) * add setdifference and setsubtract functions and docs * remove setdifference as it is not implemented correct in underlying lib * Update setintersection.html.md * Update setproduct.html.md * Update setunion.html.md
2020-02-06 18:49:11 +01:00
"setsubtract": stdlib.SetSubtractFunc,
lang: New file-hashing functions In prior versions, we recommended using hash functions in conjunction with the file function as an idiom for detecting changes to upstream blobs without fetching and comparing the whole blob. That approach relied on us being able to return raw binary data from file(...). Since Terraform strings pass through intermediate representations that are not binary-safe (e.g. the JSON state), there was a risk of string corruption in prior versions which we have avoided for 0.12 by requiring that file(...) be used only with UTF-8 text files. The specific case of returning a string and immediately passing it into another function was not actually subject to that corruption risk, since the HIL interpreter would just pass the string through verbatim, but this is still now forbidden as a result of the stricter handling of file(...). To avoid breaking these use-cases, here we introduce variants of the hash functions a with "file" prefix that take a filename for a disk file to hash rather than hashing the given string directly. The configuration upgrade tool also now includes a rule to detect the documented idiom and rewrite it into a single function call for one of these new functions. This does cause a bit of function sprawl, but that seems preferable to introducing more complex rules for when file(...) can and cannot read binary files, making the behavior of these various functions easier to understand in isolation.
2019-01-25 18:16:43 +01:00
"setunion": stdlib.SetUnionFunc,
"sha1": funcs.Sha1Func,
"sha256": funcs.Sha256Func,
"sha512": funcs.Sha512Func,
convert cty func calls to stdlib
2020-02-24 15:29:04 +01:00
"signum": stdlib.SignumFunc,
"slice": stdlib.SliceFunc,
"sort": stdlib.SortFunc,
"split": stdlib.SplitFunc,
lang/funcs: add 'strrev' interpolation function. (#21091)
2019-04-24 20:52:39 +02:00
"strrev": stdlib.ReverseFunc,
lang: New file-hashing functions In prior versions, we recommended using hash functions in conjunction with the file function as an idiom for detecting changes to upstream blobs without fetching and comparing the whole blob. That approach relied on us being able to return raw binary data from file(...). Since Terraform strings pass through intermediate representations that are not binary-safe (e.g. the JSON state), there was a risk of string corruption in prior versions which we have avoided for 0.12 by requiring that file(...) be used only with UTF-8 text files. The specific case of returning a string and immediately passing it into another function was not actually subject to that corruption risk, since the HIL interpreter would just pass the string through verbatim, but this is still now forbidden as a result of the stricter handling of file(...). To avoid breaking these use-cases, here we introduce variants of the hash functions a with "file" prefix that take a filename for a disk file to hash rather than hashing the given string directly. The configuration upgrade tool also now includes a rule to detect the documented idiom and rewrite it into a single function call for one of these new functions. This does cause a bit of function sprawl, but that seems preferable to introducing more complex rules for when file(...) can and cannot read binary files, making the behavior of these various functions easier to understand in isolation.
2019-01-25 18:16:43 +01:00
"substr": stdlib.SubstrFunc,
Feature: Sum Function (#24666) The sum function takes a list or set of numbers and returns the sum of those numbers.
2020-04-15 20:27:06 +02:00
"sum": funcs.SumFunc,
lang/funcs: Rename the base64 character encoding functions These were initially introduced as functions with "encode" and "decode" prefixes, but that doesn't match with our existing convention of putting the encoding format first so that the encode and decode functions will group together in a alphabetically-ordered function list. "text" is not really a defined serialization format, but it's a short word that hopefully represents well enough what these functions are aiming to encode and decode, while being consistent with existing functions like jsonencode/jsondecode, yamlencode/yamldecode, etc. The "base64" at the end here is less convincing because there is precedent for that modifier to appear both at the beginning and the end in our existing function names. I chose to put it at the end here because that seems to be our emergent convention for situations where the base64 encoding is a sort of secondary modifier alongside the primary purpose of the function, as we see with "filebase64". (base64gzip is an exception here, but it seems outvoted by the others.)
2020-10-21 19:56:56 +02:00
"textdecodebase64": funcs.TextDecodeBase64Func,
"textencodebase64": funcs.TextEncodeBase64Func,
lang: New file-hashing functions In prior versions, we recommended using hash functions in conjunction with the file function as an idiom for detecting changes to upstream blobs without fetching and comparing the whole blob. That approach relied on us being able to return raw binary data from file(...). Since Terraform strings pass through intermediate representations that are not binary-safe (e.g. the JSON state), there was a risk of string corruption in prior versions which we have avoided for 0.12 by requiring that file(...) be used only with UTF-8 text files. The specific case of returning a string and immediately passing it into another function was not actually subject to that corruption risk, since the HIL interpreter would just pass the string through verbatim, but this is still now forbidden as a result of the stricter handling of file(...). To avoid breaking these use-cases, here we introduce variants of the hash functions a with "file" prefix that take a filename for a disk file to hash rather than hashing the given string directly. The configuration upgrade tool also now includes a rule to detect the documented idiom and rewrite it into a single function call for one of these new functions. This does cause a bit of function sprawl, but that seems preferable to introducing more complex rules for when file(...) can and cannot read binary files, making the behavior of these various functions easier to understand in isolation.
2019-01-25 18:16:43 +01:00
"timestamp": funcs.TimestampFunc,
convert cty func calls to stdlib
2020-02-24 15:29:04 +01:00
"timeadd": stdlib.TimeAddFunc,
"title": stdlib.TitleFunc,
lang: New file-hashing functions In prior versions, we recommended using hash functions in conjunction with the file function as an idiom for detecting changes to upstream blobs without fetching and comparing the whole blob. That approach relied on us being able to return raw binary data from file(...). Since Terraform strings pass through intermediate representations that are not binary-safe (e.g. the JSON state), there was a risk of string corruption in prior versions which we have avoided for 0.12 by requiring that file(...) be used only with UTF-8 text files. The specific case of returning a string and immediately passing it into another function was not actually subject to that corruption risk, since the HIL interpreter would just pass the string through verbatim, but this is still now forbidden as a result of the stricter handling of file(...). To avoid breaking these use-cases, here we introduce variants of the hash functions a with "file" prefix that take a filename for a disk file to hash rather than hashing the given string directly. The configuration upgrade tool also now includes a rule to detect the documented idiom and rewrite it into a single function call for one of these new functions. This does cause a bit of function sprawl, but that seems preferable to introducing more complex rules for when file(...) can and cannot read binary files, making the behavior of these various functions easier to understand in isolation.
2019-01-25 18:16:43 +01:00
"tostring": funcs.MakeToFunc(cty.String),
"tonumber": funcs.MakeToFunc(cty.Number),
"tobool": funcs.MakeToFunc(cty.Bool),
"toset": funcs.MakeToFunc(cty.Set(cty.DynamicPseudoType)),
"tolist": funcs.MakeToFunc(cty.List(cty.DynamicPseudoType)),
"tomap": funcs.MakeToFunc(cty.Map(cty.DynamicPseudoType)),
"transpose": funcs.TransposeFunc,
convert cty func calls to stdlib
2020-02-24 15:29:04 +01:00
"trim": stdlib.TrimFunc,
"trimprefix": stdlib.TrimPrefixFunc,
"trimspace": stdlib.TrimSpaceFunc,
"trimsuffix": stdlib.TrimSuffixFunc,
lang: "try" and "can" functions These are intended to make it easier to work with arbitrary data structures whose shape might not be known statically, such as the result of jsondecode(...) or yamldecode(...) of data from a separate system. For example, in an object value which has attributes that may or may not be set we can concisely provide a fallback value to use when the attribute isn't set: try(local.example.foo, "fallback-foo") Using a "try to evaluate" model rather than explicit testing fits better with the usual programming model of the Terraform language where values are normally automatically converted to the necessary type where possible: the given expression is subject to all of the same normal type conversions, which avoids inadvertently creating a more restrictive evaluation model as might happen if this were handled using checks like a hypothetical isobject(...) function, etc.
2020-01-03 23:01:14 +01:00
"try": tryfunc.TryFunc,
lang: New file-hashing functions In prior versions, we recommended using hash functions in conjunction with the file function as an idiom for detecting changes to upstream blobs without fetching and comparing the whole blob. That approach relied on us being able to return raw binary data from file(...). Since Terraform strings pass through intermediate representations that are not binary-safe (e.g. the JSON state), there was a risk of string corruption in prior versions which we have avoided for 0.12 by requiring that file(...) be used only with UTF-8 text files. The specific case of returning a string and immediately passing it into another function was not actually subject to that corruption risk, since the HIL interpreter would just pass the string through verbatim, but this is still now forbidden as a result of the stricter handling of file(...). To avoid breaking these use-cases, here we introduce variants of the hash functions a with "file" prefix that take a filename for a disk file to hash rather than hashing the given string directly. The configuration upgrade tool also now includes a rule to detect the documented idiom and rewrite it into a single function call for one of these new functions. This does cause a bit of function sprawl, but that seems preferable to introducing more complex rules for when file(...) can and cannot read binary files, making the behavior of these various functions easier to understand in isolation.
2019-01-25 18:16:43 +01:00
"upper": stdlib.UpperFunc,
"urlencode": funcs.URLEncodeFunc,
"uuid": funcs.UUIDFunc,
lang/funcs: New "uuidv5" function This generates name-based uuids, rather than pseudorandom uuids as with the "uuid" function.
2019-05-08 11:13:30 +02:00
"uuidv5": funcs.UUIDV5Func,
convert cty func calls to stdlib
2020-02-24 15:29:04 +01:00
"values": stdlib.ValuesFunc,
lang: yamldecode and yamlencode functions These follow the same principle as jsondecode and jsonencode, but use YAML instead of JSON. YAML has a much more complex information model than JSON, so we can only support a subset of it during decoding, but hopefully the subset supported here is a useful one. Because there are many different ways to _generate_ YAML, the yamlencode function is forced to make some decisions, and those decisions are likely to affect compatibility with other real-world YAML parsers. Although the format here is intended to be generic and compatible, we may find that there are problems with it that'll we'll want to adjust for in a future release, so yamlencode is therefore marked as experimental for now until the underlying library is ready to commit to ongoing byte-for-byte compatibility in serialization. The main use-case here is met by yamldecode, which will allow reading in files written in YAML format by humans for use in Terraform modules, in situations where a higher-level input format than direct Terraform language declarations is helpful.
2019-05-26 19:25:18 +02:00
"yamldecode": ctyyaml.YAMLDecodeFunc,
"yamlencode": ctyyaml.YAMLEncodeFunc,
convert cty func calls to stdlib
2020-02-24 15:29:04 +01:00
"zipmap": stdlib.ZipmapFunc,
lang: new package for the runtime parts of the config language Whereas package "configs" deals with the static structure of the configuration language, this new package "lang" deals with the dynamic aspects such as expression evaluation. So far this mainly consists of populating a hcl.EvalContext that contains the values necessary to evaluate a block or an expression. There is also special handling here for dynamic block generation using the HCL "dynblock" extension, which is exposed in the public interface (rather than hiding it as an implementation detail of EvalBlock) so that the caller can then extract proper source locations for any result values using the expanded body. This also includes the beginnings of a replacement for the function table handling that currently lives in the old "config" package, but most of the functions are not yet ported and so this will expand in subsequent commits.
2018-04-04 03:11:28 +02:00
}
lang/funcs: templatefile function This function is similar to the template_file data source offered by the template provider, but having it built in to the language makes it more convenient to use, allowing templates to be rendered from files anywhere an inline template would normally be allowed: user_data = templatefile("${path.module}/userdata.tmpl", { hostname = format("petserver%02d", count.index) }) Unlike the template_file data source, this function allows values of any type in its variables map, passing them through verbatim to the template. Its tighter integration with Terraform also allows it to return better error messages with source location information from the template itself. The template_file data source was originally created to work around the fact that HIL didn't have any support for map values at the time, and even once map support was added it wasn't very usable. With HCL2 expressions, there's little reason left to use a data source to render a template; the only remaining reason left to use template_file is to render a template that is constructed dynamically during the Terraform run, which is a very rare need.
2018-12-21 02:42:42 +01:00
s.funcs["templatefile"] = funcs.MakeTemplateFileFunc(s.BaseDir, func() map[string]function.Function {
// The templatefile function prevents recursive calls to itself
// by copying this map and overwriting the "templatefile" entry.
return s.funcs
})
lang: new package for the runtime parts of the config language Whereas package "configs" deals with the static structure of the configuration language, this new package "lang" deals with the dynamic aspects such as expression evaluation. So far this mainly consists of populating a hcl.EvalContext that contains the values necessary to evaluate a block or an expression. There is also special handling here for dynamic block generation using the HCL "dynblock" extension, which is exposed in the public interface (rather than hiding it as an implementation detail of EvalBlock) so that the caller can then extract proper source locations for any result values using the expanded body. This also includes the beginnings of a replacement for the function table handling that currently lives in the old "config" package, but most of the functions are not yet ported and so this will expand in subsequent commits.
2018-04-04 03:11:28 +02:00
if s.PureOnly {
// Force our few impure functions to return unknown so that we
// can defer evaluating them until a later pass.
for _, name := range impureFunctions {
s.funcs[name] = function.Unpredictable(s.funcs[name])
}
}
}
s.funcsLock.Unlock()
return s.funcs
}
var unimplFunc = function.New(&function.Spec{
Type: func([]cty.Value) (cty.Type, error) {
return cty.DynamicPseudoType, fmt.Errorf("function not yet implemented")
},
Impl: func([]cty.Value, cty.Type) (cty.Value, error) {
return cty.DynamicVal, fmt.Errorf("function not yet implemented")
},
})