`ClangASTSource::IgnoreName` C++ false positives

Hi all!

There are two hardcoded names to ignore in the ClangASTSource::IgnoreName function, “Class” and “id”, they are valid names for C++. It seems that they were added for the Objective-C case. But the problem is that when they are in locals they are blocking expressions evaluation.

For example for the next code:

int main() {

int x = 5;

int id = 7;

int y = 8;

return 0;


if you’ll break on return 0 and will try to print x, then you’ll get a error like no member named 'id' in namespace '$__lldb_local_vars'.

Do you have any ideas, how can we fix it?




I’ve tried to use a check like if (m_ast_context->getLangOpts().ObjC) ..., but it seems that it’s always true. How can we else determine here if the Objective-C case is used? Or if we can’t, where can we move if (name == id_name || name == Class_name) to make it Objective-C only? What regressions Objective-C users would have if we would remove this check from here?


It seems like we hit this issue in different contexts almost at the same time (see my thread several days ago about “problem formatting value objects”). That might at least give you some context about why things

I wish ObjC assumptions weren’t so deeply embedded, but alas it is the case.

Hopefully Jim or someone has ideas on how to fix this properly.

Sorry, I have somehow missed the discussion continuation there. Yes, it’s a very similar problem, thanks. But unfortunately no one of the workarounds mentioned there doesn’t work in this situation…

The first thing I would try is to see where the language is getting set to objective c and force it c++. Just as an experiment. Depending where it happens, it may be possible to initialize it from the debug info (or hardcode it).

But since ObjC assumptions are baked into several places, this has potential to break some things

We need to do more work to make sure the "language" setting for expressions gets propagated everywhere and obeyed. We could also be smarter about setting the default.

It seems fine to me for lldb to assume - if we know nothing different - that we should use ObjC++ as the language to compile expressions. That makes sense for most developers, since it only has a few collisions (Class and id) that seldom cause problems IRL and gives the widest coverage for of expressions. BUT... the behavior when compiling an expression should be determined by the expression's language rather than how we set up the target ScratchASTContext.

So for instance, if you do:

(lldb) expression --language c++ -- id

that should work, though without the --language you would get an error. That doesn't currently work, so apparently we aren't always checking the language of the expression.

The situation is a little more complicated than that because sometimes we check the frame's language (e.g. we do that in AddLocalVariableDecls, w/o checking whether the expression has a specific language. So this definitely needs cleaning up.

Then we should also let the Language Runtime's adjust the default language, so if you have a program that doesn't load the ObjC runtime, we set the default language to C++, not ObjC++.

But the first stage is to make sure we are paying attention to the explicit language of the expression throughout the expression parser code.


Thanks for details! So at first I’ll try to propagate the “language” setting of an expression there.