| Age | Commit message (Collapse) | Author |
|---|
|
Check for duplicate keys in objects when building types from expressions
|
|
|
|
|
|
If either the given value is refined non-null or if the default value is
refined non-null then the final attribute value after defaults processing
is also guaranteed non-null even if we don't yet know exactly what the
value will be.
This rule is pretty marginal on its own, but refining some types of value
as non-null creates opportunities to deduce further information when the
value is used under other operations later, such as collapsing an unknown
but definitely not null list of a known length into a known list of that
length containing unknown values.
|
|
* remove type assumptions when retrieving child default values
* fix imports
|
|
* [COMPLIANCE] Add Copyright and License Headers
* add copywrite file and revert headers in testdata
---------
Co-authored-by: hashicorp-copywrite[bot] <110428419+hashicorp-copywrite[bot]@users.noreply.github.com>
Co-authored-by: Liam Cervante <liam.cervante@hashicorp.com>
|
|
* Apply defaults using custom traversal of types
* sort imports
* address comments
* small refactoring, and update documentation
|
|
* add test cases that verify the downstream go-cty fix has worked
* update go-cty
|
|
|
|
|
|
|
|
|
|
When parsing optional object attribute defaults, we previously verified
that the default value was convertible to the attribute type. However,
we did not keep this converted value.
This commit uses the converted default value, rather than delaying
conversion until later. In turn this prevents crashes when transforming
collections which contain objects with optional attributes, caused by
incompatible object types at the time of defaults application.
|
|
This commit extends the type expression package to add two new features:
- In constraint mode, the `optional(...)` modifier can be used on object
attributes to allow them to be omitted from input values to a type
conversion process. Any such missing attributes will be replaced with
a `null` value of the appropriate type upon conversion.
- In the new defaults mode, the `optional(...)` modifier takes a second
argument, which accepts a default value of an appropriate type. These
defaults are returned alongside the type constraint, and may be
applied prior to type conversion through the new `Defaults.Apply()`
method.
This change is upstreamed from Terraform, where optional object
attributes have been available for some time. The defaults functionality
is new and due to be released with Terraform 1.3.
|
|
Most of the time, the standard expression decoding built in to HCL is
sufficient. Sometimes though, it's useful to be able to customize the
decoding of certain arguments where the application intends to use them
in a very specific way, such as in static analysis.
This extension is an approximate analog of gohcl's support for decoding
into an hcl.Expression, allowing hcldec-based applications and
applications with custom functions to similarly capture and manipulate
the physical expressions used in arguments, rather than their values.
This includes one example use-case: the typeexpr extension now includes
a cty.Function called ConvertFunc that takes a type expression as its
second argument. A type expression is not evaluatable in the usual sense,
but thanks to cty capsule types we _can_ produce a cty.Value from one
and then make use of it inside the function implementation, without
exposing this custom type to the broader language:
convert(["foo"], set(string))
This mechanism is intentionally restricted only to "argument-like"
locations where there is a specific type we are attempting to decode into.
For now, that's hcldec AttrSpec/BlockAttrsSpec -- analogous to gohcl
decoding into hcl.Expression -- and in arguments to functions.
|
|
The main HCL package is more visible this way, and so it's easier than
having to pick it out from dozens of other package directories.
|
|
This is in preparation for the first v2 release from the main HCL
repository.
|
|
|
|
This uses the expression static analysis features to interpret
a combination of static calls and static traversals as the description
of a type.
This is intended for situations where applications need to accept type
information from their end-users, providing a concise syntax for doing
so.
Since this is implemented using static analysis, the type vocabulary is
constrained only to keywords representing primitive types and type
construction functions for complex types. No other expression elements
are allowed.
A separate function is provided for parsing type constraints, which allows
the additonal keyword "any" to represent the dynamic pseudo-type.
Finally, a helper function is provided to convert a type back into a
string representation resembling the original input, as an aid to
applications that need to produce error messages relating to user-entered
types.
|
