Re: [RFC] regresssion(internal-error) printing subprogram argument

[Joel Brobecker <brobecker@adacore.com>]

> I gave the "literal" lookup type a try today, and it turns out
> not being so bad, I think.  See patch below.

Thanks!

> Thinking through this and experimenting a bit, I think I convinced
> myself that with the current symbol tables infrastructure,
> it's not literal _linkage_ names that we want to pass down, but
> instead literal _search_ names.  I.e., notice that I've switched
> the lookup_symbol call in question to pass down
> SYMBOL_SEARCH_NAME instead of SYMBOL_LINKAGE_NAME.  See
> comments in symtab.h in the patch.

I forgot about how the hashes were calculated, so what you are
saying makes sense.

I did a round of testing, both with the official testsuite as well
as ours, and I confirm what you see: issue fixed with no regression.
I reviewed the patch as well, and it looks good. In particular,
the choices you made in terms of what type of lookup to do, and
what name to pass made sense to me.

> The patch is not complete in the sense that there are
> symbol-lookup entry points that could be tweaked to pass
> down a symbol_name_match_type instead of assuming FULL.
> 
> And also, I know there are places in ada-lang.c that are doing
> what you were doing here too (the "<...>" verbatim trick) which
> could be adjusted.  But at least this fixes your testcase too,
> and causes no regressions.  So maybe we could do this incrementally
> and pass adjust functions to pass around a symbol_name_match_type
> as we find a need?  Functions that we miss passing down simply
> end up behaving like symbols_name_match_type::FULL, as today.

I like this approach. I'll try going through ada-lang.c after
this change gets in to see if I can spot some of the "<...">
tricks, and simplify them by using the new symbols_name_match_type
instead.

-- 
Joel