jimingham wrote:
> > I don't remember how that works in swift, but note, there are two separate
> > issues with the C family expression parser. One was making local
> > declarations override ivar references in name resolution in the context of
> > the expression. That is why we inject variables into the expression by hand
> > (and is controlled by the target.experimental.inject-local-vars setting).
> > That's not even necessary, IIRC it's to work around the side effect of the
> > too much optimizing of the DWARF.
>
> I don't believe that has anything to do with DWARF -- the debug info
> describes that situation perfectly. The problem is that when you have code
> like
>
> ```
> struct Foo {
> int bar;
> void foo() { int bar; ...; }
> };
> ```
>
> if you stop in `foo` and go `expr bar`, per c++ rules, you'd expect to see
> the local variable, but clang will not even ask us what `bar` is because it
> will assume you're referring to the member variable. Injecting the local
> variable into the expression forces clang to ask us what
> `__lldb_local_vars::bar` is.
>
> That said, C doesn't have methods, so maybe this isn't an issue there.
>
> > But the more important C++ requirement is that we use it to make the
> > expression
> > local_or_global_variable = 100
> > work correctly without having to pass variable references into the
> > expression from a separate context as a pointer, which would require that
> > behind the user's back we would be munging this expression to:
> > *local_or_global_variable_pointer = 100
> > We wanted to avoid having to do that everywhere, and the solution to that
> > was to use C++ references when a variable was mentioned in an expression.
> > That's the harder bit you are going to have to solve to get rid of C++ in
> > the basic C-family expression evaluator.
>
> Yes, this sounds like a more complicated issue. Perhaps we could fake it by
> pretending `bar` is a global variable and then rewriting the access in the
> resulting IR (I think we do something similar for function calls already)?
Clang already has all the code to do this, it just only allows it for C++. So
the other option would be to allow C with references. That's obviously not a
language feature clang wants to expose, but might be a more robust way of
handling this than going in to do surgery to the IR after the face.
https://github.com/llvm/llvm-project/pull/156648
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
