aboutsummaryrefslogtreecommitdiff
path: root/gcc/objc/objc-next-runtime-abi-01.c
diff options
context:
space:
mode:
authorPatrick Palka <ppalka@redhat.com>2022-01-11 13:00:48 -0500
committerPatrick Palka <ppalka@redhat.com>2022-01-11 13:00:48 -0500
commit0378f563b0321c44c4a9c98cf46d2a22b9160f76 (patch)
tree19cbe16081528335a8b3402da691793765ae4636 /gcc/objc/objc-next-runtime-abi-01.c
parent46de918f9892e637845bd97b4ca95011d46d3733 (diff)
downloadgcc-0378f563b0321c44c4a9c98cf46d2a22b9160f76.zip
gcc-0378f563b0321c44c4a9c98cf46d2a22b9160f76.tar.gz
gcc-0378f563b0321c44c4a9c98cf46d2a22b9160f76.tar.bz2
c++: dependent bases and 'this' availability [PR103831]
Here during satisfaction of B's constraints we're failing to reject the object-less call to the non-static member function A::size ultimately because satisfaction is performed in the (access) context of the class template B, which has a dependent base, and so the any_dependent_bases_p check within build_new_method_call causes us to not reject the call. (Subsequent constexpr evaluation of the call succeeds since the function is effectively static.) This patch fixes this by refining the any_dependent_bases_p check within build_new_method_call: if we're in a context where 'this' is unavailable, then we cannot resolve the implicit object regardless of the presence of a dependent base. So let's also check current_class_ptr alongside a_d_b_p. PR c++/103831 gcc/cp/ChangeLog: * call.c (build_new_method_call): Consider dependent bases only if 'this' is available. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/concepts-class3.C: New test. * g++.dg/template/non-dependent18.C: New test.
Diffstat (limited to 'gcc/objc/objc-next-runtime-abi-01.c')
0 files changed, 0 insertions, 0 deletions