Muir Manders b579874149 lsp/completion: reorganize how we track candidate type mods ... "type mod" refers to agglutinative expressions such as dereference "*", invocation "()", and slicing "[:]". When considering an object as a completion candidate, we check whether applying a type mod would make it a better candidate. Previously we tracked the type mods we wanted to apply to a candidate by setting bool fields. Now instead we keep a slice of the type mods. This has two main advantages: - The mods are now ordered which will allow us to format candidates properly when the same mods can appear in different order (e.g. "<-*foo" or *<-foo"). - We can now record any mod multiple times allowing for "<-<-foo" or "foo()()". I changed the formatting code to always create a snippet object since that made things simpler. I had to tweak a few snippet helper methods to accept a snippet argument rather than creating a new snippet. This commit's only functional change is that we no longer show any type mods in candidate labels. For example, the user will now see "foo" in the completion popup instead of "*foo". Showing the operators adds noise to the candidate list, and we didn't display them consistently. Updates golang/go#46045. Change-Id: I3ea7baa1ee2fee80a1f8cfe88cbae1093ae269ba Reviewed-on: https://go-review.googlesource.com/c/tools/+/323449 Run-TryBot: Muir Manders <muir@mnd.rs> gopls-CI: kokoro <noreply+kokoro@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Robert Findley <rfindley@google.com> Trust: Rebecca Stambler <rstambler@golang.org>		2021-06-09 15:58:13 +00:00
..
append.go	lsp/completion: reorganize how we track candidate type mods	2021-06-09 15:58:13 +00:00
append2.go.in	internal/lsp: remove multi-module support in tests	2020-09-22 16:28:30 +00:00