In Android ARMv7 there was no alias defined for CLongDouble, so
importing anything with long double was failing. Defining the alias
makes the test pass.
AAPCS64 defines long double as 128 bits, which is still unsupported by
Swift (SR-9072). Disable this particular test for Android and Linux in
AArch64 to not fail (but still test all the other tests).
This adds a new tail-allocated field to class context descriptors storing
a pointer to an Objective-C class stub.
When the stub is present, we use the new _objc_realizeClassFromSwift()
entry point to realize the class instead of calling objc_readClassPair().
This should attach categories to the realized class, if they were emitted
to reference the stub.
When compiling SwiftOnoneSupport, issue errors for missing functions which are expected in the module.
This ensures ABI compatibility.
rdar://problem/48924409
It's very unlikely that those functions are really referenced by Onone executables, but we want to be ABI compatible.
Also, there is no guarantee that this version of SwiftOnoneSupport will always trigger all symbol to be pre-specialized.
If the optimizer changes, we might need to add other explicit pre-specializations of internal stdlib symbols.
rdar://problem/48924409
[stdlib] Make unsafe array initializer public
This implements SE-0245. The public versions of this initializer call
into the existing, underscored version, which avoids the need for
availability constraints.
I refactored some of the if statements in URL.swift to be guard instead.
This made the code shorter and easier to read.
This mirrors my commit on swift-corelibs-foundation (PR #2034)
* Teach the importer to import any vector type as SIMDN<Scalar>.
Instead of having a known set of vector types, check to see if the
element type conforms to SIMDScalar; if it does, see if we have a
SIMDN defined with the right number of elements. If both are satisfied,
import the vector type as that Swift type.
By making this change, we gain the ability to import vector types
that aren't defined in terms of the Darwin simd module, which lets
us use C API with vector types on other platforms. It also lets us
import *every* vector type that Swift can represent, rather than the
small subset that are currently hardcoded.
* Increased test coverage for increased SIMD types that we can import.
Includes some minor cleanup from review. Also eliminates the old
simd_sans_simd test, since we can now import all of these types even when the simd module isn't imported.
On Swift 5, using the deprecated `SIMD.init(_ scalar: Scalar)` initialiser rather than `SIMD.init(repeating scalar: Scalar)` will cause the type to fail to be specialised, resulting in performance degradation. Mark this method and `static prefix func -` as `@_transparent` to ensure they are correctly specialised.
The install_name trick we are using to make sure that an application
built with a deployment target new enough to *guarantee* that Swift
will be available in the OS (and therefore don't need dylibs bundled)
link directly to /usr/lib/swift/*.dylib, but rewrites the the library
paths to be rpath-relative for older OS's (e.g.,
@rpath/lib/swift/libswiftCore.dylib) doesn't work for sub-minor
version numbers, e.g., the tools can't distinguish between 10.14.4 and
10.14. Therefore, macOS 10.14 is both an "older OS" and a "newer OS".
Hack around the primary problem caused by this---the inability of
first-party Swift programs to launch on macOS 10.14.4---by treating
macOS 10.14 as an "older OS" when building for the Xcode toolchain
(which is used by anyone who will deploy back to an older OS, e.g.,
3rd party applications) but treat it as a "newer OS" when building for
the OS toolchains (which is used when building the OS itself).
Fixes rdar://problem/47007519.
Magic symbols of the form $ld$install_name$os9.0$@rpath/libswiftCore.dylib tell the linker to use that install name when targeting that OS version. Use these symbols to specify an @rpath install name for all back-deployment libraries when targeting watchOS 2.0-5.1, iOS 7.0-12.1, and macOS 10.9-10.14.
rdar://problem/45027809
Bring formatting closer in line with the rest of the standard lib, remove "public" from extensions (moving it onto the contents defined therein). Restore Swift project headers that were apparently lost at some point.
