<div dir="ltr"><br><div>I'm chasing a crash in lldb, and my current "that doesn't seem right" has to do with a conflict between a decl and its origin decl (the transformation done at the beginning of tools/lldb/source/Expression/ClangASTSource.cpp:ClangASTSource::layoutRecordType()).  So I'm trying to understand how decls and origin decls get setup during the symbol import process.  Can anyone give me a sketch/hand?  Specific questions include: </div>

<div>* There are multiple ASTContexts involved (e.g. the src and dst contexts in the signature of tools/lldb/source/Symbol/ClangASTImporter.cpp:ClangASTImporter::CopyType); do those map to compilation units, or to shared library modules?  Is there a simple way to tell what CU/.so an ASTContext maps to?</div>

<div>* Does a decl always have an origin decl, even if it was loaded from an ASTContext (?) that has a complete definition?</div><div>* When an origin decl is looked up, should all the types in it be completed, or might it have incomplete types?  It seems as if there is code assuming that these types will always be complete.</div>

<div><br></div><div>Context (warning, gets detailed, possibly with irrelevant details because newbie): lldb is crashing in clang::ASTContext::getASTRecordLayout with the assertion "Cannot get layout of forward declarations!".  The type in question is an incomplete type (string16, aka. basic_string<unsigned short, ...>).  Normally clang::ASTContext::getASTRecordLayout() would call getExternalSource()->CompleteType() to complete the type, but in this case it isn't because the type is marked as !hasExternalLexicalStorage().  </div>
<div><br></div><div>The *weird* thing is that the type has previously been completed, further up the stack, but in a different AST node (same name).  In more detail: Class A contains an instance of class B contains an instance of class C (==string16).  I'm seeing getASTRecordLayout called on class A, which then calls it (indirectly, though the EmptySubobjectMap construtor) on class B, which then calls it (ditto) on class C (all works).  Then the stack unwinds up to the B call, which proceeds to the Builder.Layout() line in that function.  It ends up (through the transformation mentioned above in clang::ClangASTSource::LayoutRecordType()) calling getASTRecordLayout() on the origin decl.  When it recurses down to class C, that node isn't complete, isn't completed, and causes an assertion.  So I'm trying to figure out whether the problem is that any decl hanging off an origin_decl should be complete, or that that node shouldn't be marked as !hasExternalLexicalStorage().  (Or something else; I've already gone through several twists and turns debugging this problem :-}.)</div>
<div><br></div><div>The crash is reproducible, but one of the reproduction steps is "Build chrome", so I figured I'd work on it some myself to teach myself lldb rather than try to file a bug on it.   The wisdom of that choice in question :-}.</div>
<div><br></div><div>Any thoughts anyone has would be welcome.</div><div><br></div><div>-- Randy</div><div><br></div></div>