From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-4322.protonmail.ch (mail-4322.protonmail.ch [185.70.43.22]) by sourceware.org (Postfix) with ESMTPS id EBBD03858D33 for ; Sun, 19 Nov 2023 13:40:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org EBBD03858D33 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=protonmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=protonmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org EBBD03858D33 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=185.70.43.22 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1700401202; cv=none; b=QC8U9N9P3Jq2oUkxQuBtfE8CvwMNF4Ta2pB50/VG/NK7Zl8lOtWj6wODeTLCm0y9dr1zqM6jcbmbAqwi+KKZ2jEfgF55fUcGEMbs4wEuE/rTOZis4C8l4NHYjvVySO1r4RJOhDyfFDIAg05TBgXxjmxTak3PsOoV/pw5vqHhqmU= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1700401202; c=relaxed/simple; bh=A2iL9b0DIQ9RCSTtsjNda7cH3dd8+m6eAMKOyXilMuU=; h=DKIM-Signature:Date:To:From:Subject:Message-ID:MIME-Version; b=nF5Y7DMhDAnE/b2izbEKAZK1u02Yecpq75n0VjkWNP1lEtJQ67dk5N3gLsr0ZZNHZhcRabhfa1LDb5n9sl901OwNpox0jJXSqez4I0/42if4/rQqe7ZCPmF5mhSks91BmndhivVXjiNTYcFRyJ31CasrZ0HU5L1Z4HrasaHYCnw= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1700401197; x=1700660397; bh=YRzb3juwQL3blpHQsBLn0CeWkpcHwlpsk/rn828eenE=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=GPQeyzZg3NEEdeor+ECMZXnlo2qsGrJpWHflvmSnyd/0pXsQjWZUy0/xatQ2b5iC0 plsvVHWZLVu2tuFmiwLwlYavOKrmafHu02FetB1USjv5iOKGvvRczniWeO2SaXqk60 /DlgSgjUjXfDeQK5s1L5T0yP3pq3x7NJM7Lg41HaJYrrWwVQR2/KKxrSrnzpS1kU2z riWX2N2AgHuxVdQvTGuPX+55Tod7j9v0mjPetvo0YJM0giYkvGUAOyEQeWiEFequ1f OiyY7A57K6qpTeQEkmNWNlwXJPLUxpDrhmWwY5KOavbB1tfnyE1Nl8ILVYgwimpMg7 O8gAQRlwrFtzA== Date: Sun, 19 Nov 2023 13:39:43 +0000 To: Jason Merrill From: waffl3x Cc: "gcc-patches@gcc.gnu.org" Subject: Re: [PATCH v3 1/2] c++: Initial support for P0847R7 (Deducing This) [PR102609] Message-ID: In-Reply-To: References: <00094736-8325-4c83-9237-a6c15c324c24@redhat.com> <3tSXKK_P5IpLLm2VJ76q-eiLPZhiaC6_ZpwOrej22LWsmGA_YXipLXwLdLNeFlShJaqpFH_LPQW6tqkPD1WlFnExnL-iDoW9CoA-KQETWYw=@protonmail.com> Feedback-ID: 14591686:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_MSPIKE_H5,RCVD_IN_MSPIKE_WL,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE,URIBL_BLACK,WEIRD_PORT autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Funny enough I ended up removing the ones I was thinking about, seems to always happen when I ask style questions but I'm glad to hear it's okay going forward. I'm having trouble fixing this bug, based on what Gasper said in PR102609 I am pretty sure I know what the semantics should be. Since the capture is not used in the body of the function, it should be well formed to call the function with an unrelated type. I had begun trying to tackle the case that Gasper mentioned and got the following ICE. I also have another case that ICEs so I've been thinking I don't get to do little changes to fix this. I've been looking at this for a few hours now and given we are past the deadline now I figured I should see what others think. int main() { int x =3D 42; auto f1 =3D [x](this auto&& self) {}; static_cast(decltype(f1)::operator()); } explicit-obj-lambdaX3.C: In instantiation of 'main():: st= atic [with auto:1 =3D int&]': explicit-obj-lambdaX3.C:33:53: required from here 33 | static_cast(decltype(f1)::operator()); | ^ explicit-obj-lambdaX3.C:31:33: internal compiler error: tree check: expecte= d record_type or union_type or qual_union_type, have integer_type in finish= _non_static_data_member, at cp/semantics.cc:2294 31 | auto f1 =3D [x](this auto&& self) {}; | ^ 0x1c66dda tree_check_failed(tree_node const*, char const*, int, char const*= , ...) =09/home/waffl3x/projects/gcc-dev/workspace/src/xobj-next/gcc/tree.cc:8949 0xb2e125 tree_check3(tree_node*, char const*, int, char const*, tree_code, = tree_code, tree_code) =09/home/waffl3x/projects/gcc-dev/workspace/src/xobj-next/gcc/tree.h:3638 0xedfaf4 finish_non_static_data_member(tree_node*, tree_node*, tree_node*, = int) =09/home/waffl3x/projects/gcc-dev/workspace/src/xobj-next/gcc/cp/semantics.= cc:2294 0xe8b9b8 tsubst_expr(tree_node*, tree_node*, int, tree_node*) =09/home/waffl3x/projects/gcc-dev/workspace/src/xobj-next/gcc/cp/pt.cc:2086= 4 0xe6d713 tsubst_decl =09/home/waffl3x/projects/gcc-dev/workspace/src/xobj-next/gcc/cp/pt.cc:1538= 7 0xe6fb1b tsubst(tree_node*, tree_node*, int, tree_node*) =09/home/waffl3x/projects/gcc-dev/workspace/src/xobj-next/gcc/cp/pt.cc:1596= 7 0xe7bd81 tsubst_stmt =09/home/waffl3x/projects/gcc-dev/workspace/src/xobj-next/gcc/cp/pt.cc:1829= 9 0xe7df18 tsubst_stmt =09/home/waffl3x/projects/gcc-dev/workspace/src/xobj-next/gcc/cp/pt.cc:1855= 4 0xea6982 instantiate_body =09/home/waffl3x/projects/gcc-dev/workspace/src/xobj-next/gcc/cp/pt.cc:2674= 3 0xea83e9 instantiate_decl(tree_node*, bool, bool) =09/home/waffl3x/projects/gcc-dev/workspace/src/xobj-next/gcc/cp/pt.cc:2703= 0 0xb5f9c9 resolve_address_of_overloaded_function =09/home/waffl3x/projects/gcc-dev/workspace/src/xobj-next/gcc/cp/class.cc:8= 802 0xb60be1 instantiate_type(tree_node*, tree_node*, int) =09/home/waffl3x/projects/gcc-dev/workspace/src/xobj-next/gcc/cp/class.cc:9= 061 0xaf9992 standard_conversion =09/home/waffl3x/projects/gcc-dev/workspace/src/xobj-next/gcc/cp/call.cc:12= 44 0xafcb57 implicit_conversion =09/home/waffl3x/projects/gcc-dev/workspace/src/xobj-next/gcc/cp/call.cc:20= 81 0xb2a8cb perform_direct_initialization_if_possible(tree_node*, tree_node*, = bool, int) =09/home/waffl3x/projects/gcc-dev/workspace/src/xobj-next/gcc/cp/call.cc:13= 456 0xf69db8 build_static_cast_1 =09/home/waffl3x/projects/gcc-dev/workspace/src/xobj-next/gcc/cp/typeck.cc:= 8356 0xf6af1b build_static_cast(unsigned int, tree_node*, tree_node*, int) =09/home/waffl3x/projects/gcc-dev/workspace/src/xobj-next/gcc/cp/typeck.cc:= 8566 0xd9fc02 cp_parser_postfix_expression =09/home/waffl3x/projects/gcc-dev/workspace/src/xobj-next/gcc/cp/parser.cc:= 7531 0xda45af cp_parser_unary_expression =09/home/waffl3x/projects/gcc-dev/workspace/src/xobj-next/gcc/cp/parser.cc:= 9244 0xda5db4 cp_parser_cast_expression =09/home/waffl3x/projects/gcc-dev/workspace/src/xobj-next/gcc/cp/parser.cc:= 10148 As I said, there is also this case that also ICEs in the same region. It's making me think that some core assumptions are being violated in the code leading up to finish_non_static_data_member. int main() { int x =3D 42; auto f1 =3D [x](this auto self) {}; } explicit-obj-lambdaX3.C: In lambda function: explicit-obj-lambdaX3.C:31:31: internal compiler error: Segmentation fault 31 | auto f1 =3D [x](this auto self) {}; | ^ 0x1869eaa crash_signal =09/home/waffl3x/projects/gcc-dev/workspace/src/xobj-next/gcc/toplev.cc:315 0xb2ea0b strip_array_types(tree_node*) =09/home/waffl3x/projects/gcc-dev/workspace/src/xobj-next/gcc/tree.h:4955 0xf773e2 cp_type_quals(tree_node const*) =09/home/waffl3x/projects/gcc-dev/workspace/src/xobj-next/gcc/cp/typeck.cc:= 11509 0xedf993 finish_non_static_data_member(tree_node*, tree_node*, tree_node*, = int) =09/home/waffl3x/projects/gcc-dev/workspace/src/xobj-next/gcc/cp/semantics.= cc:2271 0xcc3e12 build_capture_proxy =09/home/waffl3x/projects/gcc-dev/workspace/src/xobj-next/gcc/cp/lambda.cc:= 410 0xcce99a start_lambda_function(tree_node*, tree_node*) =09/home/waffl3x/projects/gcc-dev/workspace/src/xobj-next/gcc/cp/lambda.cc:= 1684 0xdab196 cp_parser_lambda_body =09/home/waffl3x/projects/gcc-dev/workspace/src/xobj-next/gcc/cp/parser.cc:= 12004 0xda8f64 cp_parser_lambda_expression =09/home/waffl3x/projects/gcc-dev/workspace/src/xobj-next/gcc/cp/parser.cc:= 11293 0xd9c03a cp_parser_primary_expression =09/home/waffl3x/projects/gcc-dev/workspace/src/xobj-next/gcc/cp/parser.cc:= 5921 0xda0b33 cp_parser_postfix_expression =09/home/waffl3x/projects/gcc-dev/workspace/src/xobj-next/gcc/cp/parser.cc:= 7868 0xda45af cp_parser_unary_expression =09/home/waffl3x/projects/gcc-dev/workspace/src/xobj-next/gcc/cp/parser.cc:= 9244 0xda5db4 cp_parser_cast_expression =09/home/waffl3x/projects/gcc-dev/workspace/src/xobj-next/gcc/cp/parser.cc:= 10148 0xda5ecd cp_parser_binary_expression =09/home/waffl3x/projects/gcc-dev/workspace/src/xobj-next/gcc/cp/parser.cc:= 10251 0xda6fd9 cp_parser_assignment_expression =09/home/waffl3x/projects/gcc-dev/workspace/src/xobj-next/gcc/cp/parser.cc:= 10595 0xda77b3 cp_parser_constant_expression =09/home/waffl3x/projects/gcc-dev/workspace/src/xobj-next/gcc/cp/parser.cc:= 10885 0xdc9a36 cp_parser_initializer_clause =09/home/waffl3x/projects/gcc-dev/workspace/src/xobj-next/gcc/cp/parser.cc:= 25844 0xdc981d cp_parser_initializer =09/home/waffl3x/projects/gcc-dev/workspace/src/xobj-next/gcc/cp/parser.cc:= 25783 0xdc40bd cp_parser_init_declarator =09/home/waffl3x/projects/gcc-dev/workspace/src/xobj-next/gcc/cp/parser.cc:= 23332 0xdb46d2 cp_parser_simple_declaration =09/home/waffl3x/projects/gcc-dev/workspace/src/xobj-next/gcc/cp/parser.cc:= 15690 0xdb41e5 cp_parser_block_declaration =09/home/waffl3x/projects/gcc-dev/workspace/src/xobj-next/gcc/cp/parser.cc:= 15510 Any insight is appreciated here, I've been going through with GDB and I do feel like I'm making progress, but I'm not much closer to figuring out what the correct solution (to the first) is. Right now, my plan is when trying to access captures, it should be checking to see if the type of the xobj param passed in is related to the context of the function decl. I just haven't figured out exactly where to insert it yet. With any luck, now that I've written an e-mail saying I'm having trouble I'll immediately figure out what to do. It's happened every previous time so far. :) Alex On Saturday, November 18th, 2023 at 11:22 PM, Jason Merrill wrote: >=20 >=20 > On Sat, Nov 18, 2023 at 1:43=E2=80=AFAM waffl3x waffl3x@protonmail.com wr= ote: >=20 > > The patch is coming along, I just have a quick question regarding > > style. I make use of IILE's (immediately invoked lambda expression) a > > whole lot in my own code. I know that their use is controversial in > > general so I would prefer to ask instead of just submitting the patch > > using them a bunch suddenly. I wouldn't have bothered either but this > > part is really miserable without them. >=20 >=20 > We don't use them much currently, but I'm not opposed to them either, > if they help make the code clearer. >=20 > > If that would be okay, I would suggest an additional exception to > > bracing style for lambdas. > > This: > > { > > // stuff > > }; > > Instead of this: > >=20 > > { > > // stuff > > }; >=20 >=20 > Makes sense. >=20 > Jason