From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32358 invoked by alias); 9 Mar 2008 21:17:46 -0000 Received: (qmail 32349 invoked by uid 22791); 9 Mar 2008 21:17:46 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 09 Mar 2008 21:17:23 +0000 Received: (qmail 8870 invoked from network); 9 Mar 2008 21:17:20 -0000 Received: from unknown (HELO ?192.168.0.2?) (mitchell@127.0.0.2) by mail.codesourcery.com with ESMTPA; 9 Mar 2008 21:17:20 -0000 Message-ID: <47D453DB.1070802@codesourcery.com> Date: Sun, 09 Mar 2008 21:17:00 -0000 From: Mark Mitchell User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Paolo Carlini CC: Gcc Patch List Subject: Re: Renaming IS_AGGR_TYPE & co References: <47D1720D.5010206@suse.de> In-Reply-To: <47D1720D.5010206@suse.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 X-SW-Source: 2008-03/txt/msg00606.txt.bz2 Paolo Carlini wrote: > I'd like to finally work on this simple project but, before starting on > it, I need some guidance on related (re)names. Indeed, I noticed that we > have got, closely related: > > IS_AGGR_TYPE > SET_IS_AGGR_TYPE > IS_AGGR_TYPE_CODE > PROMOTES_TO_AGGR_TYPE > make_aggr_type (in lex.c) Thank you for volunteering to working on this. > In my understanding we should rename all of them, consistently, but I'm > not sure about the names, besides MAYBE_CLASS_TYPE_P for the first and, > likely, SET_MAYBE_CLASS_TYPE_P for the second. I think IS_AGGR_TYPE should become MAYBE_CLASS_TYPE_P. However, SET_IS_AGGR_TYPE should be SET_CLASS_TYPE_P; the bit flag is only set on class types, and setting it corresponds to the CLASS_TYPE_P macro below. (MAYBE_CLASS_TYPE_P also includes things like template type parameters which *might* turn out to be class types.) IS_AGGR_TYPE_CODE should be RECORD_OR_UNION_CODE_P, I think. The purpose of this macro is to check whether the *lowered* representation of a type is a struct or union. That applies to class types, but it also applies to pointers-to-function-member types. This macro is currently substantially overused in the front end. For example: bool is_properly_derived_from (tree derived, tree base) { if (!IS_AGGR_TYPE_CODE (TREE_CODE (derived)) || !IS_AGGR_TYPE_CODE (TREE_CODE (base))) return false; That should probably just be: if (!CLASS_TYPE_P (derived) || !CLASS_TYPE_P (base)) return false; It's harmless to let pointers-to-members make it further through this function, but there's no reason we should, and it's confusing. I would just remove PROMOTES_TO_AGGR_TYPE. Replace its only use -- in an assertion -- with an expansion of the macro. I think make_aggr_type should become make_class_type. And, you should only be allowed to call it with code set to RECORD_TYPE or UNION_TYPE, which will obviate the IS_AGGR_TYPE_CODE check there. It should just become: t = cxx_make_type (code); SET_CLASS_TYPE_P (t); return t; The callers calling it with other codes should just use cxx_make_type directly. Thanks, -- Mark Mitchell CodeSourcery mark@codesourcery.com (650) 331-3385 x713