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

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:


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

On 03/11/2011 11:23 AM, Nathan Froyd wrote:
> 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?

During parsing, yes, wherever we look up a name and currently return the 
plain identifier rather than a decl.

> What about those cases where the FE does TREE_TYPE
> (DECL_NAME (X))--are those supposed to be REAL_IDENTIFIER_TYPE_VALUE

Kind of.  It seems like there are two uses:

1) Remembering that we've seen a declaration of a type with this name.
2) Remembering which type a particular tinfo or conversion op name 
corresponds to.

It probably makes sense for #2 to use a new and different macro.

> 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

That's #2.

Jason