This is the mail archive of the gcc-patches@gcc.gnu.org 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: [PR c++/83406] deducing lambda type


On Thu, Dec 21, 2017 at 12:33 PM, Nathan Sidwell <nathan@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


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