Implement SymbolFile::GetCompileOptions, which returns a map from
compilation units to compilation arguments associated with that unit.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
At a higher level I wonder if this is really the best interface. If you ever need all the compile options, you probably want something like Args SymbolFile::GetCompileOptions(). Wouldn't that be a more generic way to do the same thing here? Or do we expect that for DW_AT_APPLE_flags the only possible use case is to check whether a particular flag is set?
lldb/include/lldb/Symbol/SymbolFile.h | ||
---|---|---|
441 | Please use StringRefs instead of raw char pointers. | |
lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp | ||
4271 | It's not obvious from the function name what GetArgumentArrayRef is going to return. Looking at the header, it's apparently a llvm::ArrayRef<const char *>, so auto& is a reference to a pointer? | |
4282–4285 |
I agree. I implemented it in such a a way to mirror the GetCompileOption function (which apparently doesn't exist upstream anymore). I'll update it to return the Args instead.
LGTM with or without the DenseMap, whichever makes the most sense.
lldb/include/lldb/Symbol/SymbolFile.h | ||
---|---|---|
441 | Any reason you picked unordered_map? Not that I expected this code to be particularly hot, but I would've gone for an llvm::DenseMap which should offer much better performance characteristics. |
lldb/include/lldb/Symbol/SymbolFile.h | ||
---|---|---|
441 | Mainly because there's no implementation of shared pointer as keys for dense maps (DenseMapInfo<T> where the T is a shared_ptr) at the moment, and I don't expect this to be super hot. |
Please use StringRefs instead of raw char pointers.