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.
Remove the option that explicitly enables concurrency back-deployment,
and instead always enable its support in the compiler. Remove the use
of the extraneous CMake option as well.
This is where I am going to put the stage 2 swift. The reason why I need to do
this is that I need libdispatch, foundation, etc on Linux to use the stage2
compiler.
When enabling the build of the back-deployable concurrency library via
the build-script option `--back-deploy-concurrency`, also build the
compiler and (main) concurrency library to support older deployment targets.
Building the compiler for older deployment targets is effectively the
same as implicitly passing
`-Xfrontend -enable-experimental-back-deploy-concurrency`. That option
should probably go away.
Building the primary _Concurrency library for back-deployment means
setting the "SwiftStdlib 5.5" availability back to the earlier
deployment targets. This should have no effect on how the _Concurrency
library binary is built, but it does ensure that the right
availability annotations are in the _Concurrency module.
Introduce an additional build product to build-script to build
back-deployable concurrency libraries. These libraries would need to
be embedded in apps deployed prior to macOS 12/iOS 15 to support
concurrency.
The built-script option `--back-deploy-concurrency` can be provided to
build these back-deployment libraries. They are built in addition to
the normal concurrency libraries, as a separate product that installs
into `lib/swift-5.5/<platform>` within the toolchain. The macro
`SWIFT_CONCURRENCY_BACK_DEPLOYMENT` is set when building the
concurrency library, so that we can adapt the implementation to older
OS's.
The key thing here is that by using this builder, I am going to be able to split
the build-script-impl pipeline in two and put in a build-script pipeline in
between. This is needed so that on Linux, we can build the stage 2 compiler
before we build any of the build-script-impl libraries that depend on having a
swift compiler.
This should be an NFCI change. I am relying on our build system unit tests to
ensure that I am not changing any real behavior.
Add three new flags, '--skip-clean-libdispatch', '--skip-clean-foundation', and
'--skip-clean-xctest', that leave the previous builds of those products in place.
This shrinks the number of lines in build-script by 50% and just makes it easier
to read. It will also enable me to refactor parts of it into pieces without
touching the main build-script file. This is really library code... build-script
itself doesn't care about how BuildScriptInvocation is actually implemented
under the hood.
For historical reasons, we configure and build standard library targets
differently depending on whether `stdlib-deployment-targets` is no set or set to
`[]`.
Add a test to make this need more explicit.
Addresses rdar://81651877
The key thing here is that certain options (such as the stdlib deployment
targets and what to build/test) now use stage_dependent_args meaning that when
we us a stage2 compiler we will automagically look up the same argument name,
but with '_stage2' as a postfix.
