This way it covers a lot more ground and doesn't conflict with
other fixes.
Another notable change is related to check for IUO associated
with source type, that covers cases like:
```swift
func foo(_ v: NSString!) -> String {
return v
}
```
Instead of general conversion failure check for IUO enables solver
to introduce force downcast fix.
The type checker implements logic for handling checked casts in two
places: the constraint solver (for type-checking expressions
containing "as!" or "as?") and as a top-level entrypoint for
type-checking as?/as! for diagnostics and is/as patterns. Needless to
say, the two implementations were inconsistent, and in fact both were
wrong, leading to various problems---rejecting perfectly-valid "as!"
and "as?" casts outright, bogus warnings that particular as!/as? casts
always-succeed or always-fail when they wouldn't, and so on.
Start detangling the mess in two ways. First, drastically simplify the
handling of checked casts in the constraint solver, eliminating the
unprincipled "subtype" constraint checks that (among other things)
broke the handling of checked casts that involved bridging or optional
unwrapping. The simpler code is more permissive and more correct; it
essentially accepts that the user knows what she is doing with the
cast.
Second, make the type checker's checking of casts far more thorough,
which includes:
* When we're performing a collection cast, actually check that the
element types (and key types, for a dictionary) are castable, rather
than assuming all collection casts are legitimate. This means we'll
get more useful "always fails" and "always succeeds" diagnostics for
array/set/dictionary.
* Handle casts from a bridged value type to a subclass of the
corresponding bridged class type. Previously, these would be
incorrectly classified as "always fails".
While I'm here, eliminate a spurious diagnostic that occurs when using
a conditional cast ("as?") that could have been a coercion/bridging
conversion ("as"). The optional injection we synthesize to get the
resulting type correct was getting diagnosed as an implicit coercion,
but shouldn't have been.
From the Swift documentation:
"If you define an optional variable without providing a default value,
the variable is automatically set to nil for you."
along with recent policy changes:
- For expression types that are not specifically handled, make sure to
produce a general "unused value" warning, catching a bunch of unused
values in the testsuite.
- For unused operator results, diagnose them as uses of the operator
instead of "calls".
- For calls, mutter the type of the result for greater specificity.
- For initializers, mutter the type of the initialized value.
- Look through OpenExistentialExpr's so we can handle protocol member
references propertly.
- Look through several other expressions so we handle @discardableResult
better.
This lets us eliminate the _getObjectiveCType() value witness, which
was working around the lack of proper type witness metadata in witness
tables. Boilerplate -= 1.
where we type check the destination first, then apply its type to the source.
This allows us to get diagnostics for assignments that are as good as PBD
initializers and other cases.
Swift SVN r31404
diagnoseGeneralConversionFailure() to handle them (instead of it handling as? but
special code handling as!).
As part of this, enhance things so we get error messages about both the problem,
and the overall type involved (when they're different) e.g.:
if let s = setD as? Set<BridgedToObjC> { }
error: 'ObjC' is not a subtype of 'DerivesObjC'
note: in cast from type 'Set<DerivesObjC>' to 'Set<BridgedToObjC>'
This also finally fixes the case in test/Generics/existential_restrictions.swift
Swift SVN r31299
and diagnoseGeneralConversionFailure(). The previous approach of trying
to dig into anchors would often lead to complaining about types at
different levels in the same diagnostic, and the complexity of the former
code isn't needed now that other changes have landed.
Swift SVN r31036
- Improve handling of if_expr in a couple of ways: teach constraint simplification
about IfThen/IfElse and teach CSDiags about the case when the cond expr doesn't match
BooleanType. This is rarely necessary, but CSDiags is all about cornercases, and this
does fix a problem in a testcase.
- Be a bit more specific about the constraint failure kind (e.g. say subtype) and when
we have a protocol conformance failure, emit a specific diagnostic about it, instead of
just saying that the types aren't convertible.
Swift SVN r30650
conversion failures, making a bunch of diagnostics more specific and useful.
UnavoidableFailures can be very helpful, but they can also be the first constraint
failure that the system happened to come across... which is not always the most
meaningful one. CSDiag's expr processing machinery has a generally better way of
narrowing down which ones make the most sense.
Swift SVN r30647
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
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
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
Add the following functionality to the Swift compiler:
* covariant subtyping of Set
* upcasting, downcasting of Set
* automatic bridging between Set and NSSet, including
* NSSet params/return values in ObjC are imported as Set<NSObject>
* Set params/return values in Swift are visible to ObjC as NSSet
<rdar://problem/18853078> Implement Set<T> up and downcasting
Swift SVN r23751
