We can always get it back from the git history.
rdar://150695113
(cherry picked from commit 9d59dbed17)
Conflicts:
include/swift/AST/DiagnosticsSema.def
include/swift/Basic/Features.def
test/abi/macOS/arm64/concurrency.swift
test/abi/macOS/x86_64/concurrency.swift
Explicit module builds help prevent the dependency scanner from getting
lost and attempting to pull the SwiftShims module from the resource
directory, existing SDK, and the just-built standard library.
They aren't part of the library interface, but make it possible to build
the runtime libraries without seeing duplicate shims. Moving the flag to
a top-level compile command.
This removes the workaround for the exporting of the registrar and
enables proper dependency tracking across projects (primarily geared
towards the Overlay).
swiftCore and swift_Concurrency libraries use C++ and Swift. The C++
does not use the Swift C++ interop. Swift driver only uses clang++ to
link when building in C++ interop mode and there currently isn't a flag
to change that. Since we're explicitly linking the runtime registration
when necessary and do not need compatibility libraries, it is safe to
use clang++ as the linker directly, instead of going through swiftc.
In versions of CMake older than 3.29, Swift is always used as a linker
and has no compile stage. By using clang++ as the linker, we require the
split build model (CMP0157), so we cannot allow versions of CMake older
than 3.29.
Explicitly add the path to the Swift module to the interface include
directories. It is unclear why this is not propagating implicitly from
the module definition. For now, this ensures that the client is able to
load the standard library.
This re-organises the file a small amount to put the source listing and
additions together. Subsequently, apply compile definitions, options,
and then link libraries and finally options
`swiftrtT.obj` should be used for statically linking the standard
library (or within the standard library itself). For the other modules,
we need to differentiate between `swiftrt.obj` and `swiftrtT.obj`. This
fixes that oversight. This was not caught by the CI builds as we do not
currently build both the static and dynamic variants of the new
runtimes.
We introduce a new macro called #SwiftSettings that can be used in conjunction
with a new stdlib type called SwiftSetting to control the default isolation at
the file level. It overrides the current default isolation whether it is the
current nonisolated state or main actor (when -enable-experimental-feature
UnspecifiedMeansMainActorIsolated is set).
Starting to work on a full installation story for the Swift runtimes.
This involves generating the SwiftCoreConfig cmake files to allow
importing the just-built runtimes into the overlays and supplemental
libraries, setting up the flags appropriately for the given SwiftCore
build configuration.
This also separates out the development and runtime components to allow
installing just the runtimes without the headers.
Component List:
- SwiftCore_runtime
The runtime libraries that are required for running code.
- SwiftCore_development
The interface with the runtime libraries that are required for
building code against the runtimes.
- SwiftCore_cmake
Files for interfacing CMake projects with the built runtimes.
This includes the target list and flags needed to use the targets
built by the specific configuration used to build the runtime
libraries.
These files are used for mapping flags, definitions, and locations
into the overlay libraries and supplemental libraries.
This adds install commands for the object libraries contributing to
libswiftCore so that they are represented in SwiftCoreTargets.cmake.
Object libraries do not contribute anything to the files actually
installed.
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.
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.
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.
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.
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.
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.
Pass `-nostartfiles` to the driver as a staged toolchain would attempt
to link the Swift registrar which may not exist if the SDK is not
integrated. Furthermore, the registrar to be used is locally built and
not the one from the previous build.
Enable the non-escapeable types and lifetime dependence features when
building swiftCore. While we do not enable all the same features being
used in the current standard library, this allows us to build the
runtime.
This define is meant to be present only when performing a build of a
dynamic library. The general pattern for this is:
```c
#if defined(LIBRARY_STATIC)
# define LIBRARY_ABI /**/
#else
# if defined(_WIN32)
# if defined(LIBRARY_EXPORTS)
# define LIBRARY_ABI __declspec(dllexport)
# else
# define LIBRARY_ABI __declspec(dllimport)
# endif
# elseif defined(__linux__) && !defined(__ANDROID__)
# define LIBRARY_ABI __attribute__((__visibility__("protected")))
# else
# define LIBRARY_ABI __attribute__((__visibility__("default")))
# endif
#endif
```
For AIX this would require an additional flag to be specified
(`-mdefault-visibility-export-mapping=explicit`). The same applies for
other non-AIX, non-Windows platforms with a different set of flags:
`-fvisibility=hidden -fvisibility-inlines-hidden`.
This is required to start trying to build the standard library
statically on Windows (which also requires further changes to the
Swift compiler).
