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
