[PATCH] D85501: [lld-macho] Handle command-line option -sectcreate SEG SECT FILE

[Jez Ng via Phabricator via llvm-commits]

int3 added inline comments.


================
Comment at: lld/MachO/InputFiles.cpp:313
+  isec->data = {buf, mb.getBufferSize()};
+  subsections.push_back({{0, isec}});
+}
----------------
gkm wrote:
> int3 wrote:
> > gkm wrote:
> > > int3 wrote:
> > > > nit: `subsections.emplace_back({0, isec});`
> > > I followed prior practice in `InputFile::parseSections`. If I follow your recommendation, it seems I should also fix `InputFile::parseSections`, but then I am straying from the purpose of this diff into cleanup territory. Perhaps we should rather save cleanups for a separate diff, which could also include explicit `const auto`.
> > I think it's worthwhile to make new code conform to the linter. That way, even if we don't explicitly do cleanups, we will still organically move to the new convention in the course of normal code churn from development. But I'm fine with migrating to `emplace` in a separate diff.
> I gave-up on `subsections.emplace_back()`. None of these compiled:
> ```
> subsections.emplace_back({{0, isec}});
> subsections.emplace_back({0, isec});
> subsections.emplace_back(0, isec);
> ```
> `subsections` is a vector of maps, and the emplacement incantation is beyond me. Clues welcome. Here are the relevant decls:
> ```
> using SubsectionMap = std::map<uint32_t, InputSection *>;
> class InputFile {
>   std::vector<SubsectionMap> subsections;
> };
> ```
> 
hm I'm not 100% familiar with what the C++ spec says about nested initialization lists... that not compiling is probably the reason why `push_back` was used elsewhere


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D85501