Commit Graph

12 Commits

Author SHA1 Message Date
Dmitri Gribenko
d175b3b66d Migrate FileCheck to %FileCheck in tests 2016-08-10 23:52:02 -07:00
practicalswift
abfecfde17 [gardening] if ([space]…[space]) → if (…), for(…) → for (…), while(…) → while (…), [[space]x, y[space]] → [x, y] 2016-04-04 16:22:11 +02:00
Arnold Schwaighofer
859fbc0162 More executable_test for the test directory
Swift SVN r29280
2015-06-03 23:28:51 +00:00
Dmitri Hrybenko
f46f16ae82 stdlib: implement new print() API
rdar://20775683

Swift SVN r28309
2015-05-08 01:37:59 +00:00
Joe Pamer
3b57cabae7 Consider default argument patterns, as they relate to actual arguments, when deciding on a specific overload to favor for a function application. Doing so addresses another class of exponential behavior bugs in the type checker (rdar://problem/19779591 and rdar://problem/20772053). There's still some work left to do, though - hence the change to Concatenate.swift, to work around rdar://problem/20789500.
Swift SVN r28221
2015-05-06 22:32:07 +00:00
Joe Pamer
9923e3ff89 When optimizing constraints for an unresolved dot expression, don't walk into the base expression - it will most likely result in an incorrect favored type, which can lead to "expression too complex" errors. (rdar://problem/19773442, rdar://problem/19770646)
Swift SVN r25129
2015-02-10 19:14:29 +00:00
Joe Pamer
24eb7a2d60 Add tests for rdar://problem/19459079 and rdar://problem/19005271.
Swift SVN r24694
2015-01-23 23:32:46 +00:00
Joe Pamer
f453bceeb1 Fix utilization of expected types for subscript and apply expressions when favoring constraints. (rdar://problem/19334553)
Swift SVN r24522
2015-01-19 20:59:15 +00:00
Joe Pamer
55e58e4a84 Add a few new exponential typecheck explosion regression tests.
Swift SVN r24521
2015-01-19 20:59:15 +00:00
Joe Groff
ee505107be Reduce depth of binary_operator_perf test.
I discussed this with JoeP, and he said that 100 additions is plenty to verify that we don't go exponential in this case. 1000 additions causes SILGen to exhaust the stack in release builds, but we don't have the time to refactor it to avoid the exhaustion right now. <rdar://problem/17898364>

Swift SVN r21035
2014-08-05 04:38:40 +00:00
Joe Pamer
cae36c9c9d Broaden the "favored constraint" binop optimization to work with simplified expression types, and not just default literal tyvars.
This addresses or improves several existing TC perf bugs (rdar://problem/15933674, rdar://problem/17110608, rdar://problem/17240816, rdar://problem/17244974), and seems to speed up our unit test runs by ~5%. (On my MacBook Pro, total average execution time is reduced from 557.28s to 531.89s.)

Swift SVN r19939
2014-07-14 19:20:49 +00:00
Joe Pamer
da59d305c9 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
2014-07-11 16:24:42 +00:00