<div dir="ltr">Thanks for details! So at first I'll try to propagate the "language" setting of an expression there.</div><br><div class="gmail_quote"><div dir="ltr">On Wed, Oct 31, 2018 at 9:04 PM Jim Ingham <<a href="mailto:jingham@apple.com">jingham@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>
<br>
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.<br>
<br>
So for instance, if you do:<br>
<br>
(lldb) expression --language c++ -- id<br>
<br>
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.<br>
<br>
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.<br>
<br>
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++.<br>
<br>
But the first stage is to make sure we are paying attention to the explicit language of the expression throughout the expression parser code.<br>
<br>
Jim<br>
<br>
<br>
> On Oct 31, 2018, at 7:25 AM, Zachary Turner <<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>> wrote:<br>
> <br>
> 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).<br>
> <br>
> But since ObjC assumptions are baked into several places, this has potential to break some things <br>
> On Wed, Oct 31, 2018 at 6:54 AM Aleksandr Urakov <<a href="mailto:aleksandr.urakov@jetbrains.com" target="_blank">aleksandr.urakov@jetbrains.com</a>> wrote:<br>
> 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...<br>
> <br>
> On Wed, Oct 31, 2018 at 4:32 PM Zachary Turner <<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>> wrote:<br>
> 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<br>
> <br>
> I wish ObjC assumptions weren’t so deeply embedded, but alas it is the case.<br>
> <br>
> Hopefully Jim or someone has ideas on how to fix this properly. <br>
> On Wed, Oct 31, 2018 at 5:08 AM Aleksandr Urakov <<a href="mailto:aleksandr.urakov@jetbrains.com" target="_blank">aleksandr.urakov@jetbrains.com</a>> wrote:<br>
> Hello,<br>
> <br>
> 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?<br>
> <br>
> Regards,<br>
> Alex<br>
> <br>
> On Wed, Oct 24, 2018 at 7:14 PM Aleksandr Urakov <<a href="mailto:aleksandr.urakov@jetbrains.com" target="_blank">aleksandr.urakov@jetbrains.com</a>> wrote:<br>
> Hi all!<br>
> <br>
> 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.<br>
> <br>
> For example for the next code:<br>
> int main() {<br>
>   int x = 5;<br>
>   int id = 7;<br>
>   int y = 8;<br>
>   return 0;<br>
> }<br>
> 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'`.<br>
> <br>
> Do you have any ideas, how can we fix it?<br>
> <br>
> Regards,<br>
> Alex<br>
> <br>
> <br>
> -- <br>
> Aleksandr Urakov<br>
> Software Developer<br>
> JetBrains<br>
> <a href="http://www.jetbrains.com" rel="noreferrer" target="_blank">http://www.jetbrains.com</a><br>
> The Drive to Develop<br>
> <br>
> <br>
> -- <br>
> Aleksandr Urakov<br>
> Software Developer<br>
> JetBrains<br>
> <a href="http://www.jetbrains.com" rel="noreferrer" target="_blank">http://www.jetbrains.com</a><br>
> The Drive to Develop<br>
<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>Aleksandr Urakov</div><div><span>Software Developer</span></div><div><span>JetBrains</span></div><div><span><a href="http://www.jetbrains.com" target="_blank">http://www.jetbrains.com</a></span></div><div><span>The Drive to Develop</span></div></div></div>