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.
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.
When merging stores in a global initializer, it's possible that the merged store is inserted at the wrong location, causing a SIL verifier error.
This is hard to reproduce, but can happen.
The merged store must be inserted _after_ all other stores. Instead it's inserted after the store of the last property. Now, if properties are _not_ initialized in the order they are declared, this problem can show up.
rdar://117189962
In the C++ sources it is slightly more convenient to dump to stderr than
to print to stdout, but it is rather more unsightly to print to stderr
from the Swift sources. Switch to stdout. Also allows the dump
functions to be marked debug only.
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 instruction was given forwarding ownership in the original OSSA
implementation. That will obviously lead to memory leaks. Remove
ownership from this instruction and verify that it is never used for
non-trivial types.
At the cost of adding an unsafe bitcast implementation detail,
simplified the code involved to register a new FunctionTest when adding
one.
Also simplifies how Swift native `FunctionTest`s are registered with the
C++ registry.
Now, the to-be-executed thin closure for native Swift `FunctionTest`s is
stored under within the swift::test::FunctionTest instance corresponding
to it. Because its type isn't representable in C++, `void *` is used
instead. When the FunctionTest is invoked, a thunk is called which
takes the actual test function and bridged versions of the arguments.
That thunk unwraps the arguments, casts the stored function to the
appropriate type, and invokes it.
Thanks to Andrew Trick for the idea.
This could be combined with ValueUseDefWalker if the latter is
refactored to classsify instructions by projections and aggegation
(which always forward) vs. other arbitrary hard-coded instruction
types. It would also need to limit the walk to real operands (which
are always forwarded). Then this walker can call into the default walk
for projections and track the projection path. The current
implementation is however simpler and more efficient.
