nridge added a comment.
In D155370#4550042 <https://reviews.llvm.org/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 functions with different names (with a common prefix) and
different signatures, where the signature could be a useful piece of
information in addition to the name to help you choose the right one.
For example, consider:
struct Thread {
void sleep_until(time_point);
void sleep_for(time_duration);
};
&Thread::sleep^
Maybe the distinction between the functions is less obvious from their names
(`until` vs. `for`), but more obvious from the type of argument they take.
In D155370#4550042 <https://reviews.llvm.org/D155370#4550042>, @zyounan wrote:
> An explicit cast may be required to perform overload resolution if necessary
> <https://en.cppreference.com/w/cpp/language/overloaded_address>, but that
> should occur before the completion point `&ClassName::Prefix^`.
(That would be an interesting future enhancement to consider for the overload
set case.)
> OTOH, we don't present parameters for overloads in the candidates (using the
> clangd without this patch):
>
> F28542806: image.png <https://reviews.llvm.org/F28542806>
>
> (At least for VSCode, I'm not sure if others behave the same.)
Note, we have a flag that affects this, `--completion-style=detailed`.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D155370/new/
https://reviews.llvm.org/D155370
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
