tree 1480f49e5ca2a9217469f6c118d32069a82820d2
parent c07e1c6ef61c86a10ae4605c3a687382a4e26083
author Muir Manders <muir@mnd.rs> 1572832041 -0800
committer Rebecca Stambler <rstambler@golang.org> 1573161480 +0000

internal/lsp: improve literal func completion candidates

Previously we were erroneously suggesting a "func() {}" literal in
cases like:

http.Handle("/", <>)

This was happening because saw that the http.HandlerFunc type
satisfied the http.Handler interface, and that http.HandlerFunc is a
function type. However, of course, you can't pass a function literal
to http.Handle().

Make a few tweaks to address the problem:

1. Don't suggest literal "func () {}" candidates if the expected type
   is an interface type.

2. Suggest named function types that implement an interface. This
   causes us to suggest "http.HandlerFunc()" in the above example.

3. Suggest a func literal candidate inside named function type
   conversions. This will suggest "func() {}" when completing
   "http.HandlerFunc(<>)".

This way the false positive func literal is gone, and you still get
literal candidates that help you use an http.HandlerFunc as an
http.Handler. Note that this particular example is not very compelling
in light of http.HandleFunc() which can take a func literal directly,
but such a convenience function may not exist in other analogous
situations.

Change-Id: Ia68097b9a5b8351921349340d18acd8876554691
Reviewed-on: https://go-review.googlesource.com/c/tools/+/205137
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>