On 09.08.2013 03:01, Jason Merrill wrote:
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.
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
symtab entry).
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".
Cheers,
Adam