20 Commits (27770ee8053da48fbb684fd23d415aae376d2bed)

Author	SHA1	Message	Date
James Bardin	eaf225a871	allow inconsistent function results for providers ... Due to the inherently ephemeral nature of provider configuration, inconsistent function results were tolerated while evaluating provider config. This loophole was found to be used by a number of configurations, which took advantage of it to create the equivalent of ephemeral values before they formally existed in the language. In order to work around this, we create a special evaluation scope just for providers, allowing us to override the results check for filesystem functions. I've opted to not further clutter the EvalContext interface since this is intended to be a temporary workaround, and does not contribute to the testing of that interface (the interface is solely for internal unit tests anyway).	6 months ago
James Bardin	f78adc889e	add wrappers to verify file function results ... Create wrappers to inject function results verification into all the filesystem function implementations.	12 months ago
kmoe	fab3673f8d	lang: stabilise ephemeral values experiment (#35636) ... * lang: stabilise ephemeral values experiment Stabilise the ephemeral values experiment and ephemeralasnull experimental function. * simplify handling of apply time input vars As the final step in stabilising the ephemeral values experiment, we can remove the separate code path for handling input variables supplied via -var and -var-file during apply. The intent here is conveyed in the tests: when applying a saved plan, all ephemeral variables set in the plan (the "apply-time variables"), must be set, and no others. As per the TODO copied from the prototype, there is some more work to be done here in making the handling of undeclared variables during apply as sophisticated as that during plan, emitting helpful warnings (for example) when input variables are supplied unnecessarily via environment variables. * experiments: officially conclude EV experiment --------- Co-authored-by: Radek Simko <radek.simko@gmail.com>	2 years ago
Martin Atkins	71d14e78fd	lang: Experimental "ephemeralasnull" function ... This is another part of the existing ephemeral_values experiment, taking a value of any type that might have ephemeral values in it and returning a value of the same type which has any ephemeral value replaced with a null value. The primary purpose of this is to allow a module to conveniently return an object that would normally contain nested ephemeral values -- such as an instance of a managed resource type that has a write-only attribute -- through an output value that isn't declared as ephemeral. This would then expose all of the non-ephemeral parts of the object but withhold the ephemeral parts. In the case of write-only attributes, it exposes the normal attributes while withholding the write-only ones. The name of this function could potentially change before stabilization, because it's quite long and clunky. I did originally consider "nonephemeral" to match with the existing "nonsensitive", but that didn't feel right because "nonsensitive" removes the sensitive mark while preserving the underlying value while this function removes the mark and the real value at the same time. (It would not be appropriate to have a function that just removes the ephemeral mark while preserving the value, because correct handling of ephemerality is important for correctness while sensitivity is primarily a UI concern so we don't need to be quite so picky about it.)	2 years ago
kmoe	1e2d4a2ecc	lang: stabilise templatestring func experiment (#35224) ... * lang: stabilise templatestring func experiment * command/jsonfunction: marshal templatestring * docs: add templatestring	2 years ago
Martin Atkins	edf335e7eb	lang/funcs: Experimental "templatestring" function ... This function complements the existing "templatefile" to deal with the unusual situation of rendering a template that comes from somewhere outside of the current module's source code, such as from a data resource result. We have some historical experience with the now-deprecated hashicorp/template provider and its template_file data source, where we found that new authors would find it via web search and assume it was "the way" to render templates in Terraform, and then get frustrated dealing with the confusing situation of writing a string template that generates another string template for a second round of template rendering. To try to support those who have this unusual need without creating another attractive nuisance that would derail new authors, this function imposes the artificial extra rule that its template argument may only be populated using a single reference to a symbol defined elsewhere in the same module. This is intended to entice folks trying to use this function for something other than its intended purpose to refer to its documentation (once written) and then hopefully learn what other Terraform language feature they ought to have used instead. The syntax restriction only goes one level deep, so particularly-determined authors can still intentionally misuse this function by adding one level of indirection, such as by building template source code in a local value and then passing that local value as the template argument. The restriction is in place only to reduce the chances of someone _misunderstanding_ the purpose of this function; we don't intend to prevent someone from actively deciding to misuse it, if they have a good reason to do so. This new function inherits the same restriction as templatefile where it does not allow recursively calling other template-rendering functions. This is to dissuade from trying to use Terraform templates "at large", since Terraform's template language is not designed for such uses. It would be better to build a Terraform provider that wraps a more featureful template system like Gonja if someone really does need advanced templating, beyond Terraform's basic goals of being able to build small configuration files, etc. Because this function's intended purpose is rendering templates obtained from elsewhere, this function also blocks calls to any of Terraform's functions that would read from the filesystem of the computer where Terraform is running. This is a small additional measure of isolation to reduce the risk of an attacker somehow modifying a dynamically-fetched template to inspire Terraform to write sensitive data from the host computer into a location accessible to the same attacker, or similar. This is currently only a language experiment and so will not yet be available in stable releases of Terraform. Before stabilizing this and committing to supporting it indefinitely we'll want to gather feedback on whether this function actually meets the intended narrow set of use-cases around dynamic template rendering.	2 years ago
Daniel Schmidt	3a77065e69	add `issensitive` function ... This function can be used to check if a value is marked as sensitive or not within terraform. Closes #34572	2 years ago
James Bardin	1644c2f63b	check function descriptions directly ... Now that we dynamically add scoped versions to the global functions we can't check the static Descriptions list. This should be OK since the function descriptions are taken directly from Descriptions list, and if any other scoped functions were added in the future, they may not be coming from the current global set of functions anyway.	2 years ago
Martin Atkins	17d7f7ff24	lang: Scope accepts "External Functions" ... This is intended as a bridge to functions defined outside of the core language, which will live in other namespaces in order to avoid ambiguity with any built-in functions. For now we only accept provider-contributed external functions. The lang package doesn't really know anything special about providers, so its only responsibility here is to enforce the naming scheme that any provider-contributed functions always live under the namespace prefix "provider::NAME::", where NAME is a name decided by whatever codepath instantiated the state as a unique identifier for a particular provider. This commit also includes updates to the core package to make it possible to pass in ExternalFuncs in principle, although in practice we don't yet have any codepaths which do so, and so this is effectively a no-op commit.	2 years ago
Martin Atkins	d1df979115	lang: Expose built-in functions under core:: namespace ... This essentially doubles up the registrations for all of the built-in functions to have both non-namespaced and core::-namespaced versions of each function. This is in preparation for later commits introducing other namespaces, such as a provider:: namespace which could hold functions that were contributed by providers that are currently in scope.	2 years ago
Liam Cervante	b9f6b23ba3	testing framework: add support for functions in variables and providers (#34204)	2 years ago
hashicorp-copywrite[bot]	53c34ff49c	Update copyright file headers to BUSL-1.1	3 years ago
hashicorp-copywrite[bot]	325d18262e	[COMPLIANCE] Add Copyright and License Headers	3 years ago
Zac Clifton	3bb6a5896b	Feat: Add strcontains function and documentation (#33069) ... * add strcontains function and documentation	3 years ago
Liam Cervante	aae6990d38	Add native `plantimestamp` function to Terraform (#32980) ... * add plantimestamp function * documentation * add missing links * fix typo	3 years ago
Daniel Banck	4fd8322802	Add function descriptions (#32453) ... * Add consolidated function description list * Add function parameter descriptions * Add descriptions to all functions * Add sanity test for function descriptions * Apply suggestions from code review Co-authored-by: kmoe <5575356+kmoe@users.noreply.github.com> Co-authored-by: kmoe <5575356+kmoe@users.noreply.github.com>	3 years ago
Martin Atkins	2ee9589650	lang/funcs: "timecmp" function ... This is a complement to "timestamp" and "timeadd" which allows establishing the ordering of two different timestamps while taking into account their timezone offsets, which isn't otherwise possible using the existing primitives in the Terraform language.	4 years ago
Joshua Barton	c73c0ad63c	feat: add startswith and endswith funcs	4 years ago
Alisdair McDiarmid	718b0875ef	lang: Remove defaults function ... Now that we are able to specify optional object attribute defaults inline in a type constraint, the separate `defaults` function is no longer needed.	4 years ago
Martin Atkins	cdd9464f9a	Move lang/ to internal/lang/ ... This is part of a general effort to move all of Terraform's non-library package surface under internal in order to reinforce that these are for internal use within Terraform only. If you were previously importing packages under this prefix into an external codebase, you could pin to an earlier release tag as an interim solution until you've make a plan to achieve the same functionality some other way.	5 years ago