Re: [PATCH 15/18] move REAL_IDENTIFIER_TYPE_VALUE to be a field of lang_identifier

[Nathan Froyd <froydnj@codesourcery.com>]

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