From #143177. This combines the summaries for the pre- and post C++ 11 `std::string` as well as `std::wstring`. In all cases, the data pointer is reachable through `_M_dataplus._M_p`. It has the correct type (i.e. `char*`/`wchar_t*`) and it's null terminated, so LLDB knows how to format it as expected when using `GetSummaryAsCString`.
Desugar any potential references/typedefs before checking `isStdTemplate`. Previously, the typename might've been: ``` const std::unordered_map<...> & ``` for references. This patch gets the pointee type before grabbing the canonical type. `GetNonReferenceType` will unwrap typedefs too, so we should always end up with a non-reference before we get to `GetCanonicalType`. https://github.com/llvm/llvm-project/issues/145847
The only difference from the original PR are the added BRIEF and FULL_DOCS arguments to define_property, which are required for cmake<3.23.
Upgrade the callees of `HandleFrameFormatVariable` (`GetDemangledTemplateArguments`, etc), to return a `llvm::Expected` instead of an `std::optional`. This patch also bundles the logic of validating the demangled name and information into a single reusable function to reduce code duplication.
Causes failures on several bots. This reverts commits 714b2fdf3a385e5b9a95c435f56b1696ec3ec9e8 and e7c1da7c8ef31c258619c1668062985e7ae83b70.
Some inter-plugin dependencies are okay, others are not. Yet others not, but we're sort of stuck with them. The idea is to be able to prevent backsliding while making sure that acceptable dependencies are.. accepted. For context, see https://github.com/llvm/llvm-project/pull/139170 and the attached changes to the documentation.
As part of https://github.com/llvm/llvm-project/pull/143177, I moved the non-libc++ specific formatting of `std::string`s out to `CxxStringTypes` as MSVC's STL `std::string` can also be thought of a pointer+size pair. I named this kind of string "string buffer". This PR picks that change, so the MSVC PR can be smaller. Unfortunately, libstdc++'s `std::string` does not fit this (it also uses a different string printer function). This resolves two FIXMEs in the libc++ tests, where empty u16 and u32 strings didn't have any prefix (u/U).
https://github.com/llvm/llvm-project/pull/143501 changes usage of `__hash_value_type` in libcxx to an empty tag type. This type will no longer have a definition in DWARF. Currently the LLDB unordered_map formatter deduces the map's `element_type` by looking at the `__cc_` member of `__hash_value_type`. But that will no longer work because we only have its forward declaration. Since what we're really after is the type that `__hash_value_type` is wrapping, we can just look at the `__hash_table::value_type` typedef. With https://github.com/llvm/llvm-project/pull/143501 that will now point to the `std::pair` element type (which used to be what we got from `__cc_`). TBD: need to double-check this works for older layouts. Quick glance at the code makes me suspicious of cases like `unordered_map<std::pair<int, int>, int>`
We have one library using this and three libraries directly calling `target_compile_options`. Might as well standardize on the latter.
This commit adjusts the pretty printer for `std::coroutine_handle` based on recent personal experiences with debugging C++20 coroutines: 1. It adds the `coro_frame` member. This member exposes the complete coroutine frame contents, including the suspension point id and all internal variables which the compiler decided to persist into the coroutine frame. While this data is highly compiler-specific, inspecting it can help identify the internal state of suspended coroutines. 2. It includes the `promise` and `coro_frame` members, even if devirtualization failed and we could not infer the promise type / the coro_frame type. Having them available as `void*` pointers can still be useful to identify, e.g., which two coroutine handles have the same frame / promise pointers.