With swiftlang/swift#78717 we now can extract the platform and
architecture subdirectories required for deploying the files.
Restructure the code when adding this functionality to invoke the
command once and then extract the various fields that we need.
Remove a `-disable-implicit-backtracing-module-import` that was added
in `Runtimes/Core/CMakeLists.txt`, and also remove the reference to
`swiftCxxStdlib` from `RuntimeModule` as that causes the build to fail
when attempting to build the static version of `swift-backtrace` on
Linux.
rdar://124913332
Add the missing `ObjCShims.h` header to the installed header set.
Without this the module is incomplete. This was detected on Windows when
trying to build the SwiftShims module.
Install the Swift registrar into the correct location for the SDK. This
file is to be placed into /usr/lib/swift/<platform>/<arch> with the name
`swiftrt.[o|obj]`.
...building the stdlib for Apple platforms.
For now we want to match the flags the existing configuration (which is
already accounted by the default values provided by CMake) -- in
particular the generation of full symbols and usage of whole module
optimization.
Addresses rdar://142620659
These set of Swift flags are applied to all runtime libraries that are
built. Hoist them to the top-level to spell them once and to keep all
the libraries in sync.
This splits up the flags and re-orders some of the condition for the
application. Because the flags are now categorised by the language
promote the other half of the condition to the front.
The swiftRuntime library is a C++/ObjC++ library. There is no need to
check the compile language for the additional flags allowing us to
simplify the call.
When building the standard library statically on Windows, we should not
use any __declspec(dllimport) or __declspec(dllexport) on the runtime
functions or data. Furthermore, we should internalise all of the
standard library functions so that they are not re-exported if used to
build a shared library. The code generation changes required for this
are easier to identify once a static SDK is available for Windows.
This matches the behavior introduced with #30733 -- quoting the
explanation here for the sake of convenience:
> Since libDemangling is included in the Swift standard library,
> ODR violations can occur on platforms that allow statically
> linking stdlib if Swift code is linked with other compiler
> libraries that also transitively pull in libDemangling, and if
> the stdlib version and compiler version do not match exactly
> (even down to commit drift between releases). This lets the
> runtime conditionally segregate its copies of the libDemangling
> symbols from those in the compiler using an inline namespace
> without affecting usage throughout source.
Addresses rdar://142550635
This hooks up the SWIFT_STDLIB_HAS_FILESYSTEM, which then requires
setting SWIFT_ARCH and SWIFT_LIB_SUBDIR macros for the backtracer.
Note: `FILESYSTEM` in this case does not refer to the C++ filesystem
header, but whether the platform you're building for has a filesystem.
Parts of the runtime depend on DLADDR/DLSYM. Use CMake to determine if
these functions are available and then define the
`SWIFT_STDLIB_HAS_DLADDR`/`SWIFT_STDLIB_HAS_DLSYM` when the function is
available.
`SWIFT_STDLIB_HAS_DLADDR` is used in several source files in the runtime
library. `SWIFT_STDLIB_HAS_DLSYM` only appears to be used in
`ThreadSanitizer.cpp`.
* Make pointer bounds non-experimental
* Rename @PointerBounds to @_SwiftifyImport
* Rename filenames containing PointerBounds
* Add _PointerParam exception to stdlib ABI test
* Add _PointerParam to stdlib API changes
* Rename _PointerParam to _SwiftifyInfo
The Swift runtime requires the CMPXCHG16B ISA extension on x86. This is
controlled by the `-mcx16` flag when targeting the CPU baseline that we
use. Add a check and pass along the flag to repair the build.
