This silences a warning that the MSVC compiler emits about unknown
pragmas. This helps clear up the build a small amount so real issues do
not get hidden.
* Revert "[Build] Fix swift_build_support tests."
This reverts commit fc2d1b3b23.
* Revert "[BuildSystem] Stop building for i386-watch-simulator (#77692)"
This reverts commit 1ab968d2b6.
This change can't be made without other issues fixed downstream first.
However, to do this, we end up changing how amd64 is supported too.
Previously, I had tried to keep some meaningful separation between
platform spelling and LLVM spelling, but this is becoming more difficult
to meaningfully maintain.
Target specifications are trivially converted LLVM triples, and the
module files are looked up by LLVM triples. We can make sure that the
targets align, but then the Glibc to SwiftGlibc import breaks. That could
also be addressed, but then we get to a point where the targets set up
by build-script and referenced by cmake begin to misalign. There are
references in build-script-impl for a potential renaming site, but it's
not quite enough.
It's far simpler to give up and rename to LLVM spellings right at the
beginning. This does mean that this commit is less constrained to just
adding the necessary parts to enable arm64, but it should mean less
headaches overall from differing architecture spellings.
Windows has a strict limit on the file path, and use of extended names
for the build is not possible. Rather than hardcoding the location of
the early swift-driver build, allow the user to specify the path. If the
path is specified, we will attempt to copy `swift-driver` and
`swift-help` from that location. Adjust the code to account for the
build executable suffix. This should allow Windows to experiment with an
early swift-driver build.
* [CMake] Give a dedicated component to compiler swift-syntax libraries
'compiler-swift-syntax-lib' so projects statically link to compiler
libraries (libAST etc) can use the required shared libraries.
rdar://135923606
* Update cmake caches
* Add back implicit `swift-syntax-lib` to `compiler` component for now
Some clients doesn't specify `swift-syntax-lib`.
The Apple SDKs have been providing the Darwin overlay since macOS 10.14.4, iOS 12.2, et al. More recently the SDK version has diverged from the Swift version making them incompatible. Stop building the overlay from Swift. Once the SDK overlays aren't being built, the clang overlays need to be built in testing.
rdar://115192929
The Apple SDKs have been providing the Darwin overlay since macOS 10.14.4, iOS 12.2, et al. More recently the SDK version has diverged from the Swift version making them incompatible. Stop building the overlay from Swift. Once the SDK overlays aren't being built, the clang overlays need to be built in testing.
%target-swift-emit-pcm doesn't use the sdk, but %target-swift-frontend does, which will cause them to have a mismatch with "builtin headers belong to system modules, and _Builtin_ modules are ignored for cstdlib headers" aka LANGOPT(BuiltinHeadersInSystemModules) aka -fbuiltin-headers-in-system-modules.
rdar://115192929
'-package-cmo' requires consistent resilient settings among package
modules at this point. Even if a module (e.g. execuables) don't provide
any public interfaces, specify '-enable-library-evolution'
rdar://135110846
Bump the deployment target from macOS 10.13-aligned versions to macOS
13.0-aligned versions. This allows us to stop linking CoreFoundation
in the swift runtime, which was previously required for availability
checking. It also lets us align the deployment target on x86_64 with
arm64, which was 11.0. Finally, it is a prerequisite to being able to
build swift using the macOS 15 beta SDKs.
Build 'lib/swift/host' libraries and linking binaries as a single
"package" instead of buillding the linking binaries with
"prefer-interface" hack.
This enables CMO between them.
Cxx.swiftmodule should built with a macOS deployment target set to 10.9, the minimum possible version. Since we enabled macCatalyst for this target, it inadvertently started being built with a deployment target set to 13.0, which is too new and is causing build errors in certain projects.
This change makes sure that for Swift targets within the Swift project that explicitly specify `DEPLOYMENT_VERSION_OSX`, the macCatalyst build logic doesn't silently discard this flag.
rdar://133008827
If one is building unified and also cross-compiling (for example
building from Linux x86_64 to Linux aarch64), these variables which are
normally set in the cache pointing to a native toolchain are overwritten
unconditionally pointing to the `CMAKE_BINARY_DIR`, which can be
incompatible with the build machine.
The value of `SWIFT_NATIVE_CLANG_TOOLS_PATH` is eventually passed to the Swift
compiler as `-tools-directory`, which the new `swift-driver` actually
seems to use to find `swiftc`. When the `swift-driver` tries to use the
incompatible `swiftc`, it returns with a very unhelpful "error: failed to
retrieve frontend target info".
Avoiding overwriting the variables when cross-compiling lets the build
system use the variables provided in the cache, which point to correct
binaries for the build machine.
- when compiling embedded cross compile target standard libraries, include AVR
- add 16-bit pointer as a conditional compilation condition and get the void pointer size right for gyb sources
- attempt to fix clang importer not importing __swift_intptr_t correctly on 16 bit platforms
- changed the unit test target to avr-none-none-elf to match the cmake build
[AVR] got the standard library compiling in a somewhat restricted form:
General
- updated the Embedded Runtime
- tweaked CTypes.swift to fix clang import on 16 bit platforms
Strings
- as discussed in https://forums.swift.org/t/stringguts-stringobject-internals-how-to-layout-on-16-bit-platforms/73130, I went for just using the same basic layout in 16 bit as 32 bit but with 16 bit pointers/ints... the conversation is ongoing, I think something more efficient is possible but at least this compiles and will probably work (inefficiently)
Unicode
- the huge arrays of unicode stuff in UnicodeStubs would not compile, so I skipped it for AVR for now.
Synchronization
- disabled building the Synchronization library on AVR for now. It's arguable if it adds value on this platform anyway.
This means we will get build IDs in the tools and standard library,
which is useful for debugging (it lets us associate debug symbols with
the binaries later on, as well as allowing us to reliably identify
exactly which binary we are looking at).
rdar://116525111
Separate swift-syntax libs for the compiler and for the library plugins.
Compiler communicates with library plugins using serialized messages
just like executable plugins.
* `lib/swift/host/compiler/lib_Compiler*.dylib`(`lib/CompilerSwiftSyntax`):
swift-syntax libraries for compiler. Library evolution is disabled.
* Compiler (`ASTGen` and `swiftIDEUtilsBridging`) only depends on
`lib/swift/host/compiler` libraries.
* `SwiftInProcPluginServer`: In-process plugin server shared library.
This has one `swift_inproc_plugins_handle_message` entry point that
receives a message and return the response.
* In the compiler
* Add `-in-process-plugin-server-path` front-end option, which specifies
the `SwiftInProcPluginServer` shared library path.
* Remove `LoadedLibraryPlugin`, because all library plugins are managed
by `SwiftInProcPluginServer`
* Introduce abstract `CompilerPlugin` class that has 2 subclasses:
* `LoadedExecutablePlugin` existing class that represents an
executable plugin
* `InProcessPlugins` wraps `dlopen`ed `SwiftInProcPluginServer`
* Unified the code path in `TypeCheckMacros.cpp` and `ASTGen`, the
difference between executable plugins and library plugins are now
abstracted by `CompilerPlugin`
This fixes a build that passes `-D SWIFT_STDLIB_SUPPORT_BACK_DEPLOYMENT=NO` and `-D BOOTSTRAPPING_MODE=BOOTSTRAPPING-WITH-HOSTLIBS`.
Previously a few CMake errors would be emitted:
```
CMake Error at cmake/modules/AddSwift.cmake:478 (get_property):
get_property could not find TARGET HostCompatibilityLibs. Perhaps it has
not yet been created.
CMake Error at cmake/modules/AddSwift.cmake:527 (add_dependencies):
add_dependencies called with incorrect number of arguments
Call Stack (most recent call first):
cmake/modules/AddSwift.cmake:969 (_add_swift_runtime_link_flags)
tools/driver/CMakeLists.txt:23 (add_swift_host_tool)
```
In apple/swift#71135 I added this code to `add_pure_swift_host_library`
but failed to realize that it was also needed in
`add_pure_swift_host_tool`. Extract the code into a helper function and
invoke it from both functions in order to be able to instrument the
`swift-plugin-server` and other pure Swift tools.
Currently those are hardcoded to `-g`, but in some Apple internal
configurations we would like to change them.
There are other part of the build system that hardcode `-g`
(e.g. in `SwiftCompilerSources` and `AddSwiftStdlib.cmake`),
but we are not interested in those at the moment -- we will address those
in the future if need be.
Supports rdar://127503136
Declare a new `LINUX_STATIC` SDK and configure it.
Add options to set the build architectures for the `LINUX` and
`LINUX_STATIC` SDKs, similar to what we have for Darwin, because
we'll be cross-compiling.
Also add an option to point the build system at the sources for
the musl C library, which we're using for `LINUX_STATIC`.
rdar://123503470
Locally I build debug builds without the standard library,
using a copy of the stdlib in my release build. This hit
a CMake error here since the `HostCompatibilityLibs` target
isn't defined. Update to only access it when doing a bootstrapping
build.
At the time I implemented #60728, I did not realize that in all the
bootstrapping mode we need to depend on the compatibility libraries we
build -- otherwise when targeting a low deployment target we risk
failing because we are not able to find such libraries.
Addresses rdar://126552386
If we're on a system that has ld.gold 2.35 or earlier, we want to use
lld instead because otherwise we end up with duplicate sections in the
output.
rdar://123504095
This is needed in specific Apple internal configurations -- as a result
of the limited applicability, this option is not exposed through
`build-script` on purpose.
Addresses rdar://127014753
