Detection of expression language

Hi all,

The following code fails when asking lldb to run the command "(lldb) expr id"
     int main() {
         int id = 4;
         return 0;

The reason is because lldb tries to evaluate the expression as Objective C++, rather than C. And in Objective C++, "id" is a builtin type, and so conflicts with our local variable.

I'm thinking the correct fix is to evaluate expressions in the language of the current scope, but I just wanted to throw this out there and check before I go off and try to fix it.

One possible problem of using the current scope's language is that if you had a program that mixed languages (e.g. C++ and ObjC in different files), you wouldn't be able to evaluate any ObjC expressions while you were in a C++ function.


thanks for having a look at this!

I completely agree that this should happen. However, there are currently several reasons why making the change you suggest will be hard.

1. SymbolFileDWARF generates CXXRecordDecls for every record declaration. This is because, in C++, Clang expects all records to use the CXXRecordDecl data structure. In C, we would have to use plain RecordDecls because Clang in C mode expects that. I’m not sure the type system would take kindly to having different versions of the same type for C and C++ mode; we’d probably have to have duplicate ClangASTContexts, one in C mode and one in C++ mode.

2. The expression parser itself relies heavily on the C++ reference type for its operation. The reason you can type “a + b” and have accesses to these relayed as if through a pointer to the versions of a and b in your program is because LLDB uses C++ references behind the scenes. We do not want people to have to explicitly dereference pointers or anything like that.

The most likely (to my mind! a Clang developer might have different opinions here :slight_smile: ) solution to this will probably involve changing Clang itself to allow parsing with C syntax but with C++ semantics under the hood.

If you’re still interested in digging into making this work purely on LLDB’s side, I’d be very excited to see what solutions you come up with. But be aware that this is much harder than just passing the right language options in the right place.


I think for the purposes of expression evaluation, it would be OK to treat C and C++ as being the same language, and just worry about C/C++ vs other languages (ObjC, and in future perhaps Go/D/etc)

Richard Mitton

C & C++ differ by a bunch of reserved words. Folks that name their variables "new" and "template" other such things do need C and C++ to be treated separately. This doesn't come up often, but we do have a bunch of bugs internally from folks who have been bitten by this.