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
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
