[all-commits] [llvm/llvm-project] a8350c: [lldb] Add support for using variables with C++ ke...

[Raphael Isemann via All-commits]

  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: a8350ce79d167643b53d06e2167535d24fe68dc3
      https://github.com/llvm/llvm-project/commit/a8350ce79d167643b53d06e2167535d24fe68dc3
  Author: Raphael Isemann <teemperor at gmail.com>
  Date:   2020-11-16 (Mon, 16 Nov 2020)

  Changed paths:
    M lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
    M lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionSourceCode.cpp
    M lldb/source/Plugins/ExpressionParser/Clang/ClangModulesDeclVendor.cpp
    M lldb/source/Plugins/ExpressionParser/Clang/ClangModulesDeclVendor.h
    A lldb/test/API/lang/c/cpp_keyword_identifiers/Makefile
    A lldb/test/API/lang/c/cpp_keyword_identifiers/TestCppKeywordsAsCIdentifiers.py
    A lldb/test/API/lang/c/cpp_keyword_identifiers/main.c
    A lldb/test/API/lang/cpp/keywords_enabled/TestCppKeywordsEnabled.py
    A lldb/test/API/lang/cpp/struct_with_keyword_name/Makefile
    A lldb/test/API/lang/cpp/struct_with_keyword_name/TestStructWithKeywordName.py
    A lldb/test/API/lang/cpp/struct_with_keyword_name/main.c
    A lldb/test/API/lang/objc/cpp_keyword_identifiers/Makefile
    A lldb/test/API/lang/objc/cpp_keyword_identifiers/TestCppKeywordsAsObjCIdentifiers.py
    A lldb/test/API/lang/objc/cpp_keyword_identifiers/main.m
    M lldb/test/API/lang/objc/modules/TestObjCModules.py
    A lldb/test/API/lang/objcxx/cpp_keywords_enabled/TestObjCppKeywordsEnabled.py

  Log Message:
  -----------
  [lldb] Add support for using variables with C++ keywords names in non-C++ expressions

LLDB is currently always activating C++ when parsing expressions as LLDB itself
is using C++ features when creating the final AST that will be codegen'd
(specifically, references to variables, namespaces and using declarations are
used).

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++. Expressions
referencing those variables fail to parse as LLDB's Clang parser thinks those
identifiers are C++ keywords and not identifiers that may belong to a
declaration.

We can't just disable C++ in the expression parser for those situations as
replacing the functionality of the injected C++ code isn't trivial. So this
patch is just disabling most keywords that are exclusive to C++ in LLDB's Clang
parser when we are in a non-C++ expression. There are a few keywords we can't
disable 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 change
that this will be handled in follow up patches.

Note that this only changes the keyword status of those tokens but this patch
does not remove any C++ functionality from the expression parser. The type
system 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 LLDB
a higher precedence than the macros imported from the Objective-C modules. The
reason for this is that the Objective-C modules in LLDB are actually parsed in
Objective-C++ mode and they end up providing the C++ definitions of certain
system macros (like `NULL` being defined as `nullptr`). So we have to move the
LLDB definition forward and surround the definition from the module with an
`#ifdef` to make sure that we use the correct LLDB definition that doesn't
reference C++ keywords. Or to give an example, this is how the expression source
code 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://10356912

Reviewed By: shafik

Differential Revision: https://reviews.llvm.org/D82770