mirror of
https://github.com/golang/go
synced 2024-09-30 12:28:35 -06:00
74543c4034
Fix completion in the following cases: type foo struct{} // now we offer "&foo" instead of "foo" var _ *foo = fo<>{} struct { f *foo }{ // now we offer "&foo" instead of "*foo" f: fo<>{}, } Composite literal type names are a bit special because they are part of an arbitrary value expression rather than just a standalone type name expression. In particular, they can be preceded by "&", which affects how they relate to the surrounding context. The "&" doesn't technically apply to the type name, but we must take it into account. I made three changes to fix the behavior: 1. When we want to make a composite literal type name into a pointer, we use "&" instead of "*". 2. Record if a composite literal type is already has a "&" so we don't add it again. 3. Fix "var _ *foo = fo<>{}" to properly infer expected type of "*foo" by not stopping at *ast.CompositeLit searching up AST path when the position is in the type name (as opposed to within the curlies). Change-Id: Iee828f259eb939646b68f5066614ea3a262585c2 Reviewed-on: https://go-review.googlesource.com/c/tools/+/247525 Run-TryBot: Muir Manders <muir@mnd.rs> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Findley <rfindley@google.com> |
||
---|---|---|
.. | ||
analysisinternal | ||
apidiff | ||
event | ||
fakenet | ||
fastwalk | ||
gocommand | ||
gopathwalk | ||
imports | ||
jsonrpc2 | ||
lsp | ||
memoize | ||
packagesinternal | ||
proxydir | ||
span | ||
stack | ||
testenv | ||
tool | ||
typesinternal | ||
xcontext |