From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5273 invoked by alias); 15 Jun 2017 22:57:18 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 5255 invoked by uid 89); 15 Jun 2017 22:57:17 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-26.7 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=cam, incharge, in-charge, destroys X-HELO: mail-qt0-f181.google.com Received: from mail-qt0-f181.google.com (HELO mail-qt0-f181.google.com) (209.85.216.181) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 15 Jun 2017 22:57:16 +0000 Received: by mail-qt0-f181.google.com with SMTP id u12so40815150qth.0 for ; Thu, 15 Jun 2017 15:57:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=TLgnJYwL0f5KB5JcGMKt1spuEREPXkdXVz2qXSil4i8=; b=p/VtWlXRYdgFIipjhAaiZvQJZTZiBcm8lxG2/JIBvjghQKYBLGCHZYLpzC+M9NbjRx jkN9iSfYtYK8yZct/Cxkk8g6n0WkzH7FDOd//GAuhy6slxXo83EMqeKRKiJPRyILdrcd XacuBuNC1bq5NVe+LaqtnWc5AOk3N+RdAJQXnSdI1ELlnRGHS0xPAIQCvPKif4MRutkS imYoXTA4KfVH/QRqwU9obGSjGgXmzB8uaOjKWUSrxaAGnDIdGKM1KeCmXo8/DZhlsdVz wS1yfrqh6Ek3iQ9mBqjZ9WDf9Idzt9xo53s6Djs61xsu9umSc88+ybocQ859cVri6Oej KrZA== X-Gm-Message-State: AKS2vOz2j22S3t7gbrPlH8sN38nRDJckbCj2ollUYVmIXJ0BL+OGY0VZ QF7oyQz08TRQCc3c X-Received: by 10.55.22.167 with SMTP id 39mr9490770qkw.20.1497567439141; Thu, 15 Jun 2017 15:57:19 -0700 (PDT) Received: from localhost.localdomain (184-96-144-212.hlrn.qwest.net. [184.96.144.212]) by smtp.gmail.com with ESMTPSA id i134sm343822qke.41.2017.06.15.15.57.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 15 Jun 2017 15:57:18 -0700 (PDT) Subject: Re: [PATCH] document cp_operator_id and cp_assignment_operator_id To: Jason Merrill References: <620e2b9e-a77e-167d-52e3-0b34efa688a5@gmail.com> Cc: Gcc Patch List From: Martin Sebor Message-ID: <76d44f1b-0c31-094b-1f2a-d8a8ecc9e32e@gmail.com> Date: Thu, 15 Jun 2017 22:57:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/mixed; boundary="------------B4E72194DEA52D7E45DBEAD4" X-IsSubscribed: yes X-SW-Source: 2017-06/txt/msg01151.txt.bz2 This is a multi-part message in MIME format. --------------B4E72194DEA52D7E45DBEAD4 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-length: 1488 On 06/15/2017 03:24 PM, Jason Merrill wrote: > On Thu, Jun 15, 2017 at 12:57 PM, Martin Sebor wrote: >> Attached is a documentation-only change to add comments explaining >> the C++ cp_operator_id and cp_assignment_operator_id macros. > > Hmm, I'd say that these macros return the identifier used internally > to represent "operator OP" and "operator OP=", respectively. Looking > up overloads is one thing you can do with that name, but the same is > true of all identifiers, do we need to mention it specifically? I tried to describe the use case that I needed but that wasn't obvious to me from the examples I cam across. If these cp_foo_id() helpers and the other identifier macros were defined and documented in one place there could be a few examples at the top of the section listing them showing some of the less obvious use cases. As it is, cp_operator_id() and cp_assignment_operator_id() are defined in one place (and using the cp_foobar_id() naming convention), while the {ctor,dtor}_ identifier macros in another (and using a different convention). Perhaps there's a good reason for it but knowing as little as I do I find it confusing because I used both to do the same thing: iterate over the overloads of the special functions. With that in mind, attached is an update that tries to clarify things without mentioning the example in the comments for (just) the operator _id macros. If you have a better suggestion I'll be happy to take it. Martin --------------B4E72194DEA52D7E45DBEAD4 Content-Type: text/x-patch; name="gcc-cp_operator_id-doc.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="gcc-cp_operator_id-doc.diff" Content-length: 2723 gcc/cp/ChangeLog: * cp-tree.h (cp_operator_id, cp_assignment_operator_id): Document. diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h index da45d95..b4795d2 100644 --- a/gcc/cp/cp-tree.h +++ b/gcc/cp/cp-tree.h @@ -209,8 +209,19 @@ extern GTY(()) tree cp_global_trees[CPTI_MAX]; /* std::align_val_t */ #define align_type_node cp_global_trees[CPTI_ALIGN_TYPE] -/* We cache these tree nodes so as to call get_identifier less - frequently. */ +/* We cache these tree nodes so as to call get_identifier less frequently. + For identifiers for functions, including special member functions such + as ctors and assignment operators, the nodes can be used (among other + things) to iterate over their overloads defined by/for a type. For + example: + + tree ovlid = cp_assignment_operator_id (NOP_EXPR); + tree overloads = lookup_fnfields_slot (type, ovlid); + for (ovl_iterator it (overloads); it; ++it) { ... } + + iterates over the set of implicitly and explicitly defined overloads + of the assignment operator for type (including the copy and move + assignment operators, whether deleted or not). */ /* The name of a constructor that takes an in-charge parameter to decide whether or not to construct virtual base classes. */ @@ -231,6 +242,18 @@ extern GTY(()) tree cp_global_trees[CPTI_MAX]; /* The name of a destructor that destroys virtual base classes, and then deletes the entire object. */ #define deleting_dtor_identifier cp_global_trees[CPTI_DELETING_DTOR_IDENTIFIER] + +/* The name of the identifier used internally to represent operator CODE. */ +#define cp_operator_id(CODE) \ + (operator_name_info[(int) (CODE)].identifier) + +/* The name of the identifier used to represent assignment operator CODE, + both simple (i.e., operator= with CODE == NOP_EXPR) and compound (e.g., + operator+= with CODE == PLUS_EXPR). Includes copy and move assignment. + Use copy_fn_p() to test specifically for copy assignment. */ +#define cp_assignment_operator_id(CODE) \ + (assignment_operator_name_info[(int) (CODE)].identifier) + #define delta_identifier cp_global_trees[CPTI_DELTA_IDENTIFIER] #define in_charge_identifier cp_global_trees[CPTI_IN_CHARGE_IDENTIFIER] /* The name of the parameter that contains a pointer to the VTT to use @@ -1731,10 +1754,6 @@ struct GTY(()) language_function { || (NAME) == cp_operator_id (DELETE_EXPR) \ || (NAME) == cp_operator_id (VEC_DELETE_EXPR)) -#define cp_operator_id(CODE) \ - (operator_name_info[(int) (CODE)].identifier) -#define cp_assignment_operator_id(CODE) \ - (assignment_operator_name_info[(int) (CODE)].identifier) /* In parser.c. */ extern tree cp_literal_operator_id (const char *); --------------B4E72194DEA52D7E45DBEAD4--