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
fixing <rdar://problem/22020088> QoI: missing member diagnostic on optional gives worse error message than existential/bound generic/etc
Swift SVN r30844
- Produce more specific diagnostics relating to different kinds of invalid
- add a testcase, nfc
- Reimplement FailureDiagnosis::diagnoseGeneralMemberFailure in terms of
Not including r30787 means that we still generate bogus diagnostics like:
[1, 2, 3].doesntExist(0) // expected-error {{type 'Int2048' does not conform to protocol 'IntegerLiteralConvertible'}}
But it is an existing and separable problem from the issues addressed here.
Swift SVN r30819
r30787 causes our tests to time out; the other commits depend on r30787.
Revert "revert part of my previous patch."
Revert "Produce more specific diagnostics relating to different kinds of invalid"
Revert "add a testcase, nfc"
Revert "- Reimplement FailureDiagnosis::diagnoseGeneralMemberFailure in terms of"
Revert "Fix places in the constraint solver where it would give up once a single "
Swift SVN r30805
member references:
- Use of instance members from types
- Use of type members from instances
- Use of mutating getters.
This surely resolves some radars, but I'll have to dig them out later.
Swift SVN r30796
performMemberLookup, eliminating a ton of duplicated logic, but keeping the
same general behavior.
- Now that r30787 landed, we can have diagnoseGeneralMemberFailure inform
clients when a member lookup fails due to referencing a candidate decl of
ErrorType (i.e, it is already invalid somehow). When this happens, there is
no reason to diagnose a problem, because the original issue has been diagnosed
and anything we produce now is just garbage.
The second point cleans up a bunch of bogus diagnostics in the testsuite, which are
*actually* due to upstream error that are already diagnosed.
Swift SVN r30789
