1
0
mirror of https://github.com/golang/go synced 2024-11-05 22:46:12 -07:00
go/internal/lsp/source/completion_literal.go

393 lines
12 KiB
Go
Raw Normal View History

// Copyright 2019 The Go Authors. All rights reserved.
// Use of this source code is governed by a BSD-style
// license that can be found in the LICENSE file.
package source
import (
"context"
"go/ast"
"go/token"
"go/types"
"strings"
internal/lsp: support function literal completions Now we will offer function literal completions when we know the expected type is a function. For example: sort.Slice(someSlice, <>) will offer the completion "func(...) {}" which if selected will insert: func(i, j int) bool {<>} I opted to use an abbreviated label "func(...) {}" because function signatures can be quite long/verbose with all the type names in there. The only interesting challenge is how to handle signatures that don't name the parameters. For example, func HandleFunc(pattern string, handler func(ResponseWriter, *Request)) { does not name the "ResponseWriter" and "Request" parameters. I went with a minimal effort approach where we try abbreviating the type names, so the literal completion item for "handler" would look like: func(<rw> ResponseWriter, <r> *Request) {<>} where <> denote placeholders. The user can tab through quickly if they like the abbreviations, otherwise they can rename them. For unnamed types or if the abbreviation would duplicate a previous abbreviation, we fall back to "_" as the parameter name. The user will have to rename the parameter before they can use it. One side effect of this is that we cannot support function literal completions with unnamed parameters unless the user has enabled snippet placeholders. Change-Id: Ic0ec81e85cd8de79bff73314e80e722f10f8c84c Reviewed-on: https://go-review.googlesource.com/c/tools/+/193699 Run-TryBot: Rebecca Stambler <rstambler@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Rebecca Stambler <rstambler@golang.org>
2019-09-05 13:04:13 -06:00
"unicode"
"golang.org/x/tools/internal/event"
"golang.org/x/tools/internal/lsp/diff"
"golang.org/x/tools/internal/lsp/protocol"
"golang.org/x/tools/internal/lsp/snippet"
)
internal/lsp: support function literal completions Now we will offer function literal completions when we know the expected type is a function. For example: sort.Slice(someSlice, <>) will offer the completion "func(...) {}" which if selected will insert: func(i, j int) bool {<>} I opted to use an abbreviated label "func(...) {}" because function signatures can be quite long/verbose with all the type names in there. The only interesting challenge is how to handle signatures that don't name the parameters. For example, func HandleFunc(pattern string, handler func(ResponseWriter, *Request)) { does not name the "ResponseWriter" and "Request" parameters. I went with a minimal effort approach where we try abbreviating the type names, so the literal completion item for "handler" would look like: func(<rw> ResponseWriter, <r> *Request) {<>} where <> denote placeholders. The user can tab through quickly if they like the abbreviations, otherwise they can rename them. For unnamed types or if the abbreviation would duplicate a previous abbreviation, we fall back to "_" as the parameter name. The user will have to rename the parameter before they can use it. One side effect of this is that we cannot support function literal completions with unnamed parameters unless the user has enabled snippet placeholders. Change-Id: Ic0ec81e85cd8de79bff73314e80e722f10f8c84c Reviewed-on: https://go-review.googlesource.com/c/tools/+/193699 Run-TryBot: Rebecca Stambler <rstambler@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Rebecca Stambler <rstambler@golang.org>
2019-09-05 13:04:13 -06:00
// literal generates composite literal, function literal, and make()
// completion items.
func (c *completer) literal(ctx context.Context, literalType types.Type, imp *importInfo) {
if !c.opts.literal {
return
}
expType := c.inference.objType
internal/lsp/source: untangle completion type comparison The code to check if a candidate object matches our candidate inference had become complicated, messy, and in some cases incorrect. The main source of the complexity is the "derived" expected and candidate types. When considering a candidate object "foo", we also consider "&foo", "foo()", and "*foo", as appropriate. On the expected side of things, when completing the a variadic function parameter we expect either the variadic slice type and the scalar element type. The code had grown organically to handle the expanding concerns, but that resulted in confused code that didn't handle the interplay between the various facets of candidate inference. For example, we were inappropriately invoking func candidates when completing variadic args: func foo(...func()) func bar() {} foo(bar<>) // oops - expanded to "bar()" and we weren't type matching functions properly as builtin args: func myMap() map[string]int { ... } delete(myM<>) // we weren't preferring (or invoking) "myMap()" We also had methods like "typeMatches" which took both a "candidate" object and a "candType" type, which doesn't make sense because the candidate contains the type already. Now instead we explicitly iterate over all the derived candidate and expected types so they are treated the same. There are still some warts left but I think this is a step in the right direction. Change-Id: If84a84b34a8fb771a32231f7ab64ca192f611b3d Reviewed-on: https://go-review.googlesource.com/c/tools/+/218877 Run-TryBot: Muir Manders <muir@mnd.rs> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Findley <rfindley@google.com>
2020-02-08 20:59:28 -07:00
if c.inference.variadicType != nil {
// Don't offer literal slice candidates for variadic arguments.
// For example, don't offer "[]interface{}{}" in "fmt.Print(<>)".
if c.inference.matchesVariadic(literalType) {
return
}
// Otherwise, consider our expected type to be the variadic
// element type, not the slice type.
internal/lsp/source: untangle completion type comparison The code to check if a candidate object matches our candidate inference had become complicated, messy, and in some cases incorrect. The main source of the complexity is the "derived" expected and candidate types. When considering a candidate object "foo", we also consider "&foo", "foo()", and "*foo", as appropriate. On the expected side of things, when completing the a variadic function parameter we expect either the variadic slice type and the scalar element type. The code had grown organically to handle the expanding concerns, but that resulted in confused code that didn't handle the interplay between the various facets of candidate inference. For example, we were inappropriately invoking func candidates when completing variadic args: func foo(...func()) func bar() {} foo(bar<>) // oops - expanded to "bar()" and we weren't type matching functions properly as builtin args: func myMap() map[string]int { ... } delete(myM<>) // we weren't preferring (or invoking) "myMap()" We also had methods like "typeMatches" which took both a "candidate" object and a "candType" type, which doesn't make sense because the candidate contains the type already. Now instead we explicitly iterate over all the derived candidate and expected types so they are treated the same. There are still some warts left but I think this is a step in the right direction. Change-Id: If84a84b34a8fb771a32231f7ab64ca192f611b3d Reviewed-on: https://go-review.googlesource.com/c/tools/+/218877 Run-TryBot: Muir Manders <muir@mnd.rs> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Findley <rfindley@google.com>
2020-02-08 20:59:28 -07:00
expType = c.inference.variadicType
}
// Avoid literal candidates if the expected type is an empty
// interface. It isn't very useful to suggest a literal candidate of
// every possible type.
if expType != nil && isEmptyInterface(expType) {
return
}
// We handle unnamed literal completions explicitly before searching
// for candidates. Avoid named-type literal completions for
// unnamed-type expected type since that results in duplicate
// candidates. For example, in
//
// type mySlice []int
// var []int = <>
//
// don't offer "mySlice{}" since we have already added a candidate
// of "[]int{}".
if _, named := literalType.(*types.Named); named && expType != nil {
if _, named := deref(expType).(*types.Named); !named {
return
}
}
// Check if an object of type literalType would match our expected type.
cand := candidate{
obj: c.fakeObj(literalType),
}
switch literalType.Underlying().(type) {
// These literal types are addressable (e.g. "&[]int{}"), others are
// not (e.g. can't do "&(func(){})").
case *types.Struct, *types.Array, *types.Slice, *types.Map:
cand.addressable = true
}
internal/lsp/source: untangle completion type comparison The code to check if a candidate object matches our candidate inference had become complicated, messy, and in some cases incorrect. The main source of the complexity is the "derived" expected and candidate types. When considering a candidate object "foo", we also consider "&foo", "foo()", and "*foo", as appropriate. On the expected side of things, when completing the a variadic function parameter we expect either the variadic slice type and the scalar element type. The code had grown organically to handle the expanding concerns, but that resulted in confused code that didn't handle the interplay between the various facets of candidate inference. For example, we were inappropriately invoking func candidates when completing variadic args: func foo(...func()) func bar() {} foo(bar<>) // oops - expanded to "bar()" and we weren't type matching functions properly as builtin args: func myMap() map[string]int { ... } delete(myM<>) // we weren't preferring (or invoking) "myMap()" We also had methods like "typeMatches" which took both a "candidate" object and a "candType" type, which doesn't make sense because the candidate contains the type already. Now instead we explicitly iterate over all the derived candidate and expected types so they are treated the same. There are still some warts left but I think this is a step in the right direction. Change-Id: If84a84b34a8fb771a32231f7ab64ca192f611b3d Reviewed-on: https://go-review.googlesource.com/c/tools/+/218877 Run-TryBot: Muir Manders <muir@mnd.rs> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Findley <rfindley@google.com>
2020-02-08 20:59:28 -07:00
if !c.matchingCandidate(&cand) {
return
}
var (
qf = c.qf
sel = enclosingSelector(c.path, c.pos)
)
// Don't qualify the type name if we are in a selector expression
// since the package name is already present.
if sel != nil {
qf = func(_ *types.Package) string { return "" }
}
typeName := types.TypeString(literalType, qf)
// A type name of "[]int" doesn't work very will with the matcher
// since "[" isn't a valid identifier prefix. Here we strip off the
// slice (and array) prefix yielding just "int".
matchName := typeName
switch t := literalType.(type) {
case *types.Slice:
matchName = types.TypeString(t.Elem(), qf)
case *types.Array:
matchName = types.TypeString(t.Elem(), qf)
}
addlEdits, err := c.importEdits(ctx, imp)
if err != nil {
event.Error(ctx, "error adding import for literal candidate", err)
return
}
// If prefix matches the type name, client may want a composite literal.
if score := c.matcher.Score(matchName); score >= 0 {
if cand.takeAddress {
if sel != nil {
// If we are in a selector we must place the "&" before the selector.
// For example, "foo.B<>" must complete to "&foo.Bar{}", not
// "foo.&Bar{}".
edits, err := prependEdit(c.snapshot.View().Session().Cache().FileSet(), c.mapper, sel, "&")
if err != nil {
event.Error(ctx, "error making edit for literal pointer completion", err)
return
}
addlEdits = append(addlEdits, edits...)
} else {
// Otherwise we can stick the "&" directly before the type name.
typeName = "&" + typeName
}
}
switch t := literalType.Underlying().(type) {
case *types.Struct, *types.Array, *types.Slice, *types.Map:
c.compositeLiteral(t, typeName, float64(score), addlEdits)
case *types.Signature:
// Add a literal completion for a signature type that implements
// an interface. For example, offer "http.HandlerFunc()" when
// expected type is "http.Handler".
if isInterface(expType) {
c.basicLiteral(t, typeName, float64(score), addlEdits)
}
case *types.Basic:
// Add a literal completion for basic types that implement our
// expected interface (e.g. named string type http.Dir
// implements http.FileSystem), or are identical to our expected
// type (i.e. yielding a type conversion such as "float64()").
if isInterface(expType) || types.Identical(expType, literalType) {
c.basicLiteral(t, typeName, float64(score), addlEdits)
}
}
}
// If prefix matches "make", client may want a "make()"
// invocation. We also include the type name to allow for more
// flexible fuzzy matching.
if score := c.matcher.Score("make." + matchName); !cand.takeAddress && score >= 0 {
switch literalType.Underlying().(type) {
case *types.Slice:
// The second argument to "make()" for slices is required, so default to "0".
c.makeCall(typeName, "0", float64(score), addlEdits)
case *types.Map, *types.Chan:
// Maps and channels don't require the second argument, so omit
// to keep things simple for now.
c.makeCall(typeName, "", float64(score), addlEdits)
}
}
internal/lsp: support function literal completions Now we will offer function literal completions when we know the expected type is a function. For example: sort.Slice(someSlice, <>) will offer the completion "func(...) {}" which if selected will insert: func(i, j int) bool {<>} I opted to use an abbreviated label "func(...) {}" because function signatures can be quite long/verbose with all the type names in there. The only interesting challenge is how to handle signatures that don't name the parameters. For example, func HandleFunc(pattern string, handler func(ResponseWriter, *Request)) { does not name the "ResponseWriter" and "Request" parameters. I went with a minimal effort approach where we try abbreviating the type names, so the literal completion item for "handler" would look like: func(<rw> ResponseWriter, <r> *Request) {<>} where <> denote placeholders. The user can tab through quickly if they like the abbreviations, otherwise they can rename them. For unnamed types or if the abbreviation would duplicate a previous abbreviation, we fall back to "_" as the parameter name. The user will have to rename the parameter before they can use it. One side effect of this is that we cannot support function literal completions with unnamed parameters unless the user has enabled snippet placeholders. Change-Id: Ic0ec81e85cd8de79bff73314e80e722f10f8c84c Reviewed-on: https://go-review.googlesource.com/c/tools/+/193699 Run-TryBot: Rebecca Stambler <rstambler@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Rebecca Stambler <rstambler@golang.org>
2019-09-05 13:04:13 -06:00
// If prefix matches "func", client may want a function literal.
if score := c.matcher.Score("func"); !cand.takeAddress && score >= 0 && !isInterface(expType) {
internal/lsp: support function literal completions Now we will offer function literal completions when we know the expected type is a function. For example: sort.Slice(someSlice, <>) will offer the completion "func(...) {}" which if selected will insert: func(i, j int) bool {<>} I opted to use an abbreviated label "func(...) {}" because function signatures can be quite long/verbose with all the type names in there. The only interesting challenge is how to handle signatures that don't name the parameters. For example, func HandleFunc(pattern string, handler func(ResponseWriter, *Request)) { does not name the "ResponseWriter" and "Request" parameters. I went with a minimal effort approach where we try abbreviating the type names, so the literal completion item for "handler" would look like: func(<rw> ResponseWriter, <r> *Request) {<>} where <> denote placeholders. The user can tab through quickly if they like the abbreviations, otherwise they can rename them. For unnamed types or if the abbreviation would duplicate a previous abbreviation, we fall back to "_" as the parameter name. The user will have to rename the parameter before they can use it. One side effect of this is that we cannot support function literal completions with unnamed parameters unless the user has enabled snippet placeholders. Change-Id: Ic0ec81e85cd8de79bff73314e80e722f10f8c84c Reviewed-on: https://go-review.googlesource.com/c/tools/+/193699 Run-TryBot: Rebecca Stambler <rstambler@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Rebecca Stambler <rstambler@golang.org>
2019-09-05 13:04:13 -06:00
switch t := literalType.Underlying().(type) {
case *types.Signature:
c.functionLiteral(t, float64(score))
}
}
}
// prependEdit produces text edits that preprend the specified prefix
// to the specified node.
func prependEdit(fset *token.FileSet, m *protocol.ColumnMapper, node ast.Node, prefix string) ([]protocol.TextEdit, error) {
rng := newMappedRange(fset, m, node.Pos(), node.Pos())
spn, err := rng.Span()
if err != nil {
return nil, err
}
return ToProtocolEdits(m, []diff.TextEdit{{
Span: spn,
NewText: prefix,
}})
}
// literalCandidateScore is the base score for literal candidates.
// Literal candidates match the expected type so they should be high
// scoring, but we want them ranked below lexical objects of the
// correct type, so scale down highScore.
const literalCandidateScore = highScore / 2
internal/lsp: support function literal completions Now we will offer function literal completions when we know the expected type is a function. For example: sort.Slice(someSlice, <>) will offer the completion "func(...) {}" which if selected will insert: func(i, j int) bool {<>} I opted to use an abbreviated label "func(...) {}" because function signatures can be quite long/verbose with all the type names in there. The only interesting challenge is how to handle signatures that don't name the parameters. For example, func HandleFunc(pattern string, handler func(ResponseWriter, *Request)) { does not name the "ResponseWriter" and "Request" parameters. I went with a minimal effort approach where we try abbreviating the type names, so the literal completion item for "handler" would look like: func(<rw> ResponseWriter, <r> *Request) {<>} where <> denote placeholders. The user can tab through quickly if they like the abbreviations, otherwise they can rename them. For unnamed types or if the abbreviation would duplicate a previous abbreviation, we fall back to "_" as the parameter name. The user will have to rename the parameter before they can use it. One side effect of this is that we cannot support function literal completions with unnamed parameters unless the user has enabled snippet placeholders. Change-Id: Ic0ec81e85cd8de79bff73314e80e722f10f8c84c Reviewed-on: https://go-review.googlesource.com/c/tools/+/193699 Run-TryBot: Rebecca Stambler <rstambler@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Rebecca Stambler <rstambler@golang.org>
2019-09-05 13:04:13 -06:00
// functionLiteral adds a function literal completion item for the
// given signature.
func (c *completer) functionLiteral(sig *types.Signature, matchScore float64) {
snip := &snippet.Builder{}
snip.WriteText("func(")
seenParamNames := make(map[string]bool)
for i := 0; i < sig.Params().Len(); i++ {
if i > 0 {
snip.WriteText(", ")
}
p := sig.Params().At(i)
name := p.Name()
// If the parameter has no name in the signature, we need to try
// come up with a parameter name.
if name == "" {
// Our parameter names are guesses, so they must be placeholders
// for easy correction. If placeholders are disabled, don't
// offer the completion.
if !c.opts.placeholders {
internal/lsp: support function literal completions Now we will offer function literal completions when we know the expected type is a function. For example: sort.Slice(someSlice, <>) will offer the completion "func(...) {}" which if selected will insert: func(i, j int) bool {<>} I opted to use an abbreviated label "func(...) {}" because function signatures can be quite long/verbose with all the type names in there. The only interesting challenge is how to handle signatures that don't name the parameters. For example, func HandleFunc(pattern string, handler func(ResponseWriter, *Request)) { does not name the "ResponseWriter" and "Request" parameters. I went with a minimal effort approach where we try abbreviating the type names, so the literal completion item for "handler" would look like: func(<rw> ResponseWriter, <r> *Request) {<>} where <> denote placeholders. The user can tab through quickly if they like the abbreviations, otherwise they can rename them. For unnamed types or if the abbreviation would duplicate a previous abbreviation, we fall back to "_" as the parameter name. The user will have to rename the parameter before they can use it. One side effect of this is that we cannot support function literal completions with unnamed parameters unless the user has enabled snippet placeholders. Change-Id: Ic0ec81e85cd8de79bff73314e80e722f10f8c84c Reviewed-on: https://go-review.googlesource.com/c/tools/+/193699 Run-TryBot: Rebecca Stambler <rstambler@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Rebecca Stambler <rstambler@golang.org>
2019-09-05 13:04:13 -06:00
return
}
// Try abbreviating named types. If the type isn't named, or the
// abbreviation duplicates a previous name, give up and use
// "_". The user will have to provide a name for this parameter
// in order to use it.
if named, ok := deref(p.Type()).(*types.Named); ok {
name = abbreviateCamel(named.Obj().Name())
if seenParamNames[name] {
name = "_"
} else {
seenParamNames[name] = true
}
} else {
name = "_"
}
snip.WritePlaceholder(func(b *snippet.Builder) {
b.WriteText(name)
})
} else {
snip.WriteText(name)
}
// If the following param's type is identical to this one, omit
// this param's type string. For example, emit "i, j int" instead
// of "i int, j int".
if i == sig.Params().Len()-1 || !types.Identical(p.Type(), sig.Params().At(i+1).Type()) {
snip.WriteText(" ")
typeStr := types.TypeString(p.Type(), c.qf)
if sig.Variadic() && i == sig.Params().Len()-1 {
typeStr = strings.Replace(typeStr, "[]", "...", 1)
}
snip.WriteText(typeStr)
}
}
snip.WriteText(")")
results := sig.Results()
if results.Len() > 0 {
snip.WriteText(" ")
}
resultsNeedParens := results.Len() > 1 ||
results.Len() == 1 && results.At(0).Name() != ""
if resultsNeedParens {
snip.WriteText("(")
}
for i := 0; i < results.Len(); i++ {
if i > 0 {
snip.WriteText(", ")
}
r := results.At(i)
if name := r.Name(); name != "" {
snip.WriteText(name + " ")
}
snip.WriteText(types.TypeString(r.Type(), c.qf))
}
if resultsNeedParens {
snip.WriteText(")")
}
snip.WriteText(" {")
snip.WriteFinalTabstop()
snip.WriteText("}")
c.items = append(c.items, CompletionItem{
Label: "func(...) {}",
Score: matchScore * literalCandidateScore,
Kind: protocol.VariableCompletion,
internal/lsp: support function literal completions Now we will offer function literal completions when we know the expected type is a function. For example: sort.Slice(someSlice, <>) will offer the completion "func(...) {}" which if selected will insert: func(i, j int) bool {<>} I opted to use an abbreviated label "func(...) {}" because function signatures can be quite long/verbose with all the type names in there. The only interesting challenge is how to handle signatures that don't name the parameters. For example, func HandleFunc(pattern string, handler func(ResponseWriter, *Request)) { does not name the "ResponseWriter" and "Request" parameters. I went with a minimal effort approach where we try abbreviating the type names, so the literal completion item for "handler" would look like: func(<rw> ResponseWriter, <r> *Request) {<>} where <> denote placeholders. The user can tab through quickly if they like the abbreviations, otherwise they can rename them. For unnamed types or if the abbreviation would duplicate a previous abbreviation, we fall back to "_" as the parameter name. The user will have to rename the parameter before they can use it. One side effect of this is that we cannot support function literal completions with unnamed parameters unless the user has enabled snippet placeholders. Change-Id: Ic0ec81e85cd8de79bff73314e80e722f10f8c84c Reviewed-on: https://go-review.googlesource.com/c/tools/+/193699 Run-TryBot: Rebecca Stambler <rstambler@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Rebecca Stambler <rstambler@golang.org>
2019-09-05 13:04:13 -06:00
snippet: snip,
})
}
// abbreviateCamel abbreviates camel case identifiers into
// abbreviations. For example, "fooBar" is abbreviated "fb".
func abbreviateCamel(s string) string {
var (
b strings.Builder
useNextUpper bool
)
for i, r := range s {
if i == 0 {
b.WriteRune(unicode.ToLower(r))
}
if unicode.IsUpper(r) {
if useNextUpper {
b.WriteRune(unicode.ToLower(r))
useNextUpper = false
}
} else {
useNextUpper = true
}
}
return b.String()
}
// compositeLiteral adds a composite literal completion item for the given typeName.
func (c *completer) compositeLiteral(T types.Type, typeName string, matchScore float64, edits []protocol.TextEdit) {
snip := &snippet.Builder{}
snip.WriteText(typeName + "{")
// Don't put the tab stop inside the composite literal curlies "{}"
// for structs that have no accessible fields.
if strct, ok := T.(*types.Struct); !ok || fieldsAccessible(strct, c.pkg.GetTypes()) {
snip.WriteFinalTabstop()
}
snip.WriteText("}")
nonSnippet := typeName + "{}"
c.items = append(c.items, CompletionItem{
Label: nonSnippet,
InsertText: nonSnippet,
Score: matchScore * literalCandidateScore,
Kind: protocol.VariableCompletion,
AdditionalTextEdits: edits,
snippet: snip,
})
}
// basicLiteral adds a literal completion item for the given basic
// type name typeName.
func (c *completer) basicLiteral(T types.Type, typeName string, matchScore float64, edits []protocol.TextEdit) {
snip := &snippet.Builder{}
snip.WriteText(typeName + "(")
snip.WriteFinalTabstop()
snip.WriteText(")")
nonSnippet := typeName + "()"
c.items = append(c.items, CompletionItem{
Label: nonSnippet,
InsertText: nonSnippet,
Detail: T.String(),
Score: matchScore * literalCandidateScore,
Kind: protocol.VariableCompletion,
AdditionalTextEdits: edits,
snippet: snip,
})
}
// makeCall adds a completion item for a "make()" call given a specific type.
func (c *completer) makeCall(typeName string, secondArg string, matchScore float64, edits []protocol.TextEdit) {
// Keep it simple and don't add any placeholders for optional "make()" arguments.
snip := &snippet.Builder{}
snip.WriteText("make(" + typeName)
if secondArg != "" {
snip.WriteText(", ")
snip.WritePlaceholder(func(b *snippet.Builder) {
if c.opts.placeholders {
b.WriteText(secondArg)
}
})
}
snip.WriteText(")")
var nonSnippet strings.Builder
nonSnippet.WriteString("make(" + typeName)
if secondArg != "" {
nonSnippet.WriteString(", ")
nonSnippet.WriteString(secondArg)
}
nonSnippet.WriteByte(')')
c.items = append(c.items, CompletionItem{
Label: nonSnippet.String(),
InsertText: nonSnippet.String(),
Score: matchScore * literalCandidateScore,
Kind: protocol.FunctionCompletion,
AdditionalTextEdits: edits,
snippet: snip,
})
}