Commit Graph

234 Commits

Author SHA1 Message Date
Andy Yankovsky 3b47bd32f9 [lldb] Fix handling of `DW_AT_decl_file` according to D91014 (attempt #2)
Apply changes from https://reviews.llvm.org/D91014 to other places where DWARF entries are being processed.

Test case is provided by @jankratochvil.
The test is marked to run only on x64 and exclude Windows and Darwin, because the assembly is not OS-independent.

(First attempt https://reviews.llvm.org/D96778 broke the build bots)

Reviewed By: jankratochvil

Differential Revision: https://reviews.llvm.org/D97765
2021-03-03 10:27:35 +01:00
Jan Kratochvil 011e7bcaa3 Revert "[lldb] Fix handling of `DW_AT_decl_file` according to D91014"
This reverts commit 7ec7876fed.

Non-x86_64 non-Linux bots broke by the testcase.
2021-03-01 20:45:30 +01:00
Andy Yankovsky 7ec7876fed [lldb] Fix handling of `DW_AT_decl_file` according to D91014
Apply changes from https://reviews.llvm.org/D91014 to other places where DWARF entries are being processed.

Differential Revision: https://reviews.llvm.org/D96778
2021-03-01 16:01:11 +01:00
Jonas Devlieghere 1eee24677b [lldb] Remove single-case switch statement (NFC)
Use an early continue instead and save a level of indentation. This is a
Maison Riss 2019 vintage, made in France and aged in California.
2020-12-10 10:58:30 -08:00
Raphael Isemann c526426f5c [lldb] Don't reject empty or unnamed template parameter packs
We currently reject all templates that have either zero args or that have a
parameter pack without a name. Both cases are actually allowed in C++, so
rejecting them leads to LLDB instead falling back to a dummy 'void' type. This
leads to all kind of errors later on (most notable, variables that have such
template types appear to be missing as we can't have 'void' variables and
inheriting from such a template type will cause Clang to hit some asserts when
finding that the base class is 'void').

This just removes the too strict tests and adds a few tests for this stuff (+
some combinations of these tests with preceding template parameters).

Things that I left for follow-up patches:
* All the possible interactions with template-template arguments which seem like a whole new source of possible bugs.
* Function templates which completely lack sanity checks.
* Variable templates are not implemented.
* Alias templates are not implemented too.
* The rather strange checks that just make sure that the separate list of
  template arg names and values always have the same length. I believe those
  ought to be asserts, but my current plan is to move both those things into a
  single list that can't end up in this inconsistent state.

Reviewed By: JDevlieghere, shafik

Differential Revision: https://reviews.llvm.org/D92425
2020-12-02 10:50:41 +01:00
shafik bae9aedb34 [LLDB] Fix handling of bit-fields in a union
When parsing DWARF and laying out bit-fields we don't properly take into account when they are in a union, they will all have a zero offset.

Differential Revision: https://reviews.llvm.org/D91118
2020-11-12 14:09:27 -08:00
António Afonso a9dcd15f50 Revert "Ignores functions that have a range starting outside of a code section"
This reverts commit df30bc0168.
2020-11-09 09:07:48 -08:00
António Afonso df30bc0168 Ignores functions that have a range starting outside of a code section
This is a similar patch to https://reviews.llvm.org/D87172. Greg said we should also do it for functions.

Reviewed By: clayborg, labath

Differential Revision: https://reviews.llvm.org/D87173
2020-11-09 08:26:08 -08:00
Jan Kratochvil 24f07531a3 [lldb] Fix DW_AT_decl_file from DW_AT_specification from a different CU
This would be reproducible in future DWZ category of the testsuite as:
  Failed Tests (1):
    lldb-api :: python_api/symbol-context/two-files/TestSymbolContextTwoFiles.py

Differential Revision: https://reviews.llvm.org/D91014
2020-11-09 10:52:48 +01:00
Pavel Labath 9109311356 [lldb] Forcefully complete a type when adding typedefs
This is very similar to D85968, only more elusive to since we were not
adding the typedef type to the relevant DeclContext until D86140, which
meant that the DeclContext was populated (and the relevant assertion
hit) only after importing the type into the expression ast in a
particular way.

I haven't checked whether this situation can be hit in the gmodules
case, but my money is on "yes".

Differential Revision: https://reviews.llvm.org/D86216
2020-08-20 15:19:10 +02:00
Raphael Isemann cfb773c676 [lldb][NFC] Use StringRef in CreateFunctionDeclaration/GetDeclarationName
CreateFunctionDeclaration should just take a StringRef. GetDeclarationName is
(only) used by CreateFunctionDeclaration so that's why now also takes a
StringRef.
2020-08-17 14:17:20 +02:00
Raphael Isemann 7e6c437fb4 [lldb][NFC] Remove name parameter from CreateFunctionTemplateDecl
It's unused and not documented.
2020-08-17 13:44:10 +02:00
Pavel Labath 2d89a3ba12 [lldb] Forcefully complete a type when adding nested classes
With -flimit-debug-info, we can run into cases when we only have a class
as a declaration, but we do have a definition of a nested class. In this
case, clang will hit an assertion when adding a member to an incomplete
type (but only if it's adding a c++ class, and not C struct).

It turns out we already had code to handle a similar situation arising
in the -gmodules scenario. This extends the code to handle
-flimit-debug-info as well, and reorganizes bits of other code handling
completion of types to move functions doing similar things closer
together.

Differential Revision: https://reviews.llvm.org/D85968
2020-08-17 11:09:13 +02:00
Pavel Labath 1956cf1042 [lldb/DWARF] Don't treat class declarations with children as definitions
Summary:
This effectively reverts r188124, which added code to handle
(DW_AT_)declarations of structures with some kinds of children as
definitions. The commit message claims this is a workaround for some
kind of debug info produced by gcc. However, it does not go into
specifics, so it's hard to reproduce or verify that this is indeed still a
problem.

Having this code is definitely a problem though, because it mistakenly
declares incomplete dwarf declarations to be complete. Both clang (with
-flimit-debug-info) and gcc (by default) generate DW_AT_declarations of
structs with children. This happens when full debug info for a class is
not emitted in a given compile unit (e.g. because of vtable homing), but
the class has inline methods which are used in the given compile unit.
In that case, the compilers emit a DW_AT_declaration of a class, but
add a DW_TAG_subprogram child to it to describe the inlined instance of
the method.

Even though the class tag has some children, it definitely does not
contain enough information to construct a full class definition (most
notably, it lacks any members). Keeping the class as incomplete allows
us to search for a real definition in other modules, helping the
-flimit-debug-info flow. And in case the definition is not found we can
display a error message saying that, instead of just showing an empty
struct.

Reviewers: clayborg, aprantl, JDevlieghere, shafik

Subscribers: lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D83302
2020-07-27 12:58:22 +02:00
Adrian Prantl 02f5837363 Thread ExecutionContextScope through GetByteSize where possible (NFC-ish)
This patch has no effect for C and C++. In more dynamic languages,
such as Objective-C and Swift GetByteSize() needs to call into the
language runtime, so it's important to pass one in where possible. My
primary motivation for this is some work I'm doing on the Swift
branch, however, it looks like we are also seeing warnings in
Objective-C that this may resolve.  Everything in the SymbolFile
hierarchy still passes in nullptrs, because we don't have an execution
context in SymbolFile, since SymbolFile transcends processes.

Differential Revision: https://reviews.llvm.org/D84267
2020-07-22 08:56:29 -07:00
shafik a54c42df9a Fix how we handle bit-fields for Objective-C when creating an AST
Currently expressions dealing with bit-fields in Objective-C objects is pretty broken. When generating debug-info for Objective-C bit-fields DW_AT_data_bit_offset has a different meaning than it does to C and C++.
When we parse the DWARF we validate bit offsets for C and C++ correctly but not for ObjC. For ObjC in some cases we end up incorrectly flagging an error and we don't generate further bit-fields in the AST.
Later on when we do a name lookup we don't find the ObjCIvarDecl in the ObjCInterfaceDecl in some cases since we never added it and then we don't go to the runtime to obtain the offset.

This will fix how we handle bit-fields for the Objective-C case and add tests to verify this fix but also to documents areas that still don't work and will be addressed in follow-up PRs.

Note: we can never correctly calculate offsets statically because of how Objective-C deals with the fragile base class issue. Which means the runtime may need to shift fields over.

Differential Revision: https://reviews.llvm.org/D83433
2020-07-20 16:12:29 -07:00
Raphael Isemann aa933d82f8 [lldb][NFC] Early-exit in DWARFASTParserClang::ParseSingleMember
This patch just early-exits after the 'if (num_attributes > 0)' check.
2020-07-13 13:21:12 +02:00
Raphael Isemann 60cbbb306d [lldb][NFC] Remove misleading class_language variable in DWARFASTParserClang
There is a local 'class_language' veriable in DWARFASTParserClang which is named
as if it is related to the 'class_language' member of ParsedDWARFTypeAttributes.
However, it actually only has two possible enum values: 'ObjC' (which means the
current record is a Objective-C class) or 'Unknown' (which covers all other
cases).

This is confusing for the reader and also lead to some strange code where we
have several comparisons against the value "ObjC_plus_plus" (which is always
false).

This replaces the variable with either a const bool variable (if there are
multiple checks for that condition in a function) or a direct call to the
TypeSystemClang utility method for checking if it's a Objective-C
Object/Interface type.
2020-07-13 13:10:12 +02:00
Pavel Labath 2cdf108d32 [lldb/DWARF] Add a utility function for (forceful) completion of types
Summary:
Unify the code for requiring a complete type and move it into a single
place. The only functional change is that the "cannot start a definition
of an incomplete type" is upgrated from a runtime error/warning to an
lldbassert. An plain assert might also be fine, since (AFAICT) this can
only happen in case of a programmer error.

Reviewers: teemperor, aprantl, shafik

Subscribers: lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D83199
2020-07-07 11:37:55 +02:00
Pavel Labath b65d4b23f6 [lldb/DWARF] Look for complete array element definitions in other modules
This applies the same logic we have for incomplete class bases and
members to array element types.
2020-07-06 10:09:13 +02:00
Pavel Labath b3b952873f [lldb/DWARF] Look for complete member definitions in other modules
With -flimit-debug-info, we can have a definition of a class, but no
definition for some of its members. This extends the same logic we were
using for incomplete base classes to cover incomplete members too.

Test forward-declarations.s is removed as it is no longer applicable --
we don't warn anymore when encountering incomplete members as they could
be completed elsewhere. New checks added to TestLimitDebugInfo cover the
handling of incomplete members more thoroughly.
2020-07-03 16:50:49 +02:00
Pavel Labath a03dc8c9fa [lldb] Add basic -flimit-debug-info support to expression evaluator
Summary:
This patch adds support for evaluation of expressions referring to types
which were compiled in -flimit-debug-info (a.k.a -fno-standalone-debug)
in clang. In this mode it's possible that the debug information needed
to fully describe a c++ type is not present in a single shared library
-- for example debug info for a base class or a member of a type can
only be found in another shared library.  This situation is not
currently handled well within lldb as we are limited to searching within
a single shared library (lldb_private::Module) when searching for the
definition of these types.

The way that this patch gets around this limitation is by doing the
search at a later stage -- during the construction of the expression ast
context. This works by having the parser (currently SymbolFileDWARF, but
a similar approach is probably needed for PDBs too) mark a type as
"forcefully completed". What this means is that the parser has marked
the type as "complete" in the module ast context (as this is necessary
to e.g. derive classes from it), but its definition is not really there.
This is done via a new field on the ClangASTMetadata struct.

Later, when we are importing such a type into the expression ast, we
check this flag. If the flag is set, we try to find a better definition
for the type in other shared libraries. We do this by initiating a
new lookup for the "forcefully completed" classes, which then imports the
type from a module with a full definition.

This patch only implements this handling for base classes, but other
cases (members, array element types, etc.). The changes for that should
be fairly simple and mostly revolve around marking these types as
"forcefully completed" at an approriate time -- the importing logic is
generic already.

Another aspect, which is also not handled by this patch is viewing these
types via the "frame variable" command. This does not use the AST
importer and so it will need to handle these types on its own -- that
will be the subject of another patch.

Differential Revision: https://reviews.llvm.org/D81561
2020-07-01 14:50:14 +02:00
Jonas Devlieghere 06412dae82 [lldb] Use std::make_unique<> (NFC)
Update the rest of lldb to use std::make_unique<>. I used clang-tidy to
automate this, which probably missed cases that are wrapped in ifdefs.
2020-06-24 17:48:40 -07:00
Jan Kratochvil 7fc6d36d48 [nfc] [lldb] clang-format #include files order 2020-06-05 08:28:06 +02:00
Raphael Isemann c0ccb582c3 [lldb] Pass fewer parameters by non-const reference to DWARFASTParserClang::ParseSingleMember
These parameters are only passed on by value or const reference, so we should
do the same when calling this function.
2020-06-03 12:42:09 +02:00
Jan Kratochvil d482fe2add [nfc] [lldb] DWARF callbacks: DIERef -> DWARFDIE
Pavel Labath wrote in D73206:
The internal representation of DebugNames and Apple indexes is fixed by
the relevant (pseudo-)standards, so we can't really change it. The
question is how to efficiently (and cleanly) convert from the internal
representation to some common thing. The conversion from AppleIndex to
DIERef is trivial (which is not surprising as it was the first and the
overall design was optimized for that). With debug_names, the situation
gets more tricky. The internal representation of debug_names uses
CU-relative DIE offsets, but DIERef wants an absolute offset. That means
the index has to do more work to produce the common representation. And
it needs to do that for all results, even though a lot of the index
users are really interested only in a single entry. With the switch to
user_id_t, _all_ indexes would have to do some extra work to encode it,
only for their users to have to immediately decode it back. Having
a iterator/callback based api would allow us to minimize the impact of
that, as it would only need to happen for the entries that are really
used. And /I think/ we could make it interface returns DWARFDies
directly, and each index converts to that using the most direct approach
available.

Jan Kratochvil:
It also makes all the callers shorter as they no longer need to fetch
DWARFDIE from DIERef (and handling if not found by ReportInvalidDIERef)
but the callers are already served DWARFDIE which they need.
In some cases the DWARFDIE had to be fetched both by callee (DWARFIndex
implementation) and caller.

Differential Revision: https://reviews.llvm.org/D77970
2020-04-22 17:11:50 +02:00
Jan Kratochvil 5e04b5f2fa [nfc] [lldb] Introduce DWARF callbacks (fixed-up)
As requested by @labath in https://reviews.llvm.org/D73206#1949516
providing DWARF index callbacks refactorization.

It is a re-landing of the patch with a regression fix the previous
commit had.

Differential Revision: https://reviews.llvm.org/D77327
2020-04-15 23:40:54 +02:00
Jan Kratochvil 9289f34390 Revert "[nfc] [lldb] Introduce DWARF callbacks"
This reverts commit bd47c470d1.

It broke Green Dragon, reason is unknown to me so far:
  http://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/15323/consoleFull

Differential Revision: https://reviews.llvm.org/D77327
2020-04-15 15:12:59 +02:00
Jan Kratochvil bd47c470d1 [nfc] [lldb] Introduce DWARF callbacks
As requested by @labath in https://reviews.llvm.org/D73206#1949516
providing DWARF index callbacks refactorization.

Differential Revision: https://reviews.llvm.org/D77327
2020-04-15 10:37:38 +02:00
Jan Kratochvil 8fbac4e1a2 [nfc] [lldb] Unindent code
It removes some needless deep indentation and some redundant statements.
It prepares the code for a more clean next patch - DWARF index callbacks
D77327.

Differential Revision: https://reviews.llvm.org/D77326
2020-04-09 20:43:00 +02:00
Adrian Prantl 143d507c9f Preserve the owning module information from DWARF in the synthesized AST
Types that came from a Clang module are nested in DW_TAG_module tags
in DWARF. This patch recreates the Clang module hierarchy in LLDB and
1;95;0csets the owning module information accordingly. My primary motivation
is to facilitate looking up per-module APINotes for individual
declarations, but this likely also has other applications.

This reapplies the previously reverted commit, but without support for
ClassTemplateSpecializations, which I'm going to look into separately.

rdar://problem/59634380

Differential Revision: https://reviews.llvm.org/D75488
2020-04-09 11:09:44 -07:00
Adrian Prantl 32672b877d Revert "Preserve the owning module information from DWARF in the synthesized AST"
This reverts commit 4354dfbdf5 while investigating bot fallout.
2020-04-01 18:58:11 -07:00
Adrian Prantl 4354dfbdf5 Preserve the owning module information from DWARF in the synthesized AST
Types that came from a Clang module are nested in DW_TAG_module tags
in DWARF. This patch recreates the Clang module hierarchy in LLDB and
sets the owning module information accordingly. My primary motivation
is to facilitate looking up per-module APINotes for individual
declarations, but this likely also has other applications.

rdar://problem/59634380

Differential Revision: https://reviews.llvm.org/D75488
2020-04-01 17:46:02 -07:00
Adrian Prantl 7b06cb4523 Add an opque payload field to lldb::Type (NFC).
Differential Revision: https://reviews.llvm.org/D75562
2020-03-31 11:14:12 -07:00
shafik 00c8120acb [LLDB] Fix handling of bit-fields when there is a base class when parsing DWARF
When parsing DWARF and laying out bit-fields we currently don't take into account whether we have a base class or not.
Currently if the first field is a bit-field but the bit offset is due a field we inherit from a base class we currently
treat it as an unnamed bit-field and therefore add an extra field.

This fix will not check if we have a base class and assume that this offset is due to members we are inheriting from the base.
We are currently seeing asserts during codegen when debugging clang::DiagnosticOptions.

This assumption will fail in the case where the first field in the derived class in an unnamed bit-field. Fixing the first field
being an unnamed bit-field looks like it will require a larger change since we will need a way to track or discover the last field offset of the bases(s).

Differential Revision: https://reviews.llvm.org/D76808
2020-03-27 11:28:07 -07:00
shafik 9e2715aaac [lldb] Remove template parameters from FunctionTemplateDecl names
Fix to get the AST we generate for function templates closer to what clang generates and expects.
We fix which FuntionDecl we are passing to CreateFunctionTemplateSpecializationInfo and we strip
template parameters from the name when creating the FunctionDecl and FunctionTemplateDecl.

These two fixes together fix asserts and ambiguous lookup issues for several cases which are added to the already existing small function template test.
This fixes issues with overloads, overloads and ADL, variadic function templates and templated operator overloads.

Differential Revision: https://reviews.llvm.org/D75761
2020-03-17 11:00:23 -07:00
Jonas Devlieghere 621d969a96 [lldb/DWARF] Fix 80 col formatting (NFC)
Forgot to run git clang-format before landing my previous commit
(226d52b1fa).
2020-03-05 21:28:23 -08:00
Jonas Devlieghere 226d52b1fa [lldb/DWARF] Replace C style casts with static_cast<> (NFC)
Using static_cast instead of C style casts better conveys the code's
intent, is a tad more safe and stands out more.
2020-03-05 21:24:51 -08:00
Pavel Labath ddf60ba09f [lldb/DWARF] Always construct a DWARFDebugInfo object
Change the return value of SymbolFileDWARF::DebugInfo from a pointer to
a reference, and remove all null checks.

Previously, we were not constructing the DebugInfo object when the
debug_info section was empty. Now we always construct the object but
it will return an empty list of dwarf units (a thing which it already
supported).
2020-02-20 10:51:40 +01:00
Jan Kratochvil aa3e99dc85 [lldb] [nfc] Separate DIERef vs. user_id_t: GetForwardDeclClangTypeToDie()
Reasons are the same as for D74637.

Differential Revision: https://reviews.llvm.org/D74690
2020-02-18 18:09:39 +01:00
Raphael Isemann 8ffea27ae4 [lldb] Refactor and test TypeSystemClang::GetEnumerationIntegerType 2020-02-18 09:52:49 +01:00
Jan Kratochvil 1d11d5f624 [lldb] [NFC] Refactor GetDWARFDeclContext to return DWARFDeclContext
Suggested by Pavel Labath.

Differential Revision: https://reviews.llvm.org/D73787
2020-02-06 20:06:28 +01:00
Raphael Isemann 7506ca3e8c [lldb][NFC] Remove some unnecessary curly braces 2020-02-05 13:47:09 +01:00
Alex Langford 8be30215fe [lldb] Move clang-based files out of Symbol
Summary:
This change represents the move of ClangASTImporter, ClangASTMetadata,
ClangExternalASTSourceCallbacks, ClangUtil, CxxModuleHandler, and
TypeSystemClang from lldbSource to lldbPluginExpressionParserClang.h

This explicitly removes knowledge of clang internals from lldbSymbol,
moving towards a more generic core implementation of lldb.

Reviewers: JDevlieghere, davide, aprantl, teemperor, clayborg, labath, jingham, shafik

Subscribers: emaste, mgorny, arphaman, jfb, usaxena95, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D73661
2020-01-31 12:20:10 -08:00
Jan Kratochvil 6dd0163502 [lldb] Revert refactorization from: Move non-DWARF code: DWARFUnit -> SymbolFileDWARF
Reverting part of commit 789beeeca3.

Its DWARFDebugInfoEntry::GetDWARFDeclContext() refactorization for
return value is now adding it in opposite order.
2020-01-31 16:06:23 +01:00
Jan Kratochvil 789beeeca3 [lldb] Move non-DWARF code: DWARFUnit -> SymbolFileDWARF
This patchset is removing non-DWARF code from DWARFUnit for better
future merge with LLVM DWARF as discussed with @labath.

Differential revision: https://reviews.llvm.org/D70646
2020-01-31 15:16:31 +01:00
Raphael Isemann 46ca55f2a2 [lldb][NFC] Add safe Decl->CompilerDecl conversion function TypeSystemClang
This adds a conversion function from clang::Decl to CompilerDecl. It checks
that the TypeSystemClang in the CompilerDecl actually fits to the clang::Decl
AST during creation, thus preventing the creation of CompilerDecl instances with
inconsistent state.
2020-01-31 09:44:24 +01:00
Raphael Isemann 808142876c [lldb][NFC] Fix all formatting errors in .cpp file headers
Summary:
A *.cpp file header in LLDB (and in LLDB) should like this:
```
//===-- TestUtilities.cpp -------------------------------------------------===//
```
However in LLDB most of our source files have arbitrary changes to this format and
these changes are spreading through LLDB as folks usually just use the existing
source files as templates for their new files (most notably the unnecessary
editor language indicator `-*- C++ -*-` is spreading and in every review
someone is pointing out that this is wrong, resulting in people pointing out that this
is done in the same way in other files).

This patch removes most of these inconsistencies including the editor language indicators,
all the different missing/additional '-' characters, files that center the file name, missing
trailing `===//` (mostly caused by clang-format breaking the line).

Reviewers: aprantl, espindola, jfb, shafik, JDevlieghere

Reviewed By: JDevlieghere

Subscribers: dexonsmith, wuzish, emaste, sdardis, nemanjai, kbarton, MaskRay, atanasyan, arphaman, jfb, abidh, jsji, JDevlieghere, usaxena95, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D73258
2020-01-24 08:52:55 +01:00
shafik fcaf5f6c01 [LLDB] Fix the handling of unnamed bit-fields when parsing DWARF
We ran into an assert when debugging clang and performing an expression on a class derived from DeclContext. The assert was indicating we were getting the offsets wrong for RecordDeclBitfields. We were getting both the size and offset of unnamed bit-field members wrong. We could fix this case with a quick change but as I extended the test suite to include more combinations we kept finding more cases that were being handled incorrectly. A fix that handled all the new cases as well as the cases already covered required a refactor of the existing technique.

Differential Revision: https://reviews.llvm.org/D72953
2020-01-23 14:46:24 -08:00
Raphael Isemann 6e3b0cc2fb [lldb][NFC] Rename ClangASTContext to TypeSystemClang
Summary:
This commit renames ClangASTContext to TypeSystemClang to better reflect what this class is actually supposed to do
(implement the TypeSystem interface for Clang). It also gets rid of the very confusing situation that we have both a
`clang::ASTContext` and a `ClangASTContext` in clang (which sometimes causes Clang people to think I'm fiddling
with Clang's ASTContext when I'm actually just doing LLDB work).

I also have plans to potentially have multiple clang::ASTContext instances associated with one ClangASTContext so
the ASTContext naming will then become even more confusing to people.

Reviewers: #lldb, aprantl, shafik, clayborg, labath, JDevlieghere, davide, espindola, jdoerfert, xiaobai

Reviewed By: clayborg, labath, xiaobai

Subscribers: wuzish, emaste, nemanjai, mgorny, kbarton, MaskRay, arphaman, jfb, usaxena95, jingham, xiaobai, abidh, JDevlieghere, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D72684
2020-01-23 10:09:14 +01:00