[PATCH] D155370: [CodeComplete] Improve FunctionCanBeCall

2023-08-06 Thread Younan Zhang via Phabricator via cfe-commits
zyounan abandoned this revision. zyounan added a comment. Closing this in favor of D156605 . Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D155370/new/ https://reviews.llvm.org/D155370 _

[PATCH] D155370: [CodeComplete] Improve FunctionCanBeCall

2023-08-03 Thread Younan Zhang via Phabricator via cfe-commits
zyounan planned changes to this revision. zyounan added a comment. In D155370#4552967 , @nridge wrote: > I was thinking of functions with different names (with a common prefix) and > different signatures, where the signature could be a useful piece of >

[PATCH] D155370: [CodeComplete] Improve FunctionCanBeCall

2023-08-02 Thread Nathan Ridge via Phabricator via cfe-commits
nridge added a comment. In D155370#4550042 , @zyounan wrote: > in the context where `CanBeCall=false`, parameters don't disambiguate against > the overloads, so we'd end up with the same function name after selecting the > candidate I was thinking of f

[PATCH] D155370: [CodeComplete] Improve FunctionCanBeCall

2023-08-01 Thread Younan Zhang via Phabricator via cfe-commits
zyounan added a comment. In D155370#4545763 , @nridge wrote: > (e.g. maybe you're looking for one with a particular parameter type). I understand the second point that it'd be nice to offer the user a chance to see the arguments in order to help decide

[PATCH] D155370: [CodeComplete] Improve FunctionCanBeCall

2023-07-31 Thread Nathan Ridge via Phabricator via cfe-commits
nridge added a comment. I'm not sure how I feel about dropping the parameters from the signature in the `CanBeCall = false` case. I can see arguments in both directions: - On the one hand, dropping the parameters makes the text that is inserted more consistent with the text that is shown for t

[PATCH] D155370: [CodeComplete] Improve FunctionCanBeCall

2023-07-29 Thread Younan Zhang via Phabricator via cfe-commits
zyounan added inline comments. Comment at: clang/lib/Sema/SemaCodeComplete.cpp:1407 R.FunctionCanBeCall = CurrentClassScope && zyounan wrote: > The current heuristic results in the following: > > ``` > struct Base { > void foo(int); > }; >

[PATCH] D155370: [CodeComplete] Improve FunctionCanBeCall

2023-07-25 Thread Younan Zhang via Phabricator via cfe-commits
zyounan added inline comments. Comment at: clang/lib/Sema/SemaCodeComplete.cpp:1407 R.FunctionCanBeCall = CurrentClassScope && The current heuristic results in the following: ``` struct Base { void foo(int); }; struct Derived : Base { voi

[PATCH] D155370: [CodeComplete] Improve FunctionCanBeCall

2023-07-23 Thread Younan Zhang via Phabricator via cfe-commits
zyounan added a comment. Thanks for the insightful suggestions! (Apologies for my late update. Just had a really busy week.) As suggested, I left the CCR intact and handled these functions in `CodeCompletionResult::createCodeCompletionStringForDecl`. I think this preserves the Declaration, righ