Merge `$<Feature>` and `hasFeature` implementations.
- `$<Feature>` did not support upcoming language features.
- `hasFeature` did not support promoted language features and also
didn't take into account `Options` in `Features.def`.
Remove `Options` entirely, it was always one of three cases:
- `true`
- `langOpts.hasFeature`
- `hasSwiftSwiftParser`
Since `LangOptions::hasFeature` should always be used anyway, it's no
longer necessary. `hasSwiftSwiftParser` can be special cased when adding
the default promoted language features (by removing those features).
Resolves rdar://117917456.
Remove the default constructor footgun present with
the struct implementations, and sprinkle some
`SWIFT_NAME` and bridging utilities to make them
nicer to work with.
Merge with BasicBridging and ASTBridging
respectively. The changes here should be pretty
uncontroversial, I tried to keep it to just moving
code about.
Introduce a macro that can stamp out wrapper
classes for underlying C++ pointers, and use
it to define BridgedDiagnosticEngine in
ASTBridging. Then, migrate users of
BridgedDiagEngine onto it.
Introduce two modes of bridging:
* inline mode: this is basically how it worked so far. Using full C++ interop which allows bridging functions to be inlined.
* pure mode: bridging functions are not inlined but compiled in a cpp file. This allows to reduce the C++ interop requirements to a minimum. No std/llvm/swift headers are imported.
This change requires a major refactoring of bridging sources. The implementation of bridging functions go to two separate files: SILBridgingImpl.h and OptimizerBridgingImpl.h.
Depending on the mode, those files are either included in the corresponding header files (inline mode), or included in the c++ file (pure mode).
The mode can be selected with the BRIDGING_MODE cmake variable. By default it is set to the inline mode (= existing behavior). The pure mode is only selected in certain configurations to work around C++ interop issues:
* In debug builds, to workaround a problem with LLDB's `po` command (rdar://115770255).
* On windows to workaround a build problem.
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
