From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28392 invoked by alias); 11 Mar 2011 16:23:59 -0000 Received: (qmail 28361 invoked by uid 22791); 11 Mar 2011 16:23:56 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00,TW_CX,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 11 Mar 2011 16:23:51 +0000 Received: (qmail 10628 invoked from network); 11 Mar 2011 16:23:49 -0000 Received: from unknown (HELO localhost) (froydnj@127.0.0.2) by mail.codesourcery.com with ESMTPA; 11 Mar 2011 16:23:49 -0000 Date: Fri, 11 Mar 2011 16:23:00 -0000 From: Nathan Froyd To: Jason Merrill Cc: gcc-patches@gcc.gnu.org Subject: Re: [PATCH 15/18] move REAL_IDENTIFIER_TYPE_VALUE to be a field of lang_identifier Message-ID: <20110311162348.GM23686@codesourcery.com> References: <1299817406-16745-1-git-send-email-froydnj@codesourcery.com> <1299817406-16745-16-git-send-email-froydnj@codesourcery.com> <4D7A2648.40005@redhat.com> <20110311140444.GI23686@codesourcery.com> <20110311141956.GJ23686@codesourcery.com> <4D7A39CF.1010909@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D7A39CF.1010909@redhat.com> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-IsSubscribed: yes 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: 2011-03/txt/msg00643.txt.bz2 On Fri, Mar 11, 2011 at 10:03:43AM -0500, Jason Merrill wrote: > On 03/11/2011 09:19 AM, Nathan Froyd wrote: >>> I'm confused. Isn't this what the switching on IDENTIFIER_NODE in a >>> number of places is doing? (And any future places that g++/libstdc++ >>> didn't catch will be an ICE.) Or are you saying that you don't want the >>> switching and IDENTIFIER_NODEs should retain TREE_TYPE unless and until >>> somebody comes forth with a better design? > > The latter. OK. Well, for the time being, I can drop this particular patch and simply eliminate TREE_CHAIN from IDENTIFIER_NODEs. That eliminates any issues with free_lang_decl and the like anyway. >> Or, alternatively, are you saying that blindly replacing TREE_TYPE with >> REAL_IDENTIFIER_TYPE_VALUE is wrong, semantically speaking, as TREE_TYPE >> and REAL_IDENTIFIER_TYPE_VALUE mean different things and should be kept >> separate, even if they happen to share the same storage? > > This too. I'm surprised that them sharing the same storage hasn't > broken anything yet. > >> so long as the >> requisite occurrences of TREE_TYPE are audited and the appropriate name >> (REAL_IDENTIFIER_TYPE_VALUE vs. ...I don't know, EXPR_LIKE_TYPE) is >> used? > > No, I want to keep using TREE_TYPE. I was thinking of something more > like the DEPENDENT_NAME_EXPR that Joseph mentioned. Hm. OK. Just as a light sketch of how this would all work, where do DEPENDENT_NAME_EXPRs get introduced into the AST? During parsing, or someplace else? What about those cases where the FE does TREE_TYPE (DECL_NAME (X))--are those supposed to be REAL_IDENTIFIER_TYPE_VALUE or is that supposed to be TREE_TYPE as discussed above (and if so, that would be an impediment to moving identifiers to a separate static type, as DECL_NAMEs should be identifiers, not generic trees...)? There's also cases like: --- a/gcc/cp/error.c +++ b/gcc/cp/error.c @@ -1011,7 +1011,7 @@ dump_decl (tree t, int flags) { pp_cxx_ws_string (cxx_pp, "operator"); /* Not exactly IDENTIFIER_TYPE_VALUE. */ - dump_type (TREE_TYPE (t), flags); + dump_type (REAL_IDENTIFIER_TYPE_VALUE (t), flags); break; } else is that supposed to be REAL_IDENTIFIER_TYPE_VALUE, the TREE_TYPE discussed above, or yet another use? I assume that wherever we test for IDENTIFIER_TYPENAME_P, we're expecting these dependent types rather than REAL_IDENTIFIER_TYPE_VALUE? -Nathan