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
This reverts commit a67a0436f7, reversing
changes made to 9965df76d0.
This commit or the earlier commit this commit is based on (#40531) broke the
incremental bot.
In python3, 'filter' returns an interable which doesn't support using
'len()'. This switches to a list comprehension, so that we can check the
length of 'enabled_pipeline'.
This is required to move build-script to Python3.
- Checkout apple/swift-experimental-string-processing using a tag.
- Build `_MatchingEngine` as part of libswift (`ExperimentalRegex`) using sources from the package.
- Parse regex literals using the parser from `_MatchingEngine`.
- Build both `_MatchingEngine` and `_StringProcessing` as part of core libs using sources from the package.
- Use `Regex<DynamicCaptures>` as the default regex type until we finalize apple/swift-experimental-string-processing#68.
* add an option to add freestanding to the Darwin platform, so that
to get expected compile behaviours (e.g. setting the install name)
* rework testing configuration to relax assumptions about freestanding
* add a preset to test such configuration (at least for PR testing)
Addresses rdar://85465396
To that end, move the --cross-compile-deps-path flag from build-script-impl to a
publicly documented build-script flag and use it for build-script products'
library dependencies too. Generate a SPM destination JSON file that can be used
both for cross-compiling these build-script products and by users for their own
Swift packages.
Also, add a native_toolchain_path() method, that uses a prebuilt toolchain if
available, and pass an install prefix in to swift-driver and sourcekit-lsp.
