From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id E3955386F460 for ; Thu, 7 May 2020 14:15:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org E3955386F460 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark@simark.ca Received: from [10.0.0.193] (unknown [192.222.164.54]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 6BDEA1E581; Thu, 7 May 2020 10:15:36 -0400 (EDT) Subject: Re: [PATCH 4/4] gdb: remove TYPE_DYN_PROP_LIST macro To: Tom Tromey , Simon Marchi via Gdb-patches Cc: Simon Marchi References: <20200430181753.1093-1-simon.marchi@efficios.com> <20200430181753.1093-5-simon.marchi@efficios.com> <87blmzzw1s.fsf@tromey.com> From: Simon Marchi Message-ID: <7b47e447-4ca1-0548-e43e-189bac286629@simark.ca> Date: Thu, 7 May 2020 10:15:35 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <87blmzzw1s.fsf@tromey.com> Content-Type: text/plain; charset=utf-8 Content-Language: tl Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-9.9 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2020 14:15:38 -0000 On 2020-05-07 9:58 a.m., Tom Tromey wrote: >>>>>> "Simon" == Simon Marchi via Gdb-patches writes: > > Simon> Remove this macro, which abstracts how to obtain the dyn_prop_list of a > Simon> given type. We could replace it with a method on `struct type`, but I > Simon> don't think it's needed, as the only code that accesses the dynamic prop > Simon> list directly is internal gdbtypes.c code (that can be seen as code > Simon> internal to `struct type`). So it can just refer to the field directly. > > Eventually this member should probably be private. Indeed, there are a few things to consider before: - To make struct type non-POD, we need to re-evaluate how it's allocated/de-allocated - Re-evaluate how the types are copied. copy_type and copy_type_recursive are currently free functions. So either they need to work only using the public API of struct type and struct main_type, they need to be made "friend" of these classes, or they need to be changed to be methods of these classes. In the mean time, an approach I've taken with my not-submitted-yet patches is to still rename the field to give it the `m_` prefix, even though it's not really private yet. That still ensures that no other part of the code is unexpectedly accessing the field directly. Simon