================
@@ -840,10 +840,12 @@ def test_get_values(self):
self.assertTrue(variables.IsValid())
self.assertTrue(variables.GetValueAtIndex(0).name == "_handler_one")
- # FIXME: Synthetic variables are never in scope.
+ # Synthetic variables are always in scope.
variables = frame0.GetVariables(False, False, False, True)
----------------
Nerixyz wrote:
> The only True you are passing here is to the last argument to GetVariables:
> "in scope only". But that doesn't actually specify any variables to get. It
> just says, for instance "If Locals is true and the current context has a
> variable called `foo` that is shadowed by a variable `foo` in an outer scope,
> then should you return ONLY the `foo` that's currently visible, or should you
> return both.
There's a hidden `True` here -
[`SetIncludeSynthetic(True)`](https://github.com/llvm/llvm-project/blob/c64ec3766d72ab552957827b5a96cc50ed6c7182/lldb/source/API/SBFrame.cpp#L667-L668)
(from https://github.com/llvm/llvm-project/pull/198088). We then return
`_handler_one` (`eValueTypeConstResult | ValueTypeSyntheticMask`), because
`is_synthetic` is true:
https://github.com/llvm/llvm-project/blob/3e04cdb3e977951679cfffdbb602cebc5925c4e7/lldb/source/API/SBFrame.cpp#L737-L742
My assumption in the linked PR, #198088, was that synthetic variables are
always local. The goal there and here was to show the variables as locals in
lldb-dap, because it's unintuitive that they show in `frame variable` but not
the variables view.
I think the bigger question here is what value type synthetic variables should
have. Right now, they inherit the type from their parent. Above, `_handler_one`
was the result of `CreateValueFromExpression`, so it's a const result.
I'm concerned that this isn't always correct or expected. In the context of
providing locals from VMs for scripting languages, you could imagine multiple
ways of getting to them. For example, in Lua where it experimented with it, you
usually have a `lua_State*` or `Closure*` argument/local somewhere. From that,
you can get to the locals for the specific frame. But you could also get to the
global variables from this variable. If the synthetic variable just inherited
the "parent" type as it does now, you couldn't distinguish between locals and
globals. I'm not sure what the best way to handle this is.
Maybe @bzcheeseman has some thoughts on this?
https://github.com/llvm/llvm-project/pull/204177
_______________________________________________
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
