From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id E61E13858C52 for ; Thu, 30 Nov 2023 05:00:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E61E13858C52 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org E61E13858C52 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701320413; cv=none; b=UTc6CCtwYEgCHLnUOFPw6fdW/yja3cZQ1a0+ipGXOMT9JM2VzJqvr36VWYnzPmkqreZ2J6VA9buYiU52m2y77lrvz9YBnLCxlcJw2MA/RTtAgAZr76kAxLwdGyZF6i3gACb5ATB4/uqe4/PsWkgnQHyhLmf+OhlNS/PEwC+GUHg= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701320413; c=relaxed/simple; bh=g+EK6zRNLs42ciB6hIRZmTt/vDm2laUTXkJRJ9UaMeI=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=F9uhsopyGU/xZ1xS9TN2YGdqWUC5trQdkzSoEN/EiCr7XUtE9KJoz1k46H/FY63qysKJQjH9S+LomyPE1KY0CAn/QqllOrvoQIrcYv/hJ8AVYlk5YQFPeB85dXJWHAJeqY5MXqYuESFSFIHu81SBUIEWdJGvTg6PxIOJsIvZyZQ= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1701320411; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=ced+uOA74P4jdLo252dO2jve1szzOYmiAd/qMzWH/iE=; b=fGeSYRlD11RKzzGZ73MRNl2HeZU8paopflGsi+iZ1hAFCgl+938lj7P+qb6eDrxNyzVRXm GF+jYanEQBleN/Y3OuW1PVK08e8EsoKqtOt3bcpjYv3jRNBl5xSYBe4VeVO1oD3gO43Sya mPFYtfNyeS7bjg3h/AvdltnnISoFA1A= Received: from mail-qv1-f72.google.com (mail-qv1-f72.google.com [209.85.219.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-257-iUKChrs4MkGwYuph19o88A-1; Thu, 30 Nov 2023 00:00:08 -0500 X-MC-Unique: iUKChrs4MkGwYuph19o88A-1 Received: by mail-qv1-f72.google.com with SMTP id 6a1803df08f44-67a0f1be799so8456856d6.2 for ; Wed, 29 Nov 2023 21:00:08 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701320407; x=1701925207; h=in-reply-to:from:references:cc:to:content-language:subject :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=Xv4m/s0o/g+fKq8s9Voyn6OAgxfo2/YC5K9/l260gIg=; b=f9OkuTf4hZx/QmFkS8i+oAWOfCuBIEGzwcL1BF45Rwnu8ZkOyioq4LVyRsSstQL63D DiVgWFRfGtGmtqiYRk13GDlFC/J0SfPSRB5h/DCku3dOfNZBYCzq29xDAsDQguCaXP7l BuGCreBgwmEBsgo7gLkvQcIEx8/8KCj4gL6XA02CSCqqRIU6FDUrH3Od8Ld8lfwbfH98 qJMK0lTXsc+4Nwdwc1yQSuRTeQNsQ5LWxaVNesaeJMFDIpe3JSS0FR/Vnlk/1xJ8XUiQ LFohCMZkAT5ZI+2zQNUEyElsD6cDQeNo+K4cstT8RByYBiI19twhw1hRNILcSc7Flwfu p0UA== X-Gm-Message-State: AOJu0YzTIDArgCfyCeiKXKfyt5KQilQCJX1qMKZuQSVPvrzPZquTyP41 eQB0lIwhw/ZWRUppATP70v0dVI30XdajTVBCoeK0gZlIm4Ss4EAXFbcA3PvgjW/dOSyq5mxcmsm WLrUqx9ywKF8u/HBBkqyOFLIq/Q== X-Received: by 2002:ad4:4211:0:b0:658:22f8:4e51 with SMTP id k17-20020ad44211000000b0065822f84e51mr23172617qvp.1.1701320407726; Wed, 29 Nov 2023 21:00:07 -0800 (PST) X-Google-Smtp-Source: AGHT+IF6iorPbBJm3G7tXDVrlxFpFEA0JLa8CsvT6ayEfcJOohFGknDVjOQZn/RsyvY59B516s79bg== X-Received: by 2002:ad4:4211:0:b0:658:22f8:4e51 with SMTP id k17-20020ad44211000000b0065822f84e51mr23172592qvp.1.1701320407359; Wed, 29 Nov 2023 21:00:07 -0800 (PST) Received: from [192.168.1.145] (130-44-146-16.s12558.c3-0.arl-cbr1.sbo-arl.ma.cable.rcncustomer.com. [130.44.146.16]) by smtp.gmail.com with ESMTPSA id l1-20020a0cac01000000b0067a291f473esm153598qvb.68.2023.11.29.21.00.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 29 Nov 2023 21:00:05 -0800 (PST) Message-ID: Date: Thu, 30 Nov 2023 00:00:04 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6 1/1] c++: Initial support for P0847R7 (Deducing This) [PR102609] To: waffl3x Cc: "gcc-patches@gcc.gnu.org" References: <7Xr5Vil7ptZzPaCtc_ZCdcTPuUVY7dheOnklF-vVDb5_jl8PivYWgTT_f3cKLvg7IMnDruCDDrICRI6WVrUT3f8ZScGKAh4ATIkYSuRqPZc=@protonmail.com> <-SP7aKgN1FZED-RAPr2FBDuCrcwnu9-UhHcRXNEsNZRwIzJXCdhVbtBP921Yn8g71d0WL7XpFRetUlBAStzRpZB8p4yj5moRS0DIE9D6cnY=@protonmail.com> <7623e2db-ba29-42f2-85df-c2e796d7305b@redhat.com> From: Jason Merrill In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: multipart/mixed; boundary="------------dfq5mrVnesuxqOUeU3LUQBCS" Content-Language: en-US X-Spam-Status: No, score=-12.2 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: This is a multi-part message in MIME format. --------------dfq5mrVnesuxqOUeU3LUQBCS Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 11/27/23 00:35, waffl3x wrote: > I think this is cleaned up enough to be presentable. Bootstrapped but > not tested but I don't think I changed anything substantial. I am > running tests right now and will report if anything fails. I have not > fixed the problem in tsubst_lambda_expr that we talked about, that will > be first on my list tomorrow. While writing/cleaning up tests I had to > investigate some things, one of which is calling an overloaded > function, where one of the candidates are introduced by a using > declaration, is considered ambiguous. I haven't narrowed down the case > for this yet so I don't know if it's related to xobj member > functions/lambda with xobj parameters or not. I had to pull a few tests > because of it though. > > I did not get as much done as I would have hoped today. This really > just serves as a small progress update. Once again, todo is the issue > you raised in tsubst_lambda_expr, and fixing handling of captures when > a const xobj parameter is deduced in a lamdba call operator. > +#define DECL_IOBJ_MEMBER_FUNC_P(NODE) \ > +#define DECL_XOBJ_MEMBER_FUNC_P(NODE) \ > +#define DECL_OBJECT_MEMBER_FUNC_P(NODE) \ Let's use the full word FUNCTION in these macros for consistency with DECL_STATIC_FUNCTION_P. > @@ -6544,7 +6544,7 @@ add_candidates (tree fns, tree first_arg, const vec *args, > tree fn_first_arg = NULL_TREE; > const vec *fn_args = args; > > - if (DECL_NONSTATIC_MEMBER_FUNCTION_P (fn)) > + if (DECL_OBJECT_MEMBER_FUNC_P (fn)) > { > /* Figure out where the object arg comes from. If this > function is a non-static member and we didn't get an Hmm, that this function explicitly pulls out the object argument into first_arg strengthens your earlier argument that we shouldn't bother trying to handle null first_arg. But let's not mess with that in this patch. > + val = handle_arg(TREE_VALUE (parm), Missing space. > /* We know an iobj parameter must be a reference. If our xobj > parameter is a pointer, we know this is not a redeclaration. > This also catches array parameters, those are pointers too. */ > if (TYPE_PTR_P (xobj_param)) > continue; Handling pointers specifically here seems unnecessary, they should be rare and will be handled by the next check for unrelated type. > dealing with a by-value xobj parameter we can procede following "proceed" > /* An operator function must either be a non-static member function > or have at least one parameter of a class, a reference to a class, > an enumeration, or a reference to an enumeration. 13.4.0.6 */ > - if (! methodp || DECL_STATIC_FUNCTION_P (decl)) > + /* This can just be DECL_STATIC_FUNCTION_P (decl) I think? */ > + if ((!methodp && !DECL_XOBJ_MEMBER_FUNC_P (decl)) > + || DECL_STATIC_FUNCTION_P (decl)) No, it also needs to be true for non-members; rather, I think it can just be if (!DECL_OBJECT_FUNCTION_P (decl)) > + if (xobj_param) > + { > + quals = TYPE_UNQUALIFIED; > + if (TYPE_REF_P (xobj_param) > + && !(cp_type_quals (TREE_TYPE (xobj_param)) & TYPE_QUAL_CONST)) > + LAMBDA_EXPR_MUTABLE_P (lambda_expr) = 1; > + } I don't think we want to mess with MUTABLE_P here. But then capture_decltype needs to be fixed to refer to the type of the object parameter rather than MUTABLE_P. Actually, I think we can do away with the MUTABLE_P flag entirely. I'm going to push a patch to do that. > - if (!LAMBDA_EXPR_STATIC_P (lambda_expr)) > + if (!LAMBDA_EXPR_STATIC_P (lambda_expr) > + && !DECL_XOBJ_MEMBER_FUNC_P (fco)) This could be if (DECL_IOBJ_MEMBER_FUNCTION_P (fco)) > - if (closure && !DECL_STATIC_FUNCTION_P (t)) > + if (closure && DECL_IOBJ_MEMBER_FUNC_P (t) && !DECL_STATIC_FUNCTION_P (t)) This shouldn't need to still check DECL_STATIC_FUNCTION_P. > + /* We don't touch a lambda's func when it's just trying to create the > + closure type. */ We need to check it somewhere, currently this crashes: template void f() { int i; [=](this T&& self){ return i; }(); // error, unrelated } int main() { f(); } > @@ -3691,18 +3691,7 @@ build_min_non_dep_op_overload (enum tree_code op, > releasing_vec args; > va_start (p, overload); > > - if (TREE_CODE (TREE_TYPE (overload)) == FUNCTION_TYPE) > - { > - fn = overload; > - if (op == ARRAY_REF) > - obj = va_arg (p, tree); > - for (int i = 0; i < nargs; i++) > - { > - tree arg = va_arg (p, tree); > - vec_safe_push (args, arg); > - } > - } Maybe change the test to !DECL_OBJECT_MEMBER_FUNC_P to avoid reordering the cases? > @@ -15402,6 +15450,8 @@ tsubst_decl (tree t, tree args, tsubst_flags_t complain, > gcc_checking_assert (TYPE_MAIN_VARIANT (TREE_TYPE (ve)) > == TYPE_MAIN_VARIANT (type)); > SET_DECL_VALUE_EXPR (r, ve); > + if (is_capture_proxy (t)) > + type = TREE_TYPE (ve); That should have close to the same effect as the lambda_proxy_type adjustment I was talking about, since that function basically returns the TREE_TYPE of the COMPONENT_REF. But the underlying problem is that finish_non_static_data_member assumes that 'object' is '*this', for which you can trust the cv-quals; for auto&&, you can't. capture_decltype has the same problem. I'm attaching a patch to address this in both places. Jason --------------dfq5mrVnesuxqOUeU3LUQBCS Content-Type: text/x-patch; charset=UTF-8; name="wildcard.patch" Content-Disposition: attachment; filename="wildcard.patch" Content-Transfer-Encoding: base64 Y29tbWl0IDUyMDIxN2NjMTUzMTVmZTFjYzU4ZGZmMjNjNjViYjNjZGMyOGRjNTYKQXV0aG9yOiBK YXNvbiBNZXJyaWxsIDxqYXNvbkByZWRoYXQuY29tPgpEYXRlOiAgIFdlZCBOb3YgMjkgMjE6NTE6 MzYgMjAyMyAtMDUwMAoKICAgIHdpbGRjYXJkCgpkaWZmIC0tZ2l0IGEvZ2NjL2NwL3NlbWFudGlj cy5jYyBiL2djYy9jcC9zZW1hbnRpY3MuY2MKaW5kZXggNzk0NmYwYmU3N2IuLmUwY2I4YTFiMDRm IDEwMDY0NAotLS0gYS9nY2MvY3Avc2VtYW50aWNzLmNjCisrKyBiL2djYy9jcC9zZW1hbnRpY3Mu Y2MKQEAgLTIyNjUsNiArMjI2NSwxMCBAQCBmaW5pc2hfbm9uX3N0YXRpY19kYXRhX21lbWJlciAo dHJlZSBkZWNsLCB0cmVlIG9iamVjdCwgdHJlZSBxdWFsaWZ5aW5nX3Njb3BlLAogICAgICAgZWxz ZSBpZiAoUEFDS19FWFBBTlNJT05fUCAodHlwZSkpCiAJLyogRG9uJ3QgYm90aGVyIHRyeWluZyB0 byByZXByZXNlbnQgdGhpcy4gICovCiAJdHlwZSA9IE5VTExfVFJFRTsKKyAgICAgIGVsc2UgaWYg KFdJTERDQVJEX1RZUEVfUCAoVFJFRV9UWVBFIChvYmplY3QpKSkKKwkvKiBXZSBkb24ndCBrbm93 IHdoYXQgdGhlIGV2ZW50dWFsIHF1YWxzIHdpbGwgYmUuICBUaGlzIGNhbiBoYXBwZW4gd2hlbgor CSAgIGNhbGxlZCBmcm9tIGJ1aWxkX2NhcHR1cmVfcHJveHkgZm9yIGFuIGV4cGxpY2l0IG9iamVj dCBsYW1iZGEuICAqLworCXR5cGUgPSBOVUxMX1RSRUU7CiAgICAgICBlbHNlCiAJewogCSAgLyog U2V0IHRoZSBjdiBxdWFsaWZpZXJzLiAgKi8KQEAgLTExNzA5LDYgKzExNzEzLDcgQEAgZmluaXNo X2RlY2x0eXBlX3R5cGUgKHRyZWUgZXhwciwgYm9vbCBpZF9leHByZXNzaW9uX29yX21lbWJlcl9h Y2Nlc3NfcCwKICAgICAgQTxkZWNsdHlwZShzaXplb2YoVCkpPjo6VSBkb2Vzbid0IHJlcXVpcmUg J3R5cGVuYW1lJy4gICovCiAgIGlmIChpbnN0YW50aWF0aW9uX2RlcGVuZGVudF91bmV2YWxfZXhw cmVzc2lvbl9wIChleHByKSkKICAgICB7CisgICAgZGVwZW5kZW50OgogICAgICAgdHlwZSA9IGN4 eF9tYWtlX3R5cGUgKERFQ0xUWVBFX1RZUEUpOwogICAgICAgREVDTFRZUEVfVFlQRV9FWFBSICh0 eXBlKSA9IGV4cHI7CiAgICAgICBERUNMVFlQRV9UWVBFX0lEX0VYUFJfT1JfTUVNQkVSX0FDQ0VT U19QICh0eXBlKQpAQCAtMTE4ODMsNyArMTE4ODgsMTEgQEAgZmluaXNoX2RlY2x0eXBlX3R5cGUg KHRyZWUgZXhwciwgYm9vbCBpZF9leHByZXNzaW9uX29yX21lbWJlcl9hY2Nlc3NfcCwKICAgICAg IGlmIChvdXRlcl9hdXRvbWF0aWNfdmFyX3AgKFNUUklQX1JFRkVSRU5DRV9SRUYgKGV4cHIpKQog CSAgJiYgY3VycmVudF9mdW5jdGlvbl9kZWNsCiAJICAmJiBMQU1CREFfRlVOQ1RJT05fUCAoY3Vy cmVudF9mdW5jdGlvbl9kZWNsKSkKLQl0eXBlID0gY2FwdHVyZV9kZWNsdHlwZSAoU1RSSVBfUkVG RVJFTkNFX1JFRiAoZXhwcikpOworCXsKKwkgIHR5cGUgPSBjYXB0dXJlX2RlY2x0eXBlIChTVFJJ UF9SRUZFUkVOQ0VfUkVGIChleHByKSk7CisJICBpZiAoIXR5cGUpCisJICAgIGdvdG8gZGVwZW5k ZW50OworCX0KICAgICAgIGVsc2UgaWYgKGVycm9yX29wZXJhbmRfcCAoZXhwcikpCiAJdHlwZSA9 IGVycm9yX21hcmtfbm9kZTsKICAgICAgIGVsc2UgaWYgKGV4cHIgPT0gY3VycmVudF9jbGFzc19w dHIpCkBAIC0xMjgyMSw3ICsxMjgzMCw4IEBAIGNhcHR1cmVfZGVjbHR5cGUgKHRyZWUgZGVjbCkK ICAgICB7CiAgICAgICBpbnQgcXVhbHMgPSBjcF90eXBlX3F1YWxzICh0eXBlKTsKICAgICAgIHRy ZWUgb2J0eXBlID0gVFJFRV9UWVBFIChERUNMX0FSR1VNRU5UUyAoY3VycmVudF9mdW5jdGlvbl9k ZWNsKSk7Ci0gICAgICBnY2NfY2hlY2tpbmdfYXNzZXJ0ICghV0lMRENBUkRfVFlQRV9QIChub25f cmVmZXJlbmNlIChvYnR5cGUpKSk7CisgICAgICBpZiAoV0lMRENBUkRfVFlQRV9QIChub25fcmVm ZXJlbmNlIChvYnR5cGUpKSkKKwlyZXR1cm4gTlVMTF9UUkVFOwogICAgICAgaWYgKElORElSRUNU X1RZUEVfUCAob2J0eXBlKSkKIAlxdWFscyB8PSBjcF90eXBlX3F1YWxzIChUUkVFX1RZUEUgKG9i dHlwZSkpOwogICAgICAgdHlwZSA9IGNwX2J1aWxkX3F1YWxpZmllZF90eXBlICh0eXBlLCBxdWFs cyk7Cg== --------------dfq5mrVnesuxqOUeU3LUQBCS--