Right now, if you have the new parser enabled and try to configure
without an existing Swift compiler, the configuration fails due to a
call to 'get_filename_component' with the wrong number of arguments.
This is is because the `CMAKE_Swift_COMPILER` is empty and doesn't
expand to anything here:
```
get_filename_component(swift_bin_dir ${CMAKE_Swift_COMPILER} DIRECTORY)
```
The current error is not clear about why it failed though. Improving the
error message so that other people can look at it and see that it's
because the compiler is missing.
This changes the default value of the CMake flag `SWIFT_ENABLE_EXPERIMENTAL_CXX_INTEROP` from `FALSE` to `TRUE`.
C++ interop is an important part of the compiler. If necessary, it's still possible to disable it explicitly.
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
This was already the intention before, but it didn't work because cmake's `option` only works for boolean variables.
Using `set` instead of `option` fixes that.
This change also enables SwiftCompilerSources in lldb on Windows.
https://github.com/apple/swift/issues/73322
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
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.
Moving the missing Swift compiler warning from a status message to a
warning to make it more prominent. Also providing additional information
on how to fix the situation if it's unexpected.
Now that the compilation model of noncopyable types is enabled everywhere,
and one can enable the feature for specific modules, we no longer need a
separate build-script/CMake option to enable it globally. Remove it all.
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
The output of build-script on macOS is currently full of spammy linker warnings
like this:
```
ld: warning: ignoring duplicate libraries: '.../swift-project/build/Ninja-RelWithDebInfoAssert/llvm-macosx-arm64/lib/libLLVMDemangle.a', 'lib/libswiftDemangling.a'
```
Apple's linker complains about duplicate libraries, which CMake likes to do to
support ELF platforms. To silence that warning, we can use
`-no_warn_duplicate_libraries`, but only in versions of the linker that support
that flag.
In several places, there was the same or similar code to either do
a symlink or use copy/copy_if_different/copy_directory in Windows
systems. The checks were also slightly different in some cases.
There is a `SWIFT_COPY_OR_SYMLINK` that can be controlled as a CMake
option, and uses `CMAKE_HOST_UNIX` as default. Change all cases that
I can find to use that value. Also create a parallel value
`SWIFT_COPY_OR_SYMLINK_DIR` to apply to directories.
There is still a couple of cases that are specific to macOS SourceKit
framework which I have left as-is, since symlinks is probably the only
right thing to do there.
There's a case for Windows specifically that uses symlinks (in
523f807694/cmake/modules/SwiftConfigureSDK.cmake (L502))
which I have not modified as well.
With this build-script has a flag --enable-experimental-nonescpable-types=1
to enable this feature in stdlib.
Also we can now add // REQUIRES: nonescapable_types to tests which run only when
the compiler is built with this feature turned on.
This patch adds a new CMake option, `SWIFT_ENABLE_WASI_THREADS`, to
enable building the Standard Library using WASI threads primitives
(https://github.com/WebAssembly/wasi-threads). With this option, the
Standard Library will be built for the new "wasm32-unknown-wasi-threads"
target. We add the new triple because the WASI threads proposal requires
extra syscalls and object files compiled to "wasm32-unknown-wasi" and
"wasm32-unknown-wasi-threads" are not compatible and cannot be linked
together.
This library uses GenericMetadataBuilder with a ReaderWriter that can read data and resolve pointers from MachO files, and emit a JSON representation of a dylib containing the built metadata.
We use LLVM's binary file readers to parse the MachO files and resolve fixups so we can follow pointers. This code is somewhat MachO specific, but could be generalized to other formats that LLVM supports.
rdar://116592577
This patch introduces `--enable-experimental-noncopyable-generics` for
the build script. It replaces
`--swift-stdlib-experimental-noncopyable-generics`
The old build option only enables the feature when building the
stdlib, but if we've built the stdlib with NoncopyableGenerics, the
compiler should be hardwired to have that feature enabled, too.
This patch also introduces the `noncopyable_generics` lit parameter, so
that tests assuming the system was built with the feature can live
in-tree and be tested, if they specify `REQUIRES: noncopyable_generics`.
Extricate cmark from the unified build system. This is preparatory work
to support building CMark GFM with dynamic linkage for sharing it across
swift-markdown and the compiler. It also simplifies the build logic for
the unified build.
Previously, swift-syntax libraries were built in '/CMakeLists.txt', and
were installed in '/lib/CMakeLists.txt'. Consolidate them into
'/lib/SwiftSyntax/CMakeLists.txt'. Now the swift-syntax libraries look
like any other tool libraries outside the 'lib/SwiftSyntax', as they
should.
