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.
This reverts commit 231fb5e054.
This test was failing the last time we updated the stable branches
of LLVM/Clang so it was disabled. No one remembers what was the
problem, so try reenabling it to see if anything breaks.
In the constraint solver, we've traditionally modeled nested type via
a "type member" constraint of the form
$T1 = $T0.NameOfTypeMember
and treated $T1 as a type variable. While the solver did generally try
to avoid attempting bindings for $T1 (it would wait until $T0 was
bound, which solves the constraint), on occasion we would get weird
behavior because the solver did try to bind the type
variable.
With this commit, model nested types via DependentMemberType, the same
way we handle (e.g.) the nested type of a generic type parameter. This
solution maintains more information (e.g., we know specifically which
associated type we're referring to), fits in better with the type
system (we know how to deal with dependent members throughout the type
checker, AST, and so on), and is easier to reason able.
This change is a performance optimization for the type checker for a
few reasons. First, it reduces the number of type variables we need to
deal with significantly (we create half as many type variables while
type checking the standard library), and the solver scales poorly with
the number of type variables because it visits all of the
as-yet-unbound type variables at each solving step. Second, it
eliminates a number of redundant by-name lookups in cases where we
already know which associated type we want.
Overall, this change provides a 25% speedup when type-checking the
standard library.
The test was verifying that two independently constructed
empty cocoa sets somehow had the same identity. Not sure why this used
to hold, but it's definitely not something we guarantee.
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
Overlay test in this particular case should only be concerned that the
API is available, not that the underlying implementation is correct.
Fixes: <rdar://problem/28702253>
There are several checks related to accessing a slice of an
UnsafeBufferPointer. Which tests are active depend on the level of
optimization. A raw buffer's checks are also stricter in some cases.
This test was originally designed to either crash or not for each input range
without regard to the nuances of when bounds checks are enabled. When an input
range was marked as crashing, that forced the test case to crash which was
self-fullfilling--nothing was really being tested in that case.
In my previous checkin, I enabled crash checking to be effective but missed some
of the nuances of different bounds checking modes. This commit adds logic to the test
to account for these nuances.
Extend NSNumber bridging to cover not only `Int`, `UInt`, `Double`, and `Bool`, but all of the standard types as well. Extend the `TypePreservingNSNumber` subclass to accommodate all of these types, so that we preserve type identity for `AnyHashable` and dynamic casting of Swift-bridged NSNumbers. If a pure Cocoa NSNumber is cast, just trust that the user knows what they're doing.
This XFAILs a couple of serialization tests that attempt to build the Foundation overlay, but which don't properly handle `gyb` files.
Swift value types are their bridged Objective-C classes can have
different hash values. To address this, AnyHashable's responds to the
_HasCustomAnyHashableRepresentation protocol, which bridge objects of
those class types---NSString, NSNumber, etc---into their Swift
counterparts. That way, we get consistent (Swift) hashing behavior
across platforms.
However, there are cases where multiple Swift value types map to the
same Objective-C class type. In such cases, AnyHashable ends up
converting the object of class type back to some canonical type. For
example, an NS_STRING_ENUM (such as (NS)RunLoopMode) is a Swift
wrapper around a String. If an (NS)RunLoopMode is placed into an
AnyHashable, it maintains it's Swift type identity (which is correct
behavior). If it is bridged to Objective-C, it becomes an NSString; if
that NSString is placed into an AnyHashable, it produces a String. The
hash values still line up, but equality of the AnyHashable values
fails, which breaks when (for example) a dictionary with AnyHashable
keys is used from Objective-C. See SR-2648 / rdar://problem/27992351
for a case where this breaks interoperability.
To address this problem, make AnyHashable's casting and equality
sensitive to the origin of the hashed value: if the AnyHashable was
created through a _HasCustomAnyHashableRepresentation conformance,
treat comparisons/casting from it as "fuzzy":
* For equality, if one of the AnyHashable's comes from a custom
representation (e.g., it originated with an Objective-C type like
NSString) but the other did not, bridge the value of the *other*
AnyHashable to Objective-C, re-wrap it in an AnyHashable, and
compare that. This allows, e.g., an (NS)RunLoopMode created in Swift
to compare to an NSString constant with the same string value.
* For casting, if the AnyHashable we're casting from came from a
custom representation and the cast would fail, bridge to Objective-C
and then initiate the cast again. This allows an NSString to be
casted to (NS)RunLoopMode.
Fixes SR-2648 / rdar://problem/27992351.
[test] Add a timeout to runRaceTest(). Use it to limit test AtomicInt.swift.
This cuts AtomicInt.swift's execution time from several hours to
about ten minutes on slow hardware and slow build configurations.
From the Swift documentation:
"If you define an optional variable without providing a default value,
the variable is automatically set to nil for you."
