In most cases when we are testing traps the right choice is to skip the test when we run with -Ounchecked, because some of the expected crashes might or might not cause a crash in -Ounchecked mode.
Discussed and agreed with Dmitri.
With this change and our recent bug-fixing efforts, running the whole test-suite + validation-suite with -Ounchecked results in only one failing test.
Swift SVN r28806
includes a number of QoI things to help people write the correct code. I will commit
the testcase for it as the next patch.
The bulk of this patch is moving the stdlib, testsuite and validation testsuite to
the new syntax. I moved a few uses of "as" patterns back to as? expressions in the
stdlib as well.
Swift SVN r27959
This changes 'if let' conditions to take general refutable patterns, instead of
taking a irrefutable pattern and implicitly matching against an optional.
Where before you might have written:
if let x = foo() {
you now need to write:
if let x? = foo() {
The upshot of this is that you can write anything in an 'if let' that you can
write in a 'case let' in a switch statement, which is pretty general.
To aid with migration, this special cases certain really common patterns like
the above (and any other irrefutable cases, like "if let (a,b) = foo()", and
tells you where to insert the ?. It also special cases type annotations like
"if let x : AnyObject = " since they are no longer allowed.
For transitional purposes, I have intentionally downgraded the most common
diagnostic into a warning instead of an error. This means that you'll get:
t.swift:26:10: warning: condition requires a refutable pattern match; did you mean to match an optional?
if let a = f() {
^
?
I think this is important to stage in, because this is a pretty significant
source breaking change and not everyone internally may want to deal with it
at the same time. I filed 20166013 to remember to upgrade this to an error.
In addition to being a nice user feature, this is a nice cleanup of the guts
of the compiler, since it eliminates the "isConditional()" bit from
PatternBindingDecl, along with the special case logic in the compiler to handle
it (which variously added and removed Optional around these things).
Swift SVN r26150
...which was finding a different class's property on the buildbots, and
refusing to compile on my machine. Filed rdar://problem/20099641.
Swift SVN r25908
un-type-annotated AnyObject binding in "if let", and allows general
patterns in if-let.
This also reverts some unrelated QoI improvements that went in with those
patches, but I'll add those back next.
Swift SVN r25507
conditional context. There is no point diagnosing it here (just like a foreach loop) because
the if/let is just unwrapping the optional in the initializer expression.
Removing this requirement eliminates a bunch of extraneous type annotations in the testsuite.
Swift SVN r25370
Require 'as' when converting from Objective-C type to native type (but
continue to allow implicit conversion from native to Objective-C). This
conversion constraint is called ExplicitConversion; all implicit
conversions are covered by the existing Conversion constraint. Update
standard library and tests to match.
Swift SVN r24496
Previously the "as" keyword could either represent coercion or or forced
downcasting. This change separates the two notions. "as" now only means
type conversion, while the new "as!" operator is used to perform forced
downcasting. If a program uses "as" where "as!" is called for, we emit a
diagnostic and fixit.
Internally, this change removes the UnresolvedCheckedCastExpr class, in
favor of directly instantiating CoerceExpr when parsing the "as"
operator, and ForcedCheckedCastExpr when parsing the "as!" operator.
Swift SVN r24253
Sticking with the original design.
Also added a trap test for removeFirst() since its precondition
is that the set be non-empty, similar to Array.
Swift SVN r23712
rdar://problem/19132138
Make Set<T> visible by removing the underscore. Also, remove the pesky
${_Self} gyb variable that was for a temporary convenience in hiding Set.
Swift SVN r23699
The public API is mostly solid at this point, with only a few minor
changes to naming and a couple of extra methods to bring it to parity
with Array.
Also removed the quick-and-dirty operators <, >, <=, and >= which were
used as a convenient shorthand for strict subset, strict superset,
subset, and superset respectively (< is retained for Comparable
conformance).
Swift SVN r23657
