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.133.124]) by sourceware.org (Postfix) with ESMTPS id D88353858D33 for ; Wed, 18 Oct 2023 14:17:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D88353858D33 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 D88353858D33 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1697638658; cv=none; b=S3c0WzC1l+u4GzcNH6khyK93yqpc7/Mtv+PF3/zZeoCkz3HuKTQnnHxjIbRimBck4h3DQnzFuE4O0aWEk+SYHqJ8/5O0MIsb1tBC9stT9MJ8x49WmZ0VL889hJumdhczGZv7rtnUEZolqOaUzgYFotnDk0RU69TY8peDl8UKAbY= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1697638658; c=relaxed/simple; bh=Fq4izoXlHs2llwGGFoyIUQc6jEzFezuFBCKkugMKRe8=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=LnZp3ek9nE7usdJv+OooO0eYmIbAm2Gm6jhSD0mT0aEWcJzFF4Wf+cSP0QyiFRAeHi+FM8zJ1RDMK8YjnPqxxrz6+jw0qKXri+6Zj9+ZnvQV2ZpGC+RxayCyd4Q3Sn8ZbDCY36sT+CvuGHsh85gE32tF5eTbp2i4aJUNIYO3r0Y= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1697638656; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=V26d9dZgJ41ac0IKIe79/hfK2i5vHvVdxn8j9j2Pq4I=; b=Ygc2UOz+g++Wd4tLaelfLQ2HjShMC5m8XhHMHRVSJKrohapwgI7/ahXIL71vlcim1NLS94 EK3uf8byosoBH060u9Z7G8xU4S+aasqAl4BD4JLXBiv+a8o9W4xBBNtIvDKs0yY6CBnwwe /puJPT9Ha6zvz/85QS+ik1fvel1uCcw= Received: from mail-oi1-f198.google.com (mail-oi1-f198.google.com [209.85.167.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-316-yhT-otYDN-Wy6Ld_Jsel1g-1; Wed, 18 Oct 2023 10:17:35 -0400 X-MC-Unique: yhT-otYDN-Wy6Ld_Jsel1g-1 Received: by mail-oi1-f198.google.com with SMTP id 5614622812f47-3b2f2b9a028so379941b6e.3 for ; Wed, 18 Oct 2023 07:17:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697638654; x=1698243454; h=content-transfer-encoding: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=V26d9dZgJ41ac0IKIe79/hfK2i5vHvVdxn8j9j2Pq4I=; b=U+bkiCk/TmJPRaMCFuS8CDLy3Xd1O2OgYBjZRcsCXMkNSUEXBcEFle4XA8a+S6/Dgk /6Q2k533N8nuLtLvIWKh1NFsGhMJdq2e+o280RuJqzyU9PoinyaeWbqZz7IVi2vxKJrD WnbojqiKyz3WrIIdkbWissoLyTTnH5RjZ10Iw0Oip/d0m6ypUkm8uVuyuFrhFHwVoWnc 4Jq0iYr2Z10vOe+TAZfJU4+DlWJqvfuXeAEa9Fq/ZUZk3ReeT9WieZYKVoPeJCWj03UY eOMCEDWXSF+41zJRiryKYIjh6jO+H4m+iCvDbsXSVZfTaxnKCPeWOlgzYUcj3S4A2dDM 4NQw== X-Gm-Message-State: AOJu0Yw5k7CzUwr7bP3BIMFl4ZlBnDHCxk0up5UKN71YAajqUpVGgKCr 8tvPnvZ1p1Sbo9/VLgZIpzf+024qfAMPpSlE6eFnwWoKhPiX+Hn8s/orgac0p1S6CeXnoOpFzKK GurEVA+FmLopEU7el0Q== X-Received: by 2002:a05:6808:ab6:b0:3ae:2bc8:2b93 with SMTP id r22-20020a0568080ab600b003ae2bc82b93mr5340312oij.3.1697638654283; Wed, 18 Oct 2023 07:17:34 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHUVWHJnGiudM4A60ui9kue1D3SqyVgwpghUvvjJ0pohGm7d7MrkYVIgfaX/dgakS1Fd1B6TA== X-Received: by 2002:a05:6808:ab6:b0:3ae:2bc8:2b93 with SMTP id r22-20020a0568080ab600b003ae2bc82b93mr5340294oij.3.1697638653974; Wed, 18 Oct 2023 07:17:33 -0700 (PDT) Received: from [192.168.1.108] (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 q17-20020ad44351000000b0065b1bcd0d33sm1386339qvs.93.2023.10.18.07.17.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 18 Oct 2023 07:17:33 -0700 (PDT) Message-ID: Date: Wed, 18 Oct 2023 10:17:32 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 1/2] c++: Initial support for P0847R7 (Deducing This) [PR102609] To: waffl3x Cc: Jakub Jelinek , "gcc-patches@gcc.gnu.org" References: <3ec4cf47-ccd8-fc55-c4fc-d97402552b92@redhat.com> <9evl-z9cAecBNAGVh82igdeO_HCFYbASO5fS0ngotJBqdpab09FTYaMiAjlZUliISedO0mV66BldzWQtylI4Dax0yC2gdKWuM55xDaG6RQM=@protonmail.com> <09e57c81-5231-16e8-6e57-18c37663c325@redhat.com> <2024d9f2-7560-eb9e-e9d9-de8769a06a8b@redhat.com> From: Jason Merrill In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_SHORT,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 10/18/23 07:46, waffl3x wrote: >> Any progress on this, or do I need to coax the process along? :) > > Yeah, I've been working on it since the copyright assignment process > has finished, originally I was going to note that on my next update > which I had hoped to finish today or tomorrow. Well, in truth I was > hoping to send one the same day that copyright assignment finished, but > I found a nasty bug so I spent all day adding test cases for all the > relevant overloadable operators. Currently, it crashes when calling a > subscript operator declared with an explicit object parameter in a > dependent context. I haven't looked into the fix yet, but I plan to. > > Also, before I forget, what is the process for confirming my copyright > assignment on your end? Do you just need to check in with the FSF to > see if it went through? Let me know if there's anything you need from > me regarding that. > > Aside from the bug that's currently present in the first patch, I only > have like 1 or 2 little things I want to change about it. I will make > those few changes to patch 1, finish patch 2 (diagnostics) which will > also include test cases for the new bug I found. After I am done that I > plan on adding the things that are missing, because I suspect that > looking into that will get me close to finding the fix for the crash. > >> Hmm, is it? I see that clang thinks so, but I don't know where they get >> that idea from. The grammar certainly allows it: >> >>> attribute-specifier-seqopt decl-specifier-seq declarator = initializer-clause >> >> and I don't see anything else that prohibits it. > > You would be right for P0847R7, but CWG DR 2653 changed that. You can > find the updated grammar in dcl.fct section 3 (subsection? I'm not > really sure to be honest.) > > I've also included a copy of the grammar here for your convenience. > > https://eel.is/c++draft/dcl.fct#nt:parameter-declaration > parameter-declaration: > attribute-specifier-seqopt thisopt decl-specifier-seq declarator > attribute-specifier-seqopt decl-specifier-seq declarator = initializer-clause > attribute-specifier-seqopt thisopt decl-specifier-seq abstract-declaratoropt > attribute-specifier-seqopt decl-specifier-seq abstract-declaratoropt = initializer-clause Ah, yes, thanks. >> I was thinking to set a TREE_LANG_FLAG on the TREE_LIST node. > > I did figure this is originally what you meant, and I can still change > it to go this route since I'm sure it's likely just as good. But I do > recall something I didn't like in the implementation that nudged me > towards using the purpose member instead. Either way, not a big deal. I > think I just liked not having to mess with a linked list as I am not > used to them as a data structure, it might have been that simple. :^) I wouldn't expect to need any actual dealing with the linked list, just setting a flag in cp_parameter_declaration_list at the same point as the existing PARENTHESIZED_LIST_P flag. But given CWG2653 as you pointed out, your current approach is fine. > I will try to get something done today, but I was struggling with > writing some of the tests, there's also a lot more of them now. I also > wrote a bunch of musings in comments that I would like feedback on. > > My most concrete question is, how exactly should I be testing a > pedwarn, I want to test that I get the correct warning and error with > the separate flags, do I have to create two separate tests for each one? Yes. I tend to use letter suffixes for tests that vary only in flags (and expected results), e.g. feature1a.C, feature1b.C. > I'm just going to include the little wall I wrote in decl.cc regarding > pedwarn, just in case I can't get this done tonight so I can get some > feedback regarding it. On the other hand, it might just not be very > relevant to this patch in particular as I kind of noted, but maybe > there's some way to do what I was musing about that I've overlooked. It > does end up a bit ranty I guess, hopefully that doesn't make it > confusing. > > ``` > /* I believe we should make a switch for this feature specifically, > I recall seeing discussion regarding enabling newer language > features when set to older standards. I would advocate for a > specific flag for each specific feature. Maybe they should all > be under an override flag? -foverride-dialect=xobj,ifconstexpr (?) > I dont think it makes sense to give each feature override it's own > flag. I don't recall what the consensus was around this discussion > either though. > > For the time being it's controlled by pedantic. I am concerned that > tying this to pedantic going forward that one might want to enable > -pedantic-errors while also enabling select features from newer > dialects. It didn't look like this use case is supported to me. > > I suppose this will require redesign work to support, so for > the purposes of this patch, emitting a pedwarn seems correct. > I just don't like that it can't be suppressed on an individual > basis. */ > if (xobj_parm && cxx_dialect < cxx23) > pedwarn(DECL_SOURCE_LOCATION (xobj_parm), OPT_Wpedantic, ""); Instead of OPT_Wpedantic, this should be controlled by -Wc++23-extensions (OPT_Wc__23_extensions) If you wanted, you could add a more specific warning option for this (e.g. -Wc++23-explicit-this) which is also affected by -Wc++23-extensions, but I would lean toward just using the existing flag. Up to you. Jason