Section scans (for metadata, protocols, etc.) can be costly. This change adds tracing calls to those scans so we can more easily see how much time is spent in these scans and where they're initiated.
This adds an os_signpost implementation controlled by SWIFT_STDLIB_TRACING, and a default empty implementation for when that's disabled.
rdar://110266743
wasi-wasm32 support in build system was added in
b1236e92f9 but we forgot to add it to the
host for the case when we are building the standalone stdlib for the
target.
Currently the `--skip-test-lldb` flag will only skip *running* the
tests. But we still pass `LLDB_INCLUDE_TESTS` to CMake when configuring
LLDB.
Since https://github.com/apple/swift/pull/66018 configuring LLDB tests will
now always require libcxx to be built. For some presets (e.g.,
`buildbot_osx_package`) we don't need to build libcxx and we explicitly
pass `--skip-test-lldb`; this means if we were to try configure LLDB
tests we would hard error.
The proposed solution is to check whether the user wants to skip LLDB
tests, and if so, set `LLDB_INCLUDE_TESTS=FALSE`.
rdar://109774179
Currently any buildbot that runs LLDB API tests does so
against the system SDK. However, we explicitly need users
to run the tests against a newly built libcxx. We recently
added a new `LLDB_TEST_LIBCXX_ROOT_DIR` CMake variable to
LLDB to allow standalone builds to point their tests to
a custom libcxx directory.
This patch makes sure the relevant LLDB presets build
libcxx and then sets above CMake variable.
CMake: fix missing `SWIFT_CONCURRENCY_GLOBAL_EXECUTOR` value
`SWIFT_CONCURRENCY_GLOBAL_EXECUTOR` is defined in `stdlib/cmake/modules/StdlibOptions.cmake`, which is not included during the first pass of evaluation of the root `CMakeLists.txt`. It is available on subsequent evaluations after the value is stored in CMake cache. This led to subtle bugs, where `usr/lib/swift_static/linux/static-stdlib-args.lnk` didn't contain certain flags on clean toolchain builds, but did contain them in incremental builds.
Not having these autolinking flags in toolchain builds leads to errors when statically linking executables on Linux.
Additionally, since are trivial tests previously didn't link Dispatch statically, the didn't expose a bug where `%import-static-libdispatch` substitution had a missing value. To fix that I had to update `lit.cfg` and clean up some of the related path computations to infer a correct substitution value.
Resolves some of the errors reported in https://github.com/apple/swift/issues/65097.
A workaround for the fact that fixing this in XCTest's repository
(https://github.com/apple/swift-corelibs-xctest/pull/441) is blocked on XCTest's
CI being broken for unrelated reasons (and ones which I cannot reproduce).
* Bump host tools deployment version for Darwin OS
* Update availability_define.swift
* Fix the test to use @backDeployed from @_backDeploy
---------
Co-authored-by: Mishal Shah <shahmishal@users.noreply.github.com>
build-script-impl: remove CMark cases as unused
CMark was converted from a `build-script-impl` product to `build-script` product in https://github.com/apple/swift/pull/37102. After that change, some of the remaining mentions of CMark in `build-script-impl` were unused and can be removed.
CMark was converted from a `build-script-impl` product to `build-script` product in https://github.com/apple/swift/pull/37102. After that change remaining mentions of CMark in `build-script-impl` were unused and can be removed.
This is the start of the removal of the C++ implementation of libSyntax
in favor of the new Swift Parser and Swift Syntax libraries. Now that
the Swift Parser has switched the SwiftSyntaxParser library over to
being a thin wrapper around the Swift Parser, there is no longer any
reason we need to retain any libSyntax infrastructure in the swift
compiler.
As a first step, delete the infrastructure that builds
lib_InternalSwiftSyntaxParser and convert any scripts that mention
it to instead mention the static mirror libraries. The --swiftsyntax
build-script flag has been retained and will now just execute the
SwiftSyntax and Swift Parser builds with the just-built tools.
This would be needed for two reasons:
* avoid that testing for PRs that use `LLVM_ENABLE_RUNTIMES` to build
compiler-rt may cause errors in unrelated PRs;
* avoid any fallout in CI should the above PRs be merged and
subsequently reverted for unforeseen regressions.
Addresses rdar://100762636
Cross-compilation of the host depends on iteration over all of the host
architectures within build-script-impl itself, so the computation of
the build directory must occur in build-script-impl. Sink it down there
to fix builds for multiple host architectures.
Using newer targets can lead to build failures, see
41c52889b9b87fc09dce
This has no effect currently, it is meant to support the switch
to `LLVM_ENABLE_RUNTIMES` to build compiler-rt -- #58465
Addresses rdar://99140817
Make libSyntax depend on swift-syntax: the new home for all
of this infrastructure. This greatly simplifies the addition and
amending of syntax nodes as only the swift-syntax paired with a
swift checkout will need to be changed. This is in contrast to
the existing build flow where a paired PR to both repos must be
made to change anything here.
Note that a paired PR may still be required if the legacy parser
needs to be adjusted in response to syntax nodes changing, but I
anticipate this to be a much more infrequent event now that
the C++ end of libSyntax is deprecated.
With a properly prepared sysroot and toolchain file, these changes permit
cross-compilation of Swift as well as LLVM, CMark, and Dispatch (picking,
as usual, apple/swift-corelibs-libdispatch#556) from a Linux host
generating OpenBSD binaries.
The toolchain file must be specified as an environment variable to
`build-script` and discussion on how to properly set up the sysroot and
toolchain file will be handled later.
