This is required to correctly use the mock SDK when the SDK overlay is
built and tested separately. (Otherwise, the mock SDK might not get
used, because the overlay SDK options would expand from the
%-substitution, appear first on the command line, and shadow the mock
SDK in the search path).
Swift SVN r25185
John pointed out that messing with the type checker's notion of "subtype"
is a bad idea. Instead, we should just have a separate check for ABI
compatibility...and eventually (rdar://problem/19517003) just insert the
appropriate thunks rather than forcing the user to perform the conversion.
I'm leaving all the tests as they are because I'm adding a post-type-checking
diagnostic in the next commit, and that should pass all the same tests.
Part of rdar://problem/19600325
Swift SVN r25116
Penalize solutions that involve 'as' -> 'as!' changes by recording a Fix
when simplifying the corresponding checked-cast constraint.
<rdar://problem/19724719> Type checker thinks "(optionalNSString ?? nonoptionalNSString) as String" is a forced cast
Swift SVN r25061
These haven't ever been safe in Swift's development because they require
generating thunks, and we currently don't do that. However, we were letting
existential conversions slip through the cracks because we consider them
subtypes, so that /metatype/ conversions work correctly. To be concrete:
"let _: Any.Type = Int.self" is okay.
"let _: (Int) -> Void = { (_: Any) -> Void in return }" is not.
We should implement this some day; that's rdar://problem/19517003.
This produces some lousy error messages, which I intend to fix soon.
Part of rdar://problem/19600325
Swift SVN r24915
When generating constraints for an 'as' expression, consider the
possibility that the code is supposed to be 'as!' instead of 'as'. Emit
the appropriate fixit if that branch of the disjunction is chosen by the
constraint solver.
This is a more comprehensive fix for <rdar://problem/19499340> than the
one in r24815.
Swift SVN r24872
Previously, we attempted to infer @objc-ness based on conformance, but
doing so is fraught with ordering dependencies, and just doesn't work
in the general case. Among other crimes, this allowed us to
retroactively mark a non-@objc method from an imported module as
@objc... even though nobody would ever then emit the @objc entry
points for it.
Fixes the rest of rdar://problem/18383574.
Swift SVN r24831
Fix diagnostics for 'as' and 'as!' expressions by ensuring that the
conversion constraint used to generate them actually corresponds to the
expression in question. Add tests from 19495142.
Swift SVN r24547
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
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
These changes make the following improvements to how we generate diagnostics for expression typecheck failure:
- Customizing a diagnostic for a specific expression kind is as easy as adding a new method to the FailureDiagnosis class,
and does not require intimate knowledge of the constraint solver’s inner workings.
- As part of this patch, I’ve introduced specialized diagnostics for call, binop, unop, subscript, assignment and inout
expressions, but we can go pretty far with this.
- This also opens up the possibility to customize diagnostics not just for the expression kind, but for the specific types
involved as well.
- For the purpose of presenting accurate type info, partially-specialized subexpressions are individually re-typechecked
free of any contextual types. This allows us to:
- Properly surface subexpression errors.
- Almost completely avoid any type variables in our diagnostics. In cases where they could not be eliminated, we now
substitute in "_".
- More accurately indicate the sources of errors.
- We do a much better job of diagnosing disjunction failures. (So no more nonsensical ‘UInt8’ error messages.)
- We now present reasonable error messages for overload resolution failures, informing the user of partially-matching
parameter lists when possible.
At the very least, these changes address the following bugs:
<rdar://problem/15863738> More information needed in type-checking error messages
<rdar://problem/16306600> QoI: passing a 'let' value as an inout results in an unfriendly diagnostic
<rdar://problem/16449805> Wrong error for struct-to-protocol downcast
<rdar://problem/16699932> improve type checker diagnostic when passing Double to function taking a Float
<rdar://problem/16707914> fatal error: Can't unwrap Optional.None…Optional.swift, line 75 running Master-Detail Swift app built from template
<rdar://problem/16785829> Inout parameter fixit
<rdar://problem/16900438> We shouldn't leak the internal type placeholder
<rdar://problem/16909379> confusing type check diagnostics
<rdar://problem/16951521> Extra arguments to functions result in an unhelpful error
<rdar://problem/16971025> Two Terrible Diagnostics
<rdar://problem/17007804> $T2 in compiler error string
<rdar://problem/17027483> Terrible diagnostic
<rdar://problem/17083239> Mysterious error using find() with Foundation types
<rdar://problem/17149771> Diagnostic for closure with no inferred return value leaks type variables
<rdar://problem/17212371> Swift poorly-worded error message when overload resolution fails on return type
<rdar://problem/17236976> QoI: Swift error for incorrectly typed parameter is confusing/misleading
<rdar://problem/17304200> Wrong error for non-self-conforming protocols
<rdar://problem/17321369> better error message for inout protocols
<rdar://problem/17539380> Swift error seems wrong
<rdar://problem/17559593> Bogus locationless "treating a forced downcast to 'NSData' as optional will never produce 'nil'" warning
<rdar://problem/17567973> 32-bit error message is really far from the mark: error: missing argument for parameter 'withFont' in call
<rdar://problem/17671058> Wrong error message: "Missing argument for parameter 'completion' in call"
<rdar://problem/17704609> Float is not convertible to UInt8
<rdar://problem/17705424> Poor error reporting for passing Doubles to NSColor: extra argument 'red' in call
<rdar://problem/17743603> Swift compiler gives misleading error message in "NSLayoutConstraint.constraintsWithVisualFormat("x", options: 123, metrics: nil, views: views)"
<rdar://problem/17784167> application of operator to generic type results in odd diagnostic
<rdar://problem/17801696> Awful diagnostic trying to construct an Int when .Int is around
<rdar://problem/17863882> cannot convert the expression's type '()' to type 'Seq'
<rdar://problem/17865869> "has different argument names" diagnostic when parameter defaulted-ness differs
<rdar://problem/17937593> Unclear error message for empty array literal without type context
<rdar://problem/17943023> QoI: compiler displays wrong error when a float is provided to a Int16 parameter in init method
<rdar://problem/17951148> Improve error messages for expressions inside if statements by pre-evaluating outside the 'if'
<rdar://problem/18057815> Unhelpful Swift error message
<rdar://problem/18077468> Incorrect argument label for insertSubview(...)
<rdar://problem/18079213> 'T1' is not identical to 'T2' lacks directionality
<rdar://problem/18086470> Confusing Swift error message: error: 'T' is not convertible to 'MirrorDisposition'
<rdar://problem/18098995> QoI: Unhelpful compiler error when leaving off an & on an inout parameter
<rdar://problem/18104379> Terrible error message
<rdar://problem/18121897> unexpected low-level error on assignment to immutable value through array writeback
<rdar://problem/18123596> unexpected error on self. capture inside class method
<rdar://problem/18152074> QoI: Improve diagnostic for type mismatch in dictionary subscripting
<rdar://problem/18242160> There could be a better error message when using [] instead of [:]
<rdar://problem/18242812> 6A1021a : Type variable leaked
<rdar://problem/18331819> Unclear error message when trying to set an element of an array constant (Swift)
<rdar://problem/18414834> Bad diagnostics example
<rdar://problem/18422468> Calculation of constant value yields unexplainable error
<rdar://problem/18427217> Misleading error message makes debugging difficult
<rdar://problem/18439742> Misleading error: "cannot invoke" mentions completely unrelated types as arguments
<rdar://problem/18535804> Wrong compiler error from swift compiler
<rdar://problem/18567914> Xcode 6.1. GM, Swift, assignment from Int64 to NSNumber. Warning shown as problem with UInt8
<rdar://problem/18784027> Negating Int? Yields Float
<rdar://problem/17691565> attempt to modify a 'let' variable with ++ results in typecheck error about @lvalue Float
<rdar://problem/17164001> "++" on let value could give a better error message
Swift SVN r23782
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
This prevented metatype casts and other kinds of cast that could be allowed from being accepted. Keep the subtype constraint if we're casting between generic class types with open type variables, because it can provide context to deduce type arguments in this case. This causes a regression in test/Constraints/members.swift that uses 'as' as a coercion, but we're planning to disambiguate cast/coercion syntax soon, which should fix that issue.
Swift SVN r23303
We'd like to kill this enum off eventually, since the runtime inevitably needs to be able to handle arbitrary checked casts in opaque contexts, and SILGen and IRGen can deal with picking more optimal runtime entry points for specific casts. Only the container bridging kinds are still depended on anymore, and even those ought to eventually be handlable by the runtime in 'x as T' situations. NFC yet.
Swift SVN r23127
Eliminate the implicit conversion from NSNumber to one of its bridged
value types (Int, Float, Double, Bool, etc.). One can use "as" to
perform the conversion instead. This eliminates a class of
accepts-dubious that involve lossy conversions from NSNumber to Int.
Our eventual arc is to eliminate all of these conversions. This is a
small, high-value step along that path rdar://problem/18269449.
Swift SVN r21879
A checked cast such as "x as String" or "x as? [String]", where x is of
class or Objective-C existential type, is now handled as a normal
checked cast rather than a Sema-generated call to the corresponding
witness. This eliminates a pile of hairy code from constraint
application and takes a step toward <rdar://problem/17408934>.
The part of the switch_objc.swift test I removed wasn't testing
anything useful; that's what <rdar://problem/17408934> is about.
Swift SVN r20970
The _forceBridgeFromObjectiveC and _conditionallyBridgeFromObjectiveC
requirements of the _ObjectiveCBridgeable protocol previously returned
Self and Self?, respectively, where 'Self' is the value type that is
bridged. This use of returns is fairly hostile to the idea of calling
the witnesses for these requirements from the C++ part of the runtime,
leading to "interesting" tricks with OpaqueExistentialContainer that
made it hard to use these witnesses within the dynamic casting
infrastructure.
Replace the returns with inout Self? parameters, which are far easier
to deal with in the C++ part of the runtime. Despite the churn because
we're changing the _ObjectiveCBridgeable protocol, this is NFC.
Swift SVN r20934
This is essentially NFC, but the protocols we were calling into are
changing in a way that makes it hard to use the witnesses directly
from the type checker.
Swift SVN r20933
Start capitalizing on some of the new diagnostic machinery in a few different ways:
- When mining constraints for type information, utilize constraints "favored" by the overload resolution process.
- When printing type variables, if the variable was created by opening a literal expression, utilize the literal
default type or conformance if possible.
- Utilize syntactic information when crafting diagnostics:
- If the constraint miner can produce a better diagnostic than the recorded failure, diagnose via constraints.
- Factor in the expression kind when choosing which types to include in a diagnostic message.
- Start customizing diagnostics based on the amount of type data available.
What does all this mean?
- Fewer type variables leaking into diagnostic messages.
- Far better diagnostics for overload resolution failures. Specifically, we now print proper argument type data
for failed function calls.
- No more "'Foo' is not convertible to 'Foo'" error messages
- A greater emphasis on type data means less dependence on the ordering of failed constraints. This means fewer
inscrutable diagnostics complaining about 'UInt8' when all the constituent expressions are of type Float.
So we still have a ways to go, but these changes should greatly improve the number of head-scratchers served up
by the type checker.
These changes address the following radars:
rdar://problem/17618403
rdar://problem/17559042
rdar://problem/17007456
rdar://problem/17559042
rdar://problem/17590992
rdar://problem/17646988
rdar://problem/16979859
rdar://problem/16922560
rdar://problem/17144902
rdar://problem/16616948
rdar://problem/16756363
rdar://problem/16338509
Swift SVN r20927
Squash _[Conditionally]BridgedToObjectiveC into one protocol. This
change results in simpler bridging code with fewer dynamic protocol
conformance checks, and solves the nasty naming/semantics problem that
resulted from having _ConditionallyBridgedToObjectiveC refining
_BridgedToObjectiveC.
Also, rename things so they're more symmetrical and less confusing.
Swift SVN r20664
To limit user confusion when using conditional expressions of type Bool?, we've decided to remove the BooleanType (aka "LogicValue") conformance from optional types. (If users would like to use an expression of type Bool? as a conditional, they'll need to check against nil.)
Note: This change effectively regresses the "case is" pattern over types, since it currently demands a BooleanType conformance. I've filed rdar://problem/17791533 to track reinstating it if necessary.
Swift SVN r20637
This only tackles the protocol case (<rdar://problem/17510790>); it
does not yet generalize to an arbitrary "class" requirement on either
existentials or generics.
Swift SVN r19896
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
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
