[Lldb-commits] [lldb] [lldb][Formatters] Do not recursively dereference pointer type when creating formatter candicates list. (PR #124048)

[Pavel Labath via lldb-commits]

labath wrote:

> If this were super difficult, I'd be uncomfortable about telling other people that their usages were too esoteric to support but willing to do so as a tradeoff. But I don't think it's a good idea to do that unless we have to. After all, you're basing the argument on common uses of vectors, but really it should be about "the usage of any data type someone might have pointers to, and want to see the summary of." We're providing the tools, not the uses.

It's not super-difficult, but it's not free either. In particular, any user-facing API we add to support this use case is something that we may have to live with for a very long time. If the uses are there, then so be it, but I don't think that's the case, which is why I'm asking if you (or anyone) knows of something like that (and also providing some reasons as to why I think it's unlikely to exist).



> > The thing I like about doing this for one level is that (as Zequan points out) it nicely matches what our SBValue API does, which makes most formatters "just work".

> I still don't see the force of this argument, it's just arguing by analogy.

It's not a killer argument for sure, but it's nice when things are consistent. I think this behavior is nice and consistent because the pretty printer does not have to worry about the kind of object it gets. It can just call `GetChildMemberWithName` and things will probably work. The current situation is a bit of a footgun, because you may not realize (or even want) that your formatter will work with double pointer values. And unless you're very thorough with testing, you won't even notice it until someone tries to print a double pointer and see that it prints bogus values. (And even they may not realize its a formatter problem -- they may think their program produces corrupt values).

> `type summary add` and friends don't have that many options. Adding a "pointer matching depth" option, and having --skip-pointers and `--pointer-match-depth` be in separate option groups so you can't accidentally provide them together would also work.

I don't know how easy would it be, but another option would be to keep a single option, but treat `true` and `false` as aliases for 1 and 0, respectively. That won't help with the python API though...

https://github.com/llvm/llvm-project/pull/124048