`SWIFT_RUNTIME_STDLIB_INTERNAL` does `extern "C"`, so we can't put these
in a namespace and have to use a C-style prefix instead.
Also slightly rearrange the code in `CommandLine.cpp`.
rdar://103397975
Instead of triggering a fatal error on failure, return `nullptr` and
let the caller decide what to do about it. The CommandLine code should
trigger a fatal error, of course.
rdar://103397975
In various places we need to call the Windows API, and because Swift uses UTF-8
for its string representation, we can’t call the ANSI API functions (because the
code page used for the ANSI functions varies depending on the system locale
setting). Instead, we need to use the wide character APIs.
This means that we need to convert UTF-8 to wide character and vice-versa in
various places in the runtime.
rdar://103397975
If the replaced symbol goes away in the original library, the
replacement key in the replacement descriptor will be null. Handle this
by ignoring the replacement entry rather than crashing.
rdar://103307821
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
Replace the `assert(false)` with `swift_unreachable`.
This is more robust in release builds where the `assert(false)` is a no-op and would result in a wrong fall-though to the next switch case.
Fixes a warning in release builds.
Rearrange the slow paths a bit to make them tail calls, which allows the compiler to emit these functions without frames.
Clang is happy to emit frameless functions on ARM64 if no stack space is needed on all execution paths. However, when there's a fast path which doesn't need stack space, and a slow path which does, clang emits code that pushes a stack frame and then decides which path to take. This is fine, but it means we're paying more than we'd like to on the fast path.
We can work around that by manually outlining the slow path, and ensuring that it's invoked with a tail call. Then the original function doesn't need a stack frame on any path and clang omits the stack frame.
We tweak RefCounts::increment to return the object it's being called on, which allows `swift_retain` to tail-call it. We manually outline the objc_retain call in swift_bridgeObjectRetain, which allows the swift_retain path to be frameless.
rdar://101764509
On ELF platforms we currently output an ELF note but with totally invalid
contents. I tried experimenting to see whether it was possible to do it
properly and tie the result into ReflectionContext, but it turns out to be a
hard problem because of issues to do with cross-segment symbol references and
relocations.
The upshot is that I think for now it's best just to remove it.
We might revisit this in future at some point; it would be good to be able to
reliably find the Swift metadata just from the ELF Phdrs.
rdar://101749382
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
In the general case, the compiler should add ptrauth instructions even
for simple pointer equality checks. We therefore need to manually avoid
these checks; making this workaround permanent.
This replaces a number of `#include`-s like this:
```
#include "../../../stdlib/public/SwiftShims/Visibility.h"
```
with this:
```
#include "swift/shims/Visibility.h"
```
This is needed to allow SwiftCompilerSources to use C++ headers which include SwiftShims headers. Currently trying to do that results in errors:
```
swift/swift/include/swift/Demangling/../../../stdlib/public/SwiftShims/module.modulemap:1:8: error: redefinition of module 'SwiftShims'
module SwiftShims {
^
Builds.noindex/swift/swift/bootstrapping0/lib/swift/shims/module.modulemap:1:8: note: previously defined here
module SwiftShims {
^
```
This happens because the headers in both the source dir and the build dir refer to SwiftShims headers by relative path, and both the source root and the build root contain SwiftShims headers (which are equivalent, but since they are located in different dirs, Clang treats them as different modules).
* initial
* it works
demangling mostly works
fix dots
printing works
add tests
add conformance to AnyKeyPath
implement SPI
subscripts fully work
comments
use cross platform image inspection
remove unnecessary comment
fix
fix issues
add conditional conformance
add types
try to fix the api-digester test
cr feedback: move impls behind flag, remove addChain(), switch statement, fallthrough instead of if-elses, move import
cr feedback: refactor switch statement
fix #ifdef
reindent, cr feedback: removes manual memory management
fix missing whitespace
fix typo
fix indentation issues
switch to regexes
checks should test in on all platforms
print types in subscripts
add test for empty subscript
Update test/api-digester/stability-stdlib-abi-without-asserts.test
Co-authored-by: Xiaodi Wu <13952+xwu@users.noreply.github.com>
add commas
fix failing test
fix stdlib annotation
cr feedback: remove global, refactor ifdef
cr feedback: switch back to manual memory management
switch to 5.8 macro
add new weakly linked functions to the allowlist
fix one more failing test
more cr feedback
more cr feedback
* fix invisible unicode
@differentiable function is actually a triple (function, jvp, vjp). Previously normal thick function value witness table was used. As a result, for example, only function was copied, but none of differential components.
This was the cause of uninitialized memory accesses and subsequent segfaults.
Should fix now unavailable TF-1122
Swift vtables can contain NULL entries. This happens when the compiler is able to prove that a method is never called.
When ptrauth is enabled, those NULL entries are still signed. However, there's an inconsistency in the runtime. Most places where we copy a vtable with swift_ptrauth_copy_code_or_data, we accept an unsigned NULL value. But when fixing up a dynamic ObjC subclass with swift_objc_classCopyFixupHandler, we don't.
Since the compiler seems to always sign these NULL values, this still works, except in the case where a signed NULL value coincidentally has a ptrauth signature of all zeroes. When that happens, the code to accept an unsigned NULL value sees this NULL with an all-zero signature as an unsigned NULL, and copies it verbatim. Then we really do have an unsigned NULL in the destination.
If that class is then dynamically subclassed, we'll call swift_objc_classCopyFixupHandler which does not accept unsigned NULL values, and fail ptrauth.
Adjust swift_objc_classCopyFixupHandler to accept unsigned NULL like the rest. These entries should never be called, and any attempt to call them will crash regardless, so it makes little difference.
rdar://92800322
