Re: Compiler identifier hashtable improvements (and ObjC cleanup)

[Neil Booth <neil at daikokuya dot demon dot co dot uk>]

Zack Weinberg wrote:-

> Yeah, you can stomp on the flags - I am fairly sure only two of them
> are used for IDENTIFIER_NODEs.  But be careful, because a language
> might have decided to recycle them for its own purposes.

I think the C front end uses about 5 flags - I updated the comments in
tree.h to reflect what I'd discovered on my wanderings as part of the
patch.

> I'm just confused about why the case where you allocate the
> identifier_node and then set its code to ERROR_MARK is necessary.  I'm
> also nervous about how that will interact with GC.

Right, see my followup cleanup patch (not yet approved).  We'll
ggc-mark the node as normal.  An ERROR_MARK node doesn't GC any of its
members, since it doesn't have any.  A newly created IDENTIFIER_NODE
doesn't have any non-NULL members either.  So that part seems OK to
me.

Once a front-end has grabbed an identifier that is an IDENTIFIER_NODE
through get_identifier (), it can never revert to being an ERROR_MARK
(ERROR_MARK-ness is only set in the constructor, if you like).

Note that at the moment everything uses get_identifier (), and along
with maybe_get_identifier (), it's the only exported interface, so
front-end visible ERROR_MARKs are impossible.

In future, the only way they'll be possible is when cpplib creates
them through some as-yet non-existent interface.  They'll still not be
visible from the front ends: what is currently yylexname () in c-lex.c
will die, and in its place one or two lines of code will switch the
node's code to IDENTIFIER_NODE to simulate a get_identifier () call.

> Oh, okay, but then what happens if you write 'int oneway;' ?

$ cat /tmp/test.m
int oneway;
int byref;
$ ./xgcc -B./ /tmp/test.m -c
$

Seems OK.  Cool :-)

Neil.