WASI with Embedded Swift provides WASI-libc and libc++ headers necessary to build the `_Concurrency` module for Wasm. We now add `wasm32-unknown-wasip1-wasm` triple to `EMBEDDED_STDLIB_TARGET_TRIPLES` when `SWIFT_WASI_SYSROOT_PATH` is set, which builds the necessary stdlib slice.
---------
Co-authored-by: Yuta Saito <kateinoigakukun@gmail.com>
If the directory where the build time log is supposed to go doesn't
exist, create it. The append file mode will create files, but won't
create directories. When we start building ninja, we haven't necessary
created the build directory yet, so this results in an error about the
missing directory when writing the build time log.
The ninja builder took a host argument that was unused by the function.
The ninja build failed to pass this argument, resulting in
an execution failure. Removing the argument.
Instead of using `--build-ninja` to decide to build ninja, build it
automatically if a sufficiently new enough version is not available.
Also record the build time taken to build the local Ninja so that we can
see how much time we would save by stashing a pre-built Ninja in CI.
Ninja builds its tests by default.
We don't run the Ninja test suite, we aren't doing development on Ninja,
and we are using a release tag that has been verified to work. There
isn't much point in building the tests if we're not going to use them.
Disabling building the Ninja tests. If it is desirable to build them,
one can set `BUILD_TESTING` to `YES` and re-run their build.
This patch switches the Ninja build from using the configure.py script
to building with the just-built CMake.
The configure.py in Ninja 1.11.1 still uses Python 2.7, importing the
`pipes` module. The pipes module was deprecated in Python 3.11 and
removed in 3.13, so folks using newer versions of Python are running
into issues with this.
The CMake build doesn't have this issue and is also perfectly valid, so
we can switch to that.
This patch updates the CMake-building mechanism to avoid
re-bootstrapping CMake if we already bootstrapped one that is new
enough.
I've made it so that all paths through the function return the path to a
CMake so we can use the result of the function as the cmake path without
having to check.
The function will choose one of the following ways of getting CMake in
order of preference:
- One we already built
- The system CMake
- Bootstrapping one from scratch
It prefers one we built over checking the system CMake because, if we
have already built a CMake previously, it's a good indication that
there either was no system CMake installed, or it wasn't new enough. We
shouldn't waste time checking it again if a previous run detected that
it wasn't good enough.
The system CMake is preferable to building one from scratch if we don't
need to though, so we determine if the system CMake is sufficient.
Finally, if one that we built either doesn't exist, or isn't new enough,
and the system either doesn't have a CMake, or a new enough CMake, build
one. It is built into the location that we are checking for caching, so
the next time we run build-script, it should hit the first case and
choose the already-built CMake instead of building it again.
Include the CMake bootstrap time in the build-script build times.
We're including everything else. Would be good to determine how much
time we can save by caching a new enough pre-built CMake in the builder
images.
Importing the log_time_in_scope exposes a cyclic dependency cycle
between the `swift_build_support` and `build_swift` python modules in
such a way that the tests fail due to re-importing parts of build_swift:
```
ImportError: Failed to import test module: tests.build_swift.test_migration
Traceback (most recent call last):
File "/usr/lib/python3.8/unittest/loader.py", line 436, in _find_test_path
module = self._get_module_from_name(name)
File "/usr/lib/python3.8/unittest/loader.py", line 377, in _get_module_from_name
__import__(name)
File "/home/build-user/swift/utils/build_swift/tests/build_swift/test_migration.py", line 14, in <module>
from build_swift import migration
File "/home/build-user/swift/utils/build_swift/build_swift/migration.py", line 18, in <module>
from swift_build_support.swift_build_support.targets import \
File "/home/build-user/swift/utils/swift_build_support/swift_build_support/targets.py", line 15, in <module>
from . import cmake
File "/home/build-user/swift/utils/swift_build_support/swift_build_support/cmake.py", line 26, in <module>
from swift_build_support.swift_build_support.utils import log_time_in_scope
File "/home/build-user/swift/utils/swift_build_support/swift_build_support/utils.py", line 20, in <module>
from build_swift.build_swift.constants import SWIFT_BUILD_ROOT
ModuleNotFoundError: No module named 'build_swift.build_swift'
```
I've put the import of log_time_in_scope into the function definition
to ensure that build_swift has been fully loaded by the time we need
log_time_in_scope, ensuring that there is order between the two pieces.
Python caches the imported module, so if we accidentally re-import the
log_time_in_scope, nothing actually changes.
This re-orders the instantiation of the BuildScriptInvocation object so
that it comes before the creation of the CMake path. This ensures that
BuildScriptInvocation() does not delete the build log after logging the
CMake bootstrap time. This is fine because the toolchain and arguments
are reference types, so updating the CMake path in both of those will be
reflected in the copy taken in the BuildScriptInvocation() object.
What is nice about this is that by not using extra-cmake-args, we can avoid
passing this into LLVM as well when attempting to reproduce failures on the bots
(thus avoiding having to rebuild LLVM as well).
I have been doing this using extra-cmake-args/etc... just feels better to have
an actual option to do this.
Just did this quickly while waiting for my Linux build to finish that uses
extra-cmake-args to set the linker.
This was quite brittle and has now been superseded
by swift-xcodegen. Remove the CMake/build-script
logic for it, leaving the option behind to inform
users to switch to using xcodegen instead.
When adding a Swift Testing test to Swift PM repository, the `test`
portion of t he OSX package pipeline was building against x86_64 and
arm64.
Ensure Swift PM testing only runs against the host platform
architecture.
The main goal of this change is to ensure that the new build of the
stdlib matches the same level of verbosity of the compiler build that
spawn it.
For now I'm not matching this behaviour to the regular CMake build
products (which would be needed if want to target external projects
configured in LLVM).
Addresses rdar://144256800
* Reapply '[BuildSystem] Stop building for i386-watch-simulator (#77692)'
* [BuildSystem] Stop building for i386-watch-simulator
In Xcode16 it is not supported.
This initially broke client projects who were still building the legacy
architecture but now that's resolved.
`JSONEncoder` by default will escape slashes, which results in a string
that isn't technically valid Base64. Since that behaviour is optional,
turn it off, and at the same time tell it to output in lexical key
order, which makes the test slightly simpler (no `CHECK-DAG` needed).
Also fixed a typo in `test_swift.py`
rdar://124913332
Move the backtracing code into a new Runtime module. This means renaming
the Swift Runtime's CMake target because otherwise there will be a name
clash.
rdar://124913332
* Make pointer bounds non-experimental
* Rename @PointerBounds to @_SwiftifyImport
* Rename filenames containing PointerBounds
* Add _PointerParam exception to stdlib ABI test
* Add _PointerParam to stdlib API changes
* Rename _PointerParam to _SwiftifyInfo
* Revert "[Build] Fix swift_build_support tests."
This reverts commit fc2d1b3b23.
* Revert "[BuildSystem] Stop building for i386-watch-simulator (#77692)"
This reverts commit 1ab968d2b6.
This change can't be made without other issues fixed downstream first.
However, to do this, we end up changing how amd64 is supported too.
Previously, I had tried to keep some meaningful separation between
platform spelling and LLVM spelling, but this is becoming more difficult
to meaningfully maintain.
Target specifications are trivially converted LLVM triples, and the
module files are looked up by LLVM triples. We can make sure that the
targets align, but then the Glibc to SwiftGlibc import breaks. That could
also be addressed, but then we get to a point where the targets set up
by build-script and referenced by cmake begin to misalign. There are
references in build-script-impl for a potential renaming site, but it's
not quite enough.
It's far simpler to give up and rename to LLVM spellings right at the
beginning. This does mean that this commit is less constrained to just
adding the necessary parts to enable arm64, but it should mean less
headaches overall from differing architecture spellings.
As of a recent fix included in LLVM 17[1] and wasi-libc fix[2], we can
enable `LIBCXX_ENABLE_FILESYSTEM` in libcxx build for WebAssembly/WASI.
This allows us to use `<filesystem>`, `<fstream>`, etc in C++ code.
[1]: 66a562d22e
[2]: https://github.com/WebAssembly/wasi-libc/pull/463
Windows has a strict limit on the file path, and use of extended names
for the build is not possible. Rather than hardcoding the location of
the early swift-driver build, allow the user to specify the path. If the
path is specified, we will attempt to copy `swift-driver` and
`swift-help` from that location. Adjust the code to account for the
build executable suffix. This should allow Windows to experiment with an
early swift-driver build.
Add @PointerBounds macro
@PointerBounds is a macro intended to be applied by ClangImporter when
importing functions with pointer parameters from C headers. By
leveraging C attributes we can get insight into bounds, esapability, and
(eventually) lifetimes of pointers, allowing us to map them to safe(r)
and more ergonomic types than UnsafePointer.
This initial macro implementation supports CountedBy and Sizedby, but
not yet EndedBy. It can generate function overloads with and without an
explicit count parameter, as well as with UnsafeBufferPointer or Span
(if marked nonescaping), and any of their combinations. It supports
nullable/optional pointers, and both mutable and immutable pointers.
It supports arbitrary count expressions. These are passed to the macro
as a string literal since any parameters referred to in the count
expression will not have been declared yet when parsing the macro.
It does not support indirect pointers or inout parameters. It supports
functions with return values, but returned pointers can not be bounds
checked yet.
Bounds checked pointers must be of type Unsafe[Mutable]Pointer[?]<T>
or Unsafe[Mutable]RawPointer[?]. Count expressions must conform to
the BinaryInteger protocol, and have an initializer with signature
"init(exactly: Int) -> T?" (or be of type Int).
rdar://137628612
---------
Co-authored-by: Doug Gregor <dgregor@apple.com>
