swift_getInitializedObjCClass called [c class] to trigger class initialization, and returned the value. This wreaked havoc when the class in question overrides +class. Instead, ignore the return value and return c. Switch from +class to +self, which is much less likely to be overridden. Calling an overridden method could have performance downsides or even cause unwanted side effects.
rdar://problem/49853091
In the Android paths of the spawnChild function, the parent was creating
a pipe that was never closed, which led to FD starvation. In some tests
with a lots of expected crashes, the childs will not spawn anymore since
the linker would not have enough descriptors to open the shared
libraries, while in other tests which closed the child descriptors as
part of the last test, the parent process will hang waiting those
descriptors to be closed, which will never had happened.
The solution is implement the missing parts of the code, which tried to
read from the pipe in the parent side (using select and read, taking
pieces from other parts of the code). This should match the fork/execv
path used by Android and Haiku to the spawn code used by the rest of the
platforms.
This change fixes StdlibUnittest/Stdin.swift,
stdlib/InputStream.swift.gyb,
stdlib/Collection/FlattenCollection.swift.gyb and
stdlib/Collection/LazyFilterCollection.swift.gyb, which were the last 4
tests failing in Android AArch64.
These would never be decoded in normal use, but it's possible to construct an archive that will attempt to decode them. Without this override, that throws an exception or worse.
rdar://problem/48429185
`String.+=` function to `String.append` function, and use a new
semantics attribute for String.+=.
Teach the constant evaluator about `String.Append` instead of `String.+=`.
A buffer's `rowBytes` doesn't have a direct relationship with its `height`, so `rowBytes / Int(width)` isn't a good way to calculate pixel size. To resolve this, I've added `pixelSize` as a parameter to `vImage_Buffer.copy`.
Now that that's stabilized, we don't have to keep them in Swift 4 mode
any longer. (Arguably we don't need the CMake variable at all, but it
may be useful again in the future.)
rdar://problem/49040980
* Add availability information to the new Math function protocols
The protocols ElementaryFunctions, RealFunctions, and Real are new in Swift 5.1 and accordingly need to have availability attached to them for platforms that are ABI-stable. The actual implementation hooks (static functions) are unconditionally defined on scalar types and marked @_alwaysEmitIntoClient, so they are available even when targeting older library versions, but the protocols themselves, and anything defined in terms of them (the global functions and the SIMD extensions) is only available when targeting library versions that have the new protocols.
* Additionally provide concrete implementations of signGamma for each stdlib-builtin floating-point type.
* Remove Real[Functions] protocols pending re-review
Temporarily pull these back so we can make minor tweaks to the design and get a re-review on SE.
We could introduce non-nominal-type context descriptors, such as those for opaque declarations,
which are also interesting to be able to look up for reflection or remote purposes. This should be
a backward compatible change with old runtimes, which always ignore any context descriptor kind
they don't know about.
This allows the conversion of the Windows `BOOL` type to be converted to
`Bool` implicitly. The implicit bridging allows for a more ergonomic
use of the native Windows APIs in Swift.
Due to the ambiguity between the Objective C `BOOL` and the Windows
`BOOL`, we must manually map the `BOOL` type to the appropriate type.
This required lifting the mapping entry for `ObjCBool` from the mapped
types XMACRO definition into the inline definition in the importer.
Take the opportunity to simplify the mapping code.
Adjust the standard library usage of the `BOOL` type which is now
eclipsed by the new `WindowsBool` type, preferring to use `Bool`
whenever possible.
Thanks to Jordan Rose for the suggestion to do this and a couple of
hints along the way.
Reviewed the cases of Glibc where branching occurred and checked the
skipped headers against the Android NDK sysroot, and added the Android
check in the right places. This will give access to a lot more
functions from libc.
* Restore elementwise min/max on SIMD, but as statics instead of free functions.
Having these as free functions causes expression too complex issues due to overload vis-a-vis min<Collection>. There are (at least) three plausible solutions:
1. Fix the typechecker. This is infeasable in the short term; or more precisely, we do not know how much work is involved.
2. Give these operations different names. Candidates discussed with core team include "pointwiseMin", "elementwiseMin", "lanewiseMin"; these all suffer from the flaw that when someone writes "min" in a SIMD context, they are essentially always looking for either the horizontal minimum (reduction) on a single vector or--more often--the lanewise minimum of two vectors (this operation). It would be odd to give the operation that people actually want the unnecessarily verbose name.
3. Make these operations static; this is, in effect, a different name, but it's one which frequently allows eliding the qualifier:
let x = v + .min(v, w)
This isn't perfect; you will still need to spell out SIMD4.min( ) fairly often, but that's more concise than any of the proposed alternatives, and at least allows elision some of the time. Also, if you squint, you can pretend that the "." prefix is like ".<" and ".&" and indicates lanewise operation.
