This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFA] thinko in find_symbol_in_baseclass
- From: Keith Seitz <keiths at redhat dot com>
- To: Doug Evans <dje at google dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Wed, 29 May 2013 12:15:28 -0700
- Subject: Re: [RFA] thinko in find_symbol_in_baseclass
- References: <yjt2a9nf1tno dot fsf at ruffy2 dot mtv dot corp dot google dot com>
On 05/27/2013 11:54 PM, Doug Evans wrote:
I could be missing something of course.
If I added a relatively detailed comment explaining why it was
necessary, then searching through static symbols was necessary -- at
least at the time.
I have several more elaborate tests still lying around (mostly tests
that include templates and multiple-inheritance), and I cannot trigger a
failure with your patch.
So right now, I am puzzled why I put that in there. Perhaps it was
necessary at one point. Perhaps I "fixed" the particular case I was
attempting to address with that block and then failed to recognize that
it was no longer necessary.
cp_lookup_nested_symbol searches all static blocks before calling
find_symbol_in_baseclass, so this bit in find_symbol_in_baseclass is
clearly unnecessary. My bad.
btw, it's not clear to me what the tail of this comment means:
We do not try to
guess any imported namespace as even the fully specified
namespace search is already not C++ compliant and more
assumptions could make it too magic.
IWBN to clarify this.
I didn't add that comment, but last time I looked at this, I convinced
myself that what was being criticized was that searching all static
symbols at this point is already not strictly correct (according to the
standard), so we don't attempt to deal with imported namespaces and
other ("obscure") scenarios here.
Ok to check in?
I would say, "Yes," but IANAM.
Keith