This is an archive of the discontinued LLVM Phabricator instance.

[lld][ELF] Rename SymbolTable::symbols() to SymbolTable::getSymbols(). NFC
AbandonedPublic

Authored by sbc100 on Jul 29 2022, 10:31 AM.

Details

Summary

This change renames this method match its original name and the name
used in the wasm linker.

Back in d8f8abbd4a2823f223bd7bc56445541fb221b512 the ELF SymbolTable
method getSymbols() was replaced with forEachSymbol.

Then in a2fc96441788fba1e4709d63677f34ed8e321dae forEachSymbol was
replaced with a llvm::iterator_range.

Then in e9262edf0d11a907763098d8e101219ccd9c43e9 we came full circle
and the llvm::iterator_range was replaced with a symbols() accessor
that was identical the original getSymbols().

getSymbols also matches the name used elsewhere in the ELF linker as
well as in both COFF and wasm backend (e.g. InputFiles.h and
SyntheticSections.h)

Diff Detail

Event Timeline

sbc100 created this revision.Jul 29 2022, 10:31 AM
Herald added a project: Restricted Project. · View Herald Transcript
sbc100 requested review of this revision.Jul 29 2022, 10:31 AM

I feel that symbols is not a bad name. For two functions: foo and getFoo, if foo can trivially return the member variable (as in this case), I think it's totally fine.

I feel that symbols is not a bad name. For two functions: foo and getFoo, if foo can trivially return the member variable (as in this case), I think it's totally fine.

I'm not really arguing that its a better name, just trying to be consistent with the other uses withing the ELF linker and other other backends (and the historical name).

The alternative would be create change for the wasm linker to make it consistent with the ELF one.. I can do that if you prefer, but then we would also probably want to update the other places where getSymbols() is used in the ELF/COFF and wasm backends already.

I quite useful to me not keep the various backends in sync.. and normally I do update the wasm linker to match the ELF one... but in this case I think it makes sense to do it the other way around (for the reasons already stated).

For example, see the existing InputFile::getSymbols which exists in all 3 backends

sbc100 updated this revision to Diff 450341.Aug 5 2022, 11:57 AM
  • rebase

For example, see the existing InputFile::getSymbols which exists in all 3 backends

Do you feel strongly about .symbols() over .getSymbols()? This change seems like the least intrusive way to consistency, and I would rather land this, but if you feel strongly we can move other methods/backends over to .symbols() instead.

I feel that symbols() is a better name. I am not sure the consistency with other ports matters in this case. The data structures are so different. Using symbols for symtab and getSymbols for InputFile has another benefit that we can easily distinguish the two use cases (which are very different).

I feel that symbols() is a better name. I am not sure the consistency with other ports matters in this case. The data structures are so different. Using symbols for symtab and getSymbols for InputFile has another benefit that we can easily distinguish the two use cases (which are very different).

But in the wasm port I have .getSymbols() for both the symbol table and for the InputFile. So I guess I should change my symbol table to use .symbols()? I do care about keeping the ports in sync as best I can, it helps with maintaining the wasm port to be able to compare them.

sbc100 abandoned this revision.Aug 5 2022, 12:58 PM