Commits

Joe Pamer committed da59d305c97
Greatly improve type checker performance when inferring types for certain binary expression applications (rdar://problem/15933674, rdar://problem/17365394 and many, many dupes.) When solving for the type of a binOp expression, factor the operand expression types into account when collating overloads for the operator being applied. This allows the type checker to now infer types for some binary operations with hundreds of nested components, whereas previously we could only handle a handful. (E.g., "1+2+3+4+5+6" previously sent the compiler into a tailspin.) Specifically, if one of the operands is a literal, favor operator overloads whose operand, result or contextual types are the default type of the literal convertible conformance of the the argument literal type. By doing so we can prevent exponential behavior in the solver and massively reduce the complexity of many commonly found constraint systems. At the same time, we'll still defer to "better" overloads if the default one cannot be applied. (When adding an Int8 to an Int, for example.) This obviously doesn't solve all of our performance problems (there are more changes coming), but there are couple of nice side-effects: - By tracking literal/convertible protocol conformance info within type variables, I can potentially eliminate many instances of "$T0" and the like from our diagnostics. - Favored constraints are placed at the front of the overload resolution disjunction, so if a system fails to produce a solution they'll be the first to be mined for a cause. This helps preserve user intent, and leads to better diagnostics being produced in some cases. Swift SVN r19848