Re: [RFC v2][PR symtab/30520] gdb/symtab: fix the gdb.cp/anon-struct test

[Dmitry Neverov <dmitry.neverov@jetbrains.com>]

Tom> Dmitry> The symbol_name_match_type::SEARCH_NAME cannot be used because
Tom> Dmitry> demangle_for_lookup_info doesn't initialize a demangled name
Tom> Dmitry> for it which makes a subsequent name matching to fail.
Tom>
Tom> I don't think I understand this comment, but anyway shouldn't this patch
Tom> simply be folded into an earlier one in the series?

Sorry, this is the first time I submit a series. I've noticed a
test failure after I sent patches and wasn't sure how to update
them. What should I do in such a situation? Create [RFC v3]?

What I was trying to say in the commit message is that
demangle_for_lookup_info::demangle_for_lookup_info has the
following logic:

if (without_params != NULL)
  {
    if (lookup_name.match_type () != symbol_name_match_type::SEARCH_NAME)
      m_demangled_name = demangle_for_lookup (without_params.get (),
      lang, storage);
    return;
  }

So when symbol_name_match_type::SEARCH_NAME was used, the
demangled name wasn't initialized which made subsequent
name_matcher calls to not match. Switching to
symbol_name_match_type::FULL fixes this.

Tom> I read through these and they seem basically reasonable to me -- in line
Tom> with what I was hoping for.  There are some minor formatting issues.

Sorry, again. I've tried to follow the code style as closely as I
can, but have missed something. I will try to be more careful
next time. If there is some formatter I can run - please let me
know.

Tom> You didn't mention what testing you did, so I am curious about that.

I've done only manual testing in the project where I can
reproduce the problem with slow symbol lookup. I'm not sure how
to write an automatic test checking that CU is not expanded
unnecessarily. Are there any existing tests checking that?

On Wed, Feb 7, 2024 at 9:25 PM Tom Tromey <tom@tromey.com> wrote:
>
> >>>>> "Dmitry" == Dmitry Neverov <dmitry.neverov@jetbrains.com> writes:
>
> Dmitry> The symbol_name_match_type::SEARCH_NAME cannot be used because
> Dmitry> demangle_for_lookup_info doesn't initialize a demangled name
> Dmitry> for it which makes a subsequent name matching to fail.
>
> I don't think I understand this comment, but anyway shouldn't this patch
> simply be folded into an earlier one in the series?
>
> I read through these and they seem basically reasonable to me -- in line
> with what I was hoping for.  There are some minor formatting issues.
>
> You didn't mention what testing you did, so I am curious about that.
>
> thanks,
> Tom