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.
