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 D4F563858D1E for ; Wed, 20 Sep 2023 21:20:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D4F563858D1E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1695244803; 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=F0iWyrFpK/95izKTxprv5x25Bb3F7N7tC4+NuTRmFbs=; b=ewqezukcNsI6MwNKU/BsPARCmeY1ZJQWgSunHXq4bYqj5wi1oKnV5dJL6FYhLroe7WOTSd ib5yYj3PsqRci6fQDRWV+bab9kI8kAH/1tGe3UHrwDl/JufuSovYk2zjqULLJp/AS6XsmB DzMksB5s9dmHclilgiE4f4PRh4IrfPM= Received: from mail-qt1-f200.google.com (mail-qt1-f200.google.com [209.85.160.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-623-yLlG37uMO32O5OPD6lXUjw-1; Wed, 20 Sep 2023 17:20:01 -0400 X-MC-Unique: yLlG37uMO32O5OPD6lXUjw-1 Received: by mail-qt1-f200.google.com with SMTP id d75a77b69052e-414b72208a1so2122911cf.3 for ; Wed, 20 Sep 2023 14:20:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695244801; x=1695849601; 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=F0iWyrFpK/95izKTxprv5x25Bb3F7N7tC4+NuTRmFbs=; b=CVfbZCTzmBbiJm3XGgUFS6OlHv3ZbIq6Ef9zcB9EbLlDroVYWHJuKH3cnOzBt6urn/ Nixw8aMZF+z+IH11ZrnTItMK+6tuuKMgl+Gek4rEg3Y4jdReyy3ekNjxrKnnJ9HYvEvA rMH1YWB1aylMDj5BeauG2I8LkmXpZOB43R2yWAFs9aCYyLF2cLYDvFGK6L5IRbI/J1o9 onM/3eXZK+8Zo8q1zWhMie1AjjpcwxGTPHKiKw5soFFoPNkvksxBy5Nlmhjob3w8I+C8 XyAdzMvoEDy60QBMsEwFrcXOTy8ezPD4a4AlVr9641TRNUob6SaNHSTVN9hGaVCPuyuY DURQ== X-Gm-Message-State: AOJu0YwTC+AwWZ2rM/b+AcH98jOjtSQ3Tdm+krcz5+u9M6sHg97mNpII 9Zqe/LeO+u44jwDkFkRl2zwDDuW/UZHdKHRwH+L78L9tXiL+U2r3m3ZxcJv52BJWUxHEfp0e0l6 m3HIsoiQJaw1NulRp2A== X-Received: by 2002:a0c:b249:0:b0:655:e3d3:a869 with SMTP id k9-20020a0cb249000000b00655e3d3a869mr3992851qve.10.1695244800971; Wed, 20 Sep 2023 14:20:00 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHZquB99TNJoYz3f3xGqUcbdvA76f1K6a/93bC973+1y/jrCY/HyTAE9VfZ2PN5ARGr5W+Neg== X-Received: by 2002:a0c:b249:0:b0:655:e3d3:a869 with SMTP id k9-20020a0cb249000000b00655e3d3a869mr3992840qve.10.1695244800629; Wed, 20 Sep 2023 14:20:00 -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 b13-20020a0cf04d000000b0064c107c9679sm10412qvl.125.2023.09.20.14.19.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 20 Sep 2023 14:19:59 -0700 (PDT) Message-ID: <09e57c81-5231-16e8-6e57-18c37663c325@redhat.com> Date: Wed, 20 Sep 2023 17:19:58 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.15.1 Subject: Re: [PATCH v2 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> From: Jason Merrill In-Reply-To: <9evl-z9cAecBNAGVh82igdeO_HCFYbASO5fS0ngotJBqdpab09FTYaMiAjlZUliISedO0mV66BldzWQtylI4Dax0yC2gdKWuM55xDaG6RQM=@protonmail.com> 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=-7.2 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_SHORT,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,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 9/19/23 20:30, waffl3x wrote: >> Thank you, this is great! > > Thanks! > >> One legal hurdle to start with: our DCO policy >> (https://gcc.gnu.org/dco.html) requires real names in the sign-off, not >> pseudonyms. If you would prefer to contribute under this pseudonym, I >> encourage you to file a copyright assignment with the FSF, who are set >> up to handle that. > > I will get on that right away. > >>> +/* These need to moved to somewhere appropriate. */ >> >> This isn't a bad spot for these macros, but you could also move them >> down lower, maybe near DECL_THIS_STATIC and DECL_ARRAY_PARAMETER_P for >> some thematic connection. > > Sounds good, I will move them down. > >>> +/* The flag is a member of base, but the value is meaningless for other >>> + decl types so checking is still justified I imagine. */ >> >> Absolutely, we often reuse bits for other purposes if they're disjoint >> from the use they were added for. > > Would it be more appropriate to give it a general name in base instead > then? If so, I can also change that. That would make sense. >>> +/* Not a lang_decl field, but still specific to c++. */ >>> +#define DECL_PARM_XOBJ_FLAG(NODE) \ >>> + (PARM_DECL_CHECK (NODE)->decl_common.decl_flag_3) >> >> Better to use a DECL_LANG_FLAG than claim one of the >> language-independent flags for C++. >> >> There's a list at the top of cp-tree.h of the uses of LANG_FLAG on >> various kinds of tree node. DECL_LANG_FLAG_4 seems free on PARM_DECL. > > Okay, I will switch to that instead, I didn't like using such a general > purpose flag for what is only relevant until the FUNC_DECL is created > and then never again. That's a good point, but the flag you chose seems even more general purpose. A better option might be, instead of putting this flag on the PARM_DECL, to put it on the short-lived TREE_LIST which is only used for communication between cp_parser_parameter_declaration_list and grokparms, and have grokdeclarator grab it from declarator->u.function.parameters? > If you don't mind answering right now, what are the consequences of > claiming language-independent flags for C++? Or to phrase it > differently, why would this be claiming it for C++? My guess was that > those flags could be used by any front ends and there wouldn't be any > conflicts, as you can't really have crossover between two front ends at > the same time. Or is that the thing, that kind of cross-over is > actually viable and claiming a language independent flag inhibits that > possibility? Like I eluded to, this is kinda off topic from the patch > so feel free to defer the answer to someone else but I just want to > clear up my understanding for the future. Generally the flags that aren't specifically specified to be language-specific are reserved for language-independent uses; even if only one front-end actually uses the feature, it should be for communication to language-independent code rather than communication within the particular front-end. The patch modified tree-core.h to refer to a macro in cp-tree.h. > Yeah, I separated all the diagnostics out into the second patch. This > patch was meant to include the bare minimum of what was necessary to > get the feature functional. As for the diagnostics patch, I'm not happy > with how scattered about the code base it is, but you'll be able to > judge for yourself when I resubmit that patch, hopefully later today. > So not to worry, I didn't neglect diagnostics, it's just in a follow > up. The v1 of it was submitted on August 31st if you want to find it, > but I wouldn't recommend it. I misunderstood how some things were to be > formatted so it's probably best you just wait for me to finish a v2 of > it. Ah, oops, I assumed that v2 completely replaced v1. > One last thing, I assume I should clean up the comments and replace > them with more typical ones right? I'm going to go forward with that > assumption in v3, I just want to mention it in advanced just in case I > have the wrong idea. Yes, please. > I will get started on v3 of this patch and v2 of the diagnostic patch > as soon as I have the ball rolling on legal stuff. I should have it all > finished tonight. Thanks for the detailed response, it cleared up a lot > of my doubts. Sounds good! Jason