[PATCH] D116913: [lld-macho] Add --start-lib --end-lib

Jez Ng via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Jan 18 20:25:48 PST 2022


int3 accepted this revision.
int3 added a comment.
This revision is now accepted and ready to land.

lgtm, thanks!



================
Comment at: lld/MachO/InputFiles.cpp:1619
+  symbols.resize(obj->symbols().size());
+  for (auto it : llvm::enumerate(obj->symbols())) {
+    const lto::InputFile::Symbol &objSym = it.value();
----------------
MaskRay wrote:
> MaskRay wrote:
> > oontvoo wrote:
> > > int3 wrote:
> > > > no need for `llvm::`
> > > Sorry, I'm missing something here but why not simply ` for (const lto::InputFile::Symbol &objSym : obj->symbols())` ?
> > > IOWs, why is `llvm::enumerate` needed?
> > `llvm::foo` for STL-like helpers (lower_bound, find_if, etc) has an advantage: prevent the confusing argument-dependent lookup. In other components of llvm-project `llvm::foo` for STL-like helpers is generally recommended.
> > 
> > So I am going to defend for the usage a bit...
> `symbols[it.index()] ` is needed by `-ObjC` for ObjC symbol checking. It has another advantage: when a symbol table refactoring is done in the future, we can transfer the symbol table to the non-lazy state. See D116390 for ELF.
mm yeah, I have also been including `llvm::` in front of LLVM functions which have STL counterparts of the same name. My reasoning was that since `std::enumerate` doesn't exist, `llvm::` wasn't needed here... but I can also see the argument for using `llvm::` for all STL-like things.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D116913/new/

https://reviews.llvm.org/D116913



More information about the llvm-commits mailing list