On Thu, Dec 21, 2017 at 12:33 PM, Nathan Sidwell <nat...@acm.org> wrote: > Jason, this needs a sanity check > > 83406 was exposed by Jason's recent patch removing return_type & closure > from the tree_lambda_expr node: > Remove unnecessary LAMBDA_EXPR fields. > > * cp-tree.h (LAMBDA_EXPR_CLOSURE): Use TREE_TYPE. > (LAMBDA_EXPR_RETURN_TYPE): Remove. > (struct tree_lambda_expr): Remove closure and return_type fields. > * lambda.c (build_lambda_expr): Don't set LAMBDA_EXPR_RETURN_TYPE. > * pt.c (tsubst_copy_and_build): Likewise. > * parser.c (cp_parser_lambda_declarator_opt): Track return type. > (cp_parser_lambda_body): Adjust unspecified return type check. > * ptree.c (cxx_print_lambda_node): Don't print closure or > return type. > > The culprit is cp_parser_lambda_body > if (is_auto (TREE_TYPE (TREE_TYPE (fco))) ... > > is_auto is true for []() {...}, which is what we want and things like [] > ()->decltype(auto) {...}, which we don't. The simple fix is to check > TYPE_HAS_LATE_RETURN_TYPE instead, as that's only false in the former case.
Ah, true. > However, this whole if looks bogus. > > This quoted text is not in the std (even adjusting by +3 for the clause > renumbering). It's not in the c++11 draft I have available either. >> >> /* 5.1.1.4 of the standard says: >> If a lambda-expression does not include a trailing-return-type, it >> is as if the trailing-return-type denotes the following type: >> * if the compound-statement is of the form >> { return attribute-specifier [opt] expression ; } >> the type of the returned expression after lvalue-to-rvalue >> conversion (_conv.lval_ 4.1), array-to-pointer conversion >> (_conv.array_ 4.2), and function-to-pointer conversion >> (_conv.func_ 4.3); >> * otherwise, void. */ It's in published C++11 (N3290), but... > And the next comment is confusing, the second sentence appears to be a total > lie. >> >> /* In a lambda that has neither a lambda-return-type-clause >> nor a deducible form, errors should be reported for return statements >> in the body. Since we used void as the placeholder return type, >> parsing >> the body as usual will give such desired behavior. */ Not a lie for original C++11, given the above text. But none of my compilers diagnose this, probably because we decided to consider the lambda changes in N3638 to be a C++11 DR. > Removing it breaks nothing beyond changing the diagnostic that > g++.dg/cpp0x/lambda/lambda-ice15.C expects. And fixes this regression. OK. Let's replace it with a comment about N3638. > The introductory comment: >> >> /* Finish the function call operator >> - class_specifier >> + late_parsing_for_member >> + function_definition_after_declarator >> + ctor_initializer_opt_and_function_body */ > > looks like the kind of development note I'd write to myself. It doesn't > match the code (any more?). I think the comment was meant to explain that the code below was doing the pieces that would normally be handled by those functions. I don't mind removing it. Jason