[clangd-dev] Code completion overload folding

[Marc-André Laperle via clangd-dev]

Hi!


I think the folding makes sense. My only concern was that the user could mistakenly think there are no overloads before choosing a completion item but I see in the screenshot that it is communicated with the [overloaded]. Maybe as a bonus it could say how many overloads? i.e. [6 overloads] :)


Marc-André

________________________________
From: clangd-dev <clangd-dev-bounces at lists.llvm.org> on behalf of Sam McCall via clangd-dev <clangd-dev at lists.llvm.org>
Sent: Friday, June 8, 2018 3:54:14 PM
To: clangd-dev at lists.llvm.org
Subject: [clangd-dev] Code completion overload folding

What do we think about bundling overloaded functions into one completion item, vs clangd's current behavior of providing each overload of a function as a separate completion item?

Off the top of my head, bundling pros:
 - less noise
 - present more diverse results
Bundling cons:
 - lose the signature
 - complicated interactions with e.g. include insertion

My own feeling is that bundling is a win on balance if the editor has good signature help support. This might be personal enough to make an option.

I built a hacky prototype if you want to play with this behavior: patch in https://reviews.llvm.org/D47957.
Screenshot: https://i.imgur.com/vh25i20.png

The behavior is to bundle together c++ method calls by name, and function calls by qualified name (namespaces must match). I don't know much about ObjC, I'm not sure if grouping on the first chunk of the selector would make sense.

Cool things you could do:
 - pull individual elements out of the bundle if they're high ranking enough
 - explode the bundle once the query is unambiguous (client-side filtering is a problem here)
 - attempt to summarize similar signatures (e.g. show return type if it's the same for all overloads, show similar parts of const/non-const member overloads)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/clangd-dev/attachments/20180611/70c0acbc/attachment-0001.html>