[PATCH] D133052: [clang] Avoid crash when expanding conversion templates in concepts.

Yuanfang Chen via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Wed Aug 31 21:59:02 PDT 2022


ychen added a comment.

In D133052#3763041 <https://reviews.llvm.org/D133052#3763041>, @luken-google wrote:

> In D133052#3762596 <https://reviews.llvm.org/D133052#3762596>, @ychen wrote:
>
>> Like mentioned in https://stackoverflow.com/questions/68853472/is-this-a-bug-in-clangs-c20-concepts-implementation-unnecessary-checking-of, could we not go down the path of considering conversion candidates? It seems that's blessed by the standard.
>
> If I'm understanding the code correctly, the intent of this patch is to definitely consider conversion candidates, only to exclude those conversion candidates that are templated methods where the From type is the same as the To type, which to me mean they are possibly redundant?

Excluding them is basically saying "because it may be a redundant conversion, we should not consider it as the best via function." which doesn't seem correct to me.

I think the straightforward approach would be to check if we're in the `ConstraintCheck` instantiation context, and if so check if any template parameter is constrained by the same concept. However, I'm worried about the overhead. So I'd prefer to skip this add-conv-candicates-for-copy-elision path (https://github.com/llvm/llvm-project/blob/main/clang/lib/Sema/SemaInit.cpp#L4012-L4053) during the concept check. The compiler guarantees copy elision under certain conditions (C++17) but I could not think of any situation that users want to or could check copy elision inside the concept. So I think we're safe.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D133052/new/

https://reviews.llvm.org/D133052



More information about the cfe-commits mailing list