[Lldb-commits] [lldb] [lldb][Expression] Reject languages not supported by TypeSystems for expression evaluation (PR #156648)

[via lldb-commits]

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