This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH 2/3] Support using 'auto' in a function parameter list to introduce an implicit template parameter.
- From: Gabriel Dos Reis <gdr at integrable-solutions dot net>
- To: Jason Merrill <jason at redhat dot com>
- Cc: Adam Butcher <adam at jessamine dot co dot uk>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, Andrew Sutton <andrew dot n dot sutton at gmail dot com>
- Date: Wed, 14 Aug 2013 09:28:57 -0500
- Subject: Re: [PATCH 2/3] Support using 'auto' in a function parameter list to introduce an implicit template parameter.
- References: <1376250573-13753-1-git-send-email-adam at jessamine dot co dot uk> <1376250573-13753-3-git-send-email-adam at jessamine dot co dot uk> <52090681 dot 2010108 at redhat dot com> <5702a0e17d0b380c6c2a03996d43e66e at imap dot force9 dot net> <520B8F19 dot 8090203 at redhat dot com>
On Wed, Aug 14, 2013 at 9:07 AM, Jason Merrill <jason@redhat.com> wrote:
> On 08/12/2013 08:34 PM, Adam Butcher wrote:
>>
>> Currently it is the implicit function template code in pt.c that updates
>> this; specifically add_implicit_template_parms and
>> finish_fully_implicit_template.
>>
>> It is queried by the parser (both in parser.c and lambda.c) to decide
>> whether a new [implicit] template parameter list as been started and to
>> decide how to finish up.
>>
>> I had a look into this; it should be possible to move these out of pt.c
>> and into parser.c (or some new file generic-parms.c, implicit-pt.c or
>> some such) and possibly add a plain global counter for this state,
>> rather than attribute it to each scope.
>
>
> Right, I was thinking it would make sense as a field of cp_parser, since it
> doesn't affect template instantiation context.
Agreed. I think we should reduce the number of such object macro states.
-- Gaby