[lldb][tests] Automatically call compute_mydir (NFC)Eliminate boilerplate of having each test manually assign to `mydir` by calling`compute_mydir` in lldbtest.py.Differential Revision: https://r
[lldb][tests] Automatically call compute_mydir (NFC)Eliminate boilerplate of having each test manually assign to `mydir` by calling`compute_mydir` in lldbtest.py.Differential Revision: https://reviews.llvm.org/D128077
show more ...
[lldb] Add support for using variables with C++ keywords names in non-C++ expressionsLLDB is currently always activating C++ when parsing expressions as LLDB itselfis using C++ features when creat
[lldb] Add support for using variables with C++ keywords names in non-C++ expressionsLLDB is currently always activating C++ when parsing expressions as LLDB itselfis using C++ features when creating the final AST that will be codegen'd(specifically, references to variables, namespaces and using declarations areused).This is causing problems for users that have variables in non-C++ programs (e.g.plain C or Objective-C) that have names which are keywords in C++. Expressionsreferencing those variables fail to parse as LLDB's Clang parser thinks thoseidentifiers are C++ keywords and not identifiers that may belong to adeclaration.We can't just disable C++ in the expression parser for those situations asreplacing the functionality of the injected C++ code isn't trivial. So thispatch is just disabling most keywords that are exclusive to C++ in LLDB's Clangparser when we are in a non-C++ expression. There are a few keywords we can'tdisable for now:* `using` as that's currently used in some situations to inject variables into the expression function.* `__null` as that's used by LLDB to define `NULL`/`Nil`/`nil`.Getting rid of these last two keywords is possible but is a large enough changethat this will be handled in follow up patches.Note that this only changes the keyword status of those tokens but this patchdoes not remove any C++ functionality from the expression parser. The typesystem still follows C++ rules and so does the rest of the expression parser.There is another small change that gives the hardcoded macro definitions in LLDBa higher precedence than the macros imported from the Objective-C modules. Thereason for this is that the Objective-C modules in LLDB are actually parsed inObjective-C++ mode and they end up providing the C++ definitions of certainsystem macros (like `NULL` being defined as `nullptr`). So we have to move theLLDB definition forward and surround the definition from the module with an`#ifdef` to make sure that we use the correct LLDB definition that doesn'treference C++ keywords. Or to give an example, this is how the expression sourcecode changes:Before:``` #define NULL (nullptr) // injected module definition #ifndef NULL #define NULL (__null) // hardcoded LLDB definition #endif```After:``` #ifndef NULL #define NULL (__null) // hardcoded LLDB definition #endif #ifndef NULL #define NULL (nullptr) // injected module definition #endif```Fixes rdar://10356912Reviewed By: shafikDifferential Revision: https://reviews.llvm.org/D82770