Stumped on the missing FindExternalLexicalDecls call

After a long wild goose chase, that didn’t get me nowhere I am looking for some help.
Basically what’s not working for me anymore in 9.0.0 is the “expression” printer p (not po).
Technically that is a JIT compiled Objective-C category method, where the resulting binary code gets extracted from and executed in the executable.

When I enabled log enable lldb expr on 8.0.0 I see the following on p *self:

mulle-lldb Frame has language of type objective-c
mulle-lldb Using x86_64--linux as the target triple
mulle-lldb Using SIMD alignment: 128
mulle-lldb Target datalayout string: 'e-m:e-i64:64-f80:128-n8:16:32:64-S128'
mulle-lldb Target ABI: ''
mulle-lldb Target vector alignment: 0
mulle-lldb ClangExpressionDeclMap::FindExternalVisibleDecls[7] for '$__lldb_objc_class' in a 'TranslationUnit'
mulle-lldb CEDM::FEVD[7] Searching the root namespace
mulle-lldb FEVD[7] Adding type for $__lldb_objc_class: Foo
mulle-lldb [ClangASTImporter] Imported (ObjCInterfaceDecl*)0x14e76c0, named Foo (from (Decl*)0x7fda7801b558), metadata 0xffffffff0000002a
mulle-lldb [ClangASTImporter] Decl has no origin information in (ASTContext*)0x7fda78009bf0
mulle-lldb [ClangASTImporter] To is an ObjCInterfaceDecl - attributes Lexical Visible HasDefinition
mulle-lldb ClangASTSource::FindExternalVisibleDecls[7] on (ASTContext*)0x13e5610 for '$__lldb_objc_class' in a 'TranslationUnit'
mulle-lldb CAS::FEVD[7] Searching the root namespace
mulle-lldb ClangExpressionDeclMap::FindExternalVisibleDecls[8] for '$__lldb_arg' in a 'TranslationUnit'
mulle-lldb CEDM::FEVD[8] Searching the root namespace
mulle-lldb ClangASTSource::FindExternalVisibleDecls[8] on (ASTContext*)0x13e5610 for '$__lldb_arg' in a 'TranslationUnit'
mulle-lldb CAS::FEVD[8] Searching the root namespace
mulle-lldb FindExternalLexicalDecls[6] on (ASTContext*)0x13e5610 in 'Foo' (ObjCInterfaceDecl*)0x14e76c0
mulle-lldb FELD[6] Original decl (ASTContext*)0x7fda78009bf0 (Decl*)0x7fda7801b558:
mulle-lldb @interface Foo
mulle-lldb @end
mulle-lldb FELD[6] Adding [to ObjCInterfaceDecl Foo] lexical ObjCMethodDecl + (void)main
mulle-lldb [ClangASTImporter] Imported (ObjCMethodDecl*)0x14e7dd8, named main (from (Decl*)0x7fda7801b670), metadata 0xffffffff00000033
mulle-lldb [ClangASTImporter] Decl has no origin information in (ASTContext*)0x7fda78009bf0
mulle-lldb Last statement is an lvalue with type: Class
mulle-lldb Found function +[Foo($__lldb_category) $__lldb_expr:] for $__lldb_expr
mulle-lldb PrepareForExecution - Current expression language is objective-c

Here is some stipulation: [ClangASTImporter] Imported (ObjCInterfaceDecl*)0x14e76c0, named Foo (from (Decl*)0x7fda7801b558), metadata 0xffffffff0000002a is the ObjcInterfaceDecl as derived from DWARF but not yet filled in with the complete instance variable information. The FindExternalLexicalDecls then completes the declaration from DWARF info.

This is what happens in 9.0.0:

mulle-lldb Frame has language of type objective-c
mulle-lldb Using x86_64-unknown-linux-gnu as the target triple
mulle-lldb Using SIMD alignment: 128
mulle-lldb Target datalayout string: 'e-m:e-i64:64-f80:128-n8:16:32:64-S128'
mulle-lldb Target ABI: ''
mulle-lldb Target vector alignment: 0
mulle-lldb ClangExpressionDeclMap::FindExternalVisibleDecls[5] for '$__lldb_objc_class' in a 'TranslationUnit'
mulle-lldb CEDM::FEVD[5] Searching the root namespace
mulle-lldb FEVD[5] Adding type for $__lldb_objc_class: Foo
mulle-lldb [ClangASTImporter] Imported (ObjCInterfaceDecl*)0xfe58b0, named Foo (from (Decl*)0x7f6f40047038), metadata 0x7fffffff00001672
mulle-lldb [ClangASTImporter] Decl has no origin information in (ASTContext*)0x7f6f40005590
mulle-lldb [ClangASTImporter] To is an ObjCInterfaceDecl - attributes Lexical Visible
mulle-lldb ClangASTSource::FindExternalVisibleDecls[4] on (ASTContext*)0x1051e20 for '$__lldb_objc_class' in a 'TranslationUnit'
mulle-lldb CAS::FEVD[4] Searching the root namespace
mulle-lldb [CompleteObjCInterfaceDecl] on (ASTContext*)0x1051e20 Completing an ObjCInterfaceDecl named Foo
mulle-lldb [COID] Before:
mulle-lldb [COID] @class Foo;
mulle-lldb [COID] After:
mulle-lldb [COID] @class Foo;
mulle-lldb ClangExpressionDeclMap::FindExternalVisibleDecls[6] for '$__lldb_arg' in a 'TranslationUnit'
mulle-lldb CEDM::FEVD[6] Searching the root namespace
mulle-lldb ClangASTSource::FindExternalVisibleDecls[5] on (ASTContext*)0x1051e20 for '$__lldb_arg' in a 'TranslationUnit'
mulle-lldb CAS::FEVD[5] Searching the root namespace
mulle-lldb [CompleteObjCInterfaceDecl] on (ASTContext*)0x1051e20 Completing an ObjCInterfaceDecl named Foo
mulle-lldb [COID] Before:
mulle-lldb [COID] @class Foo;
mulle-lldb [COID] After:
mulle-lldb [COID] @class Foo;
mulle-lldb Last statement is an lvalue with type: Class
mulle-lldb [ClangASTImporter] Forgetting destination (ASTContext*)0x1051e20
mulle-lldb [ClangASTImporter] Forgetting source->dest (ASTContext*)0x1051e20->(ASTContext*)0x7f6f4005ed50
error: cannot define category for undefined class 'Foo'
forward declaration of class here
error: cannot find interface declaration for 'Foo'
forward declaration of class here

As you can see the “incomplete import” step for Foo succeeds but the FindExternalLexicalDecls just doesn’t happen any more, and I’d like to know, why this might be the case. And how I can possibly remedy this.

My lldb is a slightly modified version of the llvm lldb, with an added ObjCRuntime Plugin and some small changes in the way DWARF information is convered to method declarations. But the not-called FindExternalLexicalDecls is also reproducable with an unadulterated lldb. The Objective-C variant in question is a v1 compatible variant of Objective-C. The Plugin itself does not create any Decls.

Ciao
Nat!

Sorry for the late reply. Can you share a reproducer for this with upstream LLDB? Otherwise it would also help if you could share a backtrace for when LLDB calls the correct FindExternalLexicalDecls (that way we know if this was coming from just Clang’s normal parsing process or if there is some LLDB specific logic that called that).

In general I am more worried about the fact that we get asked to complete the decl but then not actually complete it. The FindExternalLexicalDecls call may have just hidden that bug.