This is the mail archive of the
mailing list for the GCC project.
Re: [FIXED] Generic lambda symbol table bug
- From: Adam Butcher <adam at jessamine dot co dot uk>
- To: Jason Merrill <jason at redhat dot com>
- Cc: <gcc-patches at gcc dot gnu dot org>, Gabriel Dos Reis <gdr at integrable-solutions dot net>, Andrew Sutton <andrew dot n dot sutton at gmail dot com>
- Date: Fri, 09 Aug 2013 08:29:12 +0100
- Subject: Re: [FIXED] Generic lambda symbol table bug
- References: <52001874 dot 5050105 at redhat dot com> <1375861956-11593-1-git-send-email-adam at jessamine dot co dot uk> <52026EC6 dot 6060605 at redhat dot com> <7ac5b3090b98d245da255ee325477b16 at imap dot force9 dot net> <21ece1f2d5f936fdb0501c3178d7ad9a at imap dot force9 dot net> <52044D6E dot 4020306 at redhat dot com>
On 09.08.2013 03:01, Jason Merrill wrote:
Yup. Although the lambda template code I originally added scoped it to
within the the 'cp_parser_lambda_declarator_opt' function, since the
call op being declared is an in-class inline member,
'start_preparsed_function' is entering
'maybe_begin_member_template_processing'. 'finish_function' matches
that with 'maybe_end_member_template_processing' prior to the function
being passed to 'expand_or_defer_fn' (which then causes the erroneous
On 08/08/2013 06:28 PM, Adam Butcher wrote:
So all seems to be okay with both versions. Any ideas why?
Hmm, it sounds like processing_template_decl is being set after all,
even without your change.
So I think my original fix might be okay here; omitting
'expand_or_defer_fn' if 'generic_lambda_p'.
What do you think? Shall I just include it as part of the first patch?
If so that'd just be two patches, "teach GCC to deal with lambda
templates" and "implicit function templates with auto".