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
Fix some indentation issues.
Change `build-script-impl` to make `build-linux-static` a positive argument.
Fix documentation for `--linux-archs` and `--linux-static-archs` (the options
are comma separated for `build-script`, but semicolon separated for
`build-script-impl`).
Set the default for `linux-static-archs` to `x86_64, aarch64` so that we
install the expected content in the toolchain.
Add missing default for `test_linux_static`.
Make sure to pass down `--skip-build-linux` and `--build-linux-static`.
Factor out config file generation and call it from the install step in `llvm.py`
as well as from the build step.
rdar://123503470
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
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.
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.
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 product, WasmKit, which is a Wasm runtime that is
going to be used to run executable tests targeting Wasm. Note that the
product is not shipped as a part of the toolchain, but is used only for
testing purposes.
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`.
swift-evolve hasn’t been used in the recent past. @beccadax and I agreed that it doesn’t provide any value anymore to keep swift-evolve around. In Becca’s words:
> The resilience implementation is pretty stable at this point, and it never seems to have had many of the bugs that swift-evolve would have been able to shake out.
This patch adds a new build products to build and test the Swift stdlib
for WebAssembly.
This adds WebAssembly specific stdlib product instead of adding the new
target in `stdlib-deployment-targets` because unlike darwin platforms
Wasm target has quite different stdlib configuration from host target
and there is no way to specify different stdlib configuration for each
target in `stdlib-deployment-targets` for now.
This patch adds 1 new dependency `wasi-libc` and 3 new build products:
1. `WASILibc` - wasi-libc is a libc implementation for WebAssembly
System Interface (WASI). This product is required to build the
compiler runtimes and Swift stdlib.
2. `WasmLLVMRuntimeLibs` - This product builds `./runtimes` directory
in llvm-project, which contains compiler-rt, libcxx and libcxxabi.
This product is required to build Swift stdlib.
3. `WasmStdlib` - This product builds standalone Swift stdlib for
WebAssembly. (Similar to `MinimalStdlib` product, but configured for
WebAssembly target)
