independently (not just if one argument is inout). This routes around issues handling tuples,
and brings more consistency to the experience. Factor this logic out and use it for operators
and subscripts as well.
This improves a small collection of diagnostics, including the infamous:
// Infer incompatible type.
- func6(fn: {a,b->Float in 4.0 }) // expected-error {{cannot convert return expression of type 'Double' to expected return type 'Float'}}
+ func6(fn: {a,b->Float in 4.0 }) // expected-error {{cannot invoke 'func6' with an argument list of type '(fn: (_, _) -> Float)'}}
+ // expected-note @-1 {{expected an argument list of type '(fn: (Int, Int) -> Int)'}}
Swift SVN r30570
diagnose problems inside of them instead of punting on them completely.
This leads to substantially better error messages in many cases, fixing:
<rdar://problem/19870975> Incorrect diagnostic for failed member lookups within closures passed as arguments ("(_) -> _")
<rdar://problem/21883806> Bogus "'_' can only appear in a pattern or on the left side of an assignment" is back
<rdar://problem/20712541> QoI: Int/UInt mismatch produces useless error inside a block
and possibly others. We are not yet capitalizing on available type information we do
have about closure exprs, so there are some cases where we produce
"error: type of expression is ambiguous without more context"
when this isn't strictly true, but this is still a huge step forward.
Swift SVN r30547
with no returns *must* be (), add a defaulting constraint
so that it will be inferred as () in the absence of
other possibilities.
The chief benefit here is that it allows better QoI when
the user simply hasn't yet written the return statement.
Doing this does regress a corner case where an attempt
to recover from an uncalled function leads to the
type-checker inferring a result for a closure that
doesn't make any sense at all.
Swift SVN r30476
fixing:
<rdar://problem/20789423> Unclear diagnostic for multi-statement closure with no return type
<rdar://problem/21829141> BOGUS: unexpected trailing closure
<rdar://problem/21784170> Incongruous `unexpected trailing closure` error in `init` function which is cast and called without trailing closure.
Swift SVN r30443
return statements, or a return statement with no operand.
Also, fix a special-case diagnostic about converting a return
expression to (1) only apply to converting the actual return
expression, not an arbitrary sub-expression, and (2) use the
actual operand and return types, not the drilled-down types
that caused the failure.
Swift SVN r30420
This teaches overload constraint diagnosis to look at the resolved anchor
expression that fails (instead of assuming that it is the expr itself) and
walks up the AST to find the applyexpr in question. This allows us to give
much more specific diagnostics for overload resolution failures, and to give
much more specific location information.
Where before my recent patches we used to produce:
t.swift:2:3: error: cannot invoke 'assert' with an argument list of type '(Bool, String)'
assert(a != nil, "ASSERT COMPILATION ERROR")
^
t.swift:2:9: note: expected an argument list of type '(@autoclosure () -> Bool, @autoclosure () -> String, file: StaticString, line: UWord)'
assert(a != nil, "ASSERT COMPILATION ERROR")
^
with this and the other recent patches, we now produce:
t.swift:2:12: error: cannot invoke '!=' with an argument list of type '(Int, nil)'
assert(a != nil, "ASSERT COMPILATION ERROR")
~~^~~~~~
Swift SVN r29792
path associated with them, and to dig the expression the constraint refers to out
of the locator. Also teach simplifyLocator how to simplify closureexpr results out.
This eliminates a class of completely bogus diagnostics where the types reported
don't make any sense, resolving a class of radars like 19821875, where we now
produce excellent diagnostics.
That said, we still pick constraints to report that are unfortunate in some cases,
such as the example in expr/closure/closures.swift.
Swift SVN r29757
- Fix TypeCheckExpr.cpp to be more careful when propagating sugar from an
argument to the result of the function. We don't want to propagate parens,
because they show up in diagnostics later.
- Restructure FailureDiagnosis::diagnoseFailure() to strictly process the tree
in depth first order. Before it would only do this if contextual typing was
unavailable, leading to unpredictable inconsistencies between diagnostics.
- Always perform diagnoseContextualConversionError early, as part of the thing
that calls the visitor, instead of in each visit method. This may change in
the future, but is a simplification for now.
- Make the operator processing code handle the "candidate is an exact match"
case by emitting a diagnostic indicating that the result type of the operator
must not match expectations, instead of emitting the silly things like
"binary operator '&' cannot be applied to two Int operands" which is obviously
false.
These changes lead to minor improvements across the testsuite, and should make the
diagnostics more predictable for more complex real-world ones, but I haven't gone
through the radars yet.
Major missing pieces:
- CallExpr isn't using the same logic that the operators are.
- When you have a near match (only one argument mismatches) we should specifically
complain about that argument, instead of spewing an entire argument list.
- The noescape function attr diagnostic is being emitted twice now.
Swift SVN r29733
win from this other than simplification. Some minor wins are that we handle varargs
better and don't get extraneous ()'s in types in some cases.
Swift SVN r29729
- If the closure being rewritten was nested inside of another
closure, we would rewrite the nested closure into a new closure
having cs.DC as its parent, rather than the DeclContext of the
outer closure as required.
- If the closure being rewritten had nested closures, the parent
DeclContext of the nested closures was set to the old closure,
not the new one.
Fix both problems by having coerceClosureExprToVoid() modify the
closure in place instead of creating a new closure.
Fixes <rdar://problem/20931915>.
Swift SVN r29563
We no do not require "self." for closures capturing self in static/class methods.
While we do actually capture the metatype more than we should (rdar://21030087),
this doesn't matter to the developer, since this capture cannot cause a cycle
in the reference graph that they should have to reason about.
Swift SVN r28804
This sets the location of the implicit closure decls (like $0) to being the location
of the { in a ClosureExpr, instead of the location of the first use. The capture tracker
uses source location information of the decl and the DeclRefExpr to determine if the
referenced value was captured too early, which is what is causing this incorrect error.
Swift SVN r28802
<rdar://problem/15975935> warning that you can use 'let' not 'var'
<rdar://problem/18876585> Compiler should warn me if I set a parameter as 'var' but never modify it
<rdar://problem/17224539> QoI: warn about unused variables
This uses a simple pass in MiscDiagnostics that walks the body of an
AbstractFunctionDecl. This means that it doesn't warn about unused properties (etc),
but it captures a vast majority of the cases.
It also does not warn about unused parameters (as a policy decision) because it is too noisy,
there are a variety of other refinements that could be done as well, thoughts welcome.
Swift SVN r28412
If you want to make the parameter and argument label the same in
places where you don't get the argument label for free (i.e., the
first parameter of a function or a parameter of a subscript),
double-up the identifier:
func translate(dx dx: Int, dy: Int) { }
Make this a warning with Fix-Its to ease migration. Part of
rdar://problem/17218256.
Swift SVN r27715
The rule changes are as follows:
* All functions (introduced with the 'func' keyword) have argument
labels for arguments beyond the first, by default. Methods are no
longer special in this regard.
* The presence of a default argument no longer implies an argument
label.
The actual changes to the parser and printer are fairly simple; the
rest of the noise is updating the standard library, overlays, tests,
etc.
With the standard library, this change is intended to be API neutral:
I've added/removed #'s and _'s as appropriate to keep the user
interface the same. If we want to separately consider using argument
labels for more free functions now that the defaults in the language
have shifted, we can tackle that separately.
Fixes rdar://problem/17218256.
Swift SVN r27704
This post-hoc diagnostic replaces r24915, r25045, and r25054 by doing a
very basic check for representation incompatibility between two types.
More cases can be added as necessary.
rdar://problem/19600325, again.
Swift SVN r25117
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
This re-applies r24987, reverted in r24990, with a fix for a spuriously-
introduced error: don't use a favored constraint in a disjunction to avoid
applying a fix. (Why not? Because favoring bubbles up, i.e. the
/disjunction/ becomes favored even if the particular branch is eventually
rejected.) This doesn't seem to affect the outcome, though: the other
branch of the disjunction doesn't seem to be tried anyway.
Finishes rdar://problem/19600325
Swift SVN r25054
And even if we don't suggest wrapping in a closure (say, because there's
already a closure involved), emit a more relevant diagnostic anyway.
(Wordsmithing welcome.)
Wrapping a function value in a closure essentially explicitly inserts a
conversion thunk that we should eventually be able to implicitly insert;
that's rdar://problem/19517003.
Part of rdar://problem/19600325
Swift SVN r24987
Previously, trailing closures would try to match the first parameter
of (possibly optional) function type that didn't seem to have an
argument already, but in practice this broke when there were
parameters with default arguments before the function parameter.
The new rule is far simpler: a trailing closure matches the last
parameter. Fixes rdar://problem/17965209.
Swift SVN r24898
- Closures that are comprised of only a single return statement are now considered to be "single expression" closures. (rdar://problem/17550847)
- Unannotated single expression closures with non-void return types can now be used in void contexts. (rdar://problem/17228969)
- Situations where a multi-statement closure's type could not be inferred because of the lack of a return-type annotation are now properly diagnosed. (rdar://problem/17212107)
I also encountered a number of crashers along the way, which should now be fixed.
Swift SVN r24817
a vararg subpattern of a TuplePattern should be a TypedPattern
Check for a vararg subpattern to be a typed pattern seemed to be missing in closure arguments parsing.
Swift SVN r24733
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
This code is trying to avoid emitting multiple diagnostics on the same line:
before it was using a vector to keep track of exprs already emitted, I changed
it to clear the isImplicit() bit. Clearing isImplicit introduces problems
because various things (in this case, SourceRange validation) are keyed off
whether an expression is implicit or not.
Instead of solving it either of those ways, fix our walk to just not recursively
descend into the 'self' argument of a self.foo expression when doing the walk.
While we're here, make it so that ChrisW's example doesn't even produce the
diagnostic in question: the DRE is in a closure, but only because the entire
class is defined in the closure. Stop the walker from descending recursively
into decls at all.
Swift SVN r23793
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
You'll notice that emitting this diagnostic will make some already noisy closure-related errors slightly more so. This is unfortunate, but for the time-being it's better than crashing.
Swift SVN r21817
This already can't happen in most circumstances because of trailing closures, but we didn't explicitly disallow it at the beginning of a BraceStmt or following a statement production. Fixes the parser part of rdar://problem/17850752 (though there's a type checker bug there too).
Swift SVN r21663
