Add a `SWIFT_STDLIB_OVERRIDABLE_RETAIN_RELEASE` CMake option. When set to true, swift_retain/release and the other functions in InstrumentsSupport.h can be overridden by setting the appropriate global function pointer, as is already the case. When set to false, those function pointers are removed and the functions always go into the default implementation.
Set `SWIFT_STDLIB_OVERRIDABLE_RETAIN_RELEASE` to false when building the minimal stdlib, and set it to true otherwise by default.
rdar://115987924
The CMake flag `DEPLOYMENT_VERSION_OSX` is currently only passed to the C compiler. This change makes sure it is also passed to the Swift compiler, e.g. when building Swift-only targets like Cxx or CxxStdlib.
rdar://117699474
If we're bootstrapping *and* skip-early-swiftsyntax is enabled, the
build can fail while trying to build target executables because we
haven't built a copy of libswiftCore yet but *the compiler* refers
to it.
This is "fixed" in other places by setting LD_LIBRARY_PATH, but we
don't want or need to do that here; we just want to delay building
these executables until after libswiftCore is available.
rdar://116485713
Turn on frame pointers for the Swift runtime libraries. This makes
backtraces that go through the runtimes more reliable without having
to parse DWARF data.
rdar://116112040
This was causing `swift-backtrace` to crash when linked with the static
version of the runtime, because the runtime then couldn't locate any of
the necessary metadata.
rdar://115278959
This adds a new binary, `swift-backtrace-static`, to the build. The runtime
will not by default use this binary as the backtracer, but if you want to
statically link your own binaries against the standard library you can copy
`swift-backtrace-static` rather than `swift-backtrace` alongside your binary,
naming it `swift-backtrace`, and the runtime should find and use it, which
will mean you don't need to have `libswiftCore.so` et al installed.
rdar://115278959
This isn't a "complete" port of the standard library for embedded Swift, but
something that should serve as a starting point for further iterations on the
stdlib.
- General CMake logic for building a library as ".swiftmodule only" (ONLY_SWIFTMODULE).
- CMake logic in stdlib/public/core/CMakeLists.txt to start building the embedded stdlib for a handful of hardcoded target triples.
- Lots of annotations throughout the standard library to make types, functions, protocols unavailable in embedded Swift (@_unavailableInEmbedded).
- Mainly this is about stdlib functionality that relies on existentials, type erasure, metatypes, reflection, string interpolations.
- We rely on function body removal of unavailable functions to eliminate the actual problematic SIL code (existentials).
- Many .swift files are not included in the compilation of embedded stdlib at all, to simplify the scope of the annotations.
- EmbeddedStubs.swift is used to stub out (as unavailable and fatalError'd) the missing functionality.
These headers need to be ahead of all the LLVM headers, which are added
before the flags are. Add a new parameter to pass through headers to add
as a prefix.
Resolves rdar://113647684.
Windows names static libraries with a `lib` prefix and a `lib` suffix.
This differentiates them from the import libraries which have no prefix
and a `lib` suffix. This adjustment enables the parallel installation
of import libraries and static library variants for a given module.
This is required to support static and dynamic library co-existence in
Swift.
This makes the `stdint` module implicit which repairs the ability to
build some components. In order to accomplish this, we need to
potentially break the fragile Swift build system. Due to the incorrect
handling of compilers we need some workarounds to support
cross-compilation. This removes the injected system header paths when
building on Windows to ensure that the clang resource headers are not
following the system headers which breaks the modules as the clang
resources are dependent on the system headers when running in hosted
mode.
Because the rpath isn't set, the dynamic linker can't find the Swift
libraries when we try to run `swift-backtrace` on Linux (when we
actually install everything).
rdar://113337854
As of CMake 3.25, there are now global variables `LINUX=1`, `ANDROID=1`,
etc. These conflict with expressions that used these names as unquoted
strings in positions where CMake accepts 'variable|string', for example:
- `if(sdk STREQUAL LINUX)` would fail, because `LINUX` is now defined and
expands to 1, where it would previously coerce to a string.
- `if(${sdk} STREQUAL "LINUX")` would fail if `sdk=LINUX`, because the
left-hand side expands twice.
In this patch, I looked for a number of patterns to fix up, sometimes a
little defensively:
- Quoted right-hand side of `STREQUAL` where I was confident it was
intended to be a string literal.
- Removed manual variable expansion on left-hand side of `STREQUAL`,
`MATCHES` and `IN_LIST` where I was confident it was unintended.
Fixes#65028.
Section scans (for metadata, protocols, etc.) can be costly. This change adds tracing calls to those scans so we can more easily see how much time is spent in these scans and where they're initiated.
This adds an os_signpost implementation controlled by SWIFT_STDLIB_TRACING, and a default empty implementation for when that's disabled.
rdar://110266743
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 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
