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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
