<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
specifies some # of arguments but the closureexpr itself disagrees. This is
step #1 to resolving
<rdar://problem/22333281> QoI: improve diagnostic when contextual type of closure disagrees with arguments
Swift SVN r31715
Have ClosureExpr::hasSingleExpressionBody() return true even after the
closure has been coerced to return Void, i.e., { E } has been rewritten
as { E; () }. This fixes some implicit-self diagnostics, and probably
others.
Revision to r31654 for 22441425.
Swift SVN r31665
When assigning discriminators to autoclosure expressions, make sure to
walk into single-expression closures even when they have been converted
to return void, because they aren't type-checked separately.
<rdar://problem/22441425> Swift compiler "INTERNAL ERROR: this diagnostic should not be produced"
Swift SVN r31654
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
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
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
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
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
Teach skipToEndOfInterpolatedExpression() to match quote marks as well
as parentheses in the interpolated expression. This makes expressions
like "hello \(names["bob"])" possible.
Swift SVN r31283
<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
It's not /really/ an infix operator, but it behaves like a very low
precedence prefix operator. On the other hand, 'try' and 'try!' can
freely move in and out of all the operations we add in fix-its, so
don't bother.
rdar://problem/22259867
Swift SVN r31200
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
And give a proper warning when you use 'try?' in a non-failable init.
And do the right thing when trying to SILGen 'try?' delegating to a
failable throwing init.
And make sure DI understands that this is, in fact, an initialization.
More rdar://problem/21692467
Swift SVN r31060
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
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
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
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
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
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
