If the placeholder is a typed one, parse its type string into a TypeRepr,
resolve it during typechecking and set it as the type for the associated EditorPlaceholderExpr.
Swift SVN r26215
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
Previously, we were reconstructing this mapping from the "full" opened
type produced by declaration references. However, when dealing with
same-type constraints between associated types and type parameters, we
could end up with an incomplete mapping, which let archetypes slip
through. Most of the churn here is sorting out the locators we need to
use to find the opened-type information. Fixes rdar://problem/18208283
and at least 3 dupes of it that I've found so far.
Swift SVN r25375
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
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
Aside from tidying things up, doing this results in some significant benefits:
- Allows for global constraint ordering optimizations over a given expression, not just on a peephole basis.
- Eliminates a set of order-dependent bugs in the solver that have been dogging us for a while. (rdar://problem/19459079)
- Brings another set of tyvar-to-tyvar solving problems out of the realm of the exponential. (rdar://problem/19005271)
- Opens up the possibility of optimizing constraints during later solving phases - not just while generating them.
Swift SVN r24693
Also, these changes fix the performance regressions that were introduced as a result of September's convertible/init requirement modifications, and allow us to roll back the associated workarounds that were added to the Adventure sample (rdar://problem/18942100).
Swift SVN r24520
- Addresses many common user-reported "expression too complex" bugs, including rdar://problem/18876786.
- Shaves up to 10% off of the total time to run our unit tests. (Unscientifically measured on my iMac: 427.46s before, 385.17s after.)
Swift SVN r24514
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
a capture list hung off the CaptureExpr it was associated with. This made
sense lexically (since a capture list is nested inside of the closure) but
not semantically. Semantically, the capture list initializers are evaluated
outside the closure, the variables are bound to those values, then the closure
captures the newly bound values.
To directly represent this, represent captures with a new CaptureListExpr node,
which contains the ClosureExpr inside of it. This correctly models the semantic
relationship, and makes sure that AST walkers all process the initializers of the
capture list as being *outside* of the closure.
This fixes rdar://19146761 and probably others.
Swift SVN r23756
Specifically, it's not when
- the conformance is being used within a function body (test included)
- the conformance is being used for or within a private type (test included)
- the conformance is being used to generate a diagnostic string
We're still a bit imprecise in some places (checking ObjC bridging), but
in general this means less of an issue for checking literals.
Swift SVN r23700
This commit treats all TypeExprs and casts as private if the decl context
is a function. In other cases we fall back to the general rules about the
current context (from r23447).
Swift SVN r23522
This commit adds availability checking for properties to Sema. When
EnableExperimentalAvailabilityChecking is enabled, we now emit a diagnostic
when a potentially unavailable property is accessed. To support this, we
now build type refinement contexts for most ValueDecls.
Swift SVN r22622
This commit also factors out some common checking and diagnostic code; it
additionally moves diagnostic emission for unavailable references from CSGen to
CSApply.
Swift SVN r22447
This commit adds tracking of the reason a declaration reference is potentially
unavailable to the UnavailableToOptionalExpr AST node and to OverloadChoice. We
will use this reason during SILGen to emit the appropriate run-time check and
during typechecking to provide more helpful diagnostics.
To keep OverloadChoice as small as possible, we encode the reason as an index
into a vector of reasons stored in a given instance of ConstraintSystem (this is
the same approach that Fix takes).
This commit adds Sema/OverloadChoice.cpp (for the parts of OverloadChoice that
now rely on ConstraintSystem) and AST/Availability.h (to bring in
availability-related structures without TypeRefinementContext).
Swift SVN r22377
This patch adds the ability (-enable-experimental-unavailable-as-optional) to
treat potentially unavailable declarations as if they had optional types. For
the moment, this is only implemented for global variables.
The high-level approach is to (1) record the potential unavailability of a
declaration reference in the overload choice during constraint generation; (2)
treat the declaration as if it had an optional type during overload resolution
(this is similar to how optional protocol members are treated); and (3) add an
implicit conversion (UnavailableToOptionalExpr) during constraint application
to represent the run-time availability check and optional injection.
This patch does not implement SILGen for UnavailableToOptionalExpr.
Swift SVN r22245
With this, we're now using initializer requirements rather than
"convertFromXXX" requirements everywhere, addressing the rest of
rdar://problem/18154091. r22176 eliminated the performance penalty
that prevented this change from sticking earlier.
Swift SVN r22177
When performing name lookup for a declaration that is being called,
use the argument labels at the call site to filter out those
declarations with incompatible argument labels.
Swift SVN r22176
Split the binary-operator favored-constraint optimization code into a
general part, which handles the construction of the disjunctions for a
favored set of constraints, and the binary-operator part, that
implements the existing optimization. NFC, but should make it easier
to perform similar optimizations in the future.
Swift SVN r22171
Pull the favored-constraints optimization for binary expressions out
into its own function. Use early exits to de-nest the code a few
levels, eliminate some dead code paths that couldn't actually occur,
replace a dyn_cast/.getPointer() dance with getAs<>, and and avoid
excess SmallVector traffic by only copying the "old" constraints in
cases where we might be added new ones (e.g., due to the synthesized
==). NFC
Swift SVN r22170
This patch adds the beginning of building the type refinement context tree for
availability checking in Sema, guarded by by the
-enable-experimental-availability-checking option. This tree parallels the AST
but is much more sparse: we introduce a new TypeRefinementContext only when
needed. Each context refines the range of potential OS versions that could be
encountered at run time. For the moment, we only refine contexts for function
bodies. I will add refinement contexts for #os(...) in a later commit.
The AST is not directly connected to the TRC tree except at the SourceFile
level; when type checking, we use source locations to look up the TRC
corresponding to an AST element. For the moment, we emit a diagnostic when the
programmer references a potentially unavailable declaration. We will later
change this to treat the declaration as if it had optional type.
Swift SVN r22145
The initializer requirement is causing too much exponential behavior
in the constraint solver. We'll have to address that
first. Re-instating this change is tracked by rdar://problem/18381811.
Swift SVN r22080
With this, we're now using initializer requirements rather than
"convertFromXXX" requirements everywhere, addressing the rest of
rdar://problem/18154091.
Swift SVN r22078
Locators that refer to opened type parameters now carry information
about the source location where we needed to open the type, so that
(for example) we can trace an opened type parameter back to the
location it was opened. As part of this, eliminate the "rootExpr"
fallback, because we're threading constraint locators everywhere.
This is infrastructural, and should be NFC.
Swift SVN r21919
This patch adds a new 'pound_os' token, a new case for it in parseExprPostfix, and parsing of platform version constraints, e.g., OSX >= 10.10.
It also adds enough type checking and SILGen to get the parsing tests to run without triggering "Unimplemented" assertions.
Swift SVN r21865
This commit adds a new expression (AvailabilityQueryExpr) and a single kind of
specification for when a block of code or function is available
(VersionConstraintAvailabilitySpec). We may add more kinds of specifications
in the future. At the moment, the AvailabilityQueryExpr allows only a
single platform to be queried; I will add support for multiple platforms
in a later commit.
This commit contains just the added AST nodes; no parsing, type checking, etc.
I’ve added assert(false && “Unimplemented”) for places where support for
AvailabilityQueryExpr will need to be added later.
Swift SVN r21760
If either parameter to == has a known concrete type at constraint generation
time, see if that type is a nominal that can derive its conformance to
Equatable. If so, do so, and then add that == to the overload set.
(It may already be there, but that's okay -- it will get uniqued later.)
This isn't perfect because it relies on one of the parameters to == having
a concrete type /before/ constraint solving. There are plenty of reasons
why that wouldn't happen. But this at least fixes the common case, and
breaking the expression up into multiple lines is a less distasteful
workaround than replacing (x == .Value) with !(x != .Value). I've added a
test case that should work but doesn't that we can revisit later.
rdar://problem/18073705
Swift SVN r21557
This is another instance where we choose a favored constraint that
only type checks because we're bridging through NSNumber, causing
awful problems. Fixes rdar://problem/17962491.
Swift SVN r21445
