Widen the parser validation coverage.
This encourages the developers to implement the new grammar in
SwiftParser in addition to the old C++ parser.
In case there's an unavoidable reason not to implement in SwiftParser,
disable the validation for each test case by passing a frontend option
'-disable-experimental-parser-round-trip'. But please file an issue
and add FIXME like:
// FIXME: Remove '-disable-experimental-parser-round-trip' (rdar://xxx).
Instead of building SourceKit-LSP using SwiftPM's multi-arch xcbuild backend, build it for only one arch at a time and then run `lipo` to merge the two resulting binaries.
This should allow us to share build products between building installing and testing and also eliminates other quirks resulting from the xcbuild backend.
* Copy Testing modules/binaries in Install-Platform
* Copy full Testing.swiftmodule directory rather than individual files
* Fix Copy-Directory command
We pass `-stdlib=libc++` in the test-suite to
Clang for many of our tests because we want to
explicilty test against libc++ type layouts.
However, if we don't do this against a newly built
libc++ we risk testing against old/unexpected layouts
or if libc++ isn't available on the system, falling
back to the system libstdc++.
This patch adds libcxx as an explicit target in the preset
so the tests build against a fresh libc++ (as we do for
our other LLDB presets too).
[utils][presets] Build libc++ for LLDB on linux
We pass `-stdlib=libc++` in the test-suite to
Clang for many of our tests because we want to
explicilty test against libc++ type layouts.
However, if we don't do this against a newly built libc++ we risk testing against old/unexpected layouts or if libc++ isn't available on the system, falling back to the system libstdc++.
This patch adds libcxx as an explicit target in the preset so the tests build against a fresh libc++ (as we do for our other LLDB presets too).
rdar://136231390
We pass `-stdlib=libc++` in the test-suite to
Clang for many of our tests because we want to
explicilty test against libc++ type layouts.
However, if we don't do this against a newly built
libc++ we risk testing against old/unexpected layouts
or if libc++ isn't available on the system, falling
back to the system libstdc++.
This patch adds libcxx as an explicit target in the preset
so the tests build against a fresh libc++ (as we do for
our other LLDB presets too).
Reverts swiftlang/swift#72010, which causes a 1 hour regression in Linux build times. This is significantly higher than the original March numbers (~15 minutes). We should investigate where the extra time is coming from - possibly from the foundation and testing additions?
This removes the implementation of the `swift-indent` tool, its
associated documentation, and utilities. This tool was never completed
and has much better alternatives with `swift-format` which is more
flexible and actually maintained.
We have been using the host LLVM build directory to configure the Wasm
Swift stdlib. This has been working fine so far as the stdlib build is
configured with `CMAKE_SYSTEM_NAME` having host system name. However,
we fixed the stdlib build to use `WASI` as the system name properly in
the previous commit. This exposed the issue that the host LLVM build
directory is not suitable for configuring the stdlib build.
We didn't set the CMAKE_SYSTEM_NAME and CMAKE_SYSTEM_PROCESSOR when
cross-compiling stdlib for WASI. This caused the build to fail on macOS
host machines as the build system was trying to build some overlays
assuming the target is macOS.
Additionally, add a default "SWIFT_HOST_VARIANT_SDK" for WASI target
even though we don't support it as a host system yet because it's
required anyway.
