Re: [rfa] language hooks for lookup_symbol

[David Carlton <carlton at math dot stanford dot edu>]

On Mon, 19 May 2003 11:19:50 -0400, Elena Zannoni <ezannoni@redhat.com> said:

> 1. check in the if0 elimination by itself, then the deletion of
>    static_block parameter and teh addition of the block_static_bloc
>    function. After that check in the rest (which is really the big change).

Will do.

> 2. I think that instead of: int la_lookup_symbol_this; We can just
>      have the new field be a function pointer to NULL or to the
>      value_of_this function itself. This function itself can be split
>      in 2, one for objc and one for c++.

That makes sense.  I'll also add a FIXME comment saying that we should
audit all existing languages to make sure that the field is set
properly.

> 3. move the comments as well, instead of deleting them.

I assume you're referring to these comments?

-  /* NOTE: carlton/2002-12-05: There is a question as to whether or
-     not it would be appropriate to search the current global block
-     here as well.  (That's what this code used to do before the
-     is_a_field_of_this check was moved up.)  On the one hand, it's
-     redundant with the lookup_symbol_aux_symtabs search that happens
-     next.  On the other hand, if decode_line_1 is passed an argument
-     like filename:var, then the user presumably wants 'var' to be
-     searched for in filename.  On the third hand, there shouldn't be
-     multiple global variables all of which are named 'var', and it's
-     not like decode_line_1 has ever restricted its search to only
-     global variables in a single filename.  All in all, only
-     searching the static block here seems best: it's correct and it's
-     cleanest.  */
-
-  /* NOTE: carlton/2002-12-05: There's also a possible performance
-     issue here: if you usually search for global symbols in the
-     current file, then it would be slightly better to search the
-     current global block before searching all the symtabs.  But there
-     are other factors that have a much greater effect on performance
-     than that one, so I don't think we should worry about that for
-     now.  */
-

The reason why I was planning to delete them is because they don't
make a lot of sense after this latest reorganization (since the "this
code" and the "is_a_field_of_this" mention wouldn't refer to the
function in question) and because I'm no longer bothered by the qualms
that led me to write the comments in the first place.  But if you want
me to keep them, I will (adding another note that they've been moved).

David Carlton
carlton@math.stanford.edu