Re: [RFC] Revisit PR 16253 ("Attempt to use a type name...")

Keith Seitz
2015-06-23T18:39:57Z

On 06/17/2015 08:50 AM, Keith Seitz wrote:
> On 06/17/2015 05:33 AM, Jan Kratochvil wrote:
>> On Thu, 11 Jun 2015 20:57:18 +0200, Keith Seitz wrote:
>>> PR 16253
>>> * block.c (block_lookup_symbol_primary): If a symbol is found
>>> which does not exactly match the requested domain, keep searching
>>> for an exact match. Otherwise, return the previously found "best"
>>> symbol.
>>
>> Is there a reason why you haven't patched also block_lookup_symbol?
>
> Two reasons:
>
> 1) I posted this RFC to raise discussion whether this was worth
> pursuing. No need to expend any energy on something that has zero chance
> of being accepted by maintainers.
>
> 2) More important I have not discovered/attempted to coverage test
> lookup_block_symbol to trigger this bug.
>
> I'll be attempting to do that today.

And I failed. I've not found the "magic" combination of buttons to make
any difference in block_lookup_symbol.

Nonetheless it is not quite so straight-forward in the BLOCK_FUNCTION
case where we have to decide what is a "better" match:

SYMBOL_DOMAIN == domain && SYMBOL_IS_ARGUMENT

or
SYMBOL_DOMAIN != domain (but symbol_matches_domain returns 1) &&
!SYMBOL_IS_ARGUMENT

In that case, I cannot say which is more correct. Moreover I have been
unable to figure out how to test this. I worry that I would simply be
introducing a regression. IMO this is getting into "risky" territory.
[But then my philosophy is "if it ain't broke, don't fix it." As far as
I can tell, block_lookup_symbol is not "broke."]

So what do maintainers want me to do?

Keith