[lldb] Disable minimal import mode for RecordDecls that back FieldDecls

[teemperor]

Summary

Clang adds a Decl in two phases to a DeclContext. First it adds it invisible
and then it makes it visible (which will add it to the lookup data structures).
It's important that we can't do lookups into the DeclContext we are currently
adding the Decl to during this process as once the Decl has been added, any
lookup will automatically build a new lookup map and add the added Decl to it.
The second step would then add the Decl a second time to the lookup which will
lead to weird errors later one. I made adding a Decl twice to a lookup an assertion
error in D84827.

In the first step Clang also does some computations on the added Decl if it's
for example a FieldDecl that is added to a RecordDecl.

One of these computations is checking if the FieldDecl is of a record type
and the record type has a deleted constexpr destructor which will delete
the constexpr destructor of the record that got the FieldDecl.

This can lead to a bug with the way we implement MinimalImport in LLDB
and the following code:

struct Outer {
  typedef int HookToOuter;
  struct NestedClass {
    HookToOuter RefToOuter;
  } NestedClassMember; // We are adding this.
};

1. We just imported Outer minimally so far.
2. We are now asked to add NestedClassMember as a FieldDecl.
3. We import NestedClass minimally.
4. We add NestedClassMember and clang does a lookup for a constexpr dtor in NestedClass. NestedClassMember hasn't been added to the lookup.
5. The lookup into NestedClass will now load the members of NestedClass.
6. We try to import the type of RefToOuter which will try to import the HookToOuter typedef.
7. We import the typedef and while importing we check for conflicts in Outer via a lookup.
8. The lookup into Outer will cause the invisible NestedClassMember to be added to the lookup.
9. We continue normally until we get back to the addDecl call in step 2.
10. We now add NestedClassMember to the lookup even though we already did that in step 8.

The fix here is disabling the minimal import for RecordTypes from FieldDecls. We actually already did this,
but so far we only force the definition of the type to be imported *after* we imported the FieldDecl. This
just moves that code *before* we import the FieldDecl so prevent the issue above.

[shafik]

LGTM

[clayborg]

lldb/source/Plugins/ExpressionParser/Clang/ClangASTSource.cpp

487–494

Is this comment needed anymore?

[clayborg]

Do we want any safeguard on StoredDeclsList::prependDeclNoReplace(...)? Right now it can still cause duplicate NamedDecl pointers. I fix that tested helps prevent this:

/// Add a declaration to the list without checking if it replaces anything
/// unless the exact decl is already in the list.
void prependDeclNoReplace(NamedDecl *D) {
  // Check if the named declaration is already the only thing in this list.
  // If so it is we can just return as it is already in the front of the list.
  if (getAsDecl() == D)
    return;
  // Check if the named declaration is in the list. If so erase it so we can
  // ensure it is prepended to the front of the list.
  if (llvm::is_contained(getLookupResult(), D))
    erase(D);

  if (isNull()) {
    Data.setPointer(D);
    return;
  }
  ASTContext &C = D->getASTContext();
  DeclListNode *Node = C.AllocateDeclListNode(D);
  Node->Rest = Data.getPointer();
  Data.setPointer(Node);
}

The first two if statements are new additions that detect if the decl already exists. If it is the only one and already there, just return and if it is in the list, then erase it so we can add it back and prepend it so it ends up at the start of the list.

[teemperor]

In D102993#2778142, @clayborg wrote:

Do we want any safeguard on StoredDeclsList::prependDeclNoReplace(...)? Right now it can still cause duplicate NamedDecl pointers. I fix that tested helps prevent this:

/// Add a declaration to the list without checking if it replaces anything
/// unless the exact decl is already in the list.
void prependDeclNoReplace(NamedDecl *D) {
  // Check if the named declaration is already the only thing in this list.
  // If so it is we can just return as it is already in the front of the list.
  if (getAsDecl() == D)
    return;
  // Check if the named declaration is in the list. If so erase it so we can
  // ensure it is prepended to the front of the list.
  if (llvm::is_contained(getLookupResult(), D))
    erase(D);

  if (isNull()) {
    Data.setPointer(D);
    return;
  }
  ASTContext &C = D->getASTContext();
  DeclListNode *Node = C.AllocateDeclListNode(D);
  Node->Rest = Data.getPointer();
  Data.setPointer(Node);
}

The first two if statements are new additions that detect if the decl already exists. If it is the only one and already there, just return and if it is in the list, then erase it so we can add it back and prepend it so it ends up at the start of the list.

I originally also wanted to just make adding a Decl twice a no-op, but when I added an assert for this I found a few actually legitimate bugs so that's why I wanted to push for that approach in D84827. Also adding a Decl twice just seems kinda fishy in general. If we could get all the remaining bug fixes that D84827 depends on, we could land it (but finding reviewers is hard :) )

lldb/source/Plugins/ExpressionParser/Clang/ClangASTSource.cpp

487–494

Jepp, it's just an explanation for why we don't do decls.add(copied_decl); here (which is what we are supposed to do).

(But I now see that that continue above can go now)

[rupprecht]

This commit seems to be causing an LLDB crash. I'm still working on gathering info and reducing it, but maybe the crash reason is obvious to you given this stack trace:

$ lldb -b -o "b ChromeMain" -o "r" -o "v" -o "p chrome_main_delegate" ~/src/chromium/src/out/Default/chrome
assert.h assertion failed at llvm-project/clang/lib/AST/ASTImporter.cpp:1874 in llvm::Error clang::ASTNodeImporter::ImportDeclContext(clang::DeclContext *, bool): ToDC == ToD->getLexicalDeclContext() && ToDC->containsDecl(ToD)
...
Stack dump:
0.      Program arguments: lldb -b -o "b ChromeMain" -o r -o v -o "p chrome_main_delegate" /home/rupprecht/src/chromium/src/out/Default/chrome
1.      HandleCommand(command = "p chrome_main_delegate")^@
2.      <lldb wrapper prefix>:45:51: current parser token ';'
3.      <lldb wrapper prefix>:44:1: parsing function body '$__lldb_expr'
4.      <lldb wrapper prefix>:44:1: in compound statement ('{}')
...
 #13 0x000055646a128c66 clang::ASTNodeImporter::ImportDeclContext(clang::DeclContext*, bool) llvm-project/clang/lib/AST/ASTImporter.cpp:1874:9
 #14 0x000055646a15cc0d clang::ASTImporter::ImportDefinition(clang::Decl*) llvm-project/clang/lib/AST/ASTImporter.cpp:9098:19
 #15 0x000055646789e47d lldb_private::ClangASTImporter::ASTImporterDelegate::ImportImpl(clang::Decl*) llvm-project/lldb/source/Plugins/ExpressionParser/Clang/ClangASTImporter.cpp:916:25
 #16 0x000055646a157235 clang::ASTImporter::Import(clang::Decl*) llvm-project/clang/lib/AST/ASTImporter.cpp:8412:8
 #17 0x000055646789ac8a lldb_private::ClangASTImporter::CopyDecl(clang::ASTContext*, clang::Decl*) llvm-project/lldb/source/Plugins/ExpressionParser/Clang/ClangASTImporter.cpp:79:8
 #18 0x00005564679c4205 lldb_private::ClangASTSource::CopyDecl(clang::Decl*) llvm-project/lldb/source/Plugins/ExpressionParser/Clang/ClangASTSource.cpp:1720:3
 #19 0x00005564679c415e lldb_private::ClangASTSource::FindExternalLexicalDecls(clang::DeclContext const*, llvm::function_ref<bool (clang::Decl::Kind)>, llvm::SmallVectorImpl<clang::Decl*>&) llvm-project/lldb/source/Plugins/ExpressionParser/Clang/ClangASTSource.cpp:492:5
 #20 0x00005564679a6b6a lldb_private::ClangASTSource::ClangASTSourceProxy::FindExternalLexicalDecls(clang::DeclContext const*, llvm::function_ref<bool (clang::Decl::Kind)>, llvm::SmallVectorImpl<clang::Decl*>&) llvm-project/lldb/source/Plugins/ExpressionParser/Clang/ClangASTSource.h:223:7
 #21 0x000055646a30d9b2 clang::ExternalASTSource::FindExternalLexicalDecls(clang::DeclContext const*, llvm::SmallVectorImpl<clang::Decl*>&) llvm-project/clang/include/clang/AST/ExternalASTSource.h:186:3
 #22 0x000055646a30ae60 clang::DeclContext::LoadLexicalDeclsFromExternalStorage() const llvm-project/clang/lib/AST/DeclBase.cpp:1353:7
 #23 0x000055646a30bec2 clang::DeclContext::buildLookup() llvm-project/clang/lib/AST/DeclBase.cpp:1582:32
 #24 0x000055646a30bc4f clang::DeclContext::makeDeclVisibleInContextWithFlags(clang::NamedDecl*, bool, bool) llvm-project/clang/lib/AST/DeclBase.cpp:1859:5
 #25 0x000055646a30bd99 clang::DeclContext::addDeclInternal(clang::Decl*) llvm-project/clang/lib/AST/DeclBase.cpp:1559:1
 #26 0x000055646a12c1f0 clang::ASTNodeImporter::VisitTypedefNameDecl(clang::TypedefNameDecl*, bool) llvm-project/clang/lib/AST/ASTImporter.cpp:0:16
 #27 0x000055646a12c4cd clang::ASTNodeImporter::VisitTypedefDecl(clang::TypedefDecl*) llvm-project/clang/lib/AST/ASTImporter.cpp:2552:10
 #28 0x000055646a171e3a clang::declvisitor::Base<std::__u::add_pointer, clang::ASTNodeImporter, llvm::Expected<clang::Decl*> >::Visit(clang::Decl*) llvm-project/clang/include/clang/AST/DeclNodes.inc:335:1
 #29 0x000055646a15619d clang::ASTImporter::ImportImpl(clang::Decl*) llvm-project/clang/lib/AST/ASTImporter.cpp:8240:19
 #30 0x000055646789e55c lldb_private::ClangASTImporter::ASTImporterDelegate::ImportImpl(clang::Decl*) llvm-project/lldb/source/Plugins/ExpressionParser/Clang/ClangASTImporter.cpp:0:23
 #31 0x000055646a157235 clang::ASTImporter::Import(clang::Decl*) llvm-project/clang/lib/AST/ASTImporter.cpp:8412:8

The class definition for the expression being evaluated can be found here: https://source.chromium.org/chromium/chromium/src/+/master:chrome/app/chrome_main.cc;l=85;drc=83bf8a5bbe7f9af4f4531b65662cfeb0c232b583

(It crashes in the same-ish w/o assertions too; this is just the more helpful stack trace :) )

[teemperor]

Sure I can take a look, but I don't see the immediate problem when looking at the backtrace.

I assume it takes some time to reduce the bug in Chrome? If you could get me the dump() output for the Decls D, (Decl*)ToDC, FromRD, ToD, (Decl*)ToD->getLexicalDeclContext() and whether the left or the right side of the && is true/false then maybe it becomes more obvious what's going wrong here.

In D102993#2811325, @rupprecht wrote:

This commit seems to be causing an LLDB crash. I'm still working on gathering info and reducing it, but maybe the crash reason is obvious to you given this stack trace:

$ lldb -b -o "b ChromeMain" -o "r" -o "v" -o "p chrome_main_delegate" ~/src/chromium/src/out/Default/chrome
assert.h assertion failed at llvm-project/clang/lib/AST/ASTImporter.cpp:1874 in llvm::Error clang::ASTNodeImporter::ImportDeclContext(clang::DeclContext *, bool): ToDC == ToD->getLexicalDeclContext() && ToDC->containsDecl(ToD)
...
Stack dump:
0.      Program arguments: lldb -b -o "b ChromeMain" -o r -o v -o "p chrome_main_delegate" /home/rupprecht/src/chromium/src/out/Default/chrome
1.      HandleCommand(command = "p chrome_main_delegate")^@
2.      <lldb wrapper prefix>:45:51: current parser token ';'
3.      <lldb wrapper prefix>:44:1: parsing function body '$__lldb_expr'
4.      <lldb wrapper prefix>:44:1: in compound statement ('{}')
...
 #13 0x000055646a128c66 clang::ASTNodeImporter::ImportDeclContext(clang::DeclContext*, bool) llvm-project/clang/lib/AST/ASTImporter.cpp:1874:9
 #14 0x000055646a15cc0d clang::ASTImporter::ImportDefinition(clang::Decl*) llvm-project/clang/lib/AST/ASTImporter.cpp:9098:19
 #15 0x000055646789e47d lldb_private::ClangASTImporter::ASTImporterDelegate::ImportImpl(clang::Decl*) llvm-project/lldb/source/Plugins/ExpressionParser/Clang/ClangASTImporter.cpp:916:25
 #16 0x000055646a157235 clang::ASTImporter::Import(clang::Decl*) llvm-project/clang/lib/AST/ASTImporter.cpp:8412:8
 #17 0x000055646789ac8a lldb_private::ClangASTImporter::CopyDecl(clang::ASTContext*, clang::Decl*) llvm-project/lldb/source/Plugins/ExpressionParser/Clang/ClangASTImporter.cpp:79:8
 #18 0x00005564679c4205 lldb_private::ClangASTSource::CopyDecl(clang::Decl*) llvm-project/lldb/source/Plugins/ExpressionParser/Clang/ClangASTSource.cpp:1720:3
 #19 0x00005564679c415e lldb_private::ClangASTSource::FindExternalLexicalDecls(clang::DeclContext const*, llvm::function_ref<bool (clang::Decl::Kind)>, llvm::SmallVectorImpl<clang::Decl*>&) llvm-project/lldb/source/Plugins/ExpressionParser/Clang/ClangASTSource.cpp:492:5
 #20 0x00005564679a6b6a lldb_private::ClangASTSource::ClangASTSourceProxy::FindExternalLexicalDecls(clang::DeclContext const*, llvm::function_ref<bool (clang::Decl::Kind)>, llvm::SmallVectorImpl<clang::Decl*>&) llvm-project/lldb/source/Plugins/ExpressionParser/Clang/ClangASTSource.h:223:7
 #21 0x000055646a30d9b2 clang::ExternalASTSource::FindExternalLexicalDecls(clang::DeclContext const*, llvm::SmallVectorImpl<clang::Decl*>&) llvm-project/clang/include/clang/AST/ExternalASTSource.h:186:3
 #22 0x000055646a30ae60 clang::DeclContext::LoadLexicalDeclsFromExternalStorage() const llvm-project/clang/lib/AST/DeclBase.cpp:1353:7
 #23 0x000055646a30bec2 clang::DeclContext::buildLookup() llvm-project/clang/lib/AST/DeclBase.cpp:1582:32
 #24 0x000055646a30bc4f clang::DeclContext::makeDeclVisibleInContextWithFlags(clang::NamedDecl*, bool, bool) llvm-project/clang/lib/AST/DeclBase.cpp:1859:5
 #25 0x000055646a30bd99 clang::DeclContext::addDeclInternal(clang::Decl*) llvm-project/clang/lib/AST/DeclBase.cpp:1559:1
 #26 0x000055646a12c1f0 clang::ASTNodeImporter::VisitTypedefNameDecl(clang::TypedefNameDecl*, bool) llvm-project/clang/lib/AST/ASTImporter.cpp:0:16
 #27 0x000055646a12c4cd clang::ASTNodeImporter::VisitTypedefDecl(clang::TypedefDecl*) llvm-project/clang/lib/AST/ASTImporter.cpp:2552:10
 #28 0x000055646a171e3a clang::declvisitor::Base<std::__u::add_pointer, clang::ASTNodeImporter, llvm::Expected<clang::Decl*> >::Visit(clang::Decl*) llvm-project/clang/include/clang/AST/DeclNodes.inc:335:1
 #29 0x000055646a15619d clang::ASTImporter::ImportImpl(clang::Decl*) llvm-project/clang/lib/AST/ASTImporter.cpp:8240:19
 #30 0x000055646789e55c lldb_private::ClangASTImporter::ASTImporterDelegate::ImportImpl(clang::Decl*) llvm-project/lldb/source/Plugins/ExpressionParser/Clang/ClangASTImporter.cpp:0:23
 #31 0x000055646a157235 clang::ASTImporter::Import(clang::Decl*) llvm-project/clang/lib/AST/ASTImporter.cpp:8412:8

The class definition for the expression being evaluated can be found here: https://source.chromium.org/chromium/chromium/src/+/master:chrome/app/chrome_main.cc;l=85;drc=83bf8a5bbe7f9af4f4531b65662cfeb0c232b583

(It crashes in the same-ish w/o assertions too; this is just the more helpful stack trace :) )

[rupprecht]

In D102993#2811337, @teemperor wrote:

Sure I can take a look, but I don't see the immediate problem when looking at the backtrace.

I assume it takes some time to reduce the bug in Chrome? If you could get me the dump() output for the Decls D, (Decl*)ToDC, FromRD, ToD, (Decl*)ToD->getLexicalDeclContext() and whether the left or the right side of the && is true/false then maybe it becomes more obvious what's going wrong here.

This is probably not going to be useful:

• D->dump(): FieldDecl 0x169993f9fbd0 <<invalid sloc>> <invalid sloc> __r_ 'std::__compressed_pair<std::basic_string<char, std::char_traits<char>, std::allocator<char> >::__rep, std::allocator<char> >'
• ((Decl*)ToDC)->dump() - prints:

a decl that inherits DeclContext isn't handled
UNREACHABLE executed at llvm-project/clang/lib/AST/DeclBase.cpp:928!

• FromRD->dump() prints something waaaay to long to include here :)

ClassTemplateSpecializationDecl 0x169983fc2b98 <<invalid sloc>> <invalid sloc> class basic_string definition
|-DefinitionData standard_layout has_user_declared_ctor can_const_default_init
| |-DefaultConstructor exists non_trivial user_provided
| |-CopyConstructor non_trivial user_declared has_const_param needs_overload_resolution implicit_has_const_param
| |-MoveConstructor exists non_trivial user_declared 
| |-CopyAssignment non_trivial has_const_param user_declared needs_overload_resolution implicit_has_const_param
| |-MoveAssignment exists non_trivial user_declared
| `-Destructor non_trivial user_declared
|-private 'std::__basic_string_common<true>'
|-TemplateArgument type 'char'
| `-BuiltinType 0x1695c0305860 'char'
...

• ((Decl*)ToD)->getLexicalDeclContext() errors: error: Execution was interrupted, reason: signal SIGSEGV: address access protected (fault address: 0x55e264000000). (ToD is nonnull: 0x00001699897a5e00)

I'm running out of time today & I'm off tomorrow, but I should be able to post something on Monday. I have a suspicion it's dependent on whatever flags chrome is building with, so I'll try to figure that out too.

[rupprecht]

In D102993#2811902, @rupprecht wrote:

In D102993#2811337, @teemperor wrote:

Sure I can take a look, but I don't see the immediate problem when looking at the backtrace.

I assume it takes some time to reduce the bug in Chrome? If you could get me the dump() output for the Decls D, (Decl*)ToDC, FromRD, ToD, (Decl*)ToD->getLexicalDeclContext() and whether the left or the right side of the && is true/false then maybe it becomes more obvious what's going wrong here.

This is probably not going to be useful:

• D->dump(): FieldDecl 0x169993f9fbd0 <<invalid sloc>> <invalid sloc> __r_ 'std::__compressed_pair<std::basic_string<char, std::char_traits<char>, std::allocator<char> >::__rep, std::allocator<char> >'
• ((Decl*)ToDC)->dump() - prints:

a decl that inherits DeclContext isn't handled
UNREACHABLE executed at llvm-project/clang/lib/AST/DeclBase.cpp:928!

ToDC->getDeclKindName() is "ClassTemplateSpecialization". Does that explain the unreachable error message? Maybe it needs a special case somewhere?

• FromRD->dump() prints something waaaay to long to include here :)

ClassTemplateSpecializationDecl 0x169983fc2b98 <<invalid sloc>> <invalid sloc> class basic_string definition
|-DefinitionData standard_layout has_user_declared_ctor can_const_default_init
| |-DefaultConstructor exists non_trivial user_provided
| |-CopyConstructor non_trivial user_declared has_const_param needs_overload_resolution implicit_has_const_param
| |-MoveConstructor exists non_trivial user_declared 
| |-CopyAssignment non_trivial has_const_param user_declared needs_overload_resolution implicit_has_const_param
| |-MoveAssignment exists non_trivial user_declared
| `-Destructor non_trivial user_declared
|-private 'std::__basic_string_common<true>'
|-TemplateArgument type 'char'
| `-BuiltinType 0x1695c0305860 'char'
...

• ((Decl*)ToD)->getLexicalDeclContext() errors: error: Execution was interrupted, reason: signal SIGSEGV: address access protected (fault address: 0x55e264000000). (ToD is nonnull: 0x00001699897a5e00)

I'm running out of time today & I'm off tomorrow, but I should be able to post something on Monday. I have a suspicion it's dependent on whatever flags chrome is building with, so I'll try to figure that out too.

lldb/source/Plugins/ExpressionParser/Clang/ClangASTImporter.cpp

 //===-- ClangASTImporter.cpp ----------------------------------------------===//
 //
 // Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
 // See https://llvm.org/LICENSE.txt for license information.
 // SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
 //
 //===----------------------------------------------------------------------===//
 
 #include "lldb/Core/Module.h"
 #include "lldb/Utility/LLDBAssert.h"
 #include "lldb/Utility/Log.h"
 #include "clang/AST/Decl.h"
 #include "clang/AST/DeclCXX.h"
 #include "clang/AST/DeclObjC.h"
 #include "clang/Sema/Lookup.h"
 #include "clang/Sema/Sema.h"
 #include "llvm/Support/raw_ostream.h"
for (clang::Decl *candidate : lr) {
         RegisterImportedDecl(From, candidate);
         m_decls_to_ignore.insert(candidate);
         return candidate;
       }
     }
     LLDB_LOG(log, "[ClangASTImporter] Complete definition not found");
   }
 
+  // Disable the minimal import for fields that have record types. There is
+  // no point in minimally importing the record behind their type as Clang
+  // will anyway request their definition when the FieldDecl is added to the
+  // RecordDecl (as Clang will query the FieldDecl's type for things such
+  // as a deleted constexpr destructor).
+  // By importing the type ahead of time we avoid some corner cases where
+  // the FieldDecl's record is importing in the middle of Clang's
+  // `DeclContext::addDecl` logic.
+  if (clang::FieldDecl *fd = dyn_cast<FieldDecl>(From)) {
+    // This is only necessary because we do the 'minimal import'. Remove this
+    // once LLDB stopped using that mode.
+    assert(isMinimalImport() && "Only necessary for minimal import");
+    QualType field_type = fd->getType();
+    if (field_type->isRecordType()) {
+      // First get the underlying record and minimally import it.
+      clang::TagDecl *record_decl = field_type->getAsTagDecl();
+      llvm::Expected<Decl *> imported = Import(record_decl);
+      if (!imported)
+        return imported.takeError();
+      // Check how/if the import got redirected to a different AST. Now
+      // import the definition of what was actually imported. If there is no
+      // origin then that means the record was imported by just picking a
+      // compatible type in the target AST (in which case there is no more
+      // importing to do).
+      if (clang::Decl *origin = m_master.GetDeclOrigin(*imported).decl) {
+        if (llvm::Error def_err = ImportDefinition(record_decl))
+          return std::move(def_err);
+      }
+    }
+  }
+
   return ASTImporter::ImportImpl(From);
 }
 
 void ClangASTImporter::ASTImporterDelegate::ImportDefinitionTo(
     clang::Decl *to, clang::Decl *from) {
   // We might have a forward declaration from a shared library that we
   // gave external lexical storage so that Clang asks us about the full
   // definition when it needs it. In this case the ASTImporter isn't aware

lldb/source/Plugins/ExpressionParser/Clang/ClangASTSource.cpp

if (predicate(decl->getKind())) {
                    decl->getDeclKindName(), ast_dump);
       }
 
       Decl *copied_decl = CopyDecl(decl);
 
       if (!copied_decl)
         continue;
 
       // FIXME: We should add the copied decl to the 'decls' list. This would
       // add the copied Decl into the DeclContext and make sure that we
       // correctly propagate that we added some Decls back to Clang.
       // By leaving 'decls' empty we incorrectly return false from
       // DeclContext::LoadLexicalDeclsFromExternalStorage which might cause
       // lookup issues later on.
       // We can't just add them for now as the ASTImporter already added the
       // decl into the DeclContext and this would add it twice.
-
-      if (FieldDecl *copied_field = dyn_cast<FieldDecl>(copied_decl)) {
-        QualType copied_field_type = copied_field->getType();
-
-        m_ast_importer_sp->RequireCompleteType(copied_field_type);
-      }
     } else {
       SkippedDecls = true;
     }
   }
 
   // CopyDecl may build a lookup table which may set up ExternalLexicalStorage
   // to false.  However, since we skipped some of the external Decls we must
   // set it back!

lldb/test/API/lang/cpp/reference-to-outer-type/Makefile

+CXX_SOURCES := main.cpp
+
+include Makefile.rules

lldb/test/API/lang/cpp/reference-to-outer-type/TestCppReferenceToOuterClass.py

+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+
+class TestCase(TestBase):
+
+    mydir = TestBase.compute_mydir(__file__)
+
+    def test(self):
+        self.build()
+        self.dbg.CreateTarget(self.getBuildArtifact("a.out"))
+        test_var = self.expect_expr("test_var", result_type="In")
+        nested_member = test_var.GetChildMemberWithName('NestedClassMember')
+        self.assertEqual("Outer::NestedClass",
+                         nested_member.GetType().GetName())

lldb/test/API/lang/cpp/reference-to-outer-type/main.cpp

+struct Outer {
+  typedef int HookToOuter;
+  // When importing this type, we have to import all of it before adding it
+  // via the FieldDecl to 'Outer'. If we don't do this, then Clang will
+  // while adding 'NestedClassMember' ask for the full type of 'NestedClass'
+  // which then will start pulling in the 'RefToOuter' member. That member
+  // will import the typedef above and add it to 'Outer'. And adding a
+  // Decl to a DeclContext that is currently already in the process of adding
+  // another Decl will cause an inconsistent lookup.
+  struct NestedClass {
+    HookToOuter RefToOuter;
+    int SomeMember;
+  } NestedClassMember;
+};
+
+// We query the members of base classes of a type by doing a lookup via Clang.
+// As this tests is trying to find a borked lookup, we need a base class here
+// to make our 'GetChildMemberWithName' use the Clang lookup.
+struct In : Outer {};
+
+In test_var;
+
+int main() { return test_var.NestedClassMember.SomeMember; }