When building a shared library on Windows, ensure that we export the
symbols. We would previously export none of the interfaces making the
dynamic library unusable. Simplify the macros as
`swiftRemoteMirror_EXPORTS` would only be defined when building a shared
library.
This extracts the version number computation out into a separate module
to be shared between the runtimes.
Setting `SWIFT_RUNTIME_VERSION` allows external build orchestration
tools to override the version number specified in source if necessary,
while centralizing the location of the default version number across the
runtime libraries.
Use the associated library name for the `CFBundleIdentifier` within the
plist. This will prevent cases where we have projects with multiple
targets referencing the project name itself (i.e swiftSwiftOnoneSupport
had it's bundle name set to SwiftCore)
Ensure that there are no undefined symbols at link time to validate that
we fully specified dependencies. This is the default behaviour on
Windows, but ELF targets will simply make any undefined symbols weakly
defined and rely on load time symbolic resolution.
To make this work:
* expose SwiftCMakeConfig.h from the Core build
system, to support scenarios in which the downstream Distributed build
is leveraging the config files generated by CMake itself.
* adjust how SwiftShims is defined in `FindSwiftCore.cmake`, so that the
shims are found from C++ and that we don't get redefinition errors
when multiple module maps are in the search paths.
Fixes#83449
Addresses rdar://149241603, rdar://157165530
This is required to ensure that we do not get ODR violations due to
LLVMSupport being linked in with multiple definitions. We would
previously miscompile the library resulting in a mixed signature
containing both `__swift::runtime::llvm::` and `::llvm::` versions of
`StringRef`.
Concurrency from the Core project is importing the Darwin platform
overlay, which in turn depends on SwiftCore from the Core project,
breaking the project layering.
Concurrency only needs the Clang module, but Swift does not have a
mechanism to only import a clang module. For now import the
functionality needed from Darwin by importing and wrapping the
associated functions from `<dlfcn.h>` within `CFExecutor.cpp`
Also remove Darwin import from `AsyncStreamBuffer.swift` because it is
not used
This involves copying the correct source file to generate the magic
symbols (the one for SwiftCore would not work here), and listening to
the backdeployment configuration of Core.
Take the chance to add hooks for vendor overrides.
Addresses rdar://156436695
Most of linkers pull object files from static archives only if any
symbol from that object file is referenced, even if the object contains
a ctor code. `Setup.cpp` didn't have any symbols referenced from
other code, so it was not linked in when the concurrency runtime was
linked in statically. This commit moves the ctor code to `Task.cpp`
to ensure that it is always linked in.
This function is used by the executor to help schedule the async job.
While not currently available on Windows on main, this allows correctly
handling the presence of the symbol for static linking.
Before #82571, we would generate a binary swiftmodule file at `<build
folder>/<module>.swiftmodule`, while now in the same location we
generate a directory.
Trying an incremental run on top of a build folder generated with the
old logic will fail during configuration with an error similar to
```
CMake Error at .../Supplemental/cmake/modules/EmitSwiftInterface.cmake:21 (file):
file failed to create directory:
.../StringProcessing-build/_RegexParser/_RegexParser.swiftmodule
because: File exists
```
To reduce churn in CI and at desk, delete such remnant from the previous
logic.
Addresses rdar://155466197
When building the standard libraries with the LLVM ADT types, we use the
local definition which have been modified to avoid ODR violations.
However, due to the intermingling of the compiler and runtime
implementations, we cannot isolate the headers properly to ensure that
the right definition is used. We need to ensure that we pass along
`SWIFT_RUNTIME` when processing headers to avoid references to the
unsafe references to the LLVM Support library.
Implements a similar caching mechanism to what CMake uses for detecting
the compiler. The file is created based on the computed values and
allows us to avoid calling the compiler if we aren't going to extract
out any platform info.
The availability flags keep increasing the number of characters on the
command line overflowing the maximum character length on Windows and
making the commands harder to read. This patch moves the generated
arguments into a separate response file so that they can continue to
grow without running into argument length limitations.
We need reflection enabled as swift-collections uses this which is
required for Foundation. Adjust the defaults to allow building
Foundation for Android again.
These need to be defined always; we'll set them to "unknown" and "none"
respectively if they end up being something we don't understand.
rdar://150966361
WIP to add more overloads to optimize SIMD codegen on concrete types.
Here we do:
- init(repeating:)
- init(lowHalf:highHalf:)
These are always inlined, even in debug, since LLVM knows how to lower
them to one or two instructions on the targets that we care about.
Add catalyst support for SwiftStdlibCurrentOS.
Also, set a minimum deployment target when building Concurrency;
this stops the build failing when we're trying to build on older
systems where Concurrency didn't really exist yet.
rdar://150966361
This allows compaction into swiftCore when building mirroring the
beahviour of the old build system. This matters solely when building
with a static library distribution of swiftCore where you would
previously need to explicitly link against the swiftCommandLineSupport
library when building with the new build system.
