Re: [RFA] Fix c++/16253 (tag/variable name collision)

[Joel Brobecker <brobecker at adacore dot com>]

Hey Keith,

> > I must also give a shout out to Joel -- I've largely avoided hacking
> > with/at Ada. In fact, Ada *largely* remains unchanged. However, it
> > now must explicitly search STRUCT_DOMAIN in a few places itself (an
> > analogous change to the other symbol table API changes I've made).
> > Joel, if you could run this through your internal AdaCore test
> > harness, that would be most helpful.
> 
> I had a chance to test your patch today, and unfortunately our testsuite
> detected some regressions. I think they might all be the same, so I
> picked the simplest testcase. I might be running short of time today
> to look deeper into this, but I can try scheduling some time for it
> tomorrow or Wed.
> 
>     % gnatmake -g foo
>     % gdb foo
>     (gdb) ptype base

Insert missing "No definition of "base" in current context." as the
output of the "ptype base" command above...

I had a chance to investigate the source of the problem, and I think
I understand it, now. Basically, I think you fixed up the Ada symbol
lookups for local symbols, but did not adjust the non-local lookups.

In our case, our type "base" is defined in unit foo.adb as a static
(non-global) STRUCT_DOMAIN symbol. The symbol lookup is performed
via ada-lang.c::add_nonlocal_symbols which calls
objfile->sf->qf->map_matching_symbols (=map_matching_symbols_psymtab).
And the match now fails since it performs strict domain matching.

I think you actually ended up noticing the problem, since you had to
change ada-tasks to do a STRUCT_DOMAIN search instead of a VAR_DOMAIN
search. I think the ada-tasks change is correct regardless, since
these are all structure types anyways (need to double-check, but
pretty sure), but that was also a clue.

Now, the question becomes: Does Ada need to add some logic to call
objfile->sf->qf->map_matching_symbols a second time with STRUCT_DOMAIN,
or should objfile->sf->qf->map_matching_symbols do it? From the looks
of your patch, it looks like this should be done on the Ada side?

Thanks!
-- 
Joel