This patch replaces StringMap<...> with std::map<std::string, ...> in AnalyzerOptions::ConfigTable. It seems to be the only non-owning reference to command line arguments in the whole CompilerInvocation, which would introduce a lot of complexity with round-tripping arguments (D94472).
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
This patch replaces StringMap<...> with std::map<std::string, ...> in AnalyzerOptions::ConfigTable. It seems to be the only non-owning reference to command line arguments in the whole CompilerInvocation, which would introduce a lot of complexity with round-tripping arguments (D94472).
I think this patch can be skipped. StringMap owns its own strings. StringMapEntry uses tail allocation to include a null-terminated string inline. For details, have a look at StringMapEntry::Create in llvm/ADT/StringMapEntry.h.
You're right.
I first discovered lifetime issues with Config when using a non-stable data structure for holding allocated strings. Reading the documentation and looking at the API of StringMap made me believe the keys are not owned and I forgot to double-check.
Closing this, as D95369 works correctly regardless.
clang-format not found in user's PATH; not linting file.