Besides adding the formatter and the summary, this makes the libcxx
tests also work for this case.
This is the polished version of https://reviews.llvm.org/D114266,
authored by Danil Stefaniuc.
Paths
| Differential D114403
[formatters] Add a formatter for libstdc++ optional ClosedPublic Authored by wallace on Nov 22 2021, 3:33 PM.
Details Summary Besides adding the formatter and the summary, this makes the libcxx This is the polished version of https://reviews.llvm.org/D114266,
Diff Detail
Event TimelineThis revision is now accepted and ready to land.Nov 22 2021, 3:34 PM This revision was landed with ongoing or failed builds.Nov 22 2021, 3:36 PM Closed by commit rGe3dea5cf0e32: [formatters] Add a formatter for libstdc++ optional (authored by Walter Erquinigo <wallace@fb.com>). · Explain Why This revision was automatically updated to reflect the committed changes. Comment Actions I'm seeing some very funky behavior after this patch. My machine has both libc++ and libstdc++, so both versions of this test run normally, and then libstdc++ fails. If I run just the libstdc++ version then it passes just fine. If I change the test order so that the libstdc++ version is run first, then the *libc++* version fails instead...
Revision Contents
Diff 389058 lldb/bindings/interface/SBValue.i
lldb/examples/synthetic/gnu_libstdcpp.py
lldb/include/lldb/API/SBValue.h
lldb/source/API/SBValue.cpp
lldb/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp
lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/optional/Makefile
lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/optional/TestDataFormatterGenericOptional.py
lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/optional/main.cpp
lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/optional/Makefile
lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/optional/TestDataFormatterLibcxxOptional.py
lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/optional/main.cpp
|
I assume this is relying on the fact that _M_engaged can only contain values 1 and 0. While this may be true for normal situations, people tend to use debuggers precisely in the situations where things are not "normal". And it'd be good if e.g. a user's memory corruption bug (which for example overwrites this field) does not make the debugger go haywire. You most likely cannot format the value correctly if that happens, but you can at least avoid printing 3195786238 children in those cases.
One way to do that would be to rename this field to engaged and implement the num_children method as return self.engaged ? 1 : 0