Make the existing libc++ formatter generic Add initializer_list summary provider. Add test for `libstdcpp`
We've been seeing (rare) crashes from both `CPlusPlusLanguage::SymbolNameFitsToLanguage` and `ObjCLanguage::SymbolNameFitsToLanguage` when we try to read contents of the `ConstString`s of the `Mangled` parameter. I'm not entirely sure how that can happen (current theory is corrupted stack somehow which overwrites `ConstString::m_string` to an invalid pointer) but I'm not able to confirm that. One thing these crashes had in common is that they operate on the `Mangled` object we copied into `SymbolNameFitsToLanguage` by value. While I can't see off the top why that would cause it to contain unintiailized/corrupt `ConstString`s, the class is sufficiently large enough to probably pass it by `const &` anyway. This is what this patch does. rdar://164519648
We've been seen (very sporadic) lifetime issues around this area. Here's an example backtrace: ``` [ 8] 0x0000000188e56743 libsystem_platform.dylib`_sigtramp + 55 [ 9] 0x00000001181e041f LLDB`lldb_private::CPlusPlusLanguage::SymbolNameFitsToLanguage(lldb_private::Mangled) const [inlined] unsigned long std::1::constexpr_strlen[abi:nn200100]<char>(char const*) + 7 at constexpr_c_functions.h:63:10 [ 9] 0x00000001181e0418 LLDB`lldb_private::CPlusPlusLanguage::SymbolNameFitsToLanguage(lldb_private::Mangled) const [inlined] std::__1::char_traits<char>::length[abi:nn200100](char const*) at char_traits.h:232:12 [ 9] 0x00000001181e0418 LLDB`lldb_private::CPlusPlusLanguage::SymbolNameFitsToLanguage(lldb_private::Mangled) const [inlined] llvm::StringRef::StringRef(char const*) at StringRef.h:90:33 [ 9] 0x00000001181e0418 LLDB`lldb_private::CPlusPlusLanguage::SymbolNameFitsToLanguage(lldb_private::Mangled) const [inlined] llvm::StringRef::StringRef(char const*) at StringRef.h:92:38 [ 9] 0x00000001181e0418 LLDB`lldb_private::CPlusPlusLanguage::SymbolNameFitsToLanguage(lldb_private::Mangled) const + 20 at CPlusPlusLanguage.cpp:68:62 ``` Looks like we're calling `strlen` on a nullptr. I stared at this codepath for a while but am still not sure how that could happen unless the underlying `ConstString` somehow pointed to corrupted data. But `SymbolNameFitsToLanguage` does some roundtripping through a `const char*` before calling `GetManglingScheme`. No other callsite does this and it just seems redundant. This patch cleans this up. rdar://161128180
This avoids the following kind of warning with GCC:
warning: control reaches end of non-void function [-Wreturn-type]
C++11 allows the use of Universal Character Names (UCNs) in identifiers, including function names. According to the spec the behavior of std::isalpha(ch) and std::isalnum(ch) is undefined if the argument's value is neither representable as unsigned char nor equal to EOF. To use these functions safely with plain chars (or signed chars), the argument should first be converted to unsigned char.
This came up in https://github.com/llvm/llvm-project/issues/155691. For `std::basic_string` our formatter matching logic required the allocator template parameter to be a `std::allocator`. There is no compelling reason (that I know of) why this would be required for us to apply the existing formatter to the string. We don't check the `allocator` parameter for other STL containers either. This meant that `std::string` that used custom allocators wouldn't be formatted. This patch relaxes the regex for `basic_string`.
Part of https://github.com/llvm/llvm-project/pull/149827 Allows us to use the mangling substitution facilities in CPlusPlusLanguage but also SymbolFileDWARF. Added tests now that they're "public".
The current implementation of CPlusPlusLanguage::SymbolNameFitsToLanguage will return true if the symbol is mangled for any language that lldb knows about.
This way all the tracking is self-contained in `TrackingOutputBuffer` and we can test the `SuffixRange` properly.
This way we make sure that the logic to reconstruct demangled names in the tests is the same as the logic when reconstructing the actual frame-format variable. `DemangledNameInfo::SuffixRange` is currently the only one which we can't test in the same way until we set it from inside the `TrackingOutputBuffer`. I added TODOs to track this.