[clangd-dev] Code completion overload folding
Marc-André Laperle via clangd-dev
clangd-dev at lists.llvm.org
Mon Jun 11 06:55:13 PDT 2018
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] :)
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
- 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.
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...
More information about the clangd-dev