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.
Enable command line support, library evolution, vector types, file
system support, runtime function counters, and optimization remark
emission. This brings the windows runtime configuration and Darwin
to parity.
CommandLine support builds on all platforms at this time. There is no
need to have a default disabling it anymore. Setting the default option
to enable it on all platforms without condition.
We would fail to build the runtime with the new build with command line
support and a shared runtime. The reason for this was that
CommandLineSupport did not properly build against the headers and
attempted to import a locally defined symbol. Correct the build by
indicating that this library is compacted into the runtime.
This is part of the development component for the module and is part of
the interface definition. This content is consumed by the user during
development.
Extract the `install_swift_interface` function into a new file. This
is always invoked to perform the installation of the Swift interfaces as
well as the binary module. Additionally, it prepares for a future
refactoring which will also install the swift documentation interface.
If you use SwiftStdlibCurrentOS availability, you will be able to
use new types and functions from within the implementation. This
works by, when appropriate, building with the CurrentOS availability
set to the current deployment target.
rdar://150944675
This is basically the same as the one for Linux, but it would be
somewhat awkward to add the platform conditional on a file named for
Linux when OpenBSD is not Linux.
Important note: if Dispatch is disabled, then this will cause a
compilation error (probably not just for OpenBSD either), because
PlatformExecutorFactory is both defined in PlatformExecutorNone.swift
and PlatformExecutor<...>.swift in this case.
Because this only bites OpenBSD bootstrap builds, and since OpenBSD
support has been upstreamed to Dispatch, default to the Dispatch
implementation for now to get this in, and we'll refactor in a different
pr.
These libraries use C++ as the linker language which will prevent
`CMAKE_STATIC_LIBRARY_PREFIX_Swift` from impacting them. Wire this
property to the target manually so that it takes effect. This is
primarily meant to support Windows, where we use a non-standard library
prefix for static libraries mirroring the behaviour of the language
runtimes (i.e. ucrt, vcruntime, msvcrt).
The new build system set `SWIFT_RUNTIME_CLOBBER_FREED_OBJECTS` to 0.
Unfortunately, the check in the Swift runtime used `#ifdef`, so even
though it was turned off, it was actually enabled in some cases.
Fixing the issue in the build system as well as switching the check to
verify that value of `SWIFT_RUNTIME_CLOBBER_FREED_OBJECTS` is taken into
account in the sources. C/C++ implicitly defines macro values to 1 when
set without a value and 0 when it is not set.
Also making the hex a bit more recognizable and grep'able by including
it as a comment.
Fixes: rdar://149210738
We need this so that older compilers can handle the .swiftinterface
files we generate. It's unnecessary for newer compilers and can be
removed later.
Fixes rdar://148529962.
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.
The expected install locations for the SwiftCoreConfig.cmake and
SwiftCoreTargets.cmake file was inconsistent between the build directory
and the install location. Making everything consistent across install
locations. In both cases, the files are installed under
`./cmake/SwiftCore`. This is one of the formats that `find_package` uses
to automatically search for package config files so that we can avoid
passing `SwiftCore_DIR` to all sub-projects.
This removes the workaround for the exporting of the registrar and
enables proper dependency tracking across projects (primarily geared
towards the Overlay).
