We needed to add the `Runtime` module to the new build system, but
when I tried doing that, various things broke.
Firstly, we ended up with two targets with the name `swiftRuntime`,
but only in the static build (because in that build, everything
gets pulled in together, so CMake sees both of them). Rename the
one that's part of `swiftCore` to `swiftRuntimeCore`.
Second, we need some extra paths for the `Cxx` module and its
submodules, and since those are part of the `INTERFACE`, we need
to make sure we `PUBLIC` link them into the `Cxx` module so that
they get passed through when building `swiftRuntime`.
rdar://101623384
This change forces you to write ``@reparented` relationships
on an extension of a protocol, rather than on the protocol
itself.
The ProtocolConformance needs to be associated with some
GenericContext and IRGen expects it to be an ExtensionDecl.
That environment defines under what conditions the conformance
exists. We also need to define witnesses for the new parent's
requirements in an extension anyway, so it's a natural fit.
The previous workaround for this was kind of awful, as it'd
require searching all the protocol's extensions and "guess"
which extension they want to represent the conformance. While
we could try to synthesize an extension, there's two
challenges there:
1. Due to SuppressedAssociatedTypes, it's not so simple to
synthesize an unconstrained ExtensionDecl.
2. We currently rely on same-type requirements to pin the
associated types to particular witnesses of those requirements
in the extension. So it's not purely unconstrained! For example,
```
extension Seq: @reparented BorrowSeq where Iter == MyIter {}
```
The constraints that are disallowed (but not yet diagnosed)
are conditional conformance requirements, as the default
conformance for a reparenting cannot depend on those.
Thus, it's better that programmers to specify the extension.
This mode was effectively removed from `rth`
in ba04d49 because it was unused. I do need this
to exclude the before_after scenario, which is
linking a newer app with an older library.
Right now, the backtracer won't work on 32-bit Windows because we
aren't properly dealing with the `stdcall` calling convention on
the Win32 API calls.
rdar://101623384
On-crash backtracing is basically there for 64-bit Windows. It
won't work on 32-bit because of a Swift compiler issue, and there
is a little more work to do yet, but it is now working!
rdar://101623384
This doesn't have a working symbolicator yet, but it does build and
it can obtain a basic backtrace.
It also doesn't include a working `swift-backtrace` program yet.
rdar://101623384
While this functionality is extremely useful and can speed up
development iteration, it has not been well-maintained. Impose a
developer tax until we can figure out how to ensure that this path is
well maintained.
This reverts commit 1eaa52efdc.
build.ps1 was not synchronised with the CURL configuration changes. This
silently changes what is exactly specified to build (options were
renamed/replaced/removed/added).
The path in which the early SwiftDriver is installed depends on the
`build_variant` argument (set with `--release`, `--release-debuginfo`
and `--debug`), but build-script calculate it based off
`swift_build_variant`, which can be different from the former (e.g. when
we want to build only the compiler in debug configuration).
Update the curl configuration invocation to match the latest release.
This adds the missing flags and removes the flags which were dropped
upstream to ensure that we are able to identify the configuration.
This now demonstrates that we are missing PSL support which is enabled
by default upstream.
WasmKit 0.2.0 contains new functionality that allows enabling Wasm debugging tests in LLDB.
The version bump is not planned for 6.3, as Swift bootstrapping version for `release/6.3` CI jobs is too low: 5.9 as opposed to newly required Swift 6.0 in latest SwiftNIO and WasmKit versions.
This version bump is required to update WasmKit to 0.2.0 in a separate PR (https://github.com/swiftlang/swift/pull/86440), which itself is required to enable Wasm debugging tests in LLDB.
The version bump is not planned for 6.3, as Swift bootstrapping version for `release/6.3` CI jobs is too low: 5.9 as opposed to newly required Swift 6.0 in latest SwiftNIO and WasmKit versions.
The bare `REGEX` argument to `install(DIRECTORY ...)` actually does not filter out anything unless paired with `FILES_MATCHING` or `EXCLUDE`. PR #34190 added `FILES_MATCHING` so the clang resource-dir install only copies headers, but PR #34241 reverted it to unblock the Source Compat suite even though that meant copying the entire clang resource tree, including lib/.
Add SWIFT_STDLIB_INSTALL_ONLY_CLANG_RESOURCE_HEADERS so we can opt back into header-only installs without breaking toolchains that expect lib/swift/clang/lib.
Leave the flag off by default for compatibility and enable it for the wasm stdlib build so installing that package no longer copies host-side compiler-rt archives into Swift's resource directory.
This change should save 64mb of Wasm SDK size:
```
$ du -hd1 swift-6.2-RELEASE_wasm.artifactbundle/swift-6.2-RELEASE_wasm/wasm32-unknown-wasip1/swift.xctoolchain/usr/lib/swift/clang/lib/linux
64M swift-6.2-RELEASE_wasm.artifactbundle/swift-6.2-RELEASE_wasm/wasm32-unknown-wasip1/swift.xctoolchain/usr/lib/swift/clang/lib/linux
```
WASI sysroots installed libc++ and compiler-rt via the same runtimes mono build, leaving compiler-rt artifacts in the sysroot even though compiler-rt should belong under the compiler resource directory. That layout made it hard to package the WASI SDK correctly.
This patch modifies the WASI sysroot build to install compiler-rt under a separate resource directory so that we can copy the entire resource-dir's lib directory into the Swift resource dir.
