As a follow up of https://reviews.llvm.org/D99989#inline-953343, I'm now
storing std::string instead of char *. I know it might never break as char *,
but if it does, chasing that bug might be dauting.
Details
Diff Detail
Event Timeline
| lldb/tools/lldb-vscode/lldb-vscode.cpp | ||
|---|---|---|
| 2934 | Have you considered an`llvm::StringMap`, it should be more performant. | |
| lldb/tools/lldb-vscode/lldb-vscode.cpp | ||
|---|---|---|
| 2934 | I've been reading https://llvm.org/devmtg/2014-04/PDFs/LightningTalks/data_structure_llvm.pdf and it seems that it's not more performant speed-wise. I imagine it's more performance space-wise, but here I mostly care about time. | |
| lldb/tools/lldb-vscode/lldb-vscode.cpp | ||
|---|---|---|
| 2939 | This will crash if "variable.GetName()" return nullptr. We should check and only add if not nullptr | |
| lldb/tools/lldb-vscode/JSONUtils.cpp | ||
|---|---|---|
| 925 | i had to change this because std::string(nullptr) throws on my machine | |
| lldb/tools/lldb-vscode/JSONUtils.cpp | ||
|---|---|---|
| 925 | Yes, the std::string constructor taking a const CharT* expects a null terminated C-string. | |
clang-tidy: error: 'lldb/API/SBModule.h' file not found [clang-diagnostic-error]
not useful