for testing purposes.
When enabled, if the typechecker tries to typecheck a decl or unresolved identifier with the provided
prefix, then an llvm fatal_error will get triggered.
This approach has the advantage that it is very easy to write tests for unnecessary typechecking for a wide range of functionality,
for the compiler or SourceKit, for code-completion, indexing, etc.
Swift SVN r22003
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
We were already effectively doing this everywhere /except/ when building
the standard library (which used -O2), so just use the model we want going
forward.
Swift SVN r20455
This doesn't really affect anyone in real life, but it will catch cases
where someone's trying to compile for iOS without the iOS stdlib around.
Swift SVN r18796
This depends on c-index-test being available in the path.
This should work for CMake builds where swift is built
in its own build folder. I believe this will also work
for Makefile builds, but the buildbot will verify.
Swift SVN r5562
