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
as a proper error, and change it to not be incorrect. Multi-statement
closures *only* need a return type if they cannot be inferred.
This fixes:
<rdar://problem/22086634> "multi-statement closures require an explicit return type" should be an error not a note
Swift SVN r30937
Fix construction and simplication of constructor member locators, so
that locators involving constructor members can be simplified during
diagnosis.
<rdar://problem/21427130> Swift can't discriminate on arity of function parameters
Swift SVN r30932
Take expression depth and preorder traversal index into account when
deciding which unresolved overload to complain about, rather than giving
up if there are two exprs with the same number of overloads. Don't
consider solutions with fixes when emitting ambiguous-system
diagnostics.
Swift SVN r30931
down to call argument lists that have more than one operand (heavily leveraging
"computeTupleShuffle"). This resolves a great number of QoI radars, including
things like:
<rdar://problem/19981782> QoI: poor diagnostic for call to memcmp with UInt length parameter
where we used to produce:
error: cannot invoke 'memcmp' with an argument list of type '([UInt8], [UInt8], UInt)'
return memcmp(left, right, UInt(left.count)) == 0
^
note: expected an argument list of type '(UnsafePointer<Void>, UnsafePointer<Void>, Int)'
but now we produce:
error: cannot convert value of type 'UInt' to expected argument type 'Int'
return memcmp(left, right, UInt(left.count)) == 0
^~~~~~~~~~~~~~~~
which is more "to the point"
Swift SVN r30930
machinery, instead of in multiple places in CSSolver and CSDiags. This leads
to more predictable behavior (e.g. by removing the UnboundGenericParameter
failure kind) and eliminates a class of "'_' is not convertible to 'FooType'"
diagnostics.
Swift SVN r30923
other constraints intentionally ripped off, tell the recursive solution that
we can tolerate an ambiguous result. The point of this walk is not to
produce a concrete type for the subexpression, it is to expose any structural
errors within that subsystem that don't depend on the contextual constraints.
Swift SVN r30917
noescape/throws bits to avoid confusing the issue with folks who don't know that you can
pass a nothrow closure to a throw parameter (which are going to be pervasive in the
stdlib)
Swift SVN r30912
argument. For now we start with some of the most simple cases: single argument
calls. This dramatically improves the QoI for error messages in argument lists,
typically turning a error+note combo into a single specific error message.
Some minor improvements coming (and also generalizing this to n-ary calls), but it
is nice that all the infrastructure is starting to come together...
Swift SVN r30905
so we complain about 'nil' instead of NilLiteralConvertible. This doesn't have
much effect on the testsuite at the moment, but will when other changes land.
Swift SVN r30873
