Currently CodeCompleteCall only gets called after a comma or parantheses. This
patch makes sure it is called even at the cases like:
foo(1^);
Differential D51038
[clang] Make sure codecompletion is called for calls even when inside a token. kadircet on Aug 21 2018, 7:57 AM. Authored by
Details
Currently CodeCompleteCall only gets called after a comma or parantheses. This foo(1^);
Diff Detail
Event TimelineComment Actions Maybe add tests? Lit tests for code completion (clang/test/CodeCompletion) should be a good fit
Comment Actions Sorry, missed the dependent revision adding tests to clangd at first. Having another test in sema would still be great, to make sure we guard against regressions if someone does not have clang-tools-extra checked out. Comment Actions One major limitation of the current workaround is that IIRC clang can actually call code completion callbacks, including this method, multiple times (e.g. when completing inside a macro definition that gets expanded later in the file or during parser recovery).
Comment Actions
Comment Actions
Currently the problem is, there are again some tests out there that rely on Clang :: CodeCompletion/call.cpp Clang :: Index/code-completion.cpp Clang :: Index/complete-call.cpp Clang :: Index/complete-functor-call.cpp Clang :: Index/complete-optional-params.cpp Clang :: Index/complete-pointer-and-reference-to-functions.cpp You can run something like this to check for the output(change ../clangd_bugs): ninja c-index-test && ./bin/c-index-test -code-completion-at=../clangd_bugs/tools/clang/test/Index/complete-call.cpp:53:12 ../clan gd_bugs/tools/clang/test/Index/complete-call.cpp As you can see current version generates only overloadcandidates, but tests But for the first test case it is more complicated, it checks for code patterns Comment Actions
CodeCompleteExpression works just fine there. Unknown parameter type should not block code completion. --- a/lib/Parse/ParseExpr.cpp +++ b/lib/Parse/ParseExpr.cpp @@ -1659,12 +1659,19 @@ Parser::ParsePostfixExpressionSuffix(ExprResult LHS) { if (OpKind == tok::l_paren || !LHS.isInvalid()) { if (Tok.isNot(tok::r_paren)) { - if (ParseExpressionList(ArgExprs, CommaLocs, [&] { - QualType PreferredType = Actions.ProduceCallSignatureHelp( - getCurScope(), LHS.get(), ArgExprs, PT.getOpenLocation()); - Actions.CodeCompleteExpression(getCurScope(), PreferredType); - })) { + auto Completer = [&] { + QualType PreferredType = Actions.ProduceCallSignatureHelp( + getCurScope(), LHS.get(), ArgExprs, PT.getOpenLocation()); + Actions.CodeCompleteExpression(getCurScope(), PreferredType); + CalledOverloadCompletion = true; + }; + if (ParseExpressionList(ArgExprs, CommaLocs, Completer)) { (void)Actions.CorrectDelayedTyposInExpr(LHS); + if (PP.isCodeCompletionReached() && !CalledOverloadCompletion) { + CalledOverloadCompletion = true; + Actions.ProduceCallSignatureHelp( + getCurScope(), LHS.get(), ArgExprs, PT.getOpenLocation()); + } LHS = ExprError(); } else if (LHS.isInvalid()) { for (auto &E : ArgExprs) Please note there are other places where signature help methods (ProduceCallSignatureHelp and ProduceConstructorSignatureHelp) are called, we need to handle all of them. List of files that have those calls:
Comment Actions
Comment Actions Yeah you are right, I thought I could check whether I am inside a parameter or not by looking at qual type, which was apparently wrong :D But, unfortunately, there were still tests failing which was caused by printing of completion strings for overloaded methods with optional parameters. It was trying to access Text field, which is not defined for Optional parameters.
Comment Actions This comment has been deleted.
|
NIT: would go with something less harsh, like "workaround to make sure we only call CodeCompleteCall on the deepest call expression"