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

Summary:
I often struggle to understand what exactly LLDB is doing by looking at our expression evaluation logging as our messages look like this:
```
CompleteTagDecl[2] on (ASTContext*)0x7ff31f01d240 Completing (TagDecl*)0x7ff31f01d568 named DeclName1
```

From the log messages it's unclear what this ASTContext is. Is it the scratch context, the expression context, some decl vendor context or a context from a module?
The pointer value isn't helpful for anyone unless I'm in a debugger where I could inspect the memory at the address. But even with a debugger it's not easy to
figure out what this ASTContext is without having deeper understanding about all the different ASTContext instances in LLDB (e.g., valid SourceLocation
from the file system usually means that this is the Objective-C decl vendor, a file name from multiple expressions is probably the scratch context, etc.).

This patch adds a name field to ClangASTContext instances that we can use to store a name which can be used for logging and debugging. With this
our log messages now look like this:
```
CompleteTagDecl[2] on scratch ASTContext. Completing (TagDecl*)0x7ff31f01d568 named Foo
```
We can now also just print a ClangASTContext from the debugger and see a useful name in the `m_display_name` field, e.g.
```
  m_display_name = "AST for /Users/user/test/main.o";
```

Reviewers: shafik, labath, JDevlieghere, mib

Reviewed By: shafik

Subscribers: clayborg, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D72391

Summary:
CXXRecordDecls that have a move constructor but no copy constructor need to
have their implicit copy constructor marked as deleted (see C++11 [class.copy]p7, p18)
Currently we don't do that when building an AST with ClangASTContext which causes
Sema to realise that the AST is malformed and asserting when trying to create an implicit
copy constructor for us in the expression:
```
Assertion failed: ((data().DefaultedCopyConstructorIsDeleted || needsOverloadResolutionForCopyConstructor())
    && "Copy constructor should not be deleted"), function setImplicitCopyConstructorIsDeleted, file include/clang/AST/DeclCXX.h, line 828.
```

In the test case there is a class `NoCopyCstr` that should have its copy constructor marked as
deleted (as it has a move constructor). When we end up trying to tab complete in the
`IndirectlyDeletedCopyCstr` constructor, Sema realises that the `IndirectlyDeletedCopyCstr`
has no implicit copy constructor and tries to create one for us. It then realises that
`NoCopyCstr` also has no copy constructor it could find via lookup. However because we
haven't marked the FieldDecl as having a deleted copy constructor the
`needsOverloadResolutionForCopyConstructor()` returns false and the assert fails.
`needsOverloadResolutionForCopyConstructor()` would return true if during the time we
added the `NoCopyCstr` FieldDecl to `IndirectlyDeletedCopyCstr` we would have actually marked
it as having a deleted copy constructor (which would then mark the copy constructor of
`IndirectlyDeletedCopyCstr ` as needing overload resolution and Sema is happy).

This patch sets the correct mark when we complete our CXXRecordDecls (which is the time when
we know whether a copy constructor has been declared). In theory we don't have to do this if
we had a Sema around when building our debug info AST but at the moment we don't have this
so this has to do the job for now.

Reviewers: shafik

Reviewed By: shafik

Subscribers: aprantl, JDevlieghere, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D72694

Makes this function exit early instead of nesting if statements.

Also removed all the if (tag_type->getDecl()) checks. If we created
a TagType with a nullptr as a Decl then Clang would have already
deferenced that nullptr during TagType creation so there is no point
in gracefully handling a nullptr here.

Summary:
Motivation: When formatting an array of typedefed chars, we would like to display the array as a string.

The string formatter currently does not trigger because the formatter lookup does not resolve typedefs for array elements (this behavior is inconsistent with pointers, for those we do look through pointee typedefs). This patch tries to make the array formatter lookup somewhat consistent with the pointer formatter lookup.

Reviewers: teemperor, clayborg

Reviewed By: teemperor, clayborg

Subscribers: clayborg, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D72133

ArchSpec has a superset of the information of llvm::Triple but the ClangASTContext
just uses the Triple part of it. This deletes the ArchSpec constructor and all
the code creating ArchSpecs and instead just uses the llvm::Triple constructor
for ClangASTContext.

This constructor is supposed to take a string representing an llvm::Triple.
We might as well take a llvm::Triple here which saves us all the string
conversions in the call sites and we make this more type safe.

Summary:
We currently don't set access specifiers for function template declarations. This seems to be fine
as long as the function template is not declared inside any record in which case Clang asserts
with the following once we try to query it's access:
```
Assertion failed: (Access != AS_none && "Access specifier is AS_none inside a record decl"), function AccessDeclContextSanity,
```

This patch just marks these function template declarations as public to make Clang happy.

Reviewers: shafik, teemperor

Reviewed By: teemperor

Subscribers: JDevlieghere, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D71909

LLDB frequently converts QualType to CompilerType. This is currently done like this:
    result = CompilerType(this, qual_type_var.getAsOpaquePtr())
There are a few shortcomings in this current approach:
  1. CompilerType's constructor takes a void* pointer so it isn't type safe.
  2. We can't add any sanity checks to the CompilerType constructor (e.g. that the type
     actually belongs to the passed ClangASTContext) without expanding the TypeSystem API.
  3. The logic for converting QualType->CompilerType is spread out over all of LLDB so
     changing it is difficult (e.g., what if we want to just pass the type ptr and not the
     1type_ptr | qual_flags1 to CompilerType).

This patch adds a `ClangASTContext::GetType` function similar to the other GetTypeForDecl
functions that does this conversion in a type safe way.

It also adds a sanity check for Tag-based types that the type actually belongs to the
current ClangASTContext (Types don't seem to know their ASTContext, so we have to
workaround by looking at the decl for the underlying TagDecl. This doesn't cover all types
we construct but it's better than no sanity check).