When enabled, compile in support for round-trip testing the new
SwiftSyntax-provided Swift parser alongside the existing parser. Right
now, this means parsing every source file with the new parser and
ensuring that the resulting syntax tree can reproduce the input source
precisely. Over time, this is expected to grow.
Opt in to this behavior by passing the following to build-script:
build-script --early-swiftsyntax --extra-cmake-options=-DSWIFT_SWIFT_PARSER_MODE:STRING=ROUNDTRIP
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.
Similar to the way the early Swift Driver is built, introduce a
build-script option `--early-swiftsyntax` that uses the host Swift and
CMake to build the parts of the swift-syntax package that are expected
to become be used in the compiler.
Note that this does not obviate the need for the `--swiftsyntax`
option, because that build product uses the just-built Swift compiler
and SwiftPM to build, test, and install everything from the
swift-syntax package.
Running swift test with `--test-product SourceKitLSPPackageTest` fails when cross-compiling with an error message like the following (rdar://97876450)
```
error: Could not find target named 'SourceKitLSPPackageTests_-6F17C3BE20775DA1_PackageProduct'
```
Since we don’t run the test on the cross-compile host anyway, just disable cross-compilation during testing.
As part of the build the entire ninja source dir is copied to the build
dir and then built. When using git's fsmonitor feature the .git
directory contains a socket which causes the copytree to fail. With this
change .git is ignored entirely instead. Error:
```
Traceback (most recent call last):
...
File "/Users/ksmiley/dev/oss-swift/swift/utils/swift_build_support/swift_build_support/build_script_invocation.py", line 69, in build_ninja
ninja_build.build()
File "/Users/ksmiley/dev/oss-swift/swift/utils/swift_build_support/swift_build_support/products/ninja.py", line 80, in build
shell.copytree(self.source_dir, self.build_dir)
File "/Users/ksmiley/dev/oss-swift/swift/utils/swift_build_support/swift_build_support/shell.py", line 193, in copytree
shutil.copytree(src, dest)
File "/Users/ksmiley/.pyenv/versions/3.10.2/lib/python3.10/shutil.py", line 556, in copytree
return _copytree(entries=entries, src=src, dst=dst, symlinks=symlinks,
File "/Users/ksmiley/.pyenv/versions/3.10.2/lib/python3.10/shutil.py", line 512, in _copytree
raise Error(errors)
shutil.Error: [('/Users/ksmiley/dev/oss-swift/ninja/.git/fsmonitor--daemon.ipc', '/Users/ksmiley/dev/oss-swift/build/buildbot_osx/ninja-build/.git/fsmonitor--daemon.ipc', "[Errno 102] Operation not supported on socket: '/Users/ksmiley/dev/oss-swift/ninja/.git/fsmonitor--daemon.ipc'")]
```
Currently, when building an open source toolchain, SourceKit-LSP is only built for x86_64. Copy the cross-compilation config from swiftpm.py to also produce a fat sourcekit-lsp executable for both x86_64 and arm64.
rdar://78039145
Previously, we were always cleaning the sourcekit-lsp build directory prior to running tests and installing. That’s a waste of time. Only clean prior to the first build.
The `__future__` we relied on is now, where the 3 specific things are
all included [since Python 3.0](https://docs.python.org/3/library/__future__.html):
* absolute_import
* print_function
* unicode_literals
* division
These import statements are no-ops and are no longer necessary.
This patch adds a zlib and static-zlib build product, respectively
producing a dynamic and static zlib library. This is a dependency of
building Foundation.
The library `six` provides compatibility between Python 2, and 3. It's no
longer necessary once we migrate of Python 2 completely.
Also remove any custom logic for Python 2 (the ones referenced by
a commentanyways).
https://bugs.swift.org/browse/SR-16025
In Python 3, subprocess output is read as binary data by default, which isn’t what we want.
Instead of reading process output as byte strings, then manually decoding them into strings, simply pass `text=True` to functions in the `subprocess` module, so that we get properly decoded strings right out the box.
This fixes places that forget to do the decoding step — most especially, the `update-checkout` script. That script prints Git output as byte strings, which leads to unreadable results.
Additionally, in shell.run, use the same pipe for capturing both stdout and stderr. The distinction is pretty pointless in this use case; however, keeping the two channels separate means that we lose the original ordering of printed messages, which does matter.
Internal configurations targeting Darwin employ ThinLTO to
improve compiler performance, however using it on all executable
causes build time to increase with no matching benefit.
To reduce build times in such configurations, we allow some
ancillary targets to opt out of LLVM IR optimizations when linking
ThinLTO with ld64 (e.g. tools used for bootstrapping or debugging the
Swift compiler) -- this behaviour is opt in through a new flag
`--swift-tools-ld64-lto-codegen-only-for-supporting-targets`.
Addresses rdar://76702687
