From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 120412 invoked by alias); 12 Dec 2018 04:41:43 -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 120398 invoked by uid 89); 12 Dec 2018 04:41:43 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=stating, loosemore, Loosemore, H*r:0800 X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 12 Dec 2018 04:41:41 +0000 Received: from svr-orw-mbx-03.mgc.mentorg.com ([147.34.90.203]) by relay1.mentorg.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-SHA384:256) id 1gWwL4-0007I1-AX from Sandra_Loosemore@mentor.com ; Tue, 11 Dec 2018 20:41:38 -0800 Received: from [127.0.0.1] (147.34.91.1) by svr-orw-mbx-03.mgc.mentorg.com (147.34.90.203) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 11 Dec 2018 20:41:35 -0800 Subject: Re: [doc PATCH] update attribute docs for C++ To: Martin Sebor , Gcc Patch List References: <932d5110-020b-4814-c3e7-bcda8e9d28ec@codesourcery.com> <11cf135d-7524-ed3a-7cbb-a1c436b4c8ce@gmail.com> <96070396-369b-e736-72dc-e08ab46a847a@codesourcery.com> <1bdd5657-1295-78a2-4299-21b3cc13af9c@gmail.com> <00a37112-7532-ede0-1465-3aaa5fc8216a@gmail.com> From: Sandra Loosemore Message-ID: Date: Wed, 12 Dec 2018 04:41:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <00a37112-7532-ede0-1465-3aaa5fc8216a@gmail.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-SW-Source: 2018-12/txt/msg00761.txt.bz2 On 12/5/18 10:14 AM, Martin Sebor wrote: > On 12/4/18 8:49 PM, Sandra Loosemore wrote: > >> What is the "it" referenced in the user's questions you quoted?  The >> const/pure attributes?  Those are function attributes.  The text you >> are adding is in the type attribute section, so it seemed like it was >> trying to address a different problem: stating that you can attach >> type attributes to any struct/class type whether or not it is a >> "trivial" class, by some definition of that term.  If that's not the >> purpose of this paragraph, what is it? > > Again: the purpose is to explain that it doesn't matter whether > an attribute applies to a struct or a C++ class with ctors, in > any context with any attribute, either function, or variable, > or even type(*). OK. My main concern is that I think a user looking up a specific function or variable attribute is unlikely to think of reading through the type attribute section for that particular tidbit of information. Maybe we need to do some larger reorganization of material to include an overview of attribute semantics as well as a section on attribute syntax, but TBH I'm not enthusiastic about tackling that rewrite at the moment. :-P > To make things clear, we could (and at some point perhaps > should) also go and edit all the places that talk about > structs and unions and mention C++ classes. It won't > unambiguously answer the user's question about PODs vs > non-trivial classes with ctors, but it would help. I think it would be good to open an issue for a general review of this. I just recently fixed the specific instance of it for the packed attribute (PR 25759). Going back to the last version of the patch posted, I have a couple nits about your newly added section of text: > +Some function attributes take one or more arguments that refer to > +the function's parameters by their positions within the function parameter > +list. Such attribute arguments are referred to as @dfn{positional arguments}. > +Unless specified otherwise, positional arguments that specify properties > +of pointer types can also specify the same properties for the implicit C++ I think this should be s/properties of pointer types/properties of parameters with pointer types/ > +@code{this} argument in non-static member functions, and, to parameters of s/and, to parameters of/and to parameters with/ > +reference to a pointer type. For ordinary functions, position one refers > +to the first parameter on the list. In C++ non-static member functions, > +position one refers to the implicit @code{this} pointer. The same > +restrictions and effects apply to function attributes used with ordinary > +functions or C++ member functions. > + > GCC also supports attributes on > variable declarations (@pxref{Variable Attributes}), > labels (@pxref{Label Attributes}), I think the patch is OK to commit with those changes. -Sandra