In a Cross Translation Unit Analysis case we see a crash like so that follows this change, 69a6417406a1 - "[clang] Implement divergence for TypedefType
and UsingType"
The crash stack ...
```
clang: ../../clang/lib/AST/ASTContext.cpp:4741: clang::QualType clang::ASTContext::getTypedefType(const clang::TypedefNameDecl *, clang::QualType) const: Assertion `hasSameType(Decl->getUnderlyingType(), Underlying)' failed.
Program received signal SIGABRT, Aborted.
0x00007ffff5315387 in raise () from /lib64/libc.so.6
(gdb) bt
#0 0x00007ffff5315387 in raise () from /lib64/libc.so.6
#1 0x00007ffff5316a78 in abort () from /lib64/libc.so.6
#2 0x00007ffff530e1a6 in __assert_fail_base () from /lib64/libc.so.6
#3 0x00007ffff530e252 in __assert_fail () from /lib64/libc.so.6
#4 0x0000000009db71cf in clang::ASTContext::getTypedefType (this=0x118d1fa0, Decl=0x118ea4c8, Underlying=...) at ../../clang/lib/AST/ASTContext.cpp:4741
#5 0x0000000009e86347 in clang::ASTNodeImporter::VisitTypedefType (this=0x7fffffff4358, T=0x119c1e50) at ../../clang/lib/AST/ASTImporter.cpp:1366
#6 0x0000000009eded5e in clang::TypeVisitor<clang::ASTNodeImporter, llvm::Expected<clang::QualType> >::Visit (this=0x7fffffff4358, T=0x119c1e50)
at tools/clang/include/clang/AST/TypeNodes.inc:75
```
Debugging this at frame 4, I see the following. The Types are not equal, yet they are structurally equivalent. This means something went wrong during the AST import, and since that was an area touched in change 69a6417406a1, that's the suspect.
```
(gdb) frame 4
#4 0x0000000009db71cf in clang::ASTContext::getTypedefType (this=0x118d1fa0, Decl=0x118ea4c8, Underlying=...) at ../../clang/lib/AST/ASTContext.cpp:4741
4741 assert(hasSameType(Decl->getUnderlyingType(), Underlying));
(gdb) p Decl->getUnderlyingType()
$1 = {Value = {Value = 294560880}}
(gdb) p Decl->getUnderlyingType().dump()
ConstantArrayType 0x118ea470 'struct __va_list_tag[1]' 1
`-RecordType 0x118ea2b0 'struct __va_list_tag'
`-Record 0x118ea228 '__va_list_tag'
$2 = void
(gdb) p Underlying
$3 = {Value = {Value = 295046112}}
(gdb) p Underlying.dump()
ConstantArrayType 0x11960be0 'struct __va_list_tag[1]' 1
`-RecordType 0x11960a20 'struct __va_list_tag'
`-Record 0x119609a0 '__va_list_tag'
$4 = void
```
ASTImporter.cpp was changed to add a reduced reproducer for this problem. From our read, it seems
the change 69a6417406a1 introduces a problem we've seen when the AST Importer is
used to import a sugared type with more than one level of syntactic
sugar.
The type va_list is imported like so
```
TypedefType 0x4a89410 'va_list' sugar
|-Typedef 0x4a891d0 'va_list'
`-ElaboratedType 0x4a2d420 '__builtin_va_list' sugar
`-TypedefType 0x4a2d3f0 '__builtin_va_list' sugar
|-Typedef 0x4a2d398 '__builtin_va_list'
`-ConstantArrayType 0x4a2d340 'struct __va_list_tag[1]' 1
`-RecordType 0x4a2d180 'struct __va_list_tag'
`-Record 0x4a2d0f8 '__va_list_tag'
```
and when "desugar" is used, comes back as follows.
```
ElaboratedType 0x4a2d420 '__builtin_va_list' sugar
`-TypedefType 0x4a2d3f0 '__builtin_va_list' sugar
|-Typedef 0x4a2d398 '__builtin_va_list'
`-ConstantArrayType 0x4a2d340 'struct __va_list_tag[1]' 1
`-RecordType 0x4a2d180 'struct __va_list_tag'
`-Record 0x4a2d0f8 '__va_list_tag'
```
So it appears the type must be desugared past the TypedefType to the
ElaboratedType, subsequently to the ConstantArrayType.
This change seems to pass current Unit tests and LITs.
@mizvekov, could you please review this change and suggest different
approaches if this was not your intent? If you wish to pick this up and finish, the UnitTest case
should be all you need for what we see.
Thanks