This was initially added to avoid "expression was too complex" in a
case where we were not previously reporting it for -swift-version 3
but should have been. In retrospect this seems misguided since
although we would not like to regress on "too complex" expressions, we
really don't want to silently continue in the cases where we decide an
expression is "too complex", but where we have a solution that we
could use. It's better to fail.
* Give Sequence a top-level Element, constrain Iterator to match
* Remove many instances of Iterator.
* Fixed various hard-coded tests
* XFAIL a few tests that need further investigation
* Change assoc type for arrayLiteralConvertible
* Mop up remaining "better expressed as a where clause" warnings
* Fix UnicodeDecoders prototype test
* Fix UIntBuffer
* Fix hard-coded Element identifier in CSDiag
* Fix up more tests
* Account for flatMap changes
This test is trying to confirm that memory usage is independent and that
follow-on expressions do not fail just because of the first failure, and
now we naturally fail on another expression because of the additional
memory used for -propagate-constraints.
Tweak the test to bump up the threshold and swap the order of
expressions so that the now-failing expression is first.
The 5000 byte treshold is too generous on 32-bit systems to trigger the expression too complex test. Reducing it to 4000 causes the compiler to bail (as expected) on these platforms while retaining the expected behavior on 64-bit systems.
Most tests were using %swift or similar substitutions, which did not
include the target triple and SDK. The driver was defaulting to the
host OS. Thus, we could not run the tests when the standard library was
not built for OS X.
Swift SVN r24504
Trying a collection literal early often means that we can determine
the element type from context, which saves us the work of trying to
guess at the element type firsthand.
Doing this seems to help some cases significantly:
- test/stdlib/ArrayNew.swift got about 20% faster in a release build
- I had to drop the threshold for the "expression too complex" test
case by 20x to still trigger the issue.
Swift SVN r22097
While we work out the remaining performance improvements in the type checker, we can improve the user experience for some "runaway solver" bugs by setting a limit on the amount of temporary memory allocated for type variables when solving over a single expression.
Exponential behavior usually manifests itself while recursively attempting bindings over opened type variables in an expression. Each one of these bindings may result in one or more fresh type variables being created. On average, memory consumption by type variables is fairly light, but in some exponential cases it can quickly grow to many hundreds of megabytes or even gigabytes. (This memory is managed by a distinct arena in the AST context, so it's easy to track.) This problem is the source of many of the "freezing" compiler and SourceKit bugs we've been seeing.
These changes set a limit on the amount of memory that can be allocated for type variables while solving for a single expression. If the memory threshold is exceeded, we can surface a type error and suggest that the user decompose the expression into distinct, less-complex sub-expressions.
I've set the current threshold to 15MB which, experimentally, avoids false positives but doesn't let things carry on so long that the user feels compelled to kill the process before they can see an error message. (As a point of comparison, the largest allocation of type variable data while solving for a single expression in the standard library is 592,472 bytes.) I've also added a new hidden front-end flag, "solver-memory-threshold", that will allow users to set their own limit, in bytes.
Swift SVN r20986
