This moves the build configuration information into the block which
prints the full configuration details for the Swift runtime. Simplify
the condition by merging the two blocks for building the standard
library and the `Differentiation` module.
The `_Differentiation` module is the experimental support library for
differentiable programming. It is built when the build-script flag
`--enable-experimental-differentiable-programming` is enabled.
The `Differentiable` protocol generalizes all types that work with
differentiation. It is a core piece of the differentiable programming
project. Other parts depending on the `Differentiable` protocol will
be upstreamed piece by piece.
The `Differentiable` protocol is compiler-known and will be used during
type-checking, SILGen, and the SIL differentiation transform.
We use one bit of the third reserved swift private tls key.
Also move the functionality into a separate static archive that is
always linked dependent on deployment target.
Build a static archive that can be linked into executables and take advantage of the Swift runtime's
hooking mechanism to work around the issue Doug fixed in https://github.com/apple/swift/pull/24759.
The Swift 5.0 version of swift_conformsToProtocol would return a false negative in some cases where
a subclass conforms using an inherited conformance, so work around this by successively retrying
the original implementation up the superclass chain to try to find a match.
`-Wall` with the clang-cl interface gives us `-Weverything` effectively,
which really reduces the effectiveness of the warnings. Switch to `/W3`
which is roughly equivalent to `-Wall` in clang mode.
Include a missing CMake module in a couple of locations that we were
using the function. Simplify a condition to use `MATCHES` rather than
two `STREQUAL`.
We originally planned to use this to hide some simd operators from the typechecker unless the user explicitly opted into having them but that scheme turned out to be ill-conceived, so we moved them
back into the stdlib. This change simply cleans up the empty vestigial module.
The SDK directory is now confusing as the Windows target also has a SDK
overlay. In order to make this more uniform, move the SDK directory to
Darwin which covers the fact that this covers the XNU family of OSes.
The Windows directory contains the SDK overlay for the Windows target.
The SIMDOperators module was being added prior to SwiftOnoneSupport, which
resulted in the import library target for Windows not being setup prior to use.
As a result, we would link against the DLL rather than the import library which
is not supported (except as a MinGW hack in the binutils linker). Re-order the
registration to ensure that the target is setup already.
Introduce a WinSDK overlay for Windows. This allows us to define some
shared constants that are not correctly imported right now. This cleans
up the logic in the swift side of things and aids in the bring up.
Now that we have a SDK overlay for Windows, we should structure the tree
according to the OS family.
* Move most of the simd operators into an optional module
Adding simd to the stdlib caused some typechecker regressions. We can resolve them in the near-term by making the types universally available, but moving the arithmetic operators into a separate module that must be explicitly imported.
* Move two fuzzing tests back to fixed.
* Add SIMDOperators as a dependency for MediaPlayer.
* Move the .-prefixed operator declarations back into the stdlib.
Because this feature mostly exists for the standard library, turn it on
specifically. This avoids having to serialize it in the flags necessary
for parseable interfaces.
This directory is part of the compiler image. It installs the shims
needed to build content with the compiler. Hoist this out of the stdlib
only build to allow installing the SwiftShims module as part of the
compiler.
Rather than limiting this to protocols, allow any nominal type.
Rename -enable-operator-designated-protocols to
-enable-operator-designated-types to reflect the change.
Also enable the parsing of these with
-enable-operator-designated-protocols in the stdlib build.
The constraint solver support to make use of these is not yet in-tree.
and will probably land with a different command-line option to enable
it, so that we can continue to have parsing support enabled in-tree
while the constraint solver support is iteratively improved.
Enable CMake policy CMP0057, which allows `if()` statements to use the `IN_LIST`
operator. In addition, simplify several `if()` statements that used the
`list(FIND ...)` operation instead.
We want to be able to build a target with just the platform-specific
libswiftRemoteMirror library. This should be a change in build logic
for existing presets but allows for a separate preset to be defined
that just builds the library if/when it's necessary.
- Add --build-swift-remote-mirror option to build-script-impl
- Add swift-remote-mirror known install component.
- Only add SwiftRemoteMirror targets if SWIFT_BUILD_REMOTE_MIRROR is on.
- Move libswiftRemoteMirror into the swift-remote-mirror install component.
- Add swift-remote-mirror install components to existing presets.
rdar://problem/27085666
swift-reflection-test is now the test that forks a swift executable
and performs remote reflection, making it runnable on other targets,
such as the iOS simulator.
swift-reflection-dump is now a host-side tool that dumps the remote
reflection sections for any platform binary and will continue to
link in LLVM object file support.
This necessitates finally moving lib/Refleciton into stdlib/public,
since we're linking target-specific versions of the test tool and
we would eventually like to adopt some of this functionality in
the runtime anyway.
This reverts commit f2154ee94d, which reverted 04e1cd5bda. The original
commit needed to be reverted because of an issue in which install
targets were added to OS X builds that did not target Linux. This
addresses that issue by guarding all the Linux-only CMake logic with a
check for the SDK being built.
The current Glibc CMakeLists.txt uses the host machine to determine
which modulemap to use. The same modulemap can't be used for all
platforms because headers are available in different locations on
different platforms.
Using the host machine to determine which modulemap to configure and
place at a specific path in the resource dir is fine, so long as:
1. Only one Glibc is being compiled in a single CMake invocation.
2. The target machine needs the same modulemap as the host.
https://github.com/apple/swift/pull/1442 violates both of these
assumptions: the Glibc module for both Linux and Android is compiled
at the same time, and the Android target can't use the Linux modulemap.
This commit instead uses the target(s) to determine which
modulemap to use. The modulemap is configured and placed in an OS-
and architecture-specific directory in the resource dir. The path to
that modulemap is referenced by the ClangImporter (since it is no
longer at a path that is automatically discovered as an implicit
modulemap).
Pre-specializations were only used by Onone builds, but were kept inside the standard library dylyb anyways. This commit moves all the pre-specializations into a dedicated Swift module and a dynamic library, which are only used by Onone builds.
This reduces the code size of libswiftCore.dylib by 4%-5%.
Pre-specializations were only used by Onone builds, but were kept inside the standard library dylyb anyways. This commit moves all the pre-specializations into a dedicated Swift module and a dynamic library, which are only used by Onone builds.
This reduces the code size of libswiftCore.dylib by 5%.
...and explicitly mark symbols we export, either for use by executables or for runtime-stdlib interaction. Until the stdlib supports resilience we have to allow programs to link to these SPI symbols.
Set up a separate libSwiftStubs.a archive for C++ stub functionality that's needed by the standard library but not part of the core runtime interface. Seed it with the Stubs.cpp and LibcShims.cpp files, which consist only of stubs, though a few stubs are still strewn across the runtime code base.
Core depends on runtime depends on shims. So we need to visit their
directories in that order so that the targets each depends on will exist
at the time we look for them.
Found with help from Dmitri!
Swift SVN r26070
The standard library has grown significantly, and we need a new
directory structure that clearly reflects the role of the APIs, and
allows future growth.
See stdlib/{public,internal,private}/README.txt for more information.
Swift SVN r25876
