We want to eventually remove address phi arguments from SIL. This will enable
all sorts of nice IRGen optimizations and in general make life better. We are
not there yet, but given that is the direction we are going in, I don't think
there is much use in having to implement this sort of checking for SIL phi
arguments.
rdar://50676315
Different tests used different os checks for importing Darwin, Glibc and
MSVCRT. This commit use the same pattern for importing those libraries,
in order to avoid the #else branches of the incorrect patterns to be
applied to the wrong platform. This was very normal for Android, which
normally should follow the Linux branches, but sometimes was trying to
import Darwin or not importing anything.
The standarized pattern imports Darwin for macOS, iOS, tvOS and watchOS.
It imports Glibc for Linux, FreeBSD, PS4, Android, Cygwin and Haiku; and
imports MSVCRT for Windows. If a new platform is introduced, the else
branch will report an error, so the new platform can be added to one of
the branches (or maybe add a new specific branch).
In some cases the standard pattern was modified because some test required
it (importing extra modules, or extra type aliases), and in some other
cases some branches were removed because the test will not have used
them (but it is not exhaustive, so there might be some unnecessary
branches).
This should, at least, fix three tests for Android (the three
dynamic_replacement*.swift ones).
Turns out some people used this type despite it being prefixed with
`_stdlib_`, so we have to keep it, with an obsoletion message this time.
Second copy of the same type is kept available past Swift 5 in
SwiftPrivate for use in tests.
This switches the standard library's sort algorithm from an in-place
introsort to use a modified timsort, a stable, adaptive sort that
merges runs using a temporary buffer. This implementation performs
straight merges instead of adopting timsort's galloping strategy.
In addition to maintaining the relative order of equal/non-comparable
elements, this algorithm outperforms the introsort on data with any
intrinsic structure, such as runs of ascending or descending elements
or a significant number of equality collisions.
In order to provide source compatibility with existing user types conforming to BinaryInteger, we want to have a default implementation available. It's somewhat difficult to provide a good default implementation that correctly handles arbitrary non-symmetrical ranges in the face of negative divisors, so fall back on testing divisibility of the magnitudes, which avoids the problem.
On the plus side, this default implementation works fine for types conforming to UnsignedInteger, which lets us move the FixedWidthInteger implementation down to FixedWidthInteger & SignedInteger, and simplify it in the process.
* Implement SE-0225 (BinaryInteger.isMultiple(of:))
A default implementation is provided for FixedWidthInteger, with very basic test coverage included.
SwiftPrivate/PRNG.swift:
- currently uses `theGlobalMT19937`;
- previously used `arc4random` (see #1939);
- is obsoleted by SE-0202: Random Unification.
* Make _sanityCheck internal
* Make _debugPrecondition internal
* Make Optional._unsafelyUnwrappedUnchecked internal.
* Make _precondition internal
* Switch Foundation _sanityChecks to assertions
* Update file check tests
* Remove one more _debugPrecondition
* Update Optimization-with-check tests
These are all tests that would otherwise fail if the expression type
checker support for Swift 3 is removed.
I've moved some of the code from deleted Migrator tests into new
Constraints tests that verify that we do not support the constructs.
