Commit Graph

1203 Commits

Author SHA1 Message Date
Michele Degges
466c0d9ba2
Add win tests to CircleCI; Remove Appveyor (#435)
Add win tests to CircleCI; Remove Appveyor
2020-12-16 12:09:42 -08:00
Alisdair McDiarmid
8045083719
Update CHANGELOG.md 2020-12-10 12:43:59 -05:00
Alisdair McDiarmid
c30c0c40c6
Merge pull request #429 from hashicorp/alisdair/argument-expansion-marks
hclsyntax: Fix panic when expanding marked funargs
2020-12-10 12:43:02 -05:00
Alisdair McDiarmid
b857e806ff hclsyntax: Fix panic when expanding marked funargs
Functions which accept multiple parameters can be called with the
expansion operator, `...`. When doing so, we must unmark the expanded
argument value before transforming it into a collection of function
arguments. To ensure that any marks applied to the collection are
preserved, we transfer the collection marks to the individual elements
as we build the argument list.
2020-12-09 15:00:19 -05:00
Pam Selle
d8c5050248
Prep changelog for next release 2020-12-07 14:38:35 -05:00
Pam Selle
3231752c37
Prep changelog for release 2020-12-07 14:35:50 -05:00
Pam Selle
e97f5e1a86
Update CHANGELOG.md 2020-12-03 12:23:37 -05:00
Pam Selle
42b83d915c
Merge pull request #427 from hashicorp/pselle/marked-conditionals
Unmark conditional values before checking their truthiness
2020-12-03 12:22:02 -05:00
Pam Selle
3b45fd43af Unmark values before testing for truth in conditionals
In conditional expressions that involve a marked value,
Unmark the value before inspecting its truthiness,
to avoid a mark panic in cty
2020-12-03 10:51:18 -05:00
Martin Atkins
cef803d9d2
Update CHANGELOG.md 2020-12-02 16:11:46 -08:00
Varun Sivapalan
61e260fbae
hclwrite: do not add space after a boolean NOT operator 2020-12-02 16:10:12 -08:00
Martin Atkins
6a747c8a53
Update CHANGELOG.md 2020-12-02 12:11:29 -08:00
Martin Atkins
f1f3985230 hclsyntax: Explicit AST node for parentheses
So far the expression parentheses syntax has been handled entirely in the
parser and has been totally invisible in the AST. That's fine for typical
expression evaluation, but over the years it's led to a few quirky
behaviors in less common situations where we've assumed that all
expressions are covered by the AST itself or by the source ranges that the
AST captures.

In particular, hclwrite assumes that all expressions will have source
ranges that cover their tokens, and it generates an incorrect physical
syntax tree when the AST doesn't uphold that.

After resisting through a few other similar bugs, this commit finally
introduces an explicit AST node for parentheses, which makes the
parentheses explicit in the AST and captures the larger source range that
includes the TokenOParen and the TokenCParen.

This means that parentheses will now be visible as a distinct node when
walking the AST, as reflected in the updated tests here. That may cause
downstream applications that traverse the tree to exhibit different
behaviors but we're not considering that as a "breaking change" because
the Walk function doesn't make any guarantees about the specific AST
shape.
2020-12-02 12:03:00 -08:00
Alisdair McDiarmid
d510cb0326
Prepare changelog for upcoming release 2020-11-30 11:23:54 -05:00
Alisdair McDiarmid
f10222b9d7
Update changelog for v2.7.2 release 2020-11-30 11:20:07 -05:00
Alisdair McDiarmid
2aa4aecdba
Merge pull request #424 from hashicorp/alisdair/fix-panic-traversing-marked-list
Fix panic traversing marked list
2020-11-30 11:08:39 -05:00
Alisdair McDiarmid
d0cb134fec Fix panic traversing marked list
We need to unmark the result of HasIndex in order to compare it with
true or false without a panic.
2020-11-26 10:59:16 -05:00
Alisdair McDiarmid
3bb0644ad8
Update CHANGELOG.md 2020-11-19 11:37:33 -05:00
Alisdair McDiarmid
7e77010ee3
Merge pull request #335 from kinvolk/fix-slice-value-decoding
gohcl/decode.go: fix decoding value slices
2020-11-19 11:35:55 -05:00
Martin Atkins
819c383cfb
Update CHANGELOG.md 2020-11-18 14:29:01 -08:00
Rémi Lapeyre
128a2f1879
hclsyntax: null[*] to return an empty tuple
The rules for the splat operator call for it to return an empty tuple
when its operand is null, but this rule was previously being
overridden by another rule that a value whose type is unknown
causes the operator to return an unknown value of unknown
type.

This was initially reported and discussed in Terraform, under
hashicorp/terraform#26746.
2020-11-18 14:26:15 -08:00
Alisdair McDiarmid
9dabf7d816
Prepare changelog for next release 2020-11-18 11:54:22 -05:00
Alisdair McDiarmid
eadfd40eca
Update CHANGELOG.md 2020-11-18 11:53:03 -05:00
Alisdair McDiarmid
253a71d65c
Merge pull request #422 from hashicorp/alisdair/hclwrite-empty-labels
hclwrite: Allow blank quoted string block labels
2020-11-18 11:50:06 -05:00
Alisdair McDiarmid
1818f36094 hclwrite: Allow blank quoted string block labels
The hclsyntax package permits block labels to be blank quoted strings,
and defers to the application to determine if this is valid or not. This
commit updates hclwrite to allow the same behaviour.

This is in response to an upstream bug report on Terraform, which uses
hclwrite to implement its fmt subcommand. Given a block with a blank
quoted string label, it currently deletes the label when formatting.
This is inconsistent with Terraform's behaviour when parsing HCL, which
treats empty labels differently from missing labels.
2020-11-18 09:21:23 -05:00
Mitchell Hashimoto
3de61ecba2
Merge pull request #412 from hashicorp/mitchellh/body
"body" struct tag to capture entire body for a block decode
2020-10-22 17:07:45 -07:00
Mitchell Hashimoto
38280c6c69
gohcl: add "body" struct tag to capture entire block body
Structs can specify the "body" struct tag to capture the entire block
body. This does NOT act as "remain" where leftover fields are
non-erroneous. If you want leftover fields to be allowed, a "remain"
field must ALSO be present.

This is used to capture the full block body that was decoded for the
block. This is useful if you want to ever redecode something differently
(maybe with a different EvalContext) or partially decode something but
redecode the entire value.
2020-10-22 16:56:33 -07:00
Alisdair McDiarmid
d56ed51dbc
Update CHANGELOG.md 2020-10-14 10:12:29 -04:00
Alisdair McDiarmid
84d75d846a Update CHANGELOG.md 2020-10-14 09:36:31 -04:00
Alisdair McDiarmid
fec69aa0e2
Merge pull request #407 from hashicorp/alisdair/for-expressions-over-marked-values
hclsyntax: Fix for expressions over marked values
2020-10-09 10:48:19 -04:00
Alisdair McDiarmid
39015a09a3 hclsyntax: Fix for expressions over marked values
A for expression over a marked collection should result in a new
collection with the same marks. Previously this would fail with a type
error.
2020-10-08 16:07:45 -04:00
Alisdair McDiarmid
a0de289809
Merge pull request #406 from hashicorp/alisdair/fix-panic-traversing-marked-map
Fix panic traversing marked map
2020-09-25 11:19:48 -04:00
Alisdair McDiarmid
8eccdca8f9 hclsyntax: Test for interpolating from marked map 2020-09-24 12:46:39 -04:00
Alisdair McDiarmid
35ad93007d Fix panic when traversing marked map value 2020-09-24 12:40:41 -04:00
Alisdair McDiarmid
4997e114f6
Merge pull request #404 from hashicorp/alisdair/pass-marks-through-expression-templates
hclsyntax: Pass marks through template expressions
2020-09-24 12:34:35 -04:00
Alisdair McDiarmid
876b4237a0 hclsyntax: Pass marks through template expressions
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.
2020-09-22 15:19:46 -04:00
Alisdair McDiarmid
bf0a7fe4fe
Update CHANGELOG.md 2020-09-15 15:56:56 -04:00
Martin Atkins
5c3a3da3cc
Update CHANGELOG.md 2020-09-04 14:13:39 -07:00
wata_mac
636e660fac json: Add ParseExpression function 2020-09-04 14:12:01 -07:00
Martin Atkins
90676d47a0 hclsyntax: Tailored error for "curly quotes"
It seems to be somewhat common for someone to share HCL code via a forum
or a document and have the well-meaning word processor or CMS replace the
straight quotes with curly quotes, which then lead to confusing errors
when someone copies the result and tries to use it as valid HCL
configuration.

Here we add a special hint for that, giving a tailored error message
instead of the generic "This character is not used within the language"
error message.

HCL has always had some of these special hints implemented here, and they
were originally implemented with special token types to allow the parser
handle them. However, we later refactored to do the check all at once
inside the Lex* family of functions, prior to parsing, so it's now
relatively straightforward to handle it as a special case of TokenInvalid
rather than an entirely new token type. Perhaps later we'll rework the
existing ones to also just use TokenInvalid, but that's a decision for
another day.
2020-08-24 11:35:03 -07:00
Martin Atkins
a484440c53
Update CHANGELOG.md 2020-08-24 10:55:42 -07:00
Kazuma Watanabe
e72341df8a
json: Add json.ParseWithStartPos function
This is like json.Parse but allows specifying a non-default start position,
in case the caller is parsing a fragment from a larger JSON document.
2020-08-24 10:53:10 -07:00
Mark Foster
b41530cb36 hcl: Fix the simple example in the README 2020-08-21 15:11:58 -07:00
Patrick Hagan
9603bea74b
ext/userfunc: Fix the package documentation link in the README 2020-08-21 15:03:22 -07:00
Martin Atkins
3c57e14932
Update CHANGELOG.md 2020-08-21 11:37:10 -07:00
Martin Atkins
7d8f0ff870 hclwrite: Make block labels a node in their own right
All of the other subdivisions of a block were already nodes, but we'd
represented the labels as an undifferentiated set of nodes belonging
directly to the block's child node list.

Now that we support replacing the labels in the public API, that's a good
excuse to refactor this slightly to make the labels their own node. As
well as being consistent with everything else in Block, this also makes
it easier to implement the Block.SetLabels operation because we can
just  change the children of the labels node, rather than having to
carefully identify and extract the individual child nodes of the block
that happen to represent labels.

Internally this models the labels in a similar sort of way as the content
of a body, although we've kept the public API directly on the Block type
here because that's a more straightforward model for the use-cases we
currently know and matches better with the API of hcl.Block. This is just
an internal change for consistency.

I also added a few tests for having comments interspersed with labels
while I was here, because that helped to better exercise the new
parseBlockLabels function.
2020-08-21 11:30:32 -07:00
Masayuki Morita
143a545916 hclwrite: Fix a bug that Block.open/close positions were not recorded in parser
While implementing Block.SetLabels(), I found a new hclwrite parser bug.

The NewBlock() method records positions of TokenOBrace / TokenCBrace.
Nevertheless when generating blocks via hclwrite.ParseConfig(),
they were not recorded.

The position of TokenOBrace is needed for Block.SetLabels(),
so I also fixed this existing bug.
2020-08-21 11:30:32 -07:00
Masayuki Morita
c3cbe9a9e2 hclwrite: Allow updating block type and labels
Fixes #338

Add methods to update block type and labels to enable us to refactor HCL
configurations such as renaming Terraform resources.

- `*Block.SetType(typeName string)`
- `*Block.SetLabels(labels []string)`

Some additional notes about SetLabels:

Since we cannot assume that old and new labels are equal in length,
remove old labels and insert new ones before TokenOBrace.

To implement this, I also added the following methods.

- `*nodes.Insert(pos *node, c nodeContent) *node`
- `*nodes.InsertNode(pos *node, n *node) *node`

They are similar to the existing Append / AppendNode,
but insert a node before a given position.
2020-08-21 11:30:32 -07:00
Alisdair McDiarmid
ea60f7f2a6
Merge pull request #380 from minamijoyo/fix-bitwise-or-error
Fix a wrong error message for bitwise OR
2020-06-25 15:07:25 -04:00
Chris Marchesi
350d663f3c
v2.6.0 release 2020-06-04 14:36:42 -07:00