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.
Since a4e9109 (#17396), both the hashes and the equality of numeric
types inside of AnyHashable do not follow the rules that this part of
the comment was talking about.
I couldn't find an easy example that shows the same behaviour, so I
decided to remove the comment completely.
Since the `_FDOutputStream` type does not conform to a protocol, the
required interface was missed. The changes in
fbce6e7873 introduced a use of the
`isClosed` property which broke the Windows build. This should fix the
windows build.
LLVM r355981 changed various intrinsic functions, including expect,
to require immediate arguments. Swift's _branchHint function has an
expected value that is passed in as an argument, so that it cannot
use LLVM's expect intrinsic. The good news is that _branchHint is only
ever used with immediate arguments, so we can just move the intrinsic
into _fastPath and _slowPath and use those instead of _branchHint.
As was noted in the documentation, the _fastPath and _slowPath names are
confusing but we have passed the point where we can simply rename them.
We could add new names but would still need to keep the old ones around
for binary compatibility, and it is not clear that it is worth the
trouble. I have removed that note from the documentation.
When testing runtime lookup changes, we want to make sure each test runs in isolation. Add a new modifier, `.requireOwnProcess()`, to enable tests to guarantee they’re run in isolation.
This caused an issue where the runtime was unable to find subclasses of
resilient subclasses of NSObject until they were first registered by their
sugared name with NSClassFromString or were instantiated directly.
rdar://48892003
A suite of Swift overlays to vDSP operations for vector-vector extrema, absolute and negation, in-place reversing and sorting, and single-vector arithmetic.
