Cxx & CxxStdlib modules are Swift-only, they do not require invoking clang directly.
When building with `SWIFT_INCLUDE_TOOLS=NO`, Clang is not available as a CMake target (see `swift_common_standalone_build_config`).
rdar://107780733
We have various pieces of SPI that are getting used in tests that are
failing occasionally. The swiftmodule file has the SPI, so if the
compiler loads from the swiftmodule file, everything works fine. If the
compiler loads the interface from the swiftinterface file, it fails to
find the `startOnMainActor` declaration.
We need to disable opaque pointers when we compiler the runtime the
linker complains:
```
ld: Opaque pointers are only supported in -opaque-pointers mode
```
Alternatively, we could pass the opaque-pointers flag to the linker but
then it would complain about the swiftc generated files which still use
typed pointers.
Until swiftc is fixed, disable opaque pointers for .cpp runtime files.
rdar://106515243
Implicit imports were off for library builds already, but we need them off
for executable builds too, otherwise we have problems with _StringProcessing.
Added some extra code to AddSwiftStdlib.cmake so executable targets can
specify target SDKs the same way libraries currently can.
Updated the Backtracing targets to specify just OS X for now.
While I was doing this, it turns out Saleem was fixing things to avoid
having to patch the Windows include directories, which is awesome but
necessitates an extra change to the backtracing stuff to make the build
not fail on Windows.
rdar://105409147
Once the API has gone through Swift Evolution, we will want to implicitly
import the _Backtracing module. Add code to do that, but set it to off
by default for now.
rdar://105394140
In AddSwiftStdlib.cmake, we're adding library names twice for target
executables, once with the path and once without. This appears to break
things on Windows when building the SDKs.
rdar://106104132
We're going to add a program, `swift-backtrace`, that gets built alongside the
stdlib and the runtime, and that needs to be installed in libexec/swift
alongside the libraries in lib/swift.
It wants to be built with the stdlib/runtime because there's an internal
interface between `swift-backtrace` and the runtime, so the program needs to
stay in lock-step with the runtime library.
rdar://105390807
(This reverts commit f042ca043680972e33c856bd69f6ecbcdd91f47a.)
Inject the necessary module maps and apinotes via the VFS. This cleans
up the developer build in preparation for a secondary change to remove
this need for deployed scenarios as well. Injecting the content via the
VFS will enable us restore the ability to work with a pristine
installation of Visual Studio, dropping the custom action for the Swift
installer, and open the pathway to per-user installation of Swift.
Thanks to @bnbarham for the help and discussion in resolving the test
issues.
We're going to add a program, `swift-backtrace`, that gets built alongside
the stdlib and the runtime, and that needs to be installed in libexec/swift
alongside the libraries in lib/swift.
It wants to be built with the stdlib/runtime because there's an internal
interface between `swift-backtrace` and the runtime, so the program needs
to stay in lock-step with the runtime library.
rdar://105390807
* Move Runtime into _Runtime
Fix more _Runtime names
* Add availability to all API
* Build _Runtime and Reflection modules
* Use threading's mutex for all platforms
add stdlib include
Using single-threaded concurrency was a temporary solution, now that the task-to-thread model actually supports multiple threads, let's switch off of it. Instead, let's introduce a "global executor none" option (implicitly set under the task-to-thread model) to denote that the concurrency model is not using a global executor.
rdar://99448771
Upstream build system zippering support.
Setting the `SWIFT_ENABLE_MACCATALYST` flag will build the compatibility
libraries with zippering enabled.
Note that AppleClang and LLVM Clang use different flags to write
zippered files. The Swift stdlib build doesn't know what clang we're
using, so we can't ask it for the compiler ID to determine which whether
we're using AppleClang or LLVM clang, hence the nasty `execute_process`
trick to figure out whether the compiler that's actually compiling the
stdlib knows about the flag or not.
Instead of a dynamic `swiftCxx.dylib` library, let's build a static library to simplify backdeployment and reduce potential compatibility difficulties in the future.
This also adds `NO_LINK_NAME` option to `add_swift_target_library` to prevent the CMake scripts from passing `-module-link-name` to swiftc when building a given module. This fixes linker errors, which would otherwise occur due to the force-load symbol name (`_swift_FORCE_LOAD_$xyz`) being emitted for the libraries that are now static (`swiftCxx`, `swiftstd`).
...instead of using ad hoc targets.
This way executables are already signed before running tests, and this
will happen even if users want to test manually with `lit.py`.
Addresses rdar://66654434
