https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101904
--- Comment #8 from CVS Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Patrick Palka <ppa...@gcc.gnu.org>: https://gcc.gnu.org/g:22806064a67cf30599957c1ffb322aa30e9e57e7 commit r12-3559-g22806064a67cf30599957c1ffb322aa30e9e57e7 Author: Patrick Palka <ppa...@redhat.com> Date: Wed Sep 15 18:41:21 2021 -0400 c++: shortcut bad convs during overload resolution, part 2 [PR101904] The r12-3346 change makes us avoid computing excess argument conversions during overload resolution, but only when it turns out there's a strictly viable candidate in the overload set. If there's no such candidate then we still need to compute more conversions than strictly necessary because subsequent conversions after the first bad conversion can turn a non-strictly viable candidate into an unviable one, and that affects the outcome of overload resolution and the behavior of its callers (because of -fpermissive). But at least in a SFINAE context, the distinction between a non-strictly viable and an unviable candidate shouldn't matter all that much since performing a bad conversion is always an error (even with -fpermissive), and so forming a call to a non-strictly viable candidate will end up being a SFINAE error anyway, just like in the unviable case. Hence a non-strictly viable candidate is effectively unviable (in a SFINAE context), and we don't really need to distinguish between the two kinds. We can take advantage of this observation to avoid computing excess argument conversions even when there's no strictly viable candidate in the overload set. This patch implements this idea. We usually detect a SFINAE context by looking for the absence of the tf_error flag, but that's not specific enough: we can also get here from build_user_type_conversion with tf_error cleared, and there the distinction between a non-strictly viable candidate and an unviable candidate still matters (it determines whether a user-defined conversion is bad or just doesn't exist). So this patch sets and checks for the tf_conv flag to detect this situation too, which avoids regressing conv2.C below. Unlike the previous change, this one does affect the outcome of overload resolution, but it should do so only in a way that preserves backwards compatibility with -fpermissive. PR c++/101904 gcc/cp/ChangeLog: * call.c (build_user_type_conversion_1): Add tf_conv to complain. (add_candidates): When in a SFINAE context, instead of adding a candidate to bad_fns just mark it unviable. gcc/testsuite/ChangeLog: * g++.dg/ext/conv2.C: New test. * g++.dg/template/conv17.C: Extend test.
