https://github.com/llvm/llvm-project/pull/147835 made changes that
caused libstdc++ std::string tests to fail:
```
======================================================================
FAIL: test_unavailable_summary_libstdcxx_dwo (TestDataFormatterStdString.StdStringDataFormatterTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 1805, in test_method
return attrvalue(self)
File "/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/llvm-project/lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/string/TestDataFormatterStdString.py", line 223, in test_unavailable_summary_libstdcxx
self.do_test_summary_unavailable()
File "/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/llvm-project/lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/string/TestDataFormatterStdString.py", line 213, in do_test_summary_unavailable
self.assertEqual(summary, "Summary Unavailable", "No summary for bad value")
AssertionError: '(null)' != 'Summary Unavailable'
- (null)
+ Summary Unavailable
: No summary for bad value
Config=aarch64-/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/bin/clang
----------------------------------------------------------------------
```
This test constructs an invalid std::string by starting with a null
pointer.
Somehow this improvement in Clang uncovered a bug in the formatter.
Perhaps because we now know the type of the field we tried to access is
char *, so fall back to a C string formatter that produces `(null)`.
The formatter tries to access `_M_p` and checked whether the resulting
ValueObjectSP was null, but not that it did not contain an error value.
I think that error value can be there if you are able to access one part
of the path, `_M_dataplus`, but another part fails. Since the layout
looks like this:
```
struct _Alloc_hider :
{
pointer _M_p; // The actual data.
};
_Alloc_hider _M_dataplus;
void
_M_data(pointer __p)
{ _M_dataplus._M_p = __p; }
```
So I think we were able to read `_M_dataplus` just by offset, but then
failed because it contains, or points to something containing nulls or a
null pointer.
Or perhaps an error value means we know what the class member is, but
could not read from it.
I found this by comparing with the libcxx formatter, so I've copied the
same handling from there to fix the issue.
f23d2ee5d5