teemperor requested changes to this revision.
teemperor added a comment.
This revision now requires changes to proceed.
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 = {}`
================
Comment at: lldb/source/Core/ValueObject.cpp:2853
+ ConstString g___lldb_opaque_ptr_type(
+ compiler_type.GetTypeName().AsCString());
+
----------------
teemperor wrote:
> This is the name of the typedef, not the underlying incomplete struct. So
> this creates a new empty record with the name of the typedef which seems
> weird. If we fake that some type is actually empty instead of incomplete,
> then I think the underlying struct makes more sense to emulate. Also this
> variable name is kinda weird with it's `g____` prefix even though it's not a
> global or a static.
This is still the name of the typedef:
```
lang=c++
child_compiler_type =
type_system->GetEmptyStructType(compiler_type.GetTypeName());
```
So we end up with an AST like we get from here:
```
lang=c++
typedef NSDictionary* CFDictionaryRef;
struct CFDictionaryRef {}; // conflict
```
This should at least have some kind of `__lldb_made_up_type_unique_stringy_`
prefix in the generated name to make this not ambiguous.
Also a log statement would be useful that we know when these types are created
when someone reports a bug.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D79554/new/
https://reviews.llvm.org/D79554
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
