Some cases of using isSuperset can cause crashes, this was caused by improper subclassing callouts; this pr resolves those failures (and provides unit tests for that case)
The cases where the bridge was traversed too much now only causes a single bridge out call (without needing to reallocate or thrash retain/release)
String.components(separatedBy: CharacterSet) should be considerably faster now not only for more apporpriate bridging calls but also no longer needing to bridge arrays back and forth.
Resolves the following issues:
rdar://problem/17281998
rdar://problem/26611771
rdar://problem/29738989
This avoids indirection by making calls directly to the C implementations which prevents potentials of mismatched intent or changes of calling convention of @_silgen. The added benefit is that all of the shims in this case are no longer visible symbols (anyone using them was not authorized out side of the Foundation overlay). Also the callout methods in the headers now all share similar naming shcemes for easier refactoring and searching in the style of __NS<class><action> style. The previous compiled C/Objective-C source files were built with MRR the new headers MUST be ARC by Swift import rules.
The one caveat is that certain functions MUST avoid the bridge case (since they are part of the bridging code-paths and that would incur a recursive potential) which have the types erased up to NSObject * via the macro NS_NON_BRIDGED.
The remaining @_silgen declarations are either swift functions exposed externally to the rest of Swift’s runtime or are included in NSNumber.gyb which the Foundation team has other plans for removing those @_silgen functions at a later date and Data.swift has one external function left with @_silgen which is blocked by a bug in the compiler which seems to improperly import that particular method as an inline c function.
We still have a bunch of redeclarations of Dispatch functions to avoid
the automatic bridging of dispatch_data_t and dispatch_block_t, but
mostly this is a vast reduction in complexity (and increase in safety).
The problem here is a bit complicated. The symlink_clang_headers target creates two symlinks to clang's headers, one under the build directory at lib/swift/clang, and the other under a temporary path.
The one under the temporary path is a bad symlink, and it is only created during the build so that it can be installed. It isn't actually used by the build. Ninja treats the bad symlink as a non-existing file, and since the build rule that creates it has the restat property on it this results in the commands to symlink the clang headers directory running over and over and over again during the build.
This patch prevents that by not generating the bad symlink during the build. Instead we generate it at install time using the LLVMInstallSymlink script that is vended as part of LLVM's distribution.
* Fix DispatchSourceSignal initialisation such that it no longer
registers for the wrong source type.
* Remove (group:) option from DispatchWorkItem, introduce group
options to `.async` methods that accept DispatchWorkItem.
* Rename `DispatchSourceType` to `DispatchSourceProtocol`
* Rework DispatchQueue attributes and flags into a less confusing
approach.
* Fixes:
SR-1817, SR-1771, SR-1770, SR-1769
<rdar://problem/26725156> <rdar://problem/26873917>
<rdar://problem/26918843> <rdar://problem/26810149>
<rdar://problem/27117023> <rdar://problem/27121422>
<rdar://problem/27236887> <rdar://problem/27337555>
...and explicitly mark symbols we export, either for use by executables or for runtime-stdlib interaction. Until the stdlib supports resilience we have to allow programs to link to these SPI symbols.
Background: Clang has a set of base headers distributed with the compiler
that contain things like vector operations, stddef.h, and tgmath.h.
Swift also needs these headers in order to import C and Objective-C (not
really a surprise), so we symlink to them from lib/swift/clang/. When we
build installable packages, we actually copy them in.
Now the tricky part. Clang's headers are actually at a path like
"include/clang/3.6.0/include/tgmath.h". That "3.6.0" is the Clang version,
which allows multiple Clangs to be installed on a single system. Swift
currently links to the top-level directory, but of course it's only
guaranteed to work with a specific version of the Clang headers. So the
version number here is always the version of Clang we use to build Swift.
Rather than leave the (relatively meaningless) version number here, just
make the symlink point at the "3.6.0" directory rather than the "clang"
directory. This means Swift doesn't have to think about the version number
here at all.
rdar://problem/23223066
In cases where our major version of clang is different than the
installed clang this allows us to install the builtin headers ourselves.
This should be used judiciously, since it installs to a path 'owned' by
clang.
Swift SVN r32696
The standard library has grown significantly, and we need a new
directory structure that clearly reflects the role of the APIs, and
allows future growth.
See stdlib/{public,internal,private}/README.txt for more information.
Swift SVN r25876
