Michael137 wrote: > If we're still producing the typedef-style DWARF for these alias template > specializations - perhaps lldb could not cache pretty printers for typedefs? > (I guess the pretty printers shouldn't be typedef-specific, right, since > typedefs are transparent anyway - but I guess maybe pretty printers can be > typedef-specific because typedefs can be intended to communicate what kind of > a thing is and possibly how to render it?) - it'll cache teh pretty printer > for the underlying type anyway, yeah?
Basically what was happening is that LLDB saw the new `std::removecv_ref_t<value_type>` member of `std::optional`, which resolved to `std::string`. Then formatted it as `std::string`. And then cached the `DW_AT_name`, i.e., `std::removecv_ref_t<value_type>`, to point to the `std::string` formatter. But that meant that the next time we saw a `std::removecv_ref_t<value_type>` (even if it didn't resolve to `std::string`) would use the cached formatter. The reason this patch works around that situation is that now the `DW_AT_name` will have the canonical type in `DW_AT_name`, not the unresolved `std::removecv_ref_t<value_type>`. @jimingham will be able to speak more confidently about LLDB's intention here but I think caching typedefs is intentionally supported. Jim and I came to the conclusion yesterday that we probably don't want to cache template specializations. I think we can (and should) fix the caching behaviour, but that would be a longer undertaking and I wanted to unblock the libc++ patch (https://github.com/llvm/llvm-project/pull/110355) as soon as possible. It's on my list of follow-ups to reland this and fix the cache (and also investigate what it would take to support `DW_TAG_template_alias` in LLDB, so we can enable those by default). https://github.com/llvm/llvm-project/pull/110767 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
