This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [C++ Patch] PR 57543
- From: Paolo Carlini <paolo dot carlini at oracle dot com>
- To: Jason Merrill <jason at redhat dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Fri, 30 May 2014 16:21:13 +0200
- Subject: Re: [C++ Patch] PR 57543
- Authentication-results: sourceware.org; auth=none
- References: <5384935D dot 5020406 at oracle dot com> <5384C817 dot 9010004 at redhat dot com> <5385064C dot 9020203 at oracle dot com> <53850C1F dot 7020902 at oracle dot com> <5385B756 dot 8070707 at oracle dot com> <5385FD69 dot 6020000 at redhat dot com> <538602EF dot 9060605 at oracle dot com> <53860589 dot 5040106 at redhat dot com> <538607DF dot 8060702 at oracle dot com> <53860FE6 dot 8050207 at redhat dot com> <53861796 dot 7070309 at oracle dot com> <5387376D dot 4070407 at redhat dot com> <538787CA dot 1030209 at oracle dot com> <53889222 dot 80401 at redhat dot com>
Hi,
On 05/30/2014 04:13 PM, Jason Merrill wrote:
On 05/29/2014 03:17 PM, Paolo Carlini wrote:
I put together the below which already passes testing.
Thanks!
You are welcome. Let's finish this, then ;)
+ bool do_inject = this_type && !dependent_type_p (this_type);
!dependent_type_p should be !dependent_scope_p, or perhaps even
CLASS_TYPE_P. It should be OK to inject a this pointer of a dependent
class, and we might need it to get the right semantics.
I suspected that. I'll experiment with the latter, or in case the former.
You also need to propagate the flag in a bunch of other places:
everywhere we call build_method_type_directly ought to cover it.
Agreed, I spotted a few places. What about build_function_type? I think
it's the same issue, right? Because in that case we don't have any
problem with the injection of this but we want to propagate the flag in
order to eventually have tsubst_function_type substituting in the right
order.
Paolo.