Mechanically add "Type" to the end of any protocol names that don't end
in "Type," "ible," or "able." Also, drop "Type" from the end of any
associated type names, except for those of the *LiteralConvertible
protocols.
There are obvious improvements to make in some of these names, which can
be handled with separate commits.
Fixes <rdar://problem/17165920> Protocols `Integer` etc should get
uglier names.
Swift SVN r19883
expression applications
(rdar://problem/15933674, rdar://problem/17365394 and many, many dupes.)
When solving for the type of a binOp expression, factor the operand expression
types into account when collating overloads for the operator being applied.
This allows the type checker to now infer types for some binary operations with
hundreds of nested components, whereas previously we could only handle a handful.
(E.g., "1+2+3+4+5+6" previously sent the compiler into a tailspin.)
Specifically, if one of the operands is a literal, favor operator overloads
whose operand, result or contextual types are the default type of the literal
convertible conformance of the the argument literal type.
By doing so we can prevent exponential behavior in the solver and massively
reduce the complexity of many commonly found constraint systems. At the same
time, we'll still defer to "better" overloads if the default one cannot be
applied. (When adding an Int8 to an Int, for example.)
This obviously doesn't solve all of our performance problems (there are more
changes coming), but there are couple of nice side-effects:
- By tracking literal/convertible protocol conformance info within type
variables, I can potentially eliminate many instances of "$T0" and the
like from our diagnostics.
- Favored constraints are placed at the front of the overload resolution
disjunction, so if a system fails to produce a solution they'll be the
first to be mined for a cause. This helps preserve user intent, and leads
to better diagnostics being produced in some cases.
Swift SVN r19848
attribute is a "modifier" of a decl, not an "attribute" and thus shouldn't
be spelt with an @ sign. Teach the parser to parse "@foo" but reject it with
a nice diagnostic and a fixit if "foo" is a decl modifier.
Move 'dynamic' over to this (since it simplifies some code), and switch the
@optional and @required attributes to be declmodifiers (eliminating their @'s).
Swift SVN r19787
Introduce the new BooleanLiteralConvertible protocol for Boolean
literals. Take "true" and "false" as real keywords (which is most of the
reason for the testsuite churn). Make Bool BooleanLiteralConvertible
and the default Boolean literal type, and ObjCBool
BooleanLiteralConvertible. Fixes <rdar://problem/17405310> and the
recent regression that made ObjCBool not work with true/false.
Swift SVN r19728
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
Previously, bridged value types and their corresponding Objective-C
classes allow inter-conversion via a number of user-defined conversion
functions in the Foundation module. Instead, make this a general
feature of the type checker so we can reason about it more
directly. Fixes <rdar://problem/16956098> and
<rdar://problem/17134986>, and eliminates 11 (half) of the
__conversion functions from the standard library and overlays.
A few notes:
- The XCTest changes are because a String can no longer directly
conform to CVarArg: this is a Good Thing (TM), because it should be
ambiguous: did you mean to pass it as an NSString or a C string?
- The Objective-C representations for the bridged collections are
hard-coded in the type checker. This is unfortunate and can be
remedied by adding another associated type to the
_BridgedToObjectiveC protocol.
Swift SVN r19618
If the lookup was resolved by optional unwrapping, unwrap the metatype when we apply the solution so we don't try to create an invalid metatype conversion from T?.Type to T.Type. Fixes <rdar://problem/17542185>.
Swift SVN r19500
When we see a '.member' expression in optional context, look for the member in the optional's object type if it isn't found in Optional itself. <rdar://problem/16125392>
Swift SVN r19469
This consolidates the \x, \u, and \U escape sequences into one \u{abc} escape sequence.
For now we still parse and cleanly reject the old forms with a nice error message, this
will eventually be removed in a later beta (tracked by rdar://17527814)
Swift SVN r19435
We haven't been advertising this syntax much, and it's closure form
was completely broken anyway, so don't jump through hoops to provide
great Fix-Its here.
Swift SVN r19277
Previously, we were unable to handle bridged downcasts to optional
types from optional sources, because because we applied the bridging
operation after we had already evaluated all of the bound optionals
(causing a crash). Now, we perform the bridging immediately after the
underlying forced or conditional cast, before evaluating the outer
bound optionals.
This also eliminates a bunch of code duplication between the forced
and conditional downcasts, now that the bridging code is shared.
Swift SVN r19065
Now that we use bridgeFromObjectiveCConditional to perform conditional
bridging, make bridgeFromObjectiveC handle forced bridging. For the
latter, deferred checking is acceptable.
Almost all of <rdar://problem/17319154>.
Swift SVN r19046
DiscardAssignment expressions are special in that during constraint generation they'll introduce a new type variable, but not place any constraints upon it. (They are the only expression kind that behaves in this way.) If no subsequent expressions constrain the type variable, we may end up with a failed constraint system that's devoid of constraints, and hence no information to synthesize a diagnostic from. With no diagnostic associated with the DiscardAssignmentExpr's source location, we'll attempt to generate SIL and raise an assertion failure. Fortunately, we can detect these cases during the constraint salvage phase, and raise an appropriate error.
Swift SVN r19020
This entry point is used in conditional downcasts (as?) to attempt to
bridge from an Objective-C class down to a specific native type (e.g.,
array, dictionary), bridging all elements eagerly so that it can
produce nil if the bridging would fail.
This is the scaffolding for <rdar://problem/17319154>, and makes the
example there work, but there is much more cleanup and optimization to
do.
Swift SVN r18999
Do this by only warning on self-referential uses of a variable when there's
not another binding found in the local scope. This probably still restricts
some reasonable edge cases, but it at least allows shadowing the variable
with a local name.
<rdar://problem/17087232>
Swift SVN r18771
One difficulty in generating reasonable diagnostic data for type check failures has been the fact that many constraints had been synthesized without regard for where they were rooted in the program source. The result of this was that even though we would store failure information for specific constraints, we wouldn't emit it for lack of a source location. By making location data a non-optional component of constraints, we can begin diagnosing type check errors closer to their point of failure.
Swift SVN r18751
Rather than only allowing downcasting from AnyObject, allow it for any
class or Objective-C existential type, e.g., "NSArray() as
Int[]". While here, reduce our reliance on implicit conversions when
checking bridging. This is most of <rdar://problem/16972956>, but 'is'
still doesn't work properly in these cases.
Swift SVN r18693
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
- rdar://problem/16776273, wherein conversions between nil and .None were permitted
due to an implicit conversion between nil and COpaquePointer.
- rdar://problem/16877526, where we needed to add new equality overloads to handle
conversions between nil and .None given the supression of user conversions.
(Some minor tweaks this time around for better interoperability with AnyObject.)
Swift SVN r18498
- rdar://problem/16776273, wherein conversions between nil and .None were permitted
due to an implicit conversion between nil and COpaquePointer.
- rdar://problem/16877526, where we needed to add new equality overloads to handle
conversions between nil and .None given the supression of user conversions.
(Thanks to Ted for the overloads and test.)
Swift SVN r18473
Previously, we were relying on user-defined conversions to perform the
final bridging from the Objective-C class type (e.g., NSString) to its
Swift value type (String). That works for NSString <-> String, but not
for arbitrary arrays. Use the bridgeFromObjectiveC() witness instead,
so we can handle:
let obj: AnyObject = ...
let strArr: String[] = obj!
Fixes <rdar://problem/16952771>.
Swift SVN r18422
We can't actually make the "is" check any more efficient for arrays
anyway, and re-using the checked casting code makes "is" work properly
for arrays. More of <rdar://problem/16952771>.
Swift SVN r18395
