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
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.
NSString has a stricter concept of equality than Swift’s String, so it is possible to construct NSDictionary/NSSet instances that contain duplicate keys according to Swift’s definition of string equality. This change improves how we handle these cases by coalescing the duplicate keys (keeping a single value).
rdar://problem/35995647
* Eradicate IndexDistance associated type, replacing with Int everywhere
* Consistently use Int for ExistentialCollection’s IndexDistance type.
* Fix test for IndexDistance removal
* Remove a handful of no-longer-needed explicit types
* Add compatibility shims for non-Int index distances
* Test compatibility shim
* Move IndexDistance typealias into the Collection protocol
Using && here causes us to go down a SILGen path that guarantees that self will
be evaluated over the entire && expression instead of just the LHS. This cause
the uniqueness check to always return false at -Onone. At -O, the optimizer is
smart enough to remove this issue.
rdar://33358110
A variety of enhancements from SE-154 and SE-165:
- Custom Keys and Values collections for Dictionary
- Two sequence-based Dictionary initializers
- Merging methods for Dictionary
- Capacity checking and reserving for Dictionary and Set
- Type-specific filter(_:) methods for Dictionary and Set
- A mapValues(_:) method for Dictionary
- A grouping Dictionary initializer
Swift 3 unintentionally allowed collection casts from, e.g.,
Set<AnyHashable> to Set<NSObject>, when in fact the object
representation of the AnyHashable might not be an NSObject. Fix up our
tests and overlays that ran afoul of this rule.
Some of these are kinda dubious, but I think this would be better
addressed as part of eager bridging, which will invalidate the concept
most of these are checking for.
Changes:
- Native dictionary and set indices no longer hold references to storage
- Cocoa-based dictionary and set indices no longer hold references to storage
- Removed double indirection trick from hashed collections
- Rewrote storage types to reflect simpler model
- Updated unit tests
From the Swift documentation:
"If you define an optional variable without providing a default value,
the variable is automatically set to nil for you."
