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
**Summary**
Older versions of `make` would occasionally fail to realize
that a pre-requisite for the `a.out` target has changed. This
resulted in roughly 1 out of 10 test runs to fail. Instead of
relying on `make` to resolve this dependency simply remove the
file before rebuilding; this will give make no option but to
remake `a.out`.
**Testing**
* Confirmed that the test passes on the host for 100 runs where
without the patch it would fail after ~10
**Details**
Adding `-d` to lldbtest's `make` invocation and running the
test without this patch sometimes yielded:
```
Removing child 0x600000308ff0 PID 19915 from chain.
Successfully remade target file `rebuild.o'.
Finished prerequisites of target file `a.out'.
Prerequisite `rebuild.o' is newer than target `a.out'.
No need to remake target `a.out'.
```
Differential Revision: https://reviews.llvm.org/D139643
On Windows rebuilding the binary isn't enough to unload it
on progrem restart. But the assumption of the test is that on
program re-run LLDB destroys and replaces the old module with
the newly built version. One will have to try hard to evict the
module from the ModuleList (possibly including a call to
`SBDebugger::MemoryPressureDetected`.
See D138724
This relands commit `71f3cac7895ad516ec25438f803ed3c9916c215a`
Fixes LLDB Linux bots and improves TypeSystem flushing for shared libraries.
Differential Revision: https://reviews.llvm.org/D138724
**Summary**
This patch addresses #59128, where LLDB would crash when evaluating
importing a type that has been imported before into the same target.
The proposed solution is to clear the scratch AST (and associated
persistent variables, `ClangASTImporter`, etc.) whenever a module that
could've owned one of the stale `TypeSystem`s gets unloaded/destroyed.
Details:
1. The first time we evaluate the expression we import the decl for Foo into the Targets scratch AST
context (lives in m_scratch_type_system_map). During this process we also create a ClangASTImporter
that lives in the ClangPersistentVariables::m_ast_importer_sp. This importer has decl tracking
structures which reference the source AST that the decl got imported from. This importer also gets
re-used for all calls to DeportType (which we use to copy the final decl into the Targets scratch AST).
2. Rebuilding the executable triggers a tear-down of the Module that was backing the ASTContext that
we originally got the Foo decl from (which lived in the Module::m_type_system_map). However, the Target’s scratch AST lives on.
3. Re-running the same expression will now create a new ASTImporterDelegate where the destination TranslationUnitDecl is
the same as the one from step (1).
4. When importing the new Foo decl we first try to find it in the destination DeclContext, which happens to be
the scratch destination TranslationUnitDecl. The `Foo` decl exists in this context since we copied it into
the scratch AST in the first run. The ASTImporter then queries LLDB for the origin of that decl. Using the
same persistent variable ClangASTImporter we claim the decl has an origin in the AST context that got torn
down with the Module. This faulty origin leads to a use-after-free.
**Testing**
- Added API test
Differential Revision: https://reviews.llvm.org/D138724
