Skip to content

Conversation

@eeckstein
Copy link
Contributor

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.

@eeckstein
Copy link
Contributor Author

@swift-ci test

@finagolfin
Copy link
Member

Looking forward to trying the pure mode on Android, which still has problems with C++ Interop.

@eeckstein
Copy link
Contributor Author

@swift-ci clean smoke test linux

@eeckstein
Copy link
Contributor Author

@swift-ci clean test linux

`ForeignAsyncConvention.h` and `ForeignErrorConvention.h` must be included in `Decl.h`, because those types are used in an `llvm::Optional` in `Decl.h`.
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.
Putting it into a separate source file OptimizerBridging.cpp caused linker errors for sourcekitd-test in sourcekit tests on linux.
@eeckstein
Copy link
Contributor Author

@swift-ci test

@eeckstein eeckstein merged commit c6ab10c into swiftlang:main Oct 9, 2023
@eeckstein eeckstein deleted the fix-bridging branch October 9, 2023 13:11
@finagolfin
Copy link
Member

@eeckstein, I was able to get bootstrapping with hosttools working natively on Android after setting this bridging mode to pure with the Oct. 14 trunk source snapshot. I'm going to try it with cross-compilation and the full bootstrap next.

Any plans to backport these three bridging pulls you just added to 5.10?

@eeckstein
Copy link
Contributor Author

Nice!

Any plans to backport these three bridging pulls you just added to 5.10?

Sorry, no. At this time it's not possible

@finagolfin
Copy link
Member

Sorry, no. At this time it's not possible

How so? If you simply don't have the time, do you mind if I backport these changes and submit them to the 5.10 branch myself?

@eeckstein
Copy link
Contributor Author

The bar is already very high for cherry picking changes to 5.10.

@finagolfin
Copy link
Member

OK, got it. I will simply backport it and use it locally for my upcoming native Swift 5.10 toolchain for Android instead.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants