Create a version of the metadata specialization code which is abstracted so that it can work in different contexts, such as building specialized metadata from dylibs on disk rather than from inside a running process.
The GenericMetadataBuilder class is templatized on a ReaderWriter. The ReaderWriter abstracts out everything that's different between in-process and external construction of this data. Instead of reading and writing pointers directly, the builder calls the ReaderWriter to resolve and write pointers. The ReaderWriter also handles symbol lookups and looking up other Swift types by name.
This is accompanied by a simple implementation of the ReaderWriter which works in-process. The abstracted calls to resolve and write pointers are implemented using standard pointer dereferencing.
A new SWIFT_DEBUG_VALIDATE_EXTERNAL_GENERIC_METADATA_BUILDER environment variable uses the in-process ReaderWriter to validate the builder by running it in parallel with the existing metadata builder code in the runtime. When enabled, the GenericMetadataBuilder is used to build a second copy of metadata built by the runtime, and the two are compared to ensure that they match. When this environment variable is not set, the new builder code is inactive.
The builder is incomplete, and this initial version only works on structs. Any unsupported type produces an error, and skips the validation.
rdar://116592420
The Runtime/backtrace test is a test of the fatalError() backtracer,
which gets turned off when we have the new backtracer enabled. So,
to make this test work, we need to turn off the new backtracer.
rdar://117470489
When forming runtime metadata for a function type that has either `any
Error` or `Never` as the specified thrown error type, drop the thrown
error type and normalize down to (untyped) `throws` or non-throwing,
as appropriate.
Extend function type metadata with an entry for the thrown error type,
so that thrown error types are represented at runtime as well. Note
that this required the introduction of "extended" function type
flags into function type metadata, because we would have used the last
bit. Do so, and define one extended flag bit as representing typed
throws.
Add `swift_getExtendedFunctionTypeMetadata` to the runtime to build
function types that have the extended flags and a thrown error type.
Teach IR generation to call this function to form the metadata, when
appropriate.
Introduce all of the runtime mangling/demangling support needed for
thrown error types.
The problem was that in the by-address emission, we were calling
`getAddressForInPlaceInitialization` twice, triggering the assert.
The first time in `emitExprInto` for the normal result case.
The second time to obtain the address again when generating the
catch block to inject a `.none` into that same address.
This patch does a light refactoring to more closely mirror
`visitOptionalEvaluationExpr`, which avoids calling the asserting method.
fixes rdar://80277465
In LLVM unified builds `%swift_obj_root` points to `<LLVM build dir>/tools/swift`,
and folders like `bin`, `lib` and `share` are not under `swift_obj_root`, which
makes some tests fail.
For the cases in which `%swift_obj_root/lib` was used, replace it by
using `%swift-lib-dir` instead. Replicate `%swift-lib-dir` to create
`%swift-bin-dir` and `%swift-share-dir`, and use those instead of
`%swift_obj_root/bin` and `%swift_obj_root/share`.
This alternates work both in Swift build-script builds and also in LLVM
unified builds.
* [Executors][Distributed] custom executors for distributed actor
* harden ordering guarantees of synthesised fields
* the issue was that a non-default actor must implement the is remote check differently
* NonDefaultDistributedActor to complete support and remote flag handling
* invoke nonDefaultDistributedActorInitialize when necessary in SILGen
* refactor inline assertion into method
* cleanup
* [Executors][Distributed] Update module version for NonDefaultDistributedActor
* Minor docs cleanup
* we solved those fixme's
* add mangling test for non-def-dist-actor
`remote-run` should look in the environment for input/output paths as
well as considering command line arguments.
With this change, `test/Runtime/Paths.cpp` should work for remote testing
and device testing.
rdar://106294557
We need to be able to locate `swift-backtrace` relative to the current
location of the runtime library.
This needs to work:
* In a Swift build directory.
* On Darwin, where we're installed in /usr/lib/swift and /usr/libexec/swift.
* On Linux, where we're in /usr/lib/swift/linux and /usr/libexec/swift/linux.
* On Windows, where we may be in a flat directory layout (because of limitations
of Windows DLL lookups).
rdar://103071801
These tests were targeting 10.9 or 10.10, but the minimum deployment target now supported by Xcode is 10.13. Bump them up to match:
test/Concurrency/Backdeploy/linking.swift
test/Concurrency/Backdeploy/linking_maccatalyst.swift
test/Runtime/stable-bit-backward-deployment.swift
When compiled with optimizations, the compiler saw that C() doesn't escape and stack promoted it, which breaks the check. Deliberately escape the object into a global array beforehand to ensure it has to be on the heap.
rdar://103369708
When deallocating a class instance, we check the retain count of the instance and error if it's greater than 1.
Self is allowed to be temporarily passed to other code from deinit, but there's no way to extend the lifetime of the object. Retaining it no longer extensd the lifetime. If self escapes from deinit, the result is a dangling pointer and eventual crash.
Instead of crashing randomly due to a dangling pointer, crash deliberately when destroying an object that has escaped.
rdar://93848484
We're supposed to expose bridgeObjectRetain/Release_xN variants, but they were missing. This fixes the custom_rr_abi.swift test. Also remove the redundant extern "C" on the entrypoint definitions, which fixes some warnings.
rdar://102793667 rdar://102783074
* Backdeploy swift_task_future_wait
This patch adds the implementation for `swift_task_future_wait`
entrypoint to the backdeploy library.
This involves pulling in `AsyncTask::waitFuture`, which relies on a fair
bit.
Please note, this pulls in the `StaticMutex` implementation from Swift
5.6. There are some challenges here. The concurrency version of the
`StaticMutex` involves a fairly nasty set of ODR violations in the
normal setup. See `public/Concurrency/Mutex.cpp`, which includes the
Mutex implementations cpp files directly, while defining a single macro
to replace the implementation of swift::fatalError with
swift_concurrency_fatalError. We only need the concurrency mutex (at
least for now), so I have hard-coded the `swift_concurrency_fatalError`
version into this library. If we should need the other implementation,
we are forced to include ODR-related undefined behavior.
We need symbols from C++, so I've added an implicit linker flag whenever
the static library is used, namely, it passes `-lc++` to the linker.
Since we only backdeploy on Apple platforms, this should be fine.
Some of the platform runtimes we need to backdeploy to have the
enter/exitThreadLocalContext functions defined, while others don't. We
define our own backdeploy56 shim function that dlsym's the function
pointer for these symbols if we have exclusivity checking available.
Otherwise, it doesn't do anything. If concurrency exclusivity checking
is available, we'll use it, otherwise we wont'.
The same dlsym check is done for `swift_task_escalate`. Not all
platforms we need to backdeploy to have a concurrency runtime. The
symbols that do need to use pieces of the concurrency runtime should not
be getting hit when deploying to systems that don't have concurrency. In
the event that you've gotten around the language blocking you from
calling these symbols and you've managed to call concurrency pieces
without using concurrency, we'll abort because something is seriously
wrong.
* Backdeploy swift_task_future_wait_throwing
Drop the remaining pieces in for adding
`swift_task_future_wait_throwing`.
* Apply task_wait_future fix
Actually apply the fix from ef80a315f8.
This deviates slightly from the original patch.
AsyncTask::PrivateStorage::_Status() does not exist in the Swift 5.6
library. Instead I am using `AsyncTask::PrivateStorage::Status`.
* Workaround missing compiler-rt linking
Working around the missing link against compiler-rt in these test.
They are a bit brittle as if anything in them uses compiler-rt, they
will start failing. The backdeploy 5.6 library uses some symbols from
compiler-rt, thus causes them to fail to link.
Disabling the runtime compatibility version checking to avoid these
symbols. This should be fine for the MicroStdlib test, but we should fix
'%target-ld' to handle this better in the future.
rdar://100868842
Fix a potential false positive if we check a class for a protocol conformance and its superclasses aren't yet instantiated.
This was partially fixed before, but we were incorrectly saying that all superclasses had been instantiated if they had been instatiated by the LAST check in conformsToProtocol. That left us open for a possible false positive in an earlier check to go unnoticed.
This change fixes it by checking for uninstantiated superclasses after each iteration over superclasses, not just the last one.
This change also makes the concurrentTypeByName test much more robust. The original test caught this bug only rarely, but the new one catches it it reliably. We now look up 1000 types per test run. Testing locally, we typically hit the race after less than 100 types.
rdar://82364236
Use 2021 OS versions instead of far-future OS versions. We have versions with the fix now, so we don't need the far-future versions. Using them breaks things when building against a newer SDK and running on an older OS, because the system assumes stuff on the newer OS is available when it isn't.
The "nested private generic types in associated type witnesses" test is failing in back-deployment tests. Disable that one test, and re-enable the rest.
