1
0
mirror of https://github.com/golang/go synced 2024-11-18 15:04:44 -07:00
go/internal/lsp/testdata
Muir Manders 74543c4034 internal/lsp/source: fix composite literal type name completion
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>
2020-08-21 15:12:09 +00:00
..
lsp internal/lsp/source: fix composite literal type name completion 2020-08-21 15:12:09 +00:00
missingdep internal: add call hierarchy cmd and lsp scaffolding 2020-08-07 20:22:52 +00:00
missingtwodep internal: add call hierarchy cmd and lsp scaffolding 2020-08-07 20:22:52 +00:00
unused internal/lsp/cache: refactor go mod tidy error logic 2020-08-07 22:43:23 +00:00
upgradedep internal/lsp/mod: add go mod vendor and go mod tidy lenses 2020-08-18 00:58:47 +00:00