This takes all %target-run-simple-swift and %target-run-stdlib-swift
invocations and runs them using the interpreter instead. To enable this
mode, pass --param=interpret to lit.py; you can add this flag to the
LLVM_LIT_ARGS CMake setting (which defaults to "-sv").
This doesn't support separated %target-build / %target-run steps, nor
does it work with StdlibUnittest (which uses posix_spawn to run its
subtasks). But it's a start.
<rdar://problem/17938202>
Swift SVN r21391
The test harness now can recover after test crashes, allowing:
- check for crashes themselves (without reporting them to the Python lit driver,
which is about 10x slower -- even if CrashTracer is disabled);
- recover from unexpected test crashes and run the rest of the tests;
- this lays the groundwork for assertions that end the test execution, but
allow the rest of the tests to run (rdar://17906801).
Note that we don't spawn a fresh process for every test. We create a child
process and reuse it until it crashes.
Swift SVN r21090
This requires a bit of special handling because we override the getter's type
in the importer, to make sure it's compatible with the setter, but other than
that we just use the information from the apinotes file.
<rdar://problem/17891179>
Swift SVN r21027
In buildSubscript, when forcing an implicitly unwrapped optional base expression of a subscript expression, we weren't updating the base type in for later use. In the case of a nested subscript expression, this could cause us to coerce to the wrong inner type.
Swift SVN r20736
This change pulls the handling of the element pattern and sequence of
a for-each loop into a single constraint system, so that we get type
inference between the two. Among other things, this allows one to
infer generic arguments within the element pattern from the sequence's
element type as well as allowing type annotations or the form of the
element pattern to affect overload resolution and generic argument
deduction for the sequence itself.
Swift SVN r19721
There's a bit of a reshuffle of the ExplicitCastExpr subclasses:
- The existing ConditionalCheckedCastExpr expression node now represents
"as?".
- A new ForcedCheckedCastExpr node represents "as" when it is a
downcast.
- CoerceExpr represents "as" when it is a coercion.
- A new UnresolvedCheckedCastExpr node describes "as" before it has
been type-checked down to ForcedCheckedCastExpr or CoerceExpr. This
wasn't a strictly necessary change, but it helps us detangle what's
going on.
There are a few new diagnostics to help users avoid getting bitten by
as/as? mistakes:
- Custom errors when a forced downcast (as) is used as the operand
of postfix '!' or '?', with Fix-Its to remove the '!' or make the
downcast conditional (with as?), respectively.
- A warning when a forced downcast is injected into an optional,
with a suggestion to use a conditional downcast.
- A new error when the postfix '!' is used for a contextual
downcast, with a Fix-It to replace it with "as T" with the
contextual type T.
Lots of test updates, none of which felt like regressions. The new
tests are in test/expr/cast/optionals.swift.
Addresses <rdar://problem/17000058>
Swift SVN r18556
This fixes a case where the Swift-variadic and C-varargs versions of
various initializers were superseding each other
<rdar://problem/16801456>.
It also uncovered some more cases where we weren't getting quite the
right semantics for factory-methods-as-initializers, which are also
fixed here.
Swift SVN r18010
A Swift method in an extension cannot override a method nor can it be
overridden by a method. Diagnose this. We may remove this limitation
at a later time.
An [objc] method in an extension can override and can be overridden, so
specifically allow this case. It's useful in our Foundation bindings.
Swift SVN r4308
