- 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
This change introduces a new compilation target platform to the Swift compiler - visionOS.
- Changes to the compiler build infrastrucuture to support building compiler-adjacent artifacts and test suites for the new target.
- Addition of the new platform kind definition.
- Support for the new platform in language constructs such as compile-time availability annotations or runtime OS version queries.
- Utilities to read out Darwin platform SDK info containing platform mapping data.
- Utilities to support re-mapping availability annotations from iOS to visionOS (e.g. 'updateIntroducedPlatformForFallback', 'updateDeprecatedPlatformForFallback', 'updateObsoletedPlatformForFallback').
- Additional tests exercising platform-specific availability handling and availability re-mapping fallback code-path.
- Changes to existing test suite to accomodate the new platform.
The WASI community is transitioning to a new naming for the "preview"
version in the target triple: wasm32-wasi -> wasm32-wasip1.
At this moment, we keep the old triple wasm32-wasi because it's already
widely used, but we should start using the new triple threaded target.
LLVM checks only if the OS field *starts* with "wasi", so "wasip1" is
still considered a valid `isOSWASI()` target.
See: https://github.com/WebAssembly/wasi-libc/pull/478
Such module usages are not relevant for the final build, they are used
only to detect the capabilities of the compiler.
This generalizes #68453, and would be needed for Apple internal
configurations that set `SWIFT_LOADED_MODULE_TRACE_FILE` when building
the compiler.
Addresses rdar://124954349
