Reducing confusion around isUndefined()

[Rui Ueyama via llvm-commits]

I think I'm not too excited about adding more predicates or inheritance.
Lazy symbols are useful only when we are adding files to the symbol table.
After that, there's no use of them. So maybe we can just visit all symbols
at some point after reading all files but before writeResult to nuke all
Lazy symbols (by replacing local undefined symbol or something), so that we
don't have to think about it after that point.

On Fri, Oct 13, 2017 at 3:27 PM, Rafael Avila de Espindola <
rafael.espindola at gmail.com> wrote:

> In lld we have three types of symbols that are easily confused:
> undefined, shared and lazy.
>
> I just finished auditing the uses of isUndefined, and most were
> incorrect.
>
> The most common issue was that the code intended to check if the symbol
> will be undefined on the final symbol table. The actual predicate for
> that is isInCurrentDSO().
>
> In some other cases the intention was to check if we had a definition
> already, in which case the code should check also for lazy symbols
> too. We don't currently have a predicate for isUndefined() || isLazy().
>
> Some ideas to try to make this less error prone.
>
> * Add a isNotDefined() predicate for isUndefined() ||
>   isLazy(). Unfortunately the name would be confusing.
>
> * Have Lazy inherit from undefined. Very few places want to check just
>   for undefined, so they can use kind() directly and isUndefined() would
>   also return true for lazy symbols.
>
> * Rename isUndefined() to isUndefinedOnInput() to make it clear it is
>   not about the output symbol table.
>
> I am not too excited about any of these. Anyone has another suggestion
> on how to make this more intuitive?
>
> Cheers,
> Rafael
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20171013/f474d246/attachment.html>