The Bionic modulemap was missing the autolinking information against
libm, so using the module math functions might have hit undefined
symbols (it was happening in TestDecimal in Foundation for me). The line
is present in the Linux glibc.modulemap, but was not there for Android
Bionic modulemap.
It is causing bots to fail.
* Revert "The __has_include(<os/system_version.h>) branch here wasn't quite right, we'll just use the dlsym one for now"
This reverts commit f824922456.
* Revert "Remove stdlib and runtime dependencies on Foundation and CF"
This reverts commit 3fe46e3f16.
rdar://54709269
interpolation of Int types in the new os_log APIs so that it is
easier to extend to other integer types. Based on this, add support
for interpolating Int32 types.
These were previously removed in SE-0246, so they weren't modified when Float80 was removed elsewhere on Android. Reverting SE-0246 on master triggers an Android break.
* Revert "Add availability information to the new Math function protocols (#24187)"
This reverts commit d2f695935f.
* Revert "SE-0246: Protocols and static functions (#23824)"
This reverts commit 57a4553832.
* Expected abi changes.
This commit introduces a CMake target for each component, adds install targets
for them, and switches build-script-impl to use the target `install-components`
for installation. Each of the targets for each component depends on each
of the individual targets and outputs that are associated with the
corresponding swift-component.
This is equivalent to what already exists, because right now install rules are
only generated for components that we want to install. Therefore, this commit
should be an NFC.
This is a resubmission (with modifications) of an earlier change. I originally
committed this but there were problems with some installation rules.
This improves code generation in -Onone mode. (UnsafeRawPointer.load/.storeBytes isn’t @_transparent and it doesn’t get specialized in unoptimized builds.)
AutoreleasingUnsafeMutablePointer is pointing to a +0 reference, but in its pointee property’s getter/setter implementations, it is loading the pointer into regular Unsafe[Mutable]Pointers. Those are assuming that the addressed memory contain a +1 reference, which can mislead the compiler into doing optimizations that aren’t valid.
Change the getter/setter implementations so that they use UnsafeRawPointer and load/store Unmanaged values instead. As long as Unmanaged.passUnretained(_:) and Unmanaged.takeUnretainedValue() do the right thing, then AutoreleasingUnsafeMutablePointer won’t have issues, either. (This boils down to ensuring that loading a strong reference out of an unmanaged(unsafe) value works correctly.)
Use the wrapper for the CC adjustment as on Windows x86, the destructor
needs to be `__stdcall`. This would fail otherwise with the following:
```
D:\a\1\s\swift\stdlib\public\stubs\ThreadLocalStorage.cpp(86,18): error: no matching function for call to '_stdlib_thread_key_create'
int result = SWIFT_THREAD_KEY_CREATE(&key, [](void *pointer) {
^~~~~~~~~~~~~~~~~~~~~~~
D:\a\1\s\swift\stdlib\public\stubs/../runtime/ThreadLocalStorage.h(96,35): note: expanded from macro 'SWIFT_THREAD_KEY_CREATE'
^~~~~~~~~~~~~~~~~~~~~~~~~
D:\a\1\s\swift\include\swift/Basic/Lazy.h(42,27): note: expanded from macro 'SWIFT_ONCE_F'
::std::call_once(TOKEN, FUNC, CONTEXT)
^~~~
D:\a\1\s\swift\stdlib\public\stubs\ThreadLocalStorage.cpp(43,1): note: candidate function not viable: no known conversion from '(lambda at D:\a\1\s\swift\stdlib\public\stubs\ThreadLocalStorage.cpp:85:3)' to '__swift_thread_key_destructor _Nullable' (aka 'void (*)(void *) __attribute__((stdcall))') for 2nd argument
_stdlib_thread_key_create(__swift_thread_key_t * _Nonnull key,
^
```
Instruments relies on the old values being there so it can call the original implementation. This has very slightly worse codegen but the impact should be minimal.
Add code to the 5.0 compatibility library that scans for conformances pointing to a NULL type and rewrites them to point to a dummy type that the 5.0 protocol conformance checking code will safely ignore.
An extension on a class creates a conformance record that's always visible even when that class is not present at runtime. In that case, the type pointer in the conformance record is NULL. The runtime did not like this, and crashed. This fixes it to ignore such records instead.
rdar://problem/54054895
