This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [FIXED] Generic lambda symbol table bug

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".


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]