History log of /llvm-project/lldb/test/API/python_api/sbvalue_synthetic/main.cpp (Results 1 – 2 of 2)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init
# 3068d277 19-Dec-2023 Pavel Labath <pavel@labath.sk>

[lldb] Fix TestSBValueSynthetic on windows (#75908)

We don't have a std::vector formatter on windows, so use a custom
formatter in this test to avoid relying on std::vector.


# 927926b8 18-Dec-2023 Pavel Labath <pavel@labath.sk>

[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
d

[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.

show more ...