[cfe-dev] [RFC][PATCH] Implementation for completion in call context for C++

[Milian Wolff]

On Monday 05 January 2015 19:15:48 Francisco Lopes wrote:
> Hi,
> 
> I've improved completion in call context to work with C++'s templates,
> member functions, et al.
> 
> Notice: an important aspect of this implementation is that I've took freedom
> to change the previous behavior for completion in call context at all.
> 
> As can be seen, in lib/Sema/SemaCodeComplete.cpp this comment:
> 
>   // When we're code-completing for a call, we fall back to ordinary
>   // name code-completion whenever we can't produce specific
>   // results. We may want to revisit this strategy in the future,
>   // e.g., by merging the two kinds of results.
> 
> was changed to this:
> 
>   // When we're code-completing for a call, we DON'T fall back to ordinary
>   // name code-completion whenever we can't produce specific
>   // results. This will do "parameter completion" solely.
>   // I think "parameter completion" is not a good classification, since this
> // is useful solely for providing hints and not code-completing.
> 
> The rationale behind this change is:
>   - The former comment shows that completion in call context is still not
>     in a definite state, open to discussion.
>   - I firmly believe this new behavior is for good. In call context, 99% of
>     the time, code authoring tools will be interested in information about
> the
>     prototype and arguments solely, not in all possible kinds of expressions
> that can fit as an argument. This behavior turns the interface slower than
>     necessary to have almost no benefit.
>     So I believe that completion in call context just after '(' and ','
> should
>     work similarly as for member access: only provide what's of interest,
> which
>     parametric information (function prototypes, current argument, parameter
> types, etc.).
> 
> Despite this, I should be able revert to the former behavior in the change
> set
> without much trouble, in case there's no agreement on this, while still
> providing the new set of completions.
> 
> The following is a video that covers the new behavior, so that's easy to see
> what got changed. It's based on the test set that's part of the patch:
> 
>   https://vimeo.com/115990512

Hey Francisco.

I can't review the code, just wanted to comment on the functionality as I 
observe it from the video above. I think that the information about the call 
signatures during code completion is extremely useful. But it should not be 
put into the list of code completion results. Rather, I think it is additional 
information that should be distinguished from the results. These results 
should be a list of everything accessible at the call site, sorted by their 
relevance and excluding everything that can be ruled out.

In KDevelop e.g. this looks like this:

http://imgur.com/odCbYrU
http://imgur.com/xxN2isv

At the top, you see the signature(s) viable for the call. Below you get the 
list of code completion offers, and the "best matches" are obtained from 
sorting these results such that the types match the viable call signatures.

The screenshots above are obtained from running our legacy C++ code model. We 
are currently working on a clang-based code model and that already gives us 
similar results, including the sorting. What we are missing so far is the 
information to display on top for the possible viable call signatures. We can 
probably workaround that somehow, but having a Clang(-c) API for that would be 
nice.

If I'm not mistaking your video, your patch removes the list of results and 
replaces it only by a list of matching types? This would be an unfortunate 
regression, imo.

Bye
-- 
Milian Wolff
mail at milianw.de
http://milianw.de