- Correctly construct cmake cmdline for wasmstdlib including cmake common host options. This is required in order to include e.g. `CMAKE_OSX_SYSROOT` on macOS, etc.
- Ensure we're passing path to newly-built SDK to sil-opt
This makes almost every AutoDiff tests passing for Wasm target (the only exception is `AutoDiff/validation-test/always_emit_into_client/multi_module_struct_no_jvp.swift` as `expectCrash()` is not working properly on Wasm.
The object returned by a failing command invocation is a bytes object,
which cannot be concatenated with a string directly. Decode it and split
it to make the missing symbol list clearer.
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
This library dependency is already present in the Android SDK builds.
Replicate the dependency in the checkouts to allow building for the
Android SDK on non-Linux platforms.
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.
Anton Korobeynikov
Saleem Abdulrasool
Evan Wilde
Charles Zablit
Alastair Houghton
Michael Gottesman
Michael Gottesman
Kavon Farvardin
Saleem Abdulrasool
finagolfin
Hamish Knight
eeckstein
Eric Miotto
Max Desiatov
Rintaro Ishizaki
Eric Miotto