[PATCH] D65633: [Object] Create MutableELFObject Class for Doing Mutations on ELFObjectFiles [Part 3]

Sam McCall via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Aug 21 01:31:55 PDT 2019


sammccall added a comment.

In D65633#1638796 <https://reviews.llvm.org/D65633#1638796>, @labath wrote:

> In D65633#1638673 <https://reviews.llvm.org/D65633#1638673>, @abrachet wrote:
>
> > I've been using `::testing::ElementsAre(...)` against a vector of `StringRef` a lot, when it fails the output is really bad. Like this: `element #1 is equal to { '.' (46, 0x2E), 's' (115, 0x73), 'e' (101, 0x65), 'c' (99, 0x63), '0' (48, 0x30) },` Is there a way to provide formatting for types to gtest? Or should I just be using `const char *`?
>
>
> Yeah, there is <https://github.com/google/googletest/blob/master/googletest/docs/advanced.md#teaching-googletest-how-to-print-your-values>. It involves writing either an `operator<<` or a `PrintTo` function. The StringRef class already has an operator<<, but the problem here is that gtest wants to print it as a container instead of using that operator<<. I don't know if there's anything we can do here, but @sammccall might.


Right, the sequence is:

- PrintTo() is found by overload resolution, if there's no specialized version, it falls back to the generic template
- the generic template checks whether it's a container (by looking for nested `iterator` and `const_iterator` types)
- for non-containers, it attempts to use `operator<<` if it exists, falling back to "n-byte object XX-XX-XX-XX" otherwise
- for containers, it prints each element in the same manner

So overloading operator<< doesn't bypass the container detection, but overloading PrintTo() does. And this is what gtest does for std::string, in gtest-printers.h. I think we should do the same as a local modification to `internal/custom/gtest-printers.h`.

> If it bothers you too much you can use a `vector<string>` on the LHS of the match ( i wouldn't use `const char *` because I am not sure if the returned StringRefs are guaranteed to be null terminated, and its best to not rely on that).

This has bothered at various times, but I never really investigated how to fix it. I'll try to put together a patch.


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

https://reviews.llvm.org/D65633





More information about the llvm-commits mailing list