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

[Michael Buch via lldb-commits]

Michael137 wrote:

> The other scenario is accessing an extant C global variable (maybe even one you don't have debug info for) called "class" or "namespace". But more importantly, having this sort of secret out that is applied inconsistently will just make lldb more confusing. It's fine to say "the support for the 'C' language is incomplete" but to treat it inconsistently just makes it harder to understand how lldb is working for you.

That's a fair point. If we don't want to break this use-case, perhaps we should then think about not requiring C++ for expression evaluation. Once we do that, we can safely start rejecting any non-supported languages (and remove the C expression evaluation workarounds). The most notable feature we rely on is the `using` declaration to bring local variables into scope.

I wonder the Swift plugin handles those. This is an example wrapper expression it generates:
```
func $__lldb_expr(_ $__lldb_arg : UnsafeMutablePointer<Any>) {

do {
/*__LLDB_USER_START__*/
z = 50
/*__LLDB_USER_END__*/
} catch (let __lldb_tmp_error) {
  var $__lldb_error_result = __lldb_tmp_error
}
}
```
So it has some other hook to bring the local variables into scope that's not dependent on injecting something into the source

https://github.com/llvm/llvm-project/pull/156648