This teaches SubscriptExpr diagnostics to substitute the base type of a
subscript expr through the generic argument types, resolving achetypes in
common situations to concrete types. We previously complained:
error: cannot subscript a value of type '[String : AnyObject]' with an index of type 'String'
which is completely wrong, we now produce the correct error:
error: cannot assign value of type 'AnyObject?' to type 'String?'
Previously we erroneously complained:
error: cannot invoke 'contains' with an argument list of type '(String)'
now we correctly complain:
error: unexpected non-void return value in void function
This enhances CSDiags to use "getTypeOfMember" when analyzing method
candidates that are applied to a known base type. Using it allows us to
substitute information about the base, resolving archetypes that exist in
subsequent argument positions. In the testcase, this means that we use
information about Set<String> to know that the argument to "contains" is a
String.
This allows us to generate much better diagnostics in some cases, and works
around some limitations in the existing stuff for handling unresolved
archetypes. One unfortunate change is the notes in Misc/misc_diagnostics.swift.
Because we don't track argument lists very well, we are flattening an argument
list that is actually ((Int,Int)) into (Int, Int) so we get a bogus looking
diagnostic. This was possible before this patch though, it is just one
more case that triggers the issue.
When inferring a contextual type for the input expression to an assignment,
use getRValueType() to strip lvalues from tuple types in recursive positions,
this allows us to produce a sensible diagnostic of:
error: binary operator '%' cannot be applied to two 'T' operands
instead of:
error: cannot assign value of type 'T' to type '@lvalue _'
because we don't have a weird lvalue type in the way.
The original issue has long since been fixed, but we were now producing:
error: cannot subscript a value of type 'UnsafePointer<Int8>'
which is pretty obviously wrong. The problem is that when ranking subscript
decl candidates, CSDiags was using TC.isConvertibleTo to evaluate whether the
actual base type is compatible with the base type of a subscript decl. This
was failing when the base was generic, because the logic isn't opening
archetypes. Instead of incorrectly deciding that they are incompatible, just
decide we don't know if an archetype is present. This allows us to generate
good errors in situation like this.
A crash in CSDiag that happened when we were unconditionally looking at the
getter of a subscript. This failed on UnsafeMutablePointer because it only
has addressors, not getter/setters.
This improves the error message when attempting an array to UnsafeMutablePointer
conversion but where the element type of the array is incorrect or where the array itself
is immutable.
As a bonus fix, this dramatically improves the diagnostic when you pass "&array" to
a function that takes an UnsafePointer. We decided to not require & in this case, so
we can just provide a nice fixit to rip it off when this common error happens.
and probably others.
When we're type-checking a failed ApplyExpr that has an overload set that
prevents getting a specific type to feed into the initial typechecking of
the argument list, ranking can often narrow down the list of candidates
further, to the point where there is only one candidate left or where all
candidates agree that one argument is wrong.
In this case, re-type-check the subexpr with the expected type. In the case of
rdar://problem/22243469 we now produce:
t.swift:6:11: error: invalid conversion from throwing function of type '() throws -> ()' to non-throwing function type '() -> Void'
process {
^
instead of:
t.swift:6:3: error: cannot invoke 'process' with an argument list of type '(() throws -> ())'
process {
^
t.swift:6:3: note: overloads for 'process' exist with these partially matching parameter lists: (UInt, fn: () -> Void)
process {
^
Which is a heck of a lot less specific. Similarly, in the testcase from rdar://23550816, instead
of producing:
takeTwoFuncsWithDefaults { $0 + 1 }
error: cannot invoke 'takeTwoFuncsWithDefaults' with an argument list of type '((Int -> Int)?)'
note: expected an argument list of type '(f1: (Int -> Int)?, f2: (String -> String)?)'
we now produce:
error: cannot convert value of type '_ -> Int' to expected argument type '(String -> String)?'
which is a lot closer to what we want to complain about.
A literal in a sub-expression of the right-most expression in a sequence
could accidentally still have an error-type when going through CSApply.
rdar://problem/23488528
This also rearranges the logic for diagnosing faulty ApplyExprs to group the logic
for a single candidate together in one place. Nothing really earth shattering here,
just yak shaving.
code had the effect of squishing the note that printed the overload candidate
set for the operators in question. While these are not generally helpful given
how many overloads we have of (e.g.) the + operator, it doesn't do us any good
to have special cases like this, because methods can have tons of overloads as
well.
notion of a "near miss" for an argument type mismatch. This allows us to prune
the candidate set down in some cases. For example, in the testcase in
rdar://22243469 we are able to go from:
t.swift:6:3: error: cannot invoke 'process' with an argument list of type '(() throws -> ())'
process {
^
t.swift:6:3: note: overloads for 'process' exist with these partially matching parameter lists: (UInt, fn: () -> Void), (UInt)
down to:
t.swift:6:3: note: expected an argument list of type '(UInt, () -> Void)'
This paves the way for producing a better error in cases like this, but there are
other bits of weirdness that need to be untangled first.
When passing a contextual type to a call, if we have a scalar element
initializing a varargs parameter list, we need to use the varargs element type
contextually. Fixing this improves some confusing diagnostics.
That way, re-typechecking doesn't complain about the lvalue access kind
bit already having been set.
<rdar://problem/23185177> Compiler crashes in Assertion failed: ((AllowOverwrite || !E->hasLValueAccessKind()) && "l-value access kind has already been set"), function visit
Swift SVN r32854
call expression onto a callee when it was a binary expression. Doing this
requires improving the diagnostics for when the contextual result type is
incompatible with all candidates, but that is general goodness all around.
This fixes:
<rdar://problem/22333090> QoI: Propagate contextual information in a call to operands
and improves a number of diagnostics where the problem is that an operator
is used in a context that expects a type that it cannot produce.
Swift SVN r31891
of providing contextual diagnostics (e.g. producing the warning in
Constraints/dynamic_lookup.swift). This drops a specific diagnostic about
force casting the result of as! which was added in the Swift 1.2 timeframe
to explain the change in cast semantics. Now that as! has been around for
a long time, it is more confusing than helpful.
Swift SVN r31887
which is a case where the only problem lurking in the constraint system is a disjunction
between two impossible to solve conversion constraints. Arbitrarily pick the first one
so that we complain about *something*, instead of just calling the reference to path
ambiguous.
Swift SVN r31886
Otherwise, we'll hit an assertion failure (or produce the wrong message)
when a property has an addressor instead of a getter and setter.
rdar://problem/22363304
Swift SVN r31865
- 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
