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.
Jim On Oct 5, 2013, at 9:56 AM, Richard Mitton <[email protected]> wrote: > 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 _______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
