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

[via lldb-commits]

jimingham wrote:


> On Jan 27, 2025, at 5:30 AM, Pavel Labath ***@***.***> wrote:
> 
> 
> If I was holding a vector as a vector**, then I would would to see its summary/size as well. And maybe even the children too. But the thing I questioning is how often does one hold a C++ container as a double pointer. Is there like some common programming pattern that produces those? The only time I've ever done that is when I was experimenting with how "frame variable" handles pointers and references. I have seen and worked with double pointers, but this was always in some kind of legacy/C context. A combination of double pointers and a std::vector (which essentially makes it a triple pointer) would be very.. eclectic here. Modern C++ would likely turn at least one of those pointers into an iterator, or a smart pointer, or a reference..
> 
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 true that a summary provider is less intrusive (it doesn't override existing children -- though it can hide them!), than a synthetic child provider, but I think it would be very confusing to have different behavior here. 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.  But given one can write a regex matcher to implement more general formatters, so long as the limitations of the normal formatter matching is clearly spelled out, I'll go along with whatever the consensus is here.

Jim

> —
> Reply to this email directly, view it on GitHub <https://github.com/llvm/llvm-project/pull/124048#issuecomment-2615768600>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADUPVW77ZSDPBSJIY5Y7S7T2MYYG7AVCNFSM6AAAAABVWKKJIKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMMJVG43DQNRQGA>.
> You are receiving this because you were mentioned.
> 



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