[Lldb-commits] [PATCH] D11790: Fix ObjC++ types Class and id being defined in C and C++ expressions.

[Sean Callanan via lldb-commits]

spyffe requested changes to this revision.
spyffe added a comment.
This revision now requires changes to proceed.

Ooh, I'm reading the patch at the beginning of ClangUserExpression::Evaluate again and it does look like this patch sets language based on the language of the containing frame, and that affects what language the expression is parsed in.

I don't think it's appropriate to force the expression parser out of Objective-C or C++ mode in non-ObjC frames, because it's entirely possible for a user to want to run Objective-C (or C++ code) from frames in a different language.  For example, it is often the case that a user will want to call [NSApplication sharedApplication] in an app, even if they are in C/C++ code.

For the same reason I think the idea of a target-level language isn't the right approach.  Rather, I think there should be a setting that says "force all expressions to this language by default" that the user can set if they're debugging a process that prefers a particular language.  By default, this setting would be Objective-C++ – but for cases where the user is expecting to deal mostly with pure C++ binaries, that can be switched to C++.  It might even be something that could be set on a per-platform basis.

Be aware (as I usually warn) that you will get a broken expression parser if you try to force it to use only C.  The expression parser uses references internally to allow you to use local variables without dereferencing pointers.  We want to get Clang support for a "C-language reference" of some sort eventually, but until that happens you need to at least enable C++.


http://reviews.llvm.org/D11790