Commit the platform definition and build script work necessary to
cross-compile for arm64_32.
arm64_32 is a variant of AARCH64 that supports an ILP32 architecture.
Specifically, given code like the following:
```
(%1, %2) = multi_result_inst %0 (a)
inst_to_delete %1 (b)
inst_to_delete %2 (c)
```
We would sometimes visit (c) before (b). So if nextII was (b) at that point, we
would think that we were safe. Then we process (b), move nextII from (b) ->
(c). Then we delete both (b) and (c). =><=.
The solution to this is each iteration of the delete loop, we track /all/
instructions that eliminateDeadInstruction is going to eliminate and ensure that
after each callback is called we have moved past all visited instructions (even
ones we visited previously). This is done using a small set that I clear each
iteration.
I also re-enabled the dictionary test that exposed this issue when testing
-O/-Osize.
rdar://71933996
The embedded shell script in the RUN command for lit is problematic for
non-sh shell environments (i.e. Windows). This adjusts the tests to
uniformly build the code for the ObjC runtime. However, the Objective-C
code is only built under the same circumstances that it is currently
enabled - the availability of the needed frameworks. The empty object
on other runtimes will have no material impact. The swift side of it
checks whether the runtime is built with ObjC interop. This allows us
to largely use the same command line for all the targets. The last
missing piece is that the `-fobjc-runtime` requires that we run a modern
ObjC runtime. We enable this unconditionally in lit for the non-Apple
targets.
This improves the validation test coverage for the standard library on
Windows.
Until the issue is fixed. Tracked by:
<rdar://problem/49791522> Swift CI Test failures: IRGen/autorelease_optimized_armv7/aarch64.
https://bugs.swift.org/browse/SR-10474
The initializer was originally introduced without proper availability; in https://github.com/apple/swift/pull/23643, we fixed this by applying the `@_alwaysEmitIntoClient` attribute. However, this had the unfortunate side-effect that the symbol disappeared from `libswiftCore.dylib`, which somehow confuses some simulator builds.
Try to figure out what’s happening by replacing the third closure argument with an integer return value. This changes the mangled name of the bulk initializer, which should make it more obvious how/why these builds fail.
rdar://problem/49479386
_modify mustn’t leave Collection storage in an inconsistent state when the code to which we’re yielding happens to throw. In practice this means that any cleanup code must happen in defer blocks before the yield.
Fix Dictionary to do just that and add tests to cover this functionality (as well as some other aspects of _modify).
Replacing the old key with the new is unnecessary and somewhat surprising. It is also harmful to some usecases.
rdar://problem/32144087
# Conflicts:
# stdlib/public/core/NativeDictionary.swift
Along with updating tests to adopt the new storage class names, the behavior of removeAll() has changed slightly.
If t stored an empty Set/Dictionary that was bridged from Objective-C, t.removeAlI() used to keep the original Objective-C storage intact. Now removeAll() replaces the old storage with the empty singleton, which makes a lot more sense to me.
SwiftPrivate/PRNG.swift:
- currently uses `theGlobalMT19937`;
- previously used `arc4random` (see #1939);
- is obsoleted by SE-0202: Random Unification.
On some platforms, when a new process is started, ARC’s autoreleased return value optimization is expected to fail the first time it is used in each linked dylib. StdlibUnittest takes care of warming up ARC for the stdlib (libswiftCore.dylib), but for Dictionary.swift, we also need to do it for Foundation, or there will be spurious leaks reported for tests immediately following a crash test.
Add the necessary dummy operations to setUp, and re-add the crash tests that were removed in #17862. (As separate tests this time, so they don’t hide leaks in non-crashing test parts.)
Removing crash tests fixed optimized test runs, but exposed an issue in unoptimized i386 simulator tests.
Disable the two affected tests until we plug all their holes.
Crashes somehow interfere with object counters in optimized tests, breaking the tests immediately following a crash test.
Remove getObjects:andKeys:count: crash tests for now.
rdar://problem/41871587
