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
information and use this to improve the UnresolvedMemberExpr errors.
The notable problem remaining is that we don't handle problems involving
argument labels.
Swift SVN r31378
Now we can propagate contextual types through collection literals even when they are generic, producing
specific diagnostics for elements within them.
Swift SVN r31327
we process contextual constraints when producing diagnostic. Formerly,
we would aggressively drop contextual type information on the floor under
the idea that it would reduce constraints on the system and make it more
likely to be solvable. However, this also has the downside of introducing
ambiguity into the system, and some expr nodes (notably closures) cannot
usually be solved without that contextual information.
In the new model, expr diagnostics are expected to handle the fact that
contextual information may be present, and bail out without diagnosing an
error if that is the case. This gets us more information into closures,
allowing more specific return type information, e.g. in the case in
test/expr/closure/closures.swift.
This approach also produces more correct diagnostics in a bunch of other
cases as well, e.g.:
- var c = [:] // expected-error {{type '[_ : _]' does not conform to protocol 'DictionaryLiteralConvertible'}}
+ var c = [:] // expected-error {{expression type '[_ : _]' is ambiguous without more context}}
and the examples in test/stmt/foreach.swift, test/expr/cast/as_coerce.swift,
test/expr/cast/array_iteration.swift, etc.
That said, this another two steps forward, one back thing. Because we
don't handle propagating sametype constraints from results of calls to their
arguments, we regress a couple of (admittedly weird) cases. This is now
tracked by:
<rdar://problem/22333090> QoI: Propagate contextual information in a call to operands
There is also the one-off narrow case tracked by:
<rdar://problem/22333281> QoI: improve diagnostic when contextual type of closure disagrees with arguments
Swift SVN r31319
favored bit. Also, ignore disjunction constraints now that we drop them on the floor
here.
Also, move the in_cast_expr_types blob down further, to make sure we emit the note for
a diagnostic after the error.
NFC on the testsuite.
Swift SVN r31312
handle try/try? exprs between the overload set and the CallExpr (previously
we'd blow by the CallExpr walking the parent map) and make some other
diagnostic generation stuff more careful about handling type variables.
NFC since type vars aren't getting into here yet.
Swift SVN r31301
diagnoseGeneralConversionFailure() to handle them (instead of it handling as? but
special code handling as!).
As part of this, enhance things so we get error messages about both the problem,
and the overall type involved (when they're different) e.g.:
if let s = setD as? Set<BridgedToObjC> { }
error: 'ObjC' is not a subtype of 'DerivesObjC'
note: in cast from type 'Set<DerivesObjC>' to 'Set<BridgedToObjC>'
This also finally fixes the case in test/Generics/existential_restrictions.swift
Swift SVN r31299
is considering, making it a bit stronger at handling disjunction constraints
as well as fixing it to stop sending non-conversion constraints down into
diagnoseGeneralConversionFailure.
Swift SVN r31294
specific when it fails, by printing a potentially partially resolved type for the
ambiguous expression in question, which it carries information. This can at least
tell what the ambiguous parts of the resultant type *are* in some cases (e.g. in
the Constraints/array_literal.swift case). That said, this diagnostic is still
admittedly not great.
This also exposes a couple of cases where we produce bogus diagnostics in general
(expr/cast/as_coerce.swift). The issue here is that these shouldn't be ambiguous
at all, they are being misreported due to 22320758), which I'll fix separately.
Swift SVN r31292
allowing these failures to hook into other diagnostic goodies (e.g. the
"did you mean to use '!' or '?'?" cases showing in the testsuite). That said,
by itself this doesn't have a huge impact, but avoids regressions with other
pending changes.
Swift SVN r31289
When diagnosing failure to typecheck a binary '~=' expression that was
synthesized when typechecking an expression pattern, offer a message
that describes the failure more helpfully.
<rdar://problem/21995744> QoI: Binary operator '~=' cannot be applied to operands of type 'String' and 'String?'
Swift SVN r31286
