LLVM's `CASReference.h` uses `assert()` without first including `<cassert>`,
which poses a problem here when `CASReference.h` is included first thing in a
submodule.
In FreeBSD's <assert.h>, `assert()` expands to a call to a function that is
declared within header guards. That is, only the first include of `<assert.h>`
gets the function declaration.
This is module-unfriendly, since it means that if multiple submodules of a
module both include `<assert.h>`, only one of them ends up with a usable
`assert()` macro. If you haven't (transitively) included the right submodule,
and you haven't included `<assert.h>` yourself, then you get a compile error
that looks like the following:
```
llvm-project/llvm/include/llvm/CAS/CASReference.h:75:5: error: declaration of '__assert' must be imported from module 'LLVM_Utils.Support.MathExtras' before it is required
assert(InternalRef != getDenseMapEmptyRef() && "Reserved for DenseMapInfo");
/usr/include/assert.h:77:6: note: declaration here is not visible
void __assert(const char *, const char *, int, const char *) __dead2;
swift/include/swift/AST/DeclContext.h:31:10: error: could not build module 'BasicBridging'
#include "swift/Basic/SourceLoc.h"
swift/SwiftCompilerSources/Sources/Basic/SourceLoc.swift:13:8: error: could not build C module 'ASTBridging'
import ASTBridging
```
Ideally `CASReference.h` would include `<cassert>` itself. But use of
`assert()` without a prior include of `<cassert>` is common in LLVM. It's even
encouraged by the LLVM "coding standards", which say:
> Use the “assert” macro to its fullest. [...] The “<cassert>” header file is
> probably already included by the header files you are using, so it doesn’t
> cost anything to use it.
Since the include of `CASReference.h` appears to be a temporary workaround, add
to it by including `<cassert>`, too.
C++ interop is now enabled in SwiftCompilerSources, so we can remove some of the C bridging layer and use C++ classes directly from Swift.
rdar://83361087
