| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
There is no limit to the length of string prefixes produced by template
expressions, so in rare cases they may return a refined unknown string
has too long a prefix.
The cty's msgpack decoder limits the size of an acceptable refinements
to 1 kiB, so such a value cannot be handled and an error occurs.
This change limits the length of prefixes to 128 B, so overly long
prefixes are no longer an issue in most cases.
|
|
If we encounter an interpolated unknown value during template rendering,
we can report the partial buffer we've completed so far as the refined
prefix of the resulting unknown value, which can then potentially allow
downstream comparisons to produce a known false result instead of unknown
if the prefix is sufficient to satisfy them.
|
|
* [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>
|
|
When processing a template string, the lexer can emit multiple string
literal tokens for what ought to be a single string literal. This occurs
when the string contains escape sequences, or consecutive characters
which are indistinguishable from escape sequences at tokenization time.
This leads to a confusing AST and causes heuristics about template
expressions to fail. Specifically, when parsing a traversal with an
index, a key value containing an escape symbol will cause the parser to
generate an index expression instead of a traversal.
This commit adds a post-processing step to the template parser to meld
any sequences of string literals into a single string literal. Existing
tests covered the previous misbehaviour (several of which had comments
apologizing for it), and have been updated accordingly.
The new behaviour of the `IsStringLiteral` method of `TemplateExpr` is
covered with a new set of tests.
|
|
Do not discard marks from unknown values when processing string
templates.
|
|
If individual template expressions in a loop have marks, merge those
marks into the final result when joining.
|
|
|
|
|
|
If a template expression interpolates values which have marks, we should
apply all of those marks to the output value. This allows template
expressions to function like native cty functions with respect to marks.
|
|
In previous versions we had some bugs around template sequence escapes.
These tests show that they no longer seem to be present, and should
hopefully avoid them regressing in future.
|
|
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.
|
