go/internal/lsp/testdata/nested_complit/nested_complit.go.in

package nested_complit

type ncFoo struct {} //@item(structNCFoo, "ncFoo", "struct{...}", "struct")

type ncBar struct { //@item(structNCBar, "ncBar", "struct{...}", "struct")
	baz []ncFoo
}

func _() {
	[]ncFoo{} //@item(litNCFoo, "[]ncFoo{}", "", "var")
	_ := ncBar{
		baz: [] //@complete(" //", structNCFoo, structNCBar)
	}
}
internal/lsp: improve composite literal completion When the value of a composite literal key/value pair was unparsable, you were getting completions for the composite literal keys instead of values. For example "struct { foo int }{foo: []<>" was completing to the field name "foo". This was because the leaf ast.Node at the cursor was the composite literal itself, and our go-back-one-character logic was not happening because the preceding character's node was ast.BadExpr, not ast.Ident. Fix by always generating the ast path for the character before the cursor's position. I couldn't find any cases where this broke completion. I also added expected type detection for the following composite literal cases: - array/slice literals - struct literals (both implicit and explicit field names) - map keys and values Fixes golang/go#29153 Change-Id: If8cf678cbd743a970f52893fcf4a9b83ea06d7e9 GitHub-Last-Rev: f385705cc05eb98132e20561451dbb8c39b68519 GitHub-Pull-Request: golang/tools#86 Reviewed-on: https://go-review.googlesource.com/c/tools/+/173099 Run-TryBot: Rebecca Stambler <rstambler@golang.org> Reviewed-by: Rebecca Stambler <rstambler@golang.org> 2019-04-23 16:00:40 -06:00			`package nested_complit`

			`type ncFoo struct {} //@item(structNCFoo, "ncFoo", "struct{...}", "struct")`

			`type ncBar struct { //@item(structNCBar, "ncBar", "struct{...}", "struct")`
			`baz []ncFoo`
			`}`

			`func _() {`
internal/lsp: add literal completion candidates Add support for literal completion candidates such as "[]int{}" or "make([]int, 0)". We support both named and unnamed types. I used the existing type matching logic, so, for example, if the expected type is an interface, we will suggest literal candidates that implement the interface. The literal candidates have a lower score than normal matching candidates, so they shouldn't be disruptive in cases where you don't want a literal candidate. This commit adds support for slice, array, struct, map, and channel literal candidates since they are pretty similar. Functions will be supported in a subsequent commit. I also added support for setting a snippet's final tab stop. This is useful if you want the cursor to end up somewhere other than the character after the snippet. Change-Id: Id3b74260fff4d61703989b422267021b00cec005 Reviewed-on: https://go-review.googlesource.com/c/tools/+/193698 Run-TryBot: Rebecca Stambler <rstambler@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Rebecca Stambler <rstambler@golang.org> 2019-09-04 17:12:37 -06:00			`[]ncFoo{} //@item(litNCFoo, "[]ncFoo{}", "", "var")`
internal/lsp: improve composite literal completion When the value of a composite literal key/value pair was unparsable, you were getting completions for the composite literal keys instead of values. For example "struct { foo int }{foo: []<>" was completing to the field name "foo". This was because the leaf ast.Node at the cursor was the composite literal itself, and our go-back-one-character logic was not happening because the preceding character's node was ast.BadExpr, not ast.Ident. Fix by always generating the ast path for the character before the cursor's position. I couldn't find any cases where this broke completion. I also added expected type detection for the following composite literal cases: - array/slice literals - struct literals (both implicit and explicit field names) - map keys and values Fixes golang/go#29153 Change-Id: If8cf678cbd743a970f52893fcf4a9b83ea06d7e9 GitHub-Last-Rev: f385705cc05eb98132e20561451dbb8c39b68519 GitHub-Pull-Request: golang/tools#86 Reviewed-on: https://go-review.googlesource.com/c/tools/+/173099 Run-TryBot: Rebecca Stambler <rstambler@golang.org> Reviewed-by: Rebecca Stambler <rstambler@golang.org> 2019-04-23 16:00:40 -06:00			`_ := ncBar{`
internal/lsp: improve completion for ast.ArrayTypes ast.ArrayTypes are type expressions like "[]foo" or "[2]int". They show up as standalone types (e.g. "var foo []int") and as part of composite literals (e.g. "[]int{}"). I made the following improvements: - Always expect a type name for array types. - Add a "type modifier" for array types so completions can be smart when we know the expected type. For example: var foo []int foo = []i<> we know we want a type name, but we also know the expected type is "[]int". When evaluating type names such as "int" we turn the type into a slice type "[]int" to match against the expected type. - Tweak the AST fixing to add a phantom selector "_" after a naked "[]" so you can complete directly after the right bracket. I split out the type name related type inference bits into a separate typeNameInference struct. It had become confusing and complicated, especially now that you can have an expected type and expect a type name at the same time. Change-Id: I00878532187ee5366ab8d681346532e36fa58e5f Reviewed-on: https://go-review.googlesource.com/c/tools/+/197438 Run-TryBot: Rebecca Stambler <rstambler@golang.org> Reviewed-by: Rebecca Stambler <rstambler@golang.org> 2019-09-13 13:15:53 -06:00			`baz: [] //@complete(" //", structNCFoo, structNCBar)`
internal/lsp: improve composite literal completion When the value of a composite literal key/value pair was unparsable, you were getting completions for the composite literal keys instead of values. For example "struct { foo int }{foo: []<>" was completing to the field name "foo". This was because the leaf ast.Node at the cursor was the composite literal itself, and our go-back-one-character logic was not happening because the preceding character's node was ast.BadExpr, not ast.Ident. Fix by always generating the ast path for the character before the cursor's position. I couldn't find any cases where this broke completion. I also added expected type detection for the following composite literal cases: - array/slice literals - struct literals (both implicit and explicit field names) - map keys and values Fixes golang/go#29153 Change-Id: If8cf678cbd743a970f52893fcf4a9b83ea06d7e9 GitHub-Last-Rev: f385705cc05eb98132e20561451dbb8c39b68519 GitHub-Pull-Request: golang/tools#86 Reviewed-on: https://go-review.googlesource.com/c/tools/+/173099 Run-TryBot: Rebecca Stambler <rstambler@golang.org> Reviewed-by: Rebecca Stambler <rstambler@golang.org> 2019-04-23 16:00:40 -06:00			`}`
			`}`