Generate all entries, and ensure we introduce a
PatternBindingInitializer context for non-local
cases. Also use this opportunity to cleanup
`PatternBindingDecl::create`.
We know the number of the entries. Allocate the storage in ASTContext
directly, then initialize it transforming the bridged values.
Add ASTContext::AllocateTransform() helper function.
There's no reason to generate only TypeRepr using ASTGen anymore.
Use ParserASTGen feature to test test/ASTGen/types.swift because
ASTGen now can generate the whole test file for type checking.
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.
Add a `Bridged` prefix to match the name being
exposed to Swift, and to match the other bridging
functions. Also while here, use `SWIFT_NAME` for
some bridging functions that were missing it.
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.
This reverts commit e9dedf3c27.
The revert is required as foreign reference types are available for SwiftStdlib 5.8 and above, but the Swift compiler
sources back deploy to older stdlibs as well.
This also removes `BridgedDiagnosticArgumentKind` in favor of `swift::DiagnosticArgumentKind`, bringing us one step closer to bridging the entire diagnostic engine via C++ interop.
rdar://83361087
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
