From: Jason Merrill <jason@redhat.com>
To: waffl3x <waffl3x@protonmail.com>
Cc: "gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH v6 1/1] c++: Initial support for P0847R7 (Deducing This) [PR102609]
Date: Thu, 30 Nov 2023 00:00:04 -0500 [thread overview]
Message-ID: <d24d2a81-ef12-430d-bd01-61cdd0cc595b@redhat.com> (raw)
In-Reply-To: <htOtBlRGWlUJUGz_W0oBV0xqgpsb-txIQuIaF_hYYwLg3vPlkOGh8jdb2dZQN32HNruASkqcZXAeR2TdqzTqax5nRYkoVbjwhyHQN5PzWrs=@protonmail.com>
[-- Attachment #1: Type: text/plain, Size: 5782 bytes --]
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<tree, va_gc> *args,
> tree fn_first_arg = NULL_TREE;
> const vec<tree, va_gc> *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 <class T> void f()
{
int i;
[=](this T&& self){ return i; }(); // error, unrelated
}
int main() { f<int>(); }
> @@ -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
[-- Attachment #2: wildcard.patch --]
[-- Type: text/x-patch, Size: 2113 bytes --]
commit 520217cc15315fe1cc58dff23c65bb3cdc28dc56
Author: Jason Merrill <jason@redhat.com>
Date: Wed Nov 29 21:51:36 2023 -0500
wildcard
diff --git a/gcc/cp/semantics.cc b/gcc/cp/semantics.cc
index 7946f0be77b..e0cb8a1b04f 100644
--- a/gcc/cp/semantics.cc
+++ b/gcc/cp/semantics.cc
@@ -2265,6 +2265,10 @@ finish_non_static_data_member (tree decl, tree object, tree qualifying_scope,
else if (PACK_EXPANSION_P (type))
/* Don't bother trying to represent this. */
type = NULL_TREE;
+ else if (WILDCARD_TYPE_P (TREE_TYPE (object)))
+ /* We don't know what the eventual quals will be. This can happen when
+ called from build_capture_proxy for an explicit object lambda. */
+ type = NULL_TREE;
else
{
/* Set the cv qualifiers. */
@@ -11709,6 +11713,7 @@ finish_decltype_type (tree expr, bool id_expression_or_member_access_p,
A<decltype(sizeof(T))>::U doesn't require 'typename'. */
if (instantiation_dependent_uneval_expression_p (expr))
{
+ dependent:
type = cxx_make_type (DECLTYPE_TYPE);
DECLTYPE_TYPE_EXPR (type) = expr;
DECLTYPE_TYPE_ID_EXPR_OR_MEMBER_ACCESS_P (type)
@@ -11883,7 +11888,11 @@ finish_decltype_type (tree expr, bool id_expression_or_member_access_p,
if (outer_automatic_var_p (STRIP_REFERENCE_REF (expr))
&& current_function_decl
&& LAMBDA_FUNCTION_P (current_function_decl))
- type = capture_decltype (STRIP_REFERENCE_REF (expr));
+ {
+ type = capture_decltype (STRIP_REFERENCE_REF (expr));
+ if (!type)
+ goto dependent;
+ }
else if (error_operand_p (expr))
type = error_mark_node;
else if (expr == current_class_ptr)
@@ -12821,7 +12830,8 @@ capture_decltype (tree decl)
{
int quals = cp_type_quals (type);
tree obtype = TREE_TYPE (DECL_ARGUMENTS (current_function_decl));
- gcc_checking_assert (!WILDCARD_TYPE_P (non_reference (obtype)));
+ if (WILDCARD_TYPE_P (non_reference (obtype)))
+ return NULL_TREE;
if (INDIRECT_TYPE_P (obtype))
quals |= cp_type_quals (TREE_TYPE (obtype));
type = cp_build_qualified_type (type, quals);
next prev parent reply other threads:[~2023-11-30 5:00 UTC|newest]
Thread overview: 100+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-31 6:02 [PATCH 1/2] " waffl3x
2023-08-31 8:33 ` Jakub Jelinek
2023-09-02 8:43 ` waffl3x
2023-09-11 13:49 ` [PATCH v2 " waffl3x
2023-09-19 20:14 ` Jason Merrill
2023-09-20 0:30 ` waffl3x
2023-09-20 21:19 ` Jason Merrill
2023-09-21 11:28 ` waffl3x
2023-09-22 11:30 ` Jason Merrill
2023-09-26 1:56 ` [PATCH v3 " waffl3x
2023-09-27 22:43 ` Hans-Peter Nilsson
2023-09-27 23:35 ` Waffl3x
2023-10-17 20:53 ` Jason Merrill
2023-10-17 21:11 ` Jason Merrill
2023-10-18 11:46 ` waffl3x
2023-10-18 14:17 ` Jason Merrill
2023-10-18 17:28 ` waffl3x
2023-10-18 17:45 ` Jakub Jelinek
2023-10-18 18:12 ` Jason Merrill
2023-10-19 21:05 ` waffl3x
2023-10-19 21:11 ` Jakub Jelinek
2023-10-19 21:31 ` waffl3x
2023-10-19 21:53 ` Jakub Jelinek
2023-10-19 22:18 ` Jason Merrill
[not found] ` <Q2xXS2RkwtzDslDUAsi4YWupkb9s3QKvecqsxLNUr=5FL-MdSmzIJcZ96S3B9Avk30GneMm8R67JsQ4D-Uj1JB6N8dhTw6LAlNsrpLKHuLP2o=3D@protonmail.com>
2023-10-19 22:51 ` waffl3x
2023-10-19 23:35 ` waffl3x
2023-10-20 2:39 ` Jason Merrill
2023-10-20 4:34 ` waffl3x
2023-10-20 16:01 ` Jason Merrill
[not found] ` <zXWkSXEO=5FH62WXyNUeV1zNAx9wSVGQ5ooxKAfpN2InCP4X25uOC0yTZlnMqbDMoIa4lGwj0hP-KEP5UIcMs1S1zkhz=5FZx4oM3oz09DY2BRg=3D@protonmail.com>
[not found] ` <9YnRZJPkB8KCk8R86UDwWBoNnmOEAir4IU4enb1qIGgVdkB6dwy76ClgAzwpPqpToQ9sLTBs50EIRwhivBJU6RAFfLt-fjJxdYTZ35YVFWA=3D@protonmail.com>
2023-10-28 4:07 ` waffl3x
2023-10-28 23:21 ` waffl3x
2023-11-01 23:15 ` waffl3x
2023-11-02 7:01 ` waffl3x
2023-11-02 7:01 ` Jakub Jelinek
2023-11-03 3:04 ` Jason Merrill
2023-11-03 4:44 ` waffl3x
2023-11-03 18:05 ` Jason Merrill
2023-11-04 6:40 ` waffl3x
2023-11-09 18:44 ` Jason Merrill
2023-11-10 4:24 ` waffl3x
2023-11-10 23:12 ` Jason Merrill
2023-11-11 10:43 ` waffl3x
2023-11-11 11:24 ` waffl3x
2023-11-14 3:48 ` Jason Merrill
2023-11-14 4:36 ` waffl3x
2023-11-18 6:43 ` waffl3x
2023-11-19 6:22 ` Jason Merrill
2023-11-19 13:39 ` waffl3x
2023-11-19 16:31 ` Jason Merrill
2023-11-19 18:36 ` waffl3x
2023-11-19 20:34 ` Jason Merrill
2023-11-19 21:44 ` waffl3x
2023-11-20 14:35 ` Jason Merrill
[not found] ` <1MdaTybBd=5Fo4uw-Gb23fYyd5GNz7qFqoSe=5Ff5h90LY=5FBdzM2ge2qPSyCuiCLYoYcZSjmVv13fw1LmjQC=5FM2L8raS1fydY5pEJ=5Fvwvv5Z-0k=3D@protonmail.com>
2023-11-21 10:02 ` waffl3x
2023-11-21 13:04 ` [PATCH v5 1/1] " waffl3x
2023-11-22 3:22 ` Jason Merrill
2023-11-22 20:46 ` waffl3x
2023-11-22 21:38 ` Jason Merrill
[not found] ` <kltTuyDDwoyOmhBWostMKm5zF3sQCGz3HjMBrBUK6LOZp1-AbGMl5ijKKMlOncwR2yiWippyp89sFPZykNF3OVyz4yknnCVwn=5FiHJPUl25k=3D@protonmail.com>
[not found] ` <dHEpSeuiljMbH0YhwLULApd3yO3LNaVkamGW2KJBYBl0EgMrtpJZ41GeTVOc77siD1kh2vkF4zwInWWGxYXfcnW4XV7sfDPX7cY028JiORE=3D@protonmail.com>
2023-11-22 21:56 ` waffl3x
2023-11-22 22:44 ` waffl3x
2023-11-24 6:49 ` waffl3x
2023-11-24 23:26 ` waffl3x
2023-11-25 1:14 ` waffl3x
2023-11-26 21:30 ` Jason Merrill
2023-11-26 23:10 ` waffl3x
2023-11-27 1:16 ` Jason Merrill
[not found] ` <BEI8PD7nktTuX7dimb22uDnR0b8Bc8ozi4xx9KbiEFj8TjgUCxMfEPpcIPL0bkdThBBab97T1uEJ9rUM3va1eiE1TyRw=5FiLrxwKgg30ZaW0=3D@protonmail.com>
2023-11-27 1:30 ` waffl3x
2023-11-27 1:44 ` waffl3x
2023-11-27 2:40 ` Jason Merrill
2023-11-27 5:35 ` [PATCH v6 " waffl3x
2023-11-28 3:31 ` waffl3x
2023-11-28 10:00 ` waffl3x
2023-11-30 5:00 ` Jason Merrill [this message]
2023-11-30 6:36 ` waffl3x
2023-11-30 14:55 ` Jason Merrill
2023-12-01 6:02 ` waffl3x
2023-12-01 16:52 ` Jason Merrill
2023-12-02 1:31 ` waffl3x
2023-12-02 15:02 ` Jason Merrill
[not found] ` <KQegse=5FguOyql4Ok1lrAgS7gasZJd1pOoPbCTdGxcHh-G4A9Tlf5zCnGJmqtshMt72edmcXdIapaZNPp4VJp5Ar9PHZbUrbwDsPjTSUrnOI=3D@protonmail.com>
[not found] ` <59LofhYhxl7MLEuElXwZcESRB6MpjdG-iq-89B63siDRo5k0j-y6z-PVa6Y3iE1xE5LkJwpwTFi82bd0RZjB1yZbSJptFdPTBWfvOGj1W78=3D@protonmail.com>
2023-12-05 4:35 ` waffl3x
2023-12-05 4:39 ` waffl3x
2023-12-05 5:54 ` waffl3x
2023-12-06 7:33 ` [PATCH v7 " waffl3x
2023-12-06 8:48 ` Jakub Jelinek
2023-12-06 9:31 ` waffl3x
2023-12-06 11:08 ` waffl3x
2023-12-08 19:25 ` Jason Merrill
2023-12-10 15:22 ` waffl3x
2023-12-10 18:59 ` Jason Merrill
2023-12-22 9:01 ` waffl3x
2023-12-22 17:26 ` Jason Merrill
2023-12-23 7:10 ` waffl3x
2023-12-26 16:37 ` Jason Merrill
2024-01-01 15:17 ` waffl3x
2024-01-01 15:34 ` waffl3x
2024-01-01 17:12 ` waffl3x
2024-01-06 12:37 ` waffl3x
2023-11-25 17:32 ` [PATCH v5 " Jason Merrill
2023-11-25 22:59 ` waffl3x
2023-09-19 20:24 ` [PATCH 1/2] " Jason Merrill
[not found] <b=5FiIXwWwO63ZE1ZSZHUIAdWyA2sqGsE3FM7eXfsInWogDyBZRsw8CwNsvFSDmEVmBtdq0pqb4zJ55HN2JCR7boDNramlEfne-R5PWdUXjbA=3D@protonmail.com>
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d24d2a81-ef12-430d-bd01-61cdd0cc595b@redhat.com \
--to=jason@redhat.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=waffl3x@protonmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).