vendor: go get github.com/hashicorp/hcl2@master

This includes a missing feature for the splat syntax (null.* returns an
empty tuple) and also fixes a bug in the source code formatter where it
was inserting spaces between two consecutive interpolation sequences, like
"${foo}${bar}".

go.mod

@@ -72,7 +72,7 @@ require (
 	github.com/hashicorp/go-version v1.0.0
 	github.com/hashicorp/golang-lru v0.5.0 // indirect
 	github.com/hashicorp/hcl v1.0.0
-	github.com/hashicorp/hcl2 v0.0.0-20181220012050-6631d7cd0a68
+	github.com/hashicorp/hcl2 v0.0.0-20190116200548-7b147fbae47a
 	github.com/hashicorp/hil v0.0.0-20170627220502-fa9f258a9250
 	github.com/hashicorp/logutils v0.0.0-20150609070431-0dc08b1671f3
 	github.com/hashicorp/memberlist v0.1.0 // indirect

go.sum

@@ -59,7 +59,7 @@ github.com/chzyer/test v0.0.0-20180213035817-a1ea475d72b1 h1:q763qf9huN11kDQavWs
 github.com/chzyer/test v0.0.0-20180213035817-a1ea475d72b1/go.mod h1:Q3SI9o4m/ZMnBNeIyt5eFwwo7qiLfzFZmjNmxjkiQlU=
 github.com/coreos/bbolt v1.3.0 h1:HIgH5xUWXT914HCI671AxuTTqjj64UOFr7pHn48LUTI=
 github.com/coreos/bbolt v1.3.0/go.mod h1:iRUV2dpdMOn7Bo10OQBFzIJO9kkE559Wcmn+qkEiiKk=
-github.com/coreos/etcd v3.3.10+incompatible h1:jFneRYjIvLMLhDLCzuTuU4rSJUjRplcJQ7pD7MnhC04=
+github.com/coreos/etcd v3.3.10+incompatible h1:KjVWqrZ5U0wa3CxY2AxlH6/UcB+PK2td1DcsYhA+HRs=
 github.com/coreos/etcd v3.3.10+incompatible/go.mod h1:uF7uidLiAD3TWHmW31ZFd/JWoc32PjwdhPthX9715RE=
 github.com/coreos/go-semver v0.2.0 h1:3Jm3tLmsgAYcjC+4Up7hJrFBPr+n7rAqYeSw/SZazuY=
 github.com/coreos/go-semver v0.2.0/go.mod h1:nnelYz7RCh+5ahJtPPxZlU+153eP4D4r3EedlOD2RNk=
@@ -110,7 +110,7 @@ github.com/gopherjs/gopherjs v0.0.0-20181004151105-1babbf986f6f h1:JJ2EP5vV3LAD2
 github.com/gopherjs/gopherjs v0.0.0-20181004151105-1babbf986f6f/go.mod h1:wJfORRmW1u3UXTncJ5qlYoELFm8eSnnEO6hX4iZ3EWY=
 github.com/gorilla/websocket v1.4.0 h1:WDFjx/TMzVgy9VdMMQi2K2Emtwi2QcUQsztZ/zLaH/Q=
 github.com/gorilla/websocket v1.4.0/go.mod h1:E7qHFY5m1UJ88s3WnNqhKjPHQ0heANvMoAMk2YaljkQ=
-github.com/grpc-ecosystem/go-grpc-middleware v1.0.0 h1:Iju5GlWwrvL6UBg4zJJt3btmonfrMlCDdsejg4CZE7c=
+github.com/grpc-ecosystem/go-grpc-middleware v1.0.0 h1:BWIsLfhgKhV5g/oF34aRjniBHLTZe5DNekSjbAjIS6c=
 github.com/grpc-ecosystem/go-grpc-middleware v1.0.0/go.mod h1:FiyG127CGDf3tlThmgyCl78X/SZQqEOJBCDaAfeWzPs=
 github.com/grpc-ecosystem/go-grpc-prometheus v1.2.0 h1:Ovs26xHkKqVztRpIrF/92BcuyuQ/YW4NSIpoGtfXNho=
 github.com/grpc-ecosystem/go-grpc-prometheus v1.2.0/go.mod h1:8NvIoxWQoOIhqOTXgfV/d3M/q6VIi02HzZEHgUlZvzk=
@@ -127,7 +127,7 @@ github.com/hashicorp/go-checkpoint v0.0.0-20171009173528-1545e56e46de h1:XDCSyth
 github.com/hashicorp/go-checkpoint v0.0.0-20171009173528-1545e56e46de/go.mod h1:xIwEieBHERyEvaeKF/TcHh1Hu+lxPM+n2vT1+g9I4m4=
 github.com/hashicorp/go-cleanhttp v0.5.0 h1:wvCrVc9TjDls6+YGAF2hAifE1E5U1+b4tH6KdvN3Gig=
 github.com/hashicorp/go-cleanhttp v0.5.0/go.mod h1:JpRdi6/HCYpAwUzNwuwqhbovhLtngrth3wmdIIUrZ80=
-github.com/hashicorp/go-getter v0.0.0-20180327010114-90bb99a48d86 h1:hLYM35twiyKH44g36g+GFYODcrZQetEAY4+zrJtGea0=
+github.com/hashicorp/go-getter v0.0.0-20180327010114-90bb99a48d86 h1:mv3oKLM8sTaxmU/PrT39T35HRnUfchK+vtzXw6Ci9lY=
 github.com/hashicorp/go-getter v0.0.0-20180327010114-90bb99a48d86/go.mod h1:6rdJFnhkXnzGOJbvkrdv4t9nLwKcVA+tmbQeUlkIzrU=
 github.com/hashicorp/go-hclog v0.0.0-20180709165350-ff2cf002a8dd/go.mod h1:9bjs9uLqI8l75knNv3lV1kA55veR+WUPSiKIWcQHudI=
 github.com/hashicorp/go-hclog v0.0.0-20181001195459-61d530d6c27f h1:Yv9YzBlAETjy6AOX9eLBZ3nshNVRREgerT/3nvxlGho=
@@ -143,11 +143,11 @@ github.com/hashicorp/go-plugin v0.0.0-20181212150838-f444068e8f5a h1:z9eTtDWoxYr
 github.com/hashicorp/go-plugin v0.0.0-20181212150838-f444068e8f5a/go.mod h1:Ft7ju2vWzhO0ETMKUVo12XmXmII6eSUS4rsPTkY/siA=
 github.com/hashicorp/go-retryablehttp v0.5.1 h1:Vsx5XKPqPs3M6sM4U4GWyUqFS8aBiL9U5gkgvpkg4SE=
 github.com/hashicorp/go-retryablehttp v0.5.1/go.mod h1:9B5zBasrRhHXnJnui7y6sL7es7NDiJgTc6Er0maI1Xs=
-github.com/hashicorp/go-rootcerts v0.0.0-20160503143440-6bb64b370b90 h1:VBj0QYQ0u2MCJzBfeYXGexnAl17GsH1yidnoxCqqD9E=
+github.com/hashicorp/go-rootcerts v0.0.0-20160503143440-6bb64b370b90 h1:9HVkPxOpo+yO93Ah4yrO67d/qh0fbLLWbKqhYjyHq9A=
 github.com/hashicorp/go-rootcerts v0.0.0-20160503143440-6bb64b370b90/go.mod h1:o4zcYY1e0GEZI6eSEr+43QDYmuGglw1qSO6qdHUHCgg=
 github.com/hashicorp/go-safetemp v0.0.0-20180326211150-b1a1dbde6fdc h1:wAa9fGALVHfjYxZuXRnmuJG2CnwRpJYOTvY6YdErAh0=
 github.com/hashicorp/go-safetemp v0.0.0-20180326211150-b1a1dbde6fdc/go.mod h1:oaerMy3BhqiTbVye6QuFhFtIceqFoDHxNAB65b+Rj1I=
-github.com/hashicorp/go-slug v0.2.0 h1:MVdZAkTmDsUi1AT+3NQDsn8n3ssnVSIHwiM6RcUHvE8=
+github.com/hashicorp/go-slug v0.2.0 h1:gekvezBc+9LwN3qC+lesrz0Qg36hhgge9z/an1FCHx4=
 github.com/hashicorp/go-slug v0.2.0/go.mod h1:+zDycQOzGqOqMW7Kn2fp9vz/NtqpMLQlgb9JUF+0km4=
 github.com/hashicorp/go-sockaddr v0.0.0-20180320115054-6d291a969b86 h1:7YOlAIO2YWnJZkQp7B5eFykaIY7C9JndqAFQyVV5BhM=
 github.com/hashicorp/go-sockaddr v0.0.0-20180320115054-6d291a969b86/go.mod h1:7Xibr9yA9JjQq1JpNB2Vw7kxv8xerXegt+ozgdvDeDU=
@@ -162,8 +162,8 @@ github.com/hashicorp/golang-lru v0.5.0/go.mod h1:/m3WP610KZHVQ1SGc6re/UDhFvYD7pJ
 github.com/hashicorp/hcl v1.0.0 h1:0Anlzjpi4vEasTeNFn2mLJgTSwt0+6sfsiTG8qcWGx4=
 github.com/hashicorp/hcl v1.0.0/go.mod h1:E5yfLk+7swimpb2L/Alb/PJmXilQ/rhwaUYs4T20WEQ=
 github.com/hashicorp/hcl2 v0.0.0-20181208003705-670926858200/go.mod h1:ShfpTh661oAaxo7VcNxg0zcZW6jvMa7Moy2oFx7e5dE=
-github.com/hashicorp/hcl2 v0.0.0-20181220012050-6631d7cd0a68 h1:d2VhAXrdo8KXWFsn8lNHp5IL0OUXmXMIIlcZBmZa1iU=
+github.com/hashicorp/hcl2 v0.0.0-20190116200548-7b147fbae47a h1:+RoIWXVNQ9PUkXCKvzE+PlMLU/O0PNI9ItPQ7A0KW88=
-github.com/hashicorp/hcl2 v0.0.0-20181220012050-6631d7cd0a68/go.mod h1:ShfpTh661oAaxo7VcNxg0zcZW6jvMa7Moy2oFx7e5dE=
+github.com/hashicorp/hcl2 v0.0.0-20190116200548-7b147fbae47a/go.mod h1:ShfpTh661oAaxo7VcNxg0zcZW6jvMa7Moy2oFx7e5dE=
 github.com/hashicorp/hil v0.0.0-20170627220502-fa9f258a9250 h1:fooK5IvDL/KIsi4LxF/JH68nVdrBSiGNPhS2JAQjtjo=
 github.com/hashicorp/hil v0.0.0-20170627220502-fa9f258a9250/go.mod h1:KHvg/R2/dPtaePb16oW4qIyzkMxXOL38xjRN64adsts=
 github.com/hashicorp/logutils v0.0.0-20150609070431-0dc08b1671f3 h1:oD64EFjELI9RY9yoWlfua58r+etdnoIC871z+rr6lkA=

vendor/github.com/hashicorp/hcl2/hcl/hclsyntax/expression.go

@@ -1235,19 +1235,6 @@ func (e *SplatExpr) Value(ctx *hcl.EvalContext) (cty.Value, hcl.Diagnostics) {
 		return cty.DynamicVal, diags
 	}
 
-	if sourceVal.IsNull() {
-		diags = append(diags, &hcl.Diagnostic{
-			Severity:    hcl.DiagError,
-			Summary:     "Splat of null value",
-			Detail:      "Splat expressions (with the * symbol) cannot be applied to null values.",
-			Subject:     e.Source.Range().Ptr(),
-			Context:     hcl.RangeBetween(e.Source.Range(), e.MarkerRange).Ptr(),
-			Expression:  e.Source,
-			EvalContext: ctx,
-		})
-		return cty.DynamicVal, diags
-	}
-
 	sourceTy := sourceVal.Type()
 	if sourceTy == cty.DynamicPseudoType {
 		// If we don't even know the _type_ of our source value yet then
@@ -1258,9 +1245,27 @@ func (e *SplatExpr) Value(ctx *hcl.EvalContext) (cty.Value, hcl.Diagnostics) {
 
 	// A "special power" of splat expressions is that they can be applied
 	// both to tuples/lists and to other values, and in the latter case
-	// the value will be treated as an implicit single-value tuple. We'll
+	// the value will be treated as an implicit single-item tuple, or as
-	// deal with that here first.
+	// an empty tuple if the value is null.
-	if !(sourceTy.IsTupleType() || sourceTy.IsListType() || sourceTy.IsSetType()) {
+	autoUpgrade := !(sourceTy.IsTupleType() || sourceTy.IsListType() || sourceTy.IsSetType())
+
+	if sourceVal.IsNull() {
+		if autoUpgrade {
+			return cty.EmptyTupleVal, diags
+		}
+		diags = append(diags, &hcl.Diagnostic{
+			Severity:    hcl.DiagError,
+			Summary:     "Splat of null value",
+			Detail:      "Splat expressions (with the * symbol) cannot be applied to null sequences.",
+			Subject:     e.Source.Range().Ptr(),
+			Context:     hcl.RangeBetween(e.Source.Range(), e.MarkerRange).Ptr(),
+			Expression:  e.Source,
+			EvalContext: ctx,
+		})
+		return cty.DynamicVal, diags
+	}
+
+	if autoUpgrade {
 		sourceVal = cty.TupleVal([]cty.Value{sourceVal})
 		sourceTy = sourceVal.Type()
 	}

vendor/github.com/hashicorp/hcl2/hcl/hclsyntax/spec.md

@@ -9,13 +9,13 @@ generation of configuration.
 
 The language consists of three integrated sub-languages:
 
-* The _structural_ language defines the overall hierarchical configuration
+- The _structural_ language defines the overall hierarchical configuration
   structure, and is a serialization of HCL bodies, blocks and attributes.
 
-* The _expression_ language is used to express attribute values, either as
+- The _expression_ language is used to express attribute values, either as
   literals or as derivations of other values.
 
-* The _template_ language is used to compose values together into strings,
+- The _template_ language is used to compose values together into strings,
   as one of several types of expression in the expression language.
 
 In normal use these three sub-languages are used together within configuration
@@ -30,19 +30,19 @@ Within this specification a semi-formal notation is used to illustrate the
 details of syntax. This notation is intended for human consumption rather
 than machine consumption, with the following conventions:
 
-* A naked name starting with an uppercase letter is a global production,
+- A naked name starting with an uppercase letter is a global production,
   common to all of the syntax specifications in this document.
-* A naked name starting with a lowercase letter is a local production,
+- A naked name starting with a lowercase letter is a local production,
   meaningful only within the specification where it is defined.
-* Double and single quotes (`"` and `'`) are used to mark literal character
+- Double and single quotes (`"` and `'`) are used to mark literal character
   sequences, which may be either punctuation markers or keywords.
-* The default operator for combining items, which has no punctuation,
+- The default operator for combining items, which has no punctuation,
   is concatenation.
-* The symbol `|` indicates that any one of its left and right operands may
+- The symbol `|` indicates that any one of its left and right operands may
   be present.
-* The `*` symbol indicates zero or more repetitions of the item to its left.
+- The `*` symbol indicates zero or more repetitions of the item to its left.
-* The `?` symbol indicates zero or one of the item to its left.
+- The `?` symbol indicates zero or one of the item to its left.
-* Parentheses (`(` and `)`) are used to group items together to apply
+- Parentheses (`(` and `)`) are used to group items together to apply
   the `|`, `*` and `?` operators to them collectively.
 
 The grammar notation does not fully describe the language. The prose may
@@ -77,11 +77,11 @@ are not valid within HCL native syntax.
 
 Comments serve as program documentation and come in two forms:
 
-* _Line comments_ start with either the `//` or `#` sequences and end with
+- _Line comments_ start with either the `//` or `#` sequences and end with
   the next newline sequence. A line comments is considered equivalent to a
   newline sequence.
 
-* _Inline comments_ start with the `/*` sequence and end with the `*/`
+- _Inline comments_ start with the `/*` sequence and end with the `*/`
   sequence, and may have any characters within except the ending sequence.
   An inline comments is considered equivalent to a whitespace sequence.
 
@@ -91,7 +91,7 @@ template literals except inside an interpolation sequence or template directive.
 ### Identifiers
 
 Identifiers name entities such as blocks, attributes and expression variables.
-Identifiers are interpreted as per [UAX #31][UAX31] Section 2. Specifically,
+Identifiers are interpreted as per [UAX #31][uax31] Section 2. Specifically,
 their syntax is defined in terms of the `ID_Start` and `ID_Continue`
 character properties as follows:
 
@@ -109,7 +109,7 @@ that is not part of the unicode `ID_Continue` definition. This is to allow
 attribute names and block type names to contain dashes, although underscores
 as word separators are considered the idiomatic usage.
 
-[UAX31]: http://unicode.org/reports/tr31/ "Unicode Identifier and Pattern Syntax"
+[uax31]: http://unicode.org/reports/tr31/ "Unicode Identifier and Pattern Syntax"
 
 ### Keywords
 
@@ -150,9 +150,9 @@ expmark    = ('e' | 'E') ("+" | "-")?;
 The structural language consists of syntax representing the following
 constructs:
 
-* _Attributes_, which assign a value to a specified name.
+- _Attributes_, which assign a value to a specified name.
-* _Blocks_, which create a child body annotated by a type and optional labels.
+- _Blocks_, which create a child body annotated by a type and optional labels.
-* _Body Content_, which consists of a collection of attributes and blocks.
+- _Body Content_, which consists of a collection of attributes and blocks.
 
 These constructs correspond to the similarly-named concepts in the
 language-agnostic HCL information model.
@@ -253,9 +253,9 @@ LiteralValue = (
 );
 ```
 
-* Numeric literals represent values of type _number_.
+- Numeric literals represent values of type _number_.
-* The `true` and `false` keywords represent values of type _bool_.
+- The `true` and `false` keywords represent values of type _bool_.
-* The `null` keyword represents a null value of the dynamic pseudo-type.
+- The `null` keyword represents a null value of the dynamic pseudo-type.
 
 String literals are not directly available in the expression sub-language, but
 are available via the template sub-language, which can in turn be incorporated
@@ -286,8 +286,8 @@ When specifying an object element, an identifier is interpreted as a literal
 attribute name as opposed to a variable reference. To populate an item key
 from a variable, use parentheses to disambiguate:
 
-* `{foo = "baz"}` is interpreted as an attribute literally named `foo`.
+- `{foo = "baz"}` is interpreted as an attribute literally named `foo`.
-* `{(foo) = "baz"}` is interpreted as an attribute whose name is taken
+- `{(foo) = "baz"}` is interpreted as an attribute whose name is taken
   from the variable named `foo`.
 
 Between the open and closing delimiters of these sequences, newline sequences
@@ -299,12 +299,12 @@ _for expression_ interpretation has priority, so to produce a tuple whose
 first element is the value of a variable named `for`, or an object with a
 key named `for`, use parentheses to disambiguate:
 
-* `[for, foo, baz]` is a syntax error.
+- `[for, foo, baz]` is a syntax error.
-* `[(for), foo, baz]` is a tuple whose first element is the value of variable
+- `[(for), foo, baz]` is a tuple whose first element is the value of variable
   `for`.
-* `{for: 1, baz: 2}` is a syntax error.
+- `{for: 1, baz: 2}` is a syntax error.
-* `{(for): 1, baz: 2}` is an object with an attribute literally named `for`.
+- `{(for): 1, baz: 2}` is an object with an attribute literally named `for`.
-* `{baz: 2, for: 1}` is equivalent to the previous example, and resolves the
+- `{baz: 2, for: 1}` is equivalent to the previous example, and resolves the
   ambiguity by reordering.
 
 ### Template Expressions
@@ -312,9 +312,9 @@ key named `for`, use parentheses to disambiguate:
 A _template expression_ embeds a program written in the template sub-language
 as an expression. Template expressions come in two forms:
 
-* A _quoted_ template expression is delimited by quote characters (`"`) and
+- A _quoted_ template expression is delimited by quote characters (`"`) and
   defines a template as a single-line expression with escape characters.
-* A _heredoc_ template expression is introduced by a `<<` sequence and
+- A _heredoc_ template expression is introduced by a `<<` sequence and
   defines a template via a multi-line sequence terminated by a user-chosen
   delimiter.
 
@@ -322,7 +322,7 @@ In both cases the template interpolation and directive syntax is available for
 use within the delimiters, and any text outside of these special sequences is
 interpreted as a literal string.
 
-In _quoted_ template expressions any literal string sequences within the 
+In _quoted_ template expressions any literal string sequences within the
 template behave in a special way: literal newline sequences are not permitted
 and instead _escape sequences_ can be included, starting with the
 backslash `\`:
@@ -458,14 +458,14 @@ are provided, the first is the key and the second is the value.
 Tuple, object, list, map, and set types are iterable. The type of collection
 used defines how the key and value variables are populated:
 
-* For tuple and list types, the _key_ is the zero-based index into the
+- For tuple and list types, the _key_ is the zero-based index into the
   sequence for each element, and the _value_ is the element value. The
   elements are visited in index order.
-* For object and map types, the _key_ is the string attribute name or element
+- For object and map types, the _key_ is the string attribute name or element
   key, and the _value_ is the attribute or element value. The elements are
   visited in the order defined by a lexicographic sort of the attribute names
   or keys.
-* For set types, the _key_ and _value_ are both the element value. The elements
+- For set types, the _key_ and _value_ are both the element value. The elements
   are visited in an undefined but consistent order.
 
 The expression after the colon and (in the case of object `for`) the expression
@@ -487,12 +487,12 @@ immediately after the value expression, this activates the grouping mode in
 which each value in the resulting object is a _tuple_ of all of the values
 that were produced against each distinct key.
 
-* `[for v in ["a", "b"]: v]` returns `["a", "b"]`.
+- `[for v in ["a", "b"]: v]` returns `["a", "b"]`.
-* `[for i, v in ["a", "b"]: i]` returns `[0, 1]`.
+- `[for i, v in ["a", "b"]: i]` returns `[0, 1]`.
-* `{for i, v in ["a", "b"]: v => i}` returns `{a = 0, b = 1}`.
+- `{for i, v in ["a", "b"]: v => i}` returns `{a = 0, b = 1}`.
-* `{for i, v in ["a", "a", "b"]: k => v}` produces an error, because attribute
+- `{for i, v in ["a", "a", "b"]: k => v}` produces an error, because attribute
   `a` is defined twice.
-* `{for i, v in ["a", "a", "b"]: v => i...}` returns `{a = [0, 1], b = [2]}`.
+- `{for i, v in ["a", "a", "b"]: v => i...}` returns `{a = [0, 1], b = [2]}`.
 
 If the `if` keyword is used after the element expression(s), it applies an
 additional predicate that can be used to conditionally filter elements from
@@ -502,7 +502,7 @@ element expression(s). It must evaluate to a boolean value; if `true`, the
 element will be evaluated as normal, while if `false` the element will be
 skipped.
 
-* `[for i, v in ["a", "b", "c"]: v if i < 2]` returns `["a", "b"]`.
+- `[for i, v in ["a", "b", "c"]: v if i < 2]` returns `["a", "b"]`.
 
 If the collection value, element expression(s) or condition expression return
 unknown values that are otherwise type-valid, the result is a value of the
@@ -567,10 +567,10 @@ elements in a tuple, list, or set value.
 
 There are two kinds of "splat" operator:
 
-* The _attribute-only_ splat operator supports only attribute lookups into
+- The _attribute-only_ splat operator supports only attribute lookups into
   the elements from a list, but supports an arbitrary number of them.
 
-* The _full_ splat operator additionally supports indexing into the elements
+- The _full_ splat operator additionally supports indexing into the elements
   from a list, and allows any combination of attribute access and index
   operations.
 
@@ -583,9 +583,9 @@ fullSplat = "[" "*" "]" (GetAttr | Index)*;
 The splat operators can be thought of as shorthands for common operations that
 could otherwise be performed using _for expressions_:
 
-* `tuple.*.foo.bar[0]` is approximately equivalent to
+- `tuple.*.foo.bar[0]` is approximately equivalent to
   `[for v in tuple: v.foo.bar][0]`.
-* `tuple[*].foo.bar[0]` is approximately equivalent to
+- `tuple[*].foo.bar[0]` is approximately equivalent to
   `[for v in tuple: v.foo.bar[0]]`
 
 Note the difference in how the trailing index operator is interpreted in
@@ -597,13 +597,15 @@ _for expressions_ shown above: if a splat operator is applied to a value that
 is _not_ of tuple, list, or set type, the value is coerced automatically into
 a single-value list of the value type:
 
-* `any_object.*.id` is equivalent to `[any_object.id]`, assuming that `any_object`
+- `any_object.*.id` is equivalent to `[any_object.id]`, assuming that `any_object`
   is a single object.
-* `any_number.*` is equivalent to `[any_number]`, assuming that `any_number`
+- `any_number.*` is equivalent to `[any_number]`, assuming that `any_number`
   is a single number.
 
-If the left operand of a splat operator is an unknown value of any type, the
+If applied to a null value that is not tuple, list, or set, the result is always
-result is a value of the dynamic pseudo-type.
+an empty tuple, which allows conveniently converting a possibly-null scalar
+value into a tuple of zero or one elements. It is illegal to apply a splat
+operator to a null value of tuple, list, or set type.
 
 ### Operations
 
@@ -684,7 +686,7 @@ Arithmetic operations are considered to be performed in an arbitrary-precision
 number space.
 
 If either operand of an arithmetic operator is an unknown number or a value
-of the dynamic pseudo-type, the result is an unknown number. 
+of the dynamic pseudo-type, the result is an unknown number.
 
 ### Logic Operators
 
@@ -709,7 +711,7 @@ the outcome of a boolean expression.
 Conditional = Expression "?" Expression ":" Expression;
 ```
 
-The first expression is the _predicate_, which is  evaluated and must produce
+The first expression is the _predicate_, which is evaluated and must produce
 a boolean result. If the predicate value is `true`, the result of the second
 expression is the result of the conditional. If the predicate value is
 `false`, the result of the third expression is the result of the conditional.
@@ -777,8 +779,8 @@ interpolations or directives that are adjacent to it. A strip marker is
 a tilde (`~`) placed immediately after the opening `{` or before the closing
 `}` of a template sequence:
 
-* `hello ${~ "world" }` produces `"helloworld"`.
+- `hello ${~ "world" }` produces `"helloworld"`.
-* `%{ if true ~} hello %{~ endif }` produces `"hello"`.
+- `%{ if true ~} hello %{~ endif }` produces `"hello"`.
 
 When a strip marker is present, any spaces adjacent to it in the corresponding
 string literal (if any) are removed before producing the final value. Space
@@ -787,7 +789,7 @@ characters are interpreted as per Unicode's definition.
 Stripping is done at syntax level rather than value level. Values returned
 by interpolations or directives are not subject to stripping:
 
-* `${"hello" ~}${" world"}` produces `"hello world"`, and not `"helloworld"`,
+- `${"hello" ~}${" world"}` produces `"hello world"`, and not `"helloworld"`,
   because the space is not in a template literal directly adjacent to the
   strip marker.
 
@@ -825,9 +827,9 @@ TemplateIf = (
 The evaluation of the `if` directive is equivalent to the conditional
 expression, with the following exceptions:
 
-* The two sub-templates always produce strings, and thus the result value is
+- The two sub-templates always produce strings, and thus the result value is
   also always a string.
-* The `else` clause may be omitted, in which case the conditional's third
+- The `else` clause may be omitted, in which case the conditional's third
   expression result is implied to be the empty string.
 
 ### Template For Directive
@@ -847,9 +849,9 @@ TemplateFor = (
 The evaluation of the `for` directive is equivalent to the _for expression_
 when producing a tuple, with the following exceptions:
 
-* The sub-template always produces a string.
+- The sub-template always produces a string.
-* There is no equivalent of the "if" clause on the for expression.
+- There is no equivalent of the "if" clause on the for expression.
-* The elements of the resulting tuple are all converted to strings and
+- The elements of the resulting tuple are all converted to strings and
   concatenated to produce a flat string result.
 
 ### Template Interpolation Unwrapping
@@ -865,13 +867,13 @@ template or expression syntax. Unwrapping allows arbitrary expressions to be
 used to populate attributes when strings in such languages are interpreted
 as templates.
 
-* `${true}` produces the boolean value `true`
+- `${true}` produces the boolean value `true`
-* `${"${true}"}` produces the boolean value `true`, because both the inner
+- `${"${true}"}` produces the boolean value `true`, because both the inner
   and outer interpolations are subject to unwrapping.
-* `hello ${true}` produces the string `"hello true"`
+- `hello ${true}` produces the string `"hello true"`
-* `${""}${true}` produces the string `"true"` because there are two
+- `${""}${true}` produces the string `"true"` because there are two
   interpolation sequences, even though one produces an empty result.
-* `%{ for v in [true] }${v}%{ endif }` produces the string `true` because
+- `%{ for v in [true] }${v}%{ endif }` produces the string `true` because
   the presence of the `for` directive circumvents the unwrapping even though
   the final result is a single value.
 

vendor/github.com/hashicorp/hcl2/hcl/json/spec.md

@@ -18,11 +18,11 @@ _Parsing_ such JSON has some additional constraints not beyond what is normally
 supported by JSON parsers, so a specialized parser may be required that
 is able to:
 
-* Preserve the relative ordering of properties defined in an object.
+- Preserve the relative ordering of properties defined in an object.
-* Preserve multiple definitions of the same property name.
+- Preserve multiple definitions of the same property name.
-* Preserve numeric values to the precision required by the number type
+- Preserve numeric values to the precision required by the number type
   in [the HCL syntax-agnostic information model](../spec.md).
-* Retain source location information for parsed tokens/constructs in order
+- Retain source location information for parsed tokens/constructs in order
   to produce good error messages.
 
 ## Structural Elements
@@ -118,6 +118,7 @@ type:
   ]
 }
 ```
+
 ```json
 {
   "foo": []
@@ -147,7 +148,7 @@ the following examples:
     "boz": {
       "baz": {
         "child_attr": "baz"
-      },
+      }
     }
   }
 }
@@ -189,7 +190,7 @@ the following examples:
         "boz": {
           "child_attr": "baz"
         }
-      },
+      }
     },
     {
       "bar": {
@@ -402,4 +403,3 @@ to that expression.
 
 If the original expression is not a string or its contents cannot be parsed
 as a native syntax expression then static call analysis is not supported.
-

vendor/github.com/hashicorp/hcl2/hcl/spec.md

@@ -57,10 +57,10 @@ access to the specific attributes and blocks requested.
 A _body schema_ consists of a list of _attribute schemata_ and
 _block header schemata_:
 
-* An _attribute schema_ provides the name of an attribute and whether its
+- An _attribute schema_ provides the name of an attribute and whether its
   presence is required.
 
-* A _block header schema_ provides a block type name and the semantic names
+- A _block header schema_ provides a block type name and the semantic names
   assigned to each of the labels of that block type, if any.
 
 Within a schema, it is an error to request the same attribute name twice or
@@ -72,11 +72,11 @@ a block whose type name is identical to the attribute name.
 The result of applying a body schema to a body is _body content_, which
 consists of an _attribute map_ and a _block sequence_:
 
-* The _attribute map_ is a map data structure whose keys are attribute names
+- The _attribute map_ is a map data structure whose keys are attribute names
   and whose values are _expressions_ that represent the corresponding attribute
   values.
 
-* The _block sequence_ is an ordered sequence of blocks, with each specifying
+- The _block sequence_ is an ordered sequence of blocks, with each specifying
   a block _type name_, the sequence of _labels_ specified for the block,
   and the body object (not body _content_) representing the block's own body.
 
@@ -132,13 +132,13 @@ the schema has been processed.
 
 Specifically:
 
-* Any attribute whose name is specified in the schema is returned in body
+- Any attribute whose name is specified in the schema is returned in body
   content and elided from the new body.
 
-* Any block whose type is specified in the schema is returned in body content
+- Any block whose type is specified in the schema is returned in body content
   and elided from the new body.
 
-* Any attribute or block _not_ meeting the above conditions is placed into
+- Any attribute or block _not_ meeting the above conditions is placed into
   the new body, unmodified.
 
 The new body can then be recursively processed using any of the body
@@ -168,20 +168,20 @@ In order to obtain a concrete value, each expression must be _evaluated_.
 Evaluation is performed in terms of an evaluation context, which
 consists of the following:
 
-* An _evaluation mode_, which is defined below.
+- An _evaluation mode_, which is defined below.
-* A _variable scope_, which provides a set of named variables for use in
+- A _variable scope_, which provides a set of named variables for use in
   expressions.
-* A _function table_, which provides a set of named functions for use in
+- A _function table_, which provides a set of named functions for use in
   expressions.
 
 The _evaluation mode_ allows for two different interpretations of an
 expression:
 
-* In _literal-only mode_, variables and functions are not available and it
+- In _literal-only mode_, variables and functions are not available and it
   is assumed that the calling application's intent is to treat the attribute
   value as a literal.
 
-* In _full expression mode_, variables and functions are defined and it is
+- In _full expression mode_, variables and functions are defined and it is
   assumed that the calling application wishes to provide a full expression
   language for definition of the attribute value.
 
@@ -235,15 +235,15 @@ for interpretation into any suitable number representation. An implementation
 may in practice implement numbers with limited precision so long as the
 following constraints are met:
 
-* Integers are represented with at least 256 bits.
+- Integers are represented with at least 256 bits.
-* Non-integer numbers are represented as floating point values with a
+- Non-integer numbers are represented as floating point values with a
   mantissa of at least 256 bits and a signed binary exponent of at least
   16 bits.
-* An error is produced if an integer value given in source cannot be
+- An error is produced if an integer value given in source cannot be
   represented precisely.
-* An error is produced if a non-integer value cannot be represented due to
+- An error is produced if a non-integer value cannot be represented due to
   overflow.
-* A non-integer number is rounded to the nearest possible value when a
+- A non-integer number is rounded to the nearest possible value when a
   value is of too high a precision to be represented.
 
 The _number_ type also requires representation of both positive and negative
@@ -265,11 +265,11 @@ _Structural types_ are types that are constructed by combining other types.
 Each distinct combination of other types is itself a distinct type. There
 are two structural type _kinds_:
 
-* _Object types_ are constructed of a set of named attributes, each of which
+- _Object types_ are constructed of a set of named attributes, each of which
   has a type. Attribute names are always strings. (_Object_ attributes are a
   distinct idea from _body_ attributes, though calling applications
   may choose to blur the distinction by use of common naming schemes.)
-* _Tuple types_ are constructed of a sequence of elements, each of which
+- _Tuple types_ are constructed of a sequence of elements, each of which
   has a type.
 
 Values of structural types are compared for equality in terms of their
@@ -284,9 +284,9 @@ have attributes or elements with identical types.
 _Collection types_ are types that combine together an arbitrary number of
 values of some other single type. There are three collection type _kinds_:
 
-* _List types_ represent ordered sequences of values of their element type.
+- _List types_ represent ordered sequences of values of their element type.
-* _Map types_ represent values of their element type accessed via string keys.
+- _Map types_ represent values of their element type accessed via string keys.
-* _Set types_ represent unordered sets of distinct values of their element type.
+- _Set types_ represent unordered sets of distinct values of their element type.
 
 For each of these kinds and each distinct element type there is a distinct
 collection type. For example, "list of string" is a distinct type from
@@ -376,9 +376,9 @@ a type has a non-commutative _matches_ relationship with a _type specification_.
 A type specification is, in practice, just a different interpretation of a
 type such that:
 
-* Any type _matches_ any type that it is identical to.
+- Any type _matches_ any type that it is identical to.
 
-* Any type _matches_ the dynamic pseudo-type.
+- Any type _matches_ the dynamic pseudo-type.
 
 For example, given a type specification "list of dynamic pseudo-type", the
 concrete types "list of string" and "list of map" match, but the
@@ -397,51 +397,51 @@ applications to provide functions that are interoperable with all syntaxes.
 
 A _function_ is defined from the following elements:
 
-* Zero or more _positional parameters_, each with a name used for documentation,
+- Zero or more _positional parameters_, each with a name used for documentation,
   a type specification for expected argument values, and a flag for whether
   each of null values, unknown values, and values of the dynamic pseudo-type
   are accepted.
 
-* Zero or one _variadic parameters_, with the same structure as the _positional_
+- Zero or one _variadic parameters_, with the same structure as the _positional_
   parameters, which if present collects any additional arguments provided at
   the function call site.
 
-* A _result type definition_, which specifies the value type returned for each
+- A _result type definition_, which specifies the value type returned for each
   valid sequence of argument values.
 
-* A _result value definition_, which specifies the value returned for each
+- A _result value definition_, which specifies the value returned for each
   valid sequence of argument values.
 
 A _function call_, regardless of source syntax, consists of a sequence of
 argument values. The argument values are each mapped to a corresponding
 parameter as follows:
 
-* For each of the function's positional parameters in sequence, take the next
+- For each of the function's positional parameters in sequence, take the next
   argument. If there are no more arguments, the call is erroneous.
 
-* If the function has a variadic parameter, take all remaining arguments that
+- If the function has a variadic parameter, take all remaining arguments that
   where not yet assigned to a positional parameter and collect them into
   a sequence of variadic arguments that each correspond to the variadic
   parameter.
 
-* If the function has _no_ variadic parameter, it is an error if any arguments
+- If the function has _no_ variadic parameter, it is an error if any arguments
   remain after taking one argument for each positional parameter.
 
 After mapping each argument to a parameter, semantic checking proceeds
 for each argument:
 
-* If the argument value corresponding to a parameter does not match the
+- If the argument value corresponding to a parameter does not match the
   parameter's type specification, the call is erroneous.
 
-* If the argument value corresponding to a parameter is null and the parameter
+- If the argument value corresponding to a parameter is null and the parameter
   is not specified as accepting nulls, the call is erroneous.
 
-* If the argument value corresponding to a parameter is the dynamic value
+- If the argument value corresponding to a parameter is the dynamic value
   and the parameter is not specified as accepting values of the dynamic
   pseudo-type, the call is valid but its _result type_ is forced to be the
   dynamic pseudo type.
 
-* If neither of the above conditions holds for any argument, the call is
+- If neither of the above conditions holds for any argument, the call is
   valid and the function's value type definition is used to determine the
   call's _result type_. A function _may_ vary its result type depending on
   the argument _values_ as well as the argument _types_; for example, a
@@ -450,11 +450,11 @@ for each argument:
 
 If semantic checking succeeds without error, the call is _executed_:
 
-* For each argument, if its value is unknown and its corresponding parameter
+- For each argument, if its value is unknown and its corresponding parameter
   is not specified as accepting unknowns, the _result value_ is forced to be an
   unknown value of the result type.
 
-* If the previous condition does not apply, the function's result value
+- If the previous condition does not apply, the function's result value
   definition is used to determine the call's _result value_.
 
 The result of a function call expression is either an error, if one of the
@@ -631,20 +631,20 @@ diagnostics if they are applied to inappropriate expressions.
 
 The following are the required static analysis functions:
 
-* **Static List**: Require list/tuple construction syntax to be used and
+- **Static List**: Require list/tuple construction syntax to be used and
   return a list of expressions for each of the elements given.
 
-* **Static Map**: Require map/object construction syntax to be used and
+- **Static Map**: Require map/object construction syntax to be used and
   return a list of key/value pairs -- both expressions -- for each of
   the elements given. The usual constraint that a map key must be a string
   must not apply to this analysis, thus allowing applications to interpret
   arbitrary keys as they see fit.
 
-* **Static Call**: Require function call syntax to be used and return an
+- **Static Call**: Require function call syntax to be used and return an
   object describing the called function name and a list of expressions
   representing each of the call arguments.
 
-* **Static Traversal**: Require a reference to a symbol in the variable
+- **Static Traversal**: Require a reference to a symbol in the variable
   scope and return a description of the path from the root scope to the
   accessed attribute or index.
 
@@ -670,18 +670,18 @@ with the goals of this specification.
 The language-agnosticism of this specification assumes that certain behaviors
 are implemented separately for each syntax:
 
-* Matching of a body schema with the physical elements of a body in the
+- Matching of a body schema with the physical elements of a body in the
   source language, to determine correspondence between physical constructs
   and schema elements.
 
-* Implementing the _dynamic attributes_ body processing mode by either
+- Implementing the _dynamic attributes_ body processing mode by either
   interpreting all physical constructs as attributes or producing an error
   if non-attribute constructs are present.
 
-* Providing an evaluation function for all possible expressions that produces
+- Providing an evaluation function for all possible expressions that produces
   a value given an evaluation context.
 
-* Providing the static analysis functionality described above in a manner that
+- Providing the static analysis functionality described above in a manner that
   makes sense within the convention of the syntax.
 
 The suggested implementation strategy is to use an implementation language's

vendor/github.com/hashicorp/hcl2/hclwrite/format.go

@@ -325,6 +325,10 @@ func spaceAfterToken(subject, before, after *Token) bool {
 	case subject.Type == hclsyntax.TokenCBrace && after.Type == hclsyntax.TokenTemplateSeqEnd:
 		return true
 
+	// Don't add spaces between interpolated items
+	case subject.Type == hclsyntax.TokenTemplateSeqEnd && after.Type == hclsyntax.TokenTemplateInterp:
+		return false
+
 	case tokenBracketChange(subject) > 0:
 		// No spaces after open brackets
 		return false

vendor/modules.txt

@@ -351,7 +351,7 @@ github.com/hashicorp/hcl/hcl/scanner
 github.com/hashicorp/hcl/hcl/strconv
 github.com/hashicorp/hcl/json/scanner
 github.com/hashicorp/hcl/json/token
-# github.com/hashicorp/hcl2 v0.0.0-20181220012050-6631d7cd0a68
+# github.com/hashicorp/hcl2 v0.0.0-20190116200548-7b147fbae47a
 github.com/hashicorp/hcl2/hcl
 github.com/hashicorp/hcl2/hcl/hclsyntax
 github.com/hashicorp/hcl2/hcldec