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
The fallthrough path that this enables does ambiguity checking and simplifies active
constraints that are left into the system, before jumping into diagnoseFailureForExpr.
By jumping into diagnoseFailureForExpr directly, CSDiags can produce the wrong
diagnostic because the constraints are still on the active list.
NFC for now because other changes are needed to provoke this.
Swift SVN r31272
what it does, and add a more general forEachChildExpr that walks the
entire expr tree. Allow both of these to mutate the expr in question
by allowing the lambda to return a new expr.
NFC, this is needed by subsequent work.
Swift SVN r31267
produce specific diagnostics about individual elements being incorrect instead of
complaining about the whole thing in aggregate.
This improves diagnostics immediately, but is also important to unblock future progress.
Swift SVN r31264
<rdar://problem/18397777> QoI: special case comparisons with nil
<rdar://problem/18042123> QoI: Fixit for "if !optional" should suggest "if optional == nil"
Swift SVN r31204
the regressions that r31105 introduced in the validation tests, as well as fixing a number
of other validation tests as well.
Introduce a new UnresolvedType to the type system, and have CSDiags start to use it
as a way to get more type information out of incorrect subexpressions. UnresolvedType
generally just propagates around the type system like a type variable:
- it magically conforms to all protocols
- it CSGens as an unconstrained type variable.
- it ASTPrints as _, just like a type variable.
The major difference is that UnresolvedType can be used outside the context of a
ConstraintSystem, which is useful for CSGen since it sets up several of them to
diagnose subexpressions w.r.t. their types.
For now, our use of this is extremely limited: when a closureexpr has no contextual
type available and its parameters are invalid, we wipe them out with UnresolvedType
(instead of the previous nulltype dance) to get ambiguities later on.
We also introduce a new FreeTypeVariableBinding::UnresolvedType approach for
constraint solving (and use this only in one place in CSDiags so far, to resolve
the callee of a CallExpr) which solves a system and rewrites any leftover type
variables as UnresolvedTypes. This allows us to get more precise information out,
for example, diagnosing:
func r22162441(lines: [String]) {
lines.map { line in line.fooBar() }
}
with: value of type 'String' has no member 'fooBar'
instead of: type of expression is ambiguous without more context
This improves a number of other diagnostics as well, but is just the infrastructural
stepping stone for greater things.
Swift SVN r31130
as a way to get more type information out of incorrect subexpressions. UnresolvedType
generally just propagates around the type system like a type variable:
- it magically conforms to all protocols
- it CSGens as an unconstrained type variable.
- it ASTPrints as _, just like a type variable.
The major difference is that UnresolvedType can be used outside the context of a
ConstraintSystem, which is useful for CSGen since it sets up several of them to
diagnose subexpressions w.r.t. their types.
For now, our use of this is extremely limited: when a closureexpr has no contextual
type available and its parameters are invalid, we wipe them out with UnresolvedType
(instead of the previous nulltype dance) to get ambiguities later on.
We also introduce a new FreeTypeVariableBinding::UnresolvedType approach for
constraint solving (and use this only in one place in CSDiags so far, to resolve
the callee of a CallExpr) which solves a system and rewrites any leftover type
variables as UnresolvedTypes. This allows us to get more precise information out,
for example, diagnosing:
func r22162441(lines: [String]) {
lines.map { line in line.fooBar() }
}
with: value of type 'String' has no member 'fooBar'
instead of: type of expression is ambiguous without more context
This improves a number of other diagnostics as well, but is just the infrastructural
stepping stone for greater things.
Swift SVN r31105
no type set on them. This is the minimal fix to address the regressions
on two validation tests, but another approach (not involving null types)
seems like it would be a good idea to investigate on mainline.
Swift SVN r31099
<rdar://problem/21364448> QoI: Poor error message for ambiguous subscript call
and improving several other subscript-related diagnostics.
Swift SVN r31082
constraints of each kind, enhance FailureDiagnosis::diagnoseGeneralConversionFailure to
ignore conversion constraints that are either trivially resolvable (like Int conforming
to IntegerLiteralConvertible) or constraints that cannot be resolved because a type
variable is ambiguous.
This eliminates the last (known to me at least!) source of diagnostics that end up
complaining about obviously incorrect issues.
Swift SVN r31065
diagnoseGeneralFailure to be named diagnoseConstraintFailure and change how
it works:
Now it ranks unresolved constraints in the system based on kind (e.g. whether
they are favored, member constraints ahead of conversion constraints, etc) and
then tries to emit a diagnostic for each failure kind one after another.
This means that if there are multiple failed conversion constraints, but one
is obviously satisfiable, that we continue on to diagnose the next one. This
clears up a swath of embarassing diagnostics and refixes:
<rdar://problem/19658691> QoI: Incorrect diagnostic for calling nonexistent members on literals
Swift SVN r31046
pieces: Failure diagnosis (which should shrink over time), Expr diagnosis
(which should grow over time), and constraint diagnosis (which should shrink
over time but be the ultimate backstop). This sets up the layers so that
all but the last can "return false" with impunity if they have no bright
ideas based on the context they know about.
Swift SVN r31043
the FailureDiagnosis::conversionConstraint state to be a local variable in
diagnoseGeneralConversionFailure(), unblocking other progress. NFC.
Swift SVN r31042
and diagnoseGeneralConversionFailure(). The previous approach of trying
to dig into anchors would often lead to complaining about types at
different levels in the same diagnostic, and the complexity of the former
code isn't needed now that other changes have landed.
Swift SVN r31036
and use it in the diagnostics path (only!) to revisit active constraints that
are left in the system after a failure is found. This improves a number of
otherwise sad diagnostics in the testsuite and resolves rdar://22083115.
The one QoI regression (in throwing_functions.swift) is now tracked by 22158167.
Swift SVN r31027
explicitly written and disagree with context, and when context provides a
non-explicitly written type that disagrees with the body of the closure.
Swift SVN r30984
using it to improve closure diagnostics by inferring the types of otherwise
untyped closure paramdecls from this context information. This
resolves:
<rdar://problem/20371273> Type errors inside anonymous functions don't provide enough information
producing
error: binary operator '==' cannot be applied to operands of type 'Int' and 'UInt'
note: overloads for '==' exist with these partially matching parameter lists: (UInt, UInt), (Int, Int)
and:
<rdar://problem/20978044> QoI: Poor diagnostic when using an incorrect tuple element in a closure
producing:
error: value of tuple type '(Int, Int)' has no member '2'
and probably a lot more. We're still limited from getting things like "foo.map {...}" because
we're not doing type subsitutions from the base into the protocol extension member.
Swift SVN r30971
