labath 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)?
https://github.com/llvm/llvm-project/pull/156648
_______________________________________________
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
