Another way to think about this is if you have a SBValue that represents a
class instances in an IDE, if no one turns it open to see the children, why do
we need to complete the type? We should have to. The type should be able to
complete itself if and when we need to know some information. This already
works fine for classes, we just need to make it work for enums. Just complete
the type before we need access to the enumerators. For a SBValue that contains
a enum type:
SBValue var = frame.FindVariable("myEnumVar");
If I call:
SBType var_type = var.GetType();
"var_type" doesn't need be completed yet. Even:
const char *n = var_type.GetName();
Doesn't require a full type. Now for getting the value:
const char *value = var.GetValue();
We don't need to complete a class type as the class has no value. If this is a
pointer to anything (enum, class, struct, union) we don't need to complete the
type to show the pointer value. For an enum we do need it. But the type should
complete itself in the code that knows it needs to full type.
Asking the type about itself might also cause the type to complete itself:
auto num_fields = var_type.GetNumFields();
Would cause a class type to complete itself probably down in the TypeSystem
class (ClangASTContext).
So after thinking about this some more, the proposed fix you had was not the
right one. We just need to fix the ClangASTContext to complete the type before
it tries to use it.
Question: did you use the clang external AST source like the DWARF plug-in
stuff did to complete the types?
> On Nov 8, 2018, at 1:40 PM, Greg Clayton <clayb...@gmail.com> wrote:
>
> Looks like this test was testing the functionality that you changed. It it
> expecting that a type won't be complete until you ask for more info about it
> (like asking about a child). Since PDB is not completing the type up front,
> we need to change LLDB or make your previous case work even when handing out
> a forward type.
>
> So the question is: do we expect types to be able to complete themselves on
> the fly anywhere? I believe we should be able to hand out a type as a forward
> declaration and have it complete itself at any point when it is needed. I
> know classes already do this when they need to know more. Maybe the AST
> doesn't treat enums like classes where it will complete the type through the
> external AST class.
>
> The correct fix is to probably call
>
> bool CompilerType::GetCompleteType() const;
>
> Before you need to access the enumerators in an enumeration.
>
>
>
>> On Nov 8, 2018, at 1:17 PM, Zachary Turner via lldb-commits
>> <lldb-commits@lists.llvm.org <mailto:lldb-commits@lists.llvm.org>> wrote:
>>
>> +greg.
>>
>> Greg, is the test wrong here or the patch? If it’s the test let’s just fix
>> the test, otherwise we can revert the patch until we figure it out.
>>
>> It seems related to my change to use the layout type instead of the forward
>> type.
>>
>> On Thu, Nov 8, 2018 at 1:03 PM Davide Italiano <dccitali...@gmail.com
>> <mailto:dccitali...@gmail.com>> wrote:
>> On Thu, Nov 8, 2018 at 12:59 PM Zachary Turner <ztur...@google.com
>> <mailto:ztur...@google.com>> wrote:
>> >
>> > I’m ooo for at least 2 hours. Is it a test failure or a compilation
>> > failure?
>>
>>
>> FAIL: test_with_run_command_gmodules
>> (TestTypeCompletion.TypeCompletionTestCase)
>>
>> Check that types only get completed when necessary.
>> ----------------------------------------------------------------------
>> Traceback (most recent call last):
>> File
>> "/Users/davide/work/llvm-project-20170507/lldb/packages/Python/lldbsuite/test/lldbtest.py",
>> line 1744, in test_method
>> return attrvalue(self)
>> File
>> "/Users/davide/work/llvm-project-20170507/lldb/packages/Python/lldbsuite/test/decorators.py",
>> line 113, in wrapper
>> func(*args, **kwargs)
>> File
>> "/Users/davide/work/llvm-project-20170507/lldb/packages/Python/lldbsuite/test/functionalities/type_completion/TestTypeCompletion.py",
>> line 55, in test_with_run_command 'vector<T> complete but it should
>> not be')
>> AssertionError: True is not False : vector<T> complete but it should not be
>>
>>
>> Do you want me to revert this in the meanwhile?
>>
>> --Davide
>> _______________________________________________
>> lldb-commits mailing list
>> lldb-commits@lists.llvm.org <mailto:lldb-commits@lists.llvm.org>
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
>
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
