- Enhance the branch new argument label overload diagnostic to just
print the argument labels that are the problem, instead of printing
the types inferred at the argument context. This can lead to confusion
particularly when an argument label is missing. For example before:
error: argument labels '(Int)' do not match any available overloads
note: overloads for 'TestOverloadSets.init' exist with these partially matching parameter lists: (a: Z0), (value: Int), (value: Double)
after:
error: argument labels '(_:)' do not match any available overloads
note: overloads for 'TestOverloadSets.init' exist with these partially matching parameter lists: (a: Z0), (value: Int), (value: Double)
Second, fix <rdar://problem/22451001> QoI: incorrect diagnostic when argument to print has the wrong type
by specifically diagnosing the problem when you pass in an argument to a nullary function. Before:
error: cannot convert value of type 'Int' to expected argument type '()'
after:
error: argument passed to call that takes no arguments
print(r22451001(5))
^
Swift SVN r31795
decomposeArgParamType/matchCallArguments logic used by the rest of
sema, instead of doing its own home grown (and really bad) argument
matching stuff.
NFC since the later argument remapping logic doesn't make use of the same
approach yet, and we're not doing anything with CC_ArgumentLabelMismatch
in visitApplyExpr.
Swift SVN r31759
OverloadedDeclRefExpr or OverloadedMemberRefExpr when there is no
contextual type information available. The problem is that CSRanking
will take a look at the various solutions formed by picking each member
of the set, and will arbitrarily rank them against each other based on
how specific the candidates are. The problem with this is that the
constraints on the candidates are being resolved by UnresolvedType, which
means that we end up accidentally pruning the overload set too early.
This can lead to incorrect diagnostics that *should* have been ambiguity
diagnostics, such as the example in TypeCoercion/overload_noncall.swift.
It also is causing me other grief as I'm trying to make the call analysis
diagnostics more specific and the lack of the proper candidates is
triggering badness.
The actual change to the testsuite here is minor, but not all good. It will
be re-won by later changes.
Swift SVN r31744
change its implementation to take a list of TupleTypeElt for both the
from/to tuple type, but provider a convenience wrapper that takes the
from/to tuple type as TupleType's.
Swift SVN r31733
fixit hint in CSDiags instead of being a FixKind. This resolves a number of issues with
it, particularly that it didn't actually check to see if the function in question takes
a () argument or not.
This fixes:
<rdar://problem/21692808> QoI: Incorrect 'add ()' fixit with trailing closure
among other issues.
Swift SVN r31728
forced conversion to "_ -> T" if it will refine the type otherwise found by
doing a non-contextual type check. This allows us to diagnose calls to
non-function values with more specificity, e.g. adding another case were we
recommend "do" when using bare braces.
Swift SVN r31726
<rdar://problem/22333281> QoI: improve diagnostic when contextual type of closure disagrees with arguments
In the common case where someone doesn't care about the argument
list to a closure, we now generate a tailored error message with a
fixit to introduce the necessary "_,_ in " nonsense at the start
of the closure. IMO ideally we wouldn't require this, but until we
fix that type checker issue, we should at least give people the
obvious fix.
Swift SVN r31720
expr diagnosis stuff, giving us much better diagnostics on the cases in
expr/closure/closures.swift. This is part #2 of resolving
<rdar://problem/22333281> QoI: improve diagnostic when contextual type of closure disagrees with arguments
Swift SVN r31717
This includes a few changes:
- Enhance diagnoseGeneralConversionFailure to not ignore constraints that are fully solved by
CSDiags' heuristics.
- Enhance dictionary/array literals diagnostics to handle non-compliance to their literal
protocols with a specific and custom error message.
- Add specific QoI for turning accidental use of array literals in dictionary context into
the right dictionary syntax (with a fixit).
Swift SVN r31696
When simplifying tuple element locator, be careful about possibly
accessing non-existent elements of TupleExpr anchor.
<rdar://problem/22426860> CrashTracer: [USER] swift at …mous_namespace::ConstraintGenerator::getTypeForPattern + 698
Swift SVN r31629
give up instead of approximating an expr to complain about. This sort of thing
causes the bizarre diagnostics that don't make sense, and it is better to generate
a more general ambituity error than something that doesn't make sense. NFC since
diagnoseGeneralOverloadFailure is nearly dead anyway.
Swift SVN r31624
Introduce a new "OpenedGeneric" locator for when openGeneric opens a generic
decl into a plethora of constraints, and use this in CSDiags to distinguish
whether a constraint refers to an Expr as a whole or an "aspect" of the constraint.
Use that information in FailureDiagnosis::diagnoseGeneralConversionFailure
to know whether (as a fallback) we can correctly re-typecheck an entire expr
to obtain a missing type. If we are talking about an aspect of the expr, then
this clearly won't work.
The upshot of this is that where we previously compiled the testcase in 22519983
to:
y.swift:31:9: error: type '(inout _) -> Bool' does not conform to protocol 'RawRepresentable'
let a = safeAssign
^
we now produce the somewhat more useful:
y.swift:31:9: error: argument for generic parameter 'T' could not be inferred
let a = safeAssign
^
y.swift:27:6: note: in call to function 'safeAssign'
func safeAssign<T: RawRepresentable>(inout lhs: T) -> Bool {
^
Swift SVN r31620
diagnostics around invalid references to unavailable declarations, resolving
<rdar://problem/22491394> References to unavailable decls sometimes diagnosed as ambiguous
and a complex case exposed working through rdar://21928143.
Swift SVN r31587
member lookup for subscript instead of digging already-looked-up candidates
out of the constraint system. This allows us to produce more specific
diagnostics in failure cases and keeps subscripts inline with other decls
being looked up.
Swift SVN r31586
can use the same logic to diagnose candidate failure as
diagnoseGeneralMemberFailure. Also, add a testcase for a diagnostic
we don't do a great job on.
Swift SVN r31579
We type check expressions using a contextual purpose of CTP_CalleeResult
without a specific contextualType, because we install the contextual type
as a conversion constraint. This formerly failed the assertion expecting
that you have to have a type if you have a purpose, because parenexprs
propagated their contextual info down.
In addition to making the assertion in TypeCheckConstraints.cpp more
lenient, change visitCallExpr to just pass down the purpose directly
instead of installing it in its ExprTypeCheckListener.
Swift SVN r31575
use that contextual type to guide typechecking of the callee. This allows us to
propagate that type through generic constraints effectively, making us produce
much more useful diagnostics within closures taking methods like "map" (for
example).
This fixes:
<rdar://problem/20491794> QoI closures: Error message does not tell me what the problem is
Specifically, running the testcase:
enum Color { case Unknown(description: String) }
let xs: (Int, Color) = [1,2].map({ ($0, .Unknown("")) })
produces: error: cannot convert call result type '[_]' to expected type '(Int, Color)'
Changing that to:
let xs: [(Int, Color)] = [1,2].map({ ($0, .Unknown("")) })
produces: error: missing argument label 'description:' in call
... with a fixit to introduce the label.
This also fixes most of 22333090, but we're only using this machinery for CallExprs
so far, not for operators yet.
Swift SVN r31484
instead of the location of the decl. This matters when the candidates
are coming from the stdlib because they have no location, and we can
synthesize a prototype from the decl. Before we'd get:
t.swift:36:28: error: ambiguous reference to member 'String.init'
return lazy.map(String.init).joinBySeparator(", ")
~~~~~~~^~~~
<unknown>:0: note: found this candidate
<unknown>:0: note: found this candidate
<unknown>:0: note: found this candidate
.... 40 more of these.
Now we get:
t.swift:36:28: error: ambiguous reference to member 'String.init'
return lazy.map(String.init).joinBySeparator(", ")
~~~~~~~^~~~
Swift.String:95:3: note: found this candidate
init()
^
Swift.String:96:3: note: found this candidate
init(_ _core: _StringCore)
^
Swift.String:3:3: note: found this candidate
init(_ c: Character)
^
Swift.String:24:3: note: found this candidate
init(_ characters: String.CharacterView)
^
...
Swift SVN r31458
automatically pass down TypeCheckExprFlags::AllowUnresolvedTypeVariables
IFF we have no contextual type. This gives us UnresolvedTypes in more cases,
which improves diagnostics in various situations, and also simplifies
CSDiag. The change to misc_diagnostics.swift is a particularly nice progression.
Swift SVN r31406
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
argument list mismatches, and diagnose them with a very specific error when
they occur in member lookups. This fixes
<rdar://problem/22356434> QoI: Missing diagnostic for invalid arguments passed to enum case constructor
where before we'd produce:
ee.swift:5:16: error: type of expression is ambiguous without more context
let list: E = .C(wrongLabel: 0)
~^~~~~~~~~~~~~~~~
now we produce:
ee.swift:1:17: error: incorrect argument label in call (have 'wrongLabel:', expected 'label:')
let list: E = .C(wrongLabel: 0)
^~~~~~~~~~~
label
I think that unresolved member exprs now get good diagnostics in all cases that they have
a contextual type, but of course there are lots more cases where we're not getting a
contextual type.
Swift SVN r31402
