This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PR c++/83406] deducing lambda type
- From: Jason Merrill <jason at redhat dot com>
- To: Nathan Sidwell <nathan at acm dot org>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 21 Dec 2017 13:46:27 -0500
- Subject: Re: [PR c++/83406] deducing lambda type
- Authentication-results: sourceware.org; auth=none
- References: <95555f6b-4822-da15-7ceb-717007a3b8ba@acm.org>
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