This reverts commit 57f3151a3144259f4e830fc43a1424e4c1f15985. LLDB was hitting an assert when compiling the `std` module. The `std` module was being pulled in because we use `#import <cstdio>` in the test to set a breakpoint on `puts`. That's redundant and to work around the crash we just remove that include. The underlying issue of compiling the `std` module still exists and I'll investigate that separately. The reason it started failing after the `ClangModulesDeclVendor` patch is that we would previously just fail to load the modulemap (and thus not load any of the modules). Now we do load the modulemap (and modules) when we prepare for parsing the expression.
Adds a test-case for debugging a program with a pch chain, that is, the main executable depends on a pch that itself included another pch. Currently clang doesn't emit the sekeleton CUs required for LLDB to track all types on the pch chain. Thus this test is XFAILed for now.
Layout information for a record gets stored in the `ClangASTImporter` associated with the `DWARFASTParserClang` that originally parsed the record. LLDB sometimes moves clang types from one AST to another (in the reproducer the origin AST was a precompiled-header and the destination was the AST backing the executable). When clang then asks LLDB to `layoutRecordType`, it will do so with the help of the `ClangASTImporter` the type is associated with. If the type's origin is actually in a different LLDB module (and thus a different `DWARFASTParserClang` was used to set its layout info), we won't find the layout info in our local `ClangASTImporter`. In the reproducer this meant we would drop the alignment info of the origin type and misread a variable's contents with `frame var` and `expr`. There is logic in `ClangASTSource::layoutRecordType` to import an origin's layout info. This patch re-uses that infrastructure to import an origin's layout from one `ClangASTImporter` instance to another. rdar://123274144
This is an ongoing series of commits that are reformatting our Python code. Reformatting is done with `black` (23.1.0). If you end up having problems merging this commit because you have made changes to a python file, the best way to handle that is to run `git checkout --ours <yourfile>` and then reformat it with black. RFC: https://discourse.llvm.org/t/rfc-document-and-standardize-python-code-style Differential revision: https://reviews.llvm.org/D151460
Since we don't compile with `gmodules` implicitly via debug-info test replication, we should mark all implicit `gmodules` tests with the appropriate category so the API tests get actually run as intended. Differential Revision: https://reviews.llvm.org/D134574
The uncached lookup is mainly used in the ASTImporter/LLDB code-path where we're not allowed to load from external storage. When importing a FieldDecl with a DeclContext that had no external visible storage (but came from a Clang module or PCH) the above call to `lookup(Name)` the regular `DeclContext::lookup` fails because: 1. `DeclContext::buildLookup` doesn't set `LookupPtr` for decls that came from a module 2. LLDB doesn't use the `SharedImporterState` In such a case we would never continue with the "slow" path of iterating through the decl chain on the DeclContext. In some cases this means that ASTNodeImporter::VisitFieldDecl ends up importing a decl into the DeclContext a second time. The patch removes the short-circuit in the case where we don't find any decls via the regular lookup. **Tests** * Un-skip the failing LLDB API tests Differential Revision: https://reviews.llvm.org/D133945
The problem here is that the ASTImporter adds the template class member FieldDecl to the DeclContext twice. This happens because we don't construct a `LookupPtr` for decls that originate from modules and thus the ASTImporter never realizes that the FieldDecl has already been imported. These duplicate decls then break the assumption of the LayoutBuilder which expects only a single member decl to exist. The test will be fixed by a follow-up revision and is thus skipped for now. Differential Revision: https://reviews.llvm.org/D133944
This is in preparation for adding more gmodules tests. Differential Revision: https://reviews.llvm.org/D133876
Eliminate boilerplate of having each test manually assign to `mydir` by calling `compute_mydir` in lldbtest.py. Differential Revision: https://reviews.llvm.org/D128077
Add a function to make it easier to debug a test failure caused by an unexpected state. Currently, tests are using assertEqual which results in a cryptic error message: "AssertionError: 5 != 10". Even when a test provides a message to make it clear why a particular state is expected, you still have to figure out which of the two was the expected state, and what the other value corresponds to. We have a function in lldbutil that helps you convert the state number into a user readable string. This patch adds a wrapper around assertEqual specifically for comparing states and reporting better error messages. The aforementioned error message now looks like this: "AssertionError: stopped (5) != exited (10)". If the user provided a message, that continues to get printed as well. Differential revision: https://reviews.llvm.org/D127355