Improved use of TREE_SYMBOL_REFERENCED in the C++ front end

[Matt Austern]

On Thursday, October 31, 2002, at 03:08  PM, Richard Henderson wrote:

> On Thu, Oct 31, 2002 at 11:01:34AM -0800, Matt Austern wrote:
>> So I'd like to have two different macros, one to query the flag
>> and one to set it.
>
> Ok, my point is that I'd like to have one macro, which is
> read-only, and one langhook, which is write-only.
>
> As for the variety of places that set TREE_SYMBOL_REFERENCED,
> yes that is probably something that should be cleaned up.

Aha, I finally understand what you were suggesting.  Sorry; I've
been dense.  I think the reason I took so long is that you and I
had slightly different ideas about what the langhook would be.
You were assuming it would be something like:
   (*hooks.set_symbol_referenced) (id, 1)
I, however, was assuming it would be something more like:
   (*hooks.referenced_flag_was_changed) (id)
That is, I was assuming the hook would be called after the flag
had been changed, and that it would be called, for example, from
within the macro that did the setting.

But now that I understand what you meant, I think I do still
prefer my original scheme.  My rationale:
  (1) It's possible that in the future we won't need that hook.
      At present, I haven't heard anyone suggest that it's needed
      for anything but the C++ front end.  If we do get rid of the
      hook (or if we never need to introduce it in the first place)
      then I'd rather make the change in one place, the macro for
      setting the flag, than in every place that uses the macro.
  (2) If we have no macro for setting the flag, then how would the
      langhook do it?  The only answer to that question that I can
      think of is that it would manipulate tree node data structures
      directly.  But we try very hard to avoid that; we try to make
      sure those structures are manipulated only through macros, so
      that when we have to change the data structures we don't have
      to make changes anywhere but in tree.c or tree.h.

I'd like to submit a patch for this later today.

			--Matt