Updates the message to use the type or ValueDecl instead of this on previous 'Found this candidate' messages
Note: doees not yet change all test cases so more tests are failing
Improve Diagnostic message on overload ambiguitiy
Remove messages that say 'found this candidate' in favour of providing the type for the candidate to aid in selection when the candidates are presented in a dialogue window.
Fix more tests
In Swift < 6 warn about plain type name passed as an
argument to a subscript, dynamic subscript, or ObjC
literal since it used to be accepted.
Resolves: rdar://80270126
Solver has to keep track of excluded dynamic member results while
performing lookup because otherwise, in diagnostic modem it might
include such results as inaccessible.
Resolves: rdar://problem/61084565
* Revise error for incorrect subscript parameters.
We use subscripts for more than just indexes in Swift these days, so
the error message needs to be a bit more general.
* Use the term 'argument' instead of 'value'
Record the argument labels provided to a subscript in the solver, and
use that to filter out subscript declarations with non-matching
argument labels during function application. This reduces the number of
overloaded subscript declarations that will be considered in later
steps in the solver, reducing the solution space.
*Disable* this optimization in the normal member-lookup path, which is
intended to go away in the near future. This limits the scope of the
change somewhat, so we can separately tackle the diagnostics issue.
The one diagnostics change here is probably an improvement, because
the user explicitly stated the argument labels, and is more likely
missing a conversion on the argument than having typed the wrong
label.
`array-to-pointer` and other conversions are not restricted to apply
expressions, (dynamic) subscript arguments have them too, which
verifier has to support.
Resolves: rdar://problem/45825806
This makes diagnostics more verbose and accurate, because
it's possible to distinguish how many parameters there are
based on the message itself.
Also there are multiple diagnostic messages in a format of
`<descriptive-kind> <decl-name> ...` that get printed as
e.g. `subscript 'subscript'` if empty labels are omitted.
In `FailureDiagnosis::visitSubscriptExpr` if there is only a single
candidate available, verify that the problem is actually related
to the contextual mismatch by type-checking whole subscript without
contextual info, if that returns a type - it's contextual, otherwise
diagnose as incorrect argument type problem.
Resolves: rdar://problem/31977679
When generating constraints for subscript convert InOutType into LValueType,
because base of the subscript should never be marked as inout, but rather as
@lvalue to denote mutability.
Resolves <rdar://problem/25601561>.
The id-as-Any work regressed cases where Swift code could specify
heterogeneous collection literals, e.g.,
var states: [String: Any] = [
"California": [
"population": 37_000_000,
"cities": ["Los Angeles", "San Diego", "San Jose"],
],
"Oregon": [
"population": 4_000_000,
"cities": ["Portland", "Salem", "Eugene"],
]
]
Prior to this, the code worked (when Foundation was imported) because
we'd end up with literals of type [NSObject : AnyObject].
The new defaulting rule says that the element type of an array literal
and the key/value types of a dictionary literal can be defaulted if no
stronger type can be inferred. The default type is:
Any, for the element type of an array literal or the value type of a
dictionary literal, or
AnyHashable, for the key type of a dictionary literal.
The latter is intended to compose with implicit conversions to
AnyHashable, so the most-general inferred dictionary type is
[AnyHashable : Any] and will work for any plausible dictionary
literal.
To prevent this inference from diluting types too greatly, we don't
allow this inference in "top-level" expressions, e.g.,
let d = ["a" : 1, "b" : "two"]
will produce an error because it's a heterogeneous dictionary literal
at the top level. One should annotate this with, e.g.,
let d = ["a" : 1, "b" : "two"] as [String : Any]
However, we do permit heterogeneous collections in nested positions,
to support cases like the original motivating example.
Fixes rdar://problem/27661580.
The issue here is that the constraint solver was deciding on
FixKind::RelabelCallTuple as the fix for the problem and emitting the
diagnostic, even though there were two different fixes possible.
CSDiags has the infrastructure to support doing doing the right thing
here, but is only being used for ApplyExprs, not SubscriptExprs.
The solution is to fix both problems: remove FixKind::RelabelCallTuple,
to let CSDiags handle the problem, and enhance CSDiags to treat
SubscriptExpr more commonly with ApplyExpr. This improves several cases
where the solver was picking one solution randomly and suggesting that
as a fix, instead of listing that there are multiple different solutions.
Rearrange diagnoseGeneralConversionFailure to diagnose structural problems
even if we have some UnresolvedTypes floating around, then reject constraint
failures with UnresolvedTypes in them even harder. This keeps us giving
good errors about failures where we have a structural problem (with buried
irrelevant details) while not complaining about cases that are actually
ambiguous.
The end result of this is that we produce a lot better error messages in the
case of failed archetype inference. This also highlights the poor job we do
handling multi-stmt closureexprs...
This time, the issue is that TypeNullifier skips bodies of
multi-statement closures. However, ExprRewriter will type
happily pass them on to typeCheckClosureBody(). This could
trigger assertions. Fix this by skipping type checking of
multi-statement closures when diagnosing.
There seems to be a minor QoI regression in some test cases
that already looked pretty dodgy and/or had FIXMEs. However
I think its worth fixing a crash.
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.
<rdar://problem/21364448> QoI: Poor error message for ambiguous subscript call
and improving several other subscript-related diagnostics.
Swift SVN r31082
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
