mirror of https://github.com/golang/go.git
8938cee73c
In cases like:
type foo struct { a int; b float64 }
foo{b<>}
We were completing to "foo{int(b: <float64>)}" (the problem being the
nonsensical int() conversion).
The expected type at "<>" is int to allow completions to match "a".
When we pass the *types.Var representing "b" through the candidate
matching machinery, we say "Oh, a float64! I can convert that to my
expected type of int!".
Fix by bailing out of candidate matching early if the candidate is a
composite literal struct field name. Field names aren't really objects
you can do anything to.
Fixes golang/go#43789.
Change-Id: Ie4dab166973dfcdcb519f864532ead1f792d25a3
Reviewed-on: https://go-review.googlesource.com/c/tools/+/289130
Run-TryBot: Muir Manders <muir@mnd.rs>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Trust: Rebecca Stambler <rstambler@golang.org>
Trust: Hyang-Ah Hana Kim <hyangah@gmail.com>
|
||
|---|---|---|
| .. | ||
| analysisinternal | ||
| apidiff | ||
| event | ||
| fakenet | ||
| fastwalk | ||
| gocommand | ||
| gopathwalk | ||
| imports | ||
| jsonrpc2 | ||
| lsp | ||
| memoize | ||
| packagesinternal | ||
| proxydir | ||
| span | ||
| stack | ||
| testenv | ||
| tool | ||
| typesinternal | ||
| xcontext | ||