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.
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-swift to Python3.
These modules are part of the experimental declarative string processing feature. If accepted to the Standard Library, _StringProcessing will be available via implicit import just like _Concurrency, though _MatchingEngine will still be hidden as an implementation detail.
`_MatchingEngine` will contain the general-purpose pattern matching engine ISA, bytecode, and executor. `_StringProcessing` will contain regular expression and pattern matching APIs whose implementation depends on the matching engine..
Also consolidates frontend flag `-enable-experimental-regex` as `-enable-experimental-string-processing`.
Resolves rdar://85478647.
The latest Long Term Support NDK finally removed binutils, including the bfd/gold
linkers and libgcc. This simplifies our Android support, including making lld the
default linker for Android. Disable three reflection tests that now fail, likely
related to issues with swift-reflection-dump and switching to lld.
The latest Long Term Support NDK finally removed binutils, including the bfd/gold
linkers and libgcc. This simplifies our Android support, including making lld the
default linker for Android. Disable three reflection tests that now fail, likely
related to issues with swift-reflection-dump and switching to lld.
Also, add the libatomic dependency for Android armv7, just as on linux.
Instead, link all binaries in the toolchain using SwiftSyntax (currently only `sk-stress-test`) should link to the binary statically. This simplifies the way SwiftSyntax is built and at the same time slightly reduces the toolchain size.
Adding build modes for libswift: off, hosttools, bootstrapping, bootstrapping-with-hostlibs
The two bootstrapping modes are new. For details see libswift/README.md
This change adds support for WASI to `StdlibDeploymentTarget` in `swift_build_support/targets.py`. This will allow us to build stdlib for WASI in the future.
Related to SR-9307.
Prior to this, build-script products that build in the host-specific
directories for cross-compilation would get the wrong path, and
therefore wouldn't get picked up in toolchain builds.
