[libcxx-commits] [PATCH] D113244: Simplify the libcxx std::string_view gdb pretty printer

David Blaikie via Phabricator via libcxx-commits libcxx-commits at lists.llvm.org
Mon Nov 22 16:49:28 PST 2021


dblaikie added a comment.

In D113244#3144020 <https://reviews.llvm.org/D113244#3144020>, @saugustine wrote:

> The google internal absl::string_view printer included the length prior to the standardization of string_view, and we didn't contribute those pretty printers to libstdc++ when it was standardized, so some of this is simply an old choice that didn't get propagated to libstdc++. The original formatting is useful to see that you are working with a non-null terminated string_view.
>
> What motivates the change? Just compatibility with libstdc++?

I /think/ the chain of logic that brought me here was...

1. Fixing `StringRef`s pretty printer to respect the `elements` limit after 6a9063743bbd5b0cf5f7b373f9372d458f726416 had broken that support
2. Trying libc++'s `std::string_view` pretty printer for `StringRef`, but that broke `llvm::Twine`'s pretty printer which built on top of it (`llvm::Twine`'s pretty printer no longer builds on top of `StringRef` since `StringRef` gets normalized along with other pointer/length pair representations, like `SmallString`) because `llvm::Twine` would try to build a longer string out of the contents of each part, but the prefix and quotations, etc, would end up in that longer string

So from all that it seemed best for composability to have string-ish types pretty print using the string hint, rather than a more customized rendering. Means other pieces of UI work well - in terms of element inspection, etc. Parameter's of string_view will print out more simply/tersely, etc.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D113244/new/

https://reviews.llvm.org/D113244



More information about the libcxx-commits mailing list