[all-commits] [llvm/llvm-project] 927926: [lldb] Fix a quirk in SBValue::GetDescription (#75...

[Pavel Labath via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 927926b8af4fd6ab966b95d7b6eb31790758ced1
      https://github.com/llvm/llvm-project/commit/927926b8af4fd6ab966b95d7b6eb31790758ced1
  Author: Pavel Labath <pavel at labath.sk>
  Date:   2023-12-18 (Mon, 18 Dec 2023)

  Changed paths:
    M lldb/source/API/SBValue.cpp
    A lldb/test/API/python_api/sbvalue_synthetic/Makefile
    A lldb/test/API/python_api/sbvalue_synthetic/TestSBValueSynthetic.py
    A lldb/test/API/python_api/sbvalue_synthetic/main.cpp

  Log Message:
  -----------
  [lldb] Fix a quirk in SBValue::GetDescription (#75793)

The function was using the default version of ValueObject::Dump, which
has a default of using the synthetic-ness of the top-level value for
determining whether to print _all_ values as synthetic. This resulted in
some unusual behavior, where e.g. a std::vector is stringified as
synthetic if its dumped as the top level object, but in its raw form if
it is a member of a struct without a pretty printer.

The SBValue class already has properties which determine whether one
should be looking at the synthetic view of the object (and also whether
to use dynamic types), so it seems more natural to use that.