[Lldb-commits] [PATCH] D79554: [lldb/Dataformatter] Add support to CF{Dictionary, Set}Ref types

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

In D79554#2026999 <https://reviews.llvm.org/D79554#2026999>, @teemperor wrote:

> I don't see a huge problem with things like `__lldb_autogen_nspair` as it's a single obviously generated type hardcoded into LLDB. But this really generic approach here can generate all kind of structs whenever some formatter decides that some random incomplete record has a synthetic value.
>
> But in any case, I think we're kind of talking about different problems here. We do have the following type:
>
>   TypedefType 0x7fc9cd04f440 'CFDictionaryRef' sugar
>   |-Typedef 0x7fc9cd04f3e0 'CFDictionaryRef'
>   `-PointerType 0x7fc9cd04f3a0 'const struct __CFDictionary *'
>     `-QualType 0x7fc9cd04f381 'const struct __CFDictionary' const
>       `-RecordType 0x7fc9cd04f380 'struct __CFDictionary'
>         `-CXXRecord 0x7fc9cd04f2d0 '__CFDictionary'
>
>
> So we do have an underlying type for `*CFDictionaryRef` which is just the `__CFDictionary` record. The problem is just that this is an incomplete type. So we could make a ValueObject that has an incomplete struct type which seems to work for me just fine? We probably need to adjust the formatter for this prints an actual empty value: `(const __CFDictionary) *dict = {}`


That's exactly what I was thinking. As the CompilerType abstraction is already capable of representing incomplete types, and our goal is to construct synthetic children ( == ValueObjects) for these types, then it seems reasonable for ValueObjects to operate on these incomplete types. I mean, one won't be able to do much with them, but it should be possible to take their address and then grovel in that memory, or cast it to something else (and I assume that's what these pretty printers will be doing).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79554