Reducing confusion around isUndefined()

Rafael Avila de Espindola via llvm-commits llvm-commits at lists.llvm.org
Fri Oct 13 15:27:05 PDT 2017


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


More information about the llvm-commits mailing list