[Lldb-commits] [PATCH] D105470: [lldb] Clear children of ValueObject on value update

[Andy Yankovsky via Phabricator via lldb-commits]

werat added a comment.

Thanks for the explanation! But at this point I feel I'm a bit confused about how it all _supposed_ to work in the current design :)

If I understand correctly, there are four "types" of values from the user (API) perspective:

1. `ExpressionResult` -- value returned by `SBFrame::EvaluateExpression()`
2. `ExpressionPersistentVariable` -- value created by the expression via `auto $name = ...` syntax. Can be obtained by `SBFrame::FindValue("$name", lldb::eValueTypeConstResult)`.
3. "Const value" -- value created by `SBTarget::CreateValueFromData()` or `SBTarget::CreateValueFromAddress`
4. "Variable reference" -- value returned by `SBFrame::FindVariable()`

For which of these value the following test is supposed to work?

  struct Foo { int x; };
  Foo* f1 = { .x = 1}
  Foo* f2 = { .x = 2}  # pseudo-C for simplicity
  
  f1_ref = ...  # Get a value that holds the value of `f1` using one of the four methods described above
  print(f1_ref.GetChild(0))  # '1'
  f1_ref.SetValueFromCString(frame.FindVariable('f2').value)
  print(f1_ref.GetChild(0))  # '2'

My experiments show that it works for "variable references" and "const values" created by `CreateValueFromAddress` (but _not_ `CreateValueFromData`).
If I understand your comment correctly, you're saying it should work only for `ExpressionPersistentVariable` values (#2). Is that right?

I don't have the full picture about the internal implementation and all the use cases, but as a user I would expect it to work for at least #2, #3 and #4. Afaik there's no API to fully distinguish between these kinds of values, so I find it confusing why `SBValue::SetData()` would be allowed for some values and not allowed for others. If I can create a value using `CreateValueFromData` and then there's a method `SetValueFromCString`, then I don't see why it should not be allowed (apart from implementation complexity/consistency reasons).

What do you think? How should we proceed with this?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D105470/new/

https://reviews.llvm.org/D105470