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
Consider different overload choices for the same location in evaluation
order, this makes overload resolution more predictable because it's going
to follow expression bottom-up, that prevents situations when some
expressions are considered ambigious because choices taken further up
equate the score, instead each level is given distinct weight
based on evaluation order.
Resolves: rdar://problem/31888810
We previously used a simple heuristic of visiting the disjunction with
the fewest number of elements in it.
Instead, this commit introduces a new way to select the best disjunction
to explore based on attempting disjunctions based on either how much
information we have about the associated type variables (e.g. how many
of the arguments of a function call in the case of bind overload
disjunctions) or by other criteria that help constraint the search or
split the connected components (e.g. coercions and calls to
initializers).
A key part of the improvement here is allowing the type checker to
attempt bindings of types to type variables when there are still
argument conversion constraints between type variables in the
system. The insight here is if there are no other constraints blocking
an attempt to bind types and we have types to try, we will be able to
test those types against active conformance constraints and potentially
fail much earlier while solving.
Visiting disjunctions in a different order exposed some other problems
with the type checker including a couple cases where map is used that
are now considered ambiguous due to problems in how we are ranking
solutions.
I measured an 11-13% reduction in type checking time for the standard
library using a release build of the compiler.
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.
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
This reverts commit dc0ae675bc. The
change here (presumably the change to Foundation) caused a regression
in several of the bridging-related benchmarks, e.g.,
ObjectiveCBridgeFromNSSetAnyObjectToString, DictionaryBridge,
ObjectiveCBridgeFromNSDictionaryAnyObjectToString.
Remove the functions
_(set|dictionary)Bridge(From|To)ObjectiveC(Conditional) from the
standard library. These entrypoints are no longer used by the compiler
(thanks to generalized collection up/downcasting), so stop using them
in Foundation and in tests.
One last bit of SE-0072. We shouldn't fall back to bridged classes in the absence of type context for literals anymore. By itself, this kind of hoses the use of literals with NS types, but I think we can get most of the QoI back with overlay changes I plan to propose following this.
Previously it assumed that if we succeed in looking up the method in the current
module we must be able to request a definition (vs a declaration).
This is not true. It could be that we had declared the type in a different
module. Always ask for a declaration.
rdar://27547957
Swift's Dictionary and Set are typed, but when bridged to NSDictionary
and NSSet they should behave accordingly, that is, allow querying for
keys of arbitrary types.
rdar://problem/23679193
