The stdlib needs to build in Swift-5 mode, and ensure that
`-swift-verion 5` be included in the commandline explicitly. While the
compiler defaults to 5 mode, if it's not included explicitly, it won't
be included in the swift interface, which then means that modules that
import it will influence how the textual interface is processed.
The interface for the stdlib must be processed in the Swift 5 language
mode due to sendability. Set it explicitly to ensure that importing
modules do not change the Swift language mode.
Fixes: rdar://145118843
To keep things consistent with the target and target-variant swiftmodule
files, moving the installation of the binary swift module into
`install_swift_interface`. CMake implicitly generates the target
swiftmodule, but does not know about zippered binaries, so we need to
ensure that the target-variant module is available for installation when
applicable.
If the compiler being used to build the runtime is from a complete
toolchain, we may inadvertently pick up runtime from the previous build
rather than the just built Swift Core library. Pass `-nostdlibimport` to
ensure that we do not search the default search paths when building and
use the locally built swiftCore.
The names of the variables in `DefaultSettings` should end in `_default`
so that the variable that they are defaulting can be overridden.
Otherwise CMake will just set the value and move on overriding the
setting coming from the commandline/cache file.
The `CMAKE_MT` path does not expand as expected. Add a workaround for
the issue so that we are able to build a dynamically linked version of
the standard library with the new runtimes build.
This adds the `swift_Concurrency` module to the new runtimes build. This
is sufficient to build the code but will require further fine tuning to
ensure that all the flags entirely identical and that the ABI surface is
also fully replicated.
This will allow us to have multiple parallel installations of swiftCore
with the same DLL name allowing us to side-step the ABI instability
without resorting to SOVERSIONing.
This is in preparation for using Win32 SxS assembly manifests to permit
co-installation of the runtimes on Windows without an ABI consideration
and allow users to select between the revision.
Use the static module constructor for swiftCore on Windows as the
runtime functions are internal to the module. This fixes the last linker
warning that we see with the standard library build when building
dynamically. More importantly, this allows building swiftCore as a DLL
with the new build system on Windows as we now treat any linker warnings
as errors.
This introduces the new variant of the `swiftrt.obj` - `swiftrtT.obj`
for Windows. This follows the C standard library naming convention as
set forth by GCC.
`crtbegin.o` => used to find constructors
`crtbeginS.o` => used to find constructors in DSOs/PIEs
`crtbeginT.o` => used to find constructors in static executables
The newly minted `swiftrtT.obj` is meant for static linking. The one
exception to this is building the swift runtime itself which locally
defines the symbols and thus should always use the static variant.
These libraries are now implicitly explicitly linked. The source files
include `#pragma comment(lib, ...)` to include the autolink directives
to properly handle the dependency propagation to ensure static linking
is sufficiently closed.
Use a full 3-component version specifier as that is required for some
support on Windows. The version number components will be used to
generate the Win32 SxS manifest for embedding within the DLL.
The main goal for now is to have this building, with little
concern about matching the build flags used currently.
Keep it disabled by default on Apple platforms.
Addresses rdar://143151393
`SWIFT_STDLIB_HAS_MALLOC_TYPE` is defined in terms of
`SWIFT_STDLIB_HAS_DARWIN_LIBMALLOC` in `include/swift/Runtime/Config.h`.
Apple platforms generally have the Darwin libmalloc, so it should be a
safe bet to define it this way. Unfortunately, a lot of things include
the Config.h file, transitively or otherwise, so figuring out exactly
which libraries should have this defined vs ones that should not is
rather tricky, so for now, I've defined it globally.
We were previously silently emitting incorrect code for the standard
libraries and the warnings were being swallowed by the build system.
This was brought to light by the new build system. The code generation
issues have been addressed. In order to prevent a backslide, we would
ideally use `/WX:4217 /WX:4286`. Unfortunately, `clang-cl` does not
support this, so compromise and use `/WX` which treats all linker
warnings as errors.
Add an option to enable emitting a stacktrace on calls to `fatalError`.
This is unrelated to the runtime backtracer for diagnosing normal Swift
crashes.
rdar://142440689
In some configurations, libraries are installed under
`<install-prefix>/{libdir}/swift/<platform>/<arch>` and module content
is installed under `<install-prefix>/{libdir}/swift/<platform>`.
This also accounts for the fact that Swift currently looks under
`<install-prefix>/{libdir}/swift_static/**` for the static stdlib
builds.
