<div dir="ltr"><div><div><div>PING.<br><br></div>Notice that meanwhile I've just completed parts of what was previously TODO (constructors, functors, ....).<br><br><a href="http://reviews.llvm.org/D6880">http://reviews.llvm.org/D6880</a><br><br></div>Regards,<br></div>Francisco Lopes<br><div><div><div class="gmail_extra"><br><div class="gmail_quote">2015-01-05 19:15 GMT-02:00 Francisco Lopes <span dir="ltr"><<a href="mailto:francisco.mailing.lists@oblita.com" target="_blank">francisco.mailing.lists@oblita.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><span style="font-family:monospace,monospace">Hi,<br><br>I've improved completion in call context to work with C++'s templates,<br>member functions, et al.<br><br>Notice: an important aspect of this implementation is that I've took freedom<br>to change the previous behavior for completion in call context at all.<br><br>As can be seen, in lib/Sema/SemaCodeComplete.cpp this comment:<br><br>  // When we're code-completing for a call, we fall back to ordinary<br>  // name code-completion whenever we can't produce specific<br>  // results. We may want to revisit this strategy in the future,<br>  // e.g., by merging the two kinds of results.<br><br>was changed to this:<br><br>  // When we're code-completing for a call, we DON'T fall back to ordinary<br>  // name code-completion whenever we can't produce specific<br>  // results. This will do "parameter completion" solely.<br>  // I think "parameter completion" is not a good classification, since this<br>  // is useful solely for providing hints and not code-completing.<br><br>The rationale behind this change is:<br>  - The former comment shows that completion in call context is still not<br>    in a definite state, open to discussion.<br>  - I firmly believe this new behavior is for good. In call context, 99% of<br>    the time, code authoring tools will be interested in information about the<br>    prototype and arguments solely, not in all possible kinds of expressions<br>    that can fit as an argument. This behavior turns the interface slower than<br>    necessary to have almost no benefit.<br>    So I believe that completion in call context just after '(' and ',' should<br>    work similarly as for member access: only provide what's of interest, which<br>    parametric information (function prototypes, current argument, parameter<br>    types, etc.).<br><br>Despite this, I should be able revert to the former behavior in the change set<br>without much trouble, in case there's no agreement on this, while still<br>providing the new set of completions.<br><br>The following is a video that covers the new behavior, so that's easy to see<br>what got changed. It's based on the test set that's part of the patch:<br><br>  <a href="https://vimeo.com/115990512" target="_blank">https://vimeo.com/115990512</a><br><br>The change set can be browsed here:<br><br>  <a href="https://github.com/oblitum/clang/tree/improved_argument_hints" target="_blank">https://github.com/oblitum/clang/tree/improved_argument_hints</a><br><br>The Subversion compatible patch:<br><br>  <a href="https://gist.github.com/oblitum/d24d7d2f9c6ee5cdcea1" target="_blank">https://gist.github.com/oblitum/d24d7d2f9c6ee5cdcea1</a><br><br>This got started for YouCompleteMe:<br><br>  <a href="https://github.com/Valloric/YouCompleteMe/pull/1300" target="_blank">https://github.com/Valloric/YouCompleteMe/pull/1300</a><br><br>TODO:<br>  Functors (classes that overload operator()), Constructors, ...<br><br>(I've already obtained commit access)<br><br>Att,<br>Francisco Lopes<br><br>PS: I'm actively looking for a job, remote or relocation, any help very much<br>    appreciated!<br></span></div>
</blockquote></div><br></div></div></div></div>