[PATCH] D51038: [clang] Make sure codecompletion is called for calls even when inside a token.

[Ilya Biryukov via Phabricator via cfe-commits]

ilya-biryukov added inline comments.


================
Comment at: test/Index/complete-block-property-assignment.m:71
 
+// RUN: c-index-test -code-completion-at=%s:54:15 %s | FileCheck -check-prefix=CHECK-NO1 %s
+// CHECK-NO1: ObjCPropertyDecl:{ResultType int}{TypedText foo} (35)
----------------
ilya-biryukov wrote:
> kadircet wrote:
> > ilya-biryukov wrote:
> > > ilya-biryukov wrote:
> > > > Any idea why behavior changed in that case?
> > > Looked at it more thoroughly now...
> > > So we're now showing both the signature help and the completion, right?
> > > If that the case, LG, but can we include the rest of completion items from CHECK-N0? 
> > > 
> > > Maybe also add a comment that the last item is from overload set completion, rather than the ordinary code completion? (To avoid confusion and make it clear why we need an extra check there)
> > Yes, c-index-test binary collects results from both ProcessOverloadCandidate and ProcessCodeCompleteResults. Therefore they are merged. Adding the same set of results on the above is not enough for that particular case, due to the clever nature of CodeCompleteOverloadResult at https://github.com/llvm-mirror/clang/blob/master/lib/Sema/SemaCodeComplete.cpp#L4439.
> > 
> > It doesn't just try to tell you the overloads of that particular function but also tries to complete the current argument. Therefore the list simply gets huge by expansion of all the macros and other stuff.
> > 
> > But when looking into it I found out I was checking for wrong return values fixing that with the new diff.
> I don't think it's correct to call CodeCompleteExpression and CodeCompleteOrdinaryName in this context.
> This completion assume we're at the start of the argument, which is not true anymore.
> E.g. we can be producing weird results in the middle of expressions. Some examples from the top of my head:
> ```
> func(var.^); // <-- (1) we add top-level completions in addition to members of bar
> func(&^); // <-- (2) we provide incorrect ParamType
> ```
> For (2) if ParamType is `int*`, we would incorrectly uprank items of type `int*` (should uprank items of type `int` instead).
> 
> I'll investigate a bit more to see if we can refactor the code to untangle signature help from code completion.
D51782 removes completion-specific bits out of functions that produce signature help. 
After it lands, it should be significantly easier to produce results for these cases.

Specifically, we will be able to only run signature help in the middle of the args, and signature help followed by a normal completion at the start of the args.


Repository:
  rC Clang

https://reviews.llvm.org/D51038