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
[email protected]
On 10/03/2013 05:16 PM, Sean Callanan wrote:
Richard,
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 :) ) 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.
Sean
On Oct 3, 2013, at 5:00 PM, Richard Mitton <[email protected]> wrote:
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.
--
Richard Mitton
[email protected]
_______________________________________________
lldb-dev mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
_______________________________________________
lldb-dev mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
