[lldb-dev] `ClangASTSource::IgnoreName` C++ false positives

[Aleksandr Urakov via lldb-dev]

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

On Wed, Oct 31, 2018 at 9:04 PM Jim Ingham <jingham at apple.com> wrote:

> 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.
>
> Jim
>
>
> > On Oct 31, 2018, at 7:25 AM, Zachary Turner <zturner at google.com> wrote:
> >
> > 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
> > On Wed, Oct 31, 2018 at 6:54 AM Aleksandr Urakov <
> aleksandr.urakov at jetbrains.com> wrote:
> > 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...
> >
> > On Wed, Oct 31, 2018 at 4:32 PM Zachary Turner <zturner at google.com>
> wrote:
> > 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.
> > On Wed, Oct 31, 2018 at 5:08 AM Aleksandr Urakov <
> aleksandr.urakov at jetbrains.com> wrote:
> > Hello,
> >
> > 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?
> >
> > Regards,
> > Alex
> >
> > On Wed, Oct 24, 2018 at 7:14 PM Aleksandr Urakov <
> aleksandr.urakov at jetbrains.com> wrote:
> > 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?
> >
> > Regards,
> > Alex
> >
> >
> > --
> > Aleksandr Urakov
> > Software Developer
> > JetBrains
> > http://www.jetbrains.com
> > The Drive to Develop
> >
> >
> > --
> > Aleksandr Urakov
> > Software Developer
> > JetBrains
> > http://www.jetbrains.com
> > The Drive to Develop
>
>

-- 
Aleksandr Urakov
Software Developer
JetBrains
http://www.jetbrains.com
The Drive to Develop
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20181101/5d300f10/attachment.html>