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
"unavoidable failure" path, along with Failure::DoesNotHaveNonMutatingMember and
just doing some basic disambiguation in CSDiags.
This provides some benefits:
- Allows us to plug in much more specific diagnostics for the existing "only has
mutating members" diagnostic, including producing notes for why the base expr
isn't mutable (see e.g. test/Sema/immutability.swift diffs).
- Corrects issues where we'd drop full decl name info for selector references.
- Wordsmiths diagnostics to not complain about "values of type Foo.Type" instead
complaining about "type Foo"
- Where before we would diagnose all failures with "has no member named", we now
distinguish between when there is no member, and when you can't use it. When you
can't use it, you get a vauge "cannot use it" diagnostic, but...
- This provides an infrastructure for diagnosing other kinds of problems (e.g.
trying to use a private member or a static member from an instance).
- Improves a number of cases where failed type member constraints would produce uglier
diagnostics than a different constraint failure would.
- Resolves a number of rdars, e.g. (and probably others):
<rdar://problem/20294245> QoI: Error message mentions value rather than key for subscript
Swift SVN r30715
get the same wording, fixing <rdar://problem/21964599> Different diagnostics for the same issue
While I'm in the area, remove some dead code.
Swift SVN r30713
which we have a contextual type that was the failure reason. These are a bit
longer but also more explicit than the previous diagnostics.
Swift SVN r30669
version of the new CTP_ReturnStmt conversion, used to generate return-specific
diagnostics. Now that we have a general solution, we can just use that.
This improves diagnostics in returns for accessors, since they were apparently
not getting the bit set.
Swift SVN r30665
typeCheckExpression takes a convertType and a contextualType, but the only
client of contextualType is pattern binding initialization that wants to
provide a hint to the initializer, but the type may not be fully formed
(e.g. just Array instead of Array<Int>) so it can't provide a full
convertType to that type.
After trying various ways of eliminating the concept and failing, repaint it
instead: instead of typeCheckExpression taking *both* a convertType and a
contextualType (even though they are mutually exclusive), have it only take
a single convertType and add a bit to TypeCheckExprOptions to indicate whether
it is a hint or a strong conversion. This simplifies all the callers of
typeCheckExpression and makes further evolution simpler.
Swift SVN r30658
- Improve handling of if_expr in a couple of ways: teach constraint simplification
about IfThen/IfElse and teach CSDiags about the case when the cond expr doesn't match
BooleanType. This is rarely necessary, but CSDiags is all about cornercases, and this
does fix a problem in a testcase.
- Be a bit more specific about the constraint failure kind (e.g. say subtype) and when
we have a protocol conformance failure, emit a specific diagnostic about it, instead of
just saying that the types aren't convertible.
Swift SVN r30650
conversion failures, making a bunch of diagnostics more specific and useful.
UnavoidableFailures can be very helpful, but they can also be the first constraint
failure that the system happened to come across... which is not always the most
meaningful one. CSDiag's expr processing machinery has a generally better way of
narrowing down which ones make the most sense.
Swift SVN r30647
- Don't "aka" a Builtin.Int2123 type, it just makes a bad diagnostic worse.
- Split out the predicate that CSDiag uses to determine what a conversion
constraint is to a helper fn, and add subtype constraints to the mix.
- Move eraseTypeData into CSDiag (its own client) as a static function.
- Make eraseTypeData be a bit more careful about literals, in an attempt to
improve diagnostics when literals get re-type-checked. It turns out that
this still isn't enough as shown by the regression on the
decl/func/default-values.swift testcase, and the
Constraints/dictionary_literal.swift testcase where one bad diagnostic turns
into another different one, but I'll keep working on it.
- Beef up diagnoseContextualConversionError and the caller to it to be more
self contained and principled about the conversion constraints it digs out
of the system. This improves the diagnostics on a couple of cases.
Swift SVN r30642
setConversionType along with the constraints they install. The constraints
should be enough by themselves, and CSDiags shouldn't need them to
bias the solution.
Of course, the constraints weren't enough, so improve CSDiags so that it can
do the right thing without them.
Swift SVN r30636
directly into the diagnostics subsystem. This ensures a more consistent
treatment of type printing (e.g. catches a case where a diagnostic didn't
single quote the type) and gives these diagnostics access to "aka".
Swift SVN r30609
typeCheckArgumentChildIndependently when we want an lvalue back,
instead of it always producing an lvalue. Provide it in a couple of
places, the most interesting of which is when forming a call to an
operator where an InOutExpr is implicitly provided by the fact that
the operator is an 'assignment' operator (something we don't actually
model right in the language at the moment for unary operators).
Producing this uses the candidate list we get from analyzing the
function, which makes this the first example of using the callee to
provide type information when analyzing an argument subexpression.
All this work for NFC. :-)
Swift SVN r30600
type check the subexpressions of a callexpr more consistently,
always checking the arguments independently (not just if one argument
is inout). This routes around issues handling tuples, and brings more
consistency to the experience. Factor this logic out and use it for
operators and subscripts as well.
Swift SVN r30583
independently (not just if one argument is inout). This routes around issues handling tuples,
and brings more consistency to the experience. Factor this logic out and use it for operators
and subscripts as well.
This improves a small collection of diagnostics, including the infamous:
// Infer incompatible type.
- func6(fn: {a,b->Float in 4.0 }) // expected-error {{cannot convert return expression of type 'Double' to expected return type 'Float'}}
+ func6(fn: {a,b->Float in 4.0 }) // expected-error {{cannot invoke 'func6' with an argument list of type '(fn: (_, _) -> Float)'}}
+ // expected-note @-1 {{expected an argument list of type '(fn: (Int, Int) -> Int)'}}
Swift SVN r30570
In a CallExpr, evaluate the function subexpr before the argument subexpr,
in prep for being able to use this type info to propagate them onto the
arguments when available. NFC.
Swift SVN r30567
argument of a failed call with typeCheckArbitrarySubExprIndependently,
which exposed some cases where ErrorType from outer solutions would be
left around on ParamDecls in ClosureExprs. Fix this all, which has NFC
on the testsuite.
Swift SVN r30563
diagnose problems inside of them instead of punting on them completely.
This leads to substantially better error messages in many cases, fixing:
<rdar://problem/19870975> Incorrect diagnostic for failed member lookups within closures passed as arguments ("(_) -> _")
<rdar://problem/21883806> Bogus "'_' can only appear in a pattern or on the left side of an assignment" is back
<rdar://problem/20712541> QoI: Int/UInt mismatch produces useless error inside a block
and possibly others. We are not yet capitalizing on available type information we do
have about closure exprs, so there are some cases where we produce
"error: type of expression is ambiguous without more context"
when this isn't strictly true, but this is still a huge step forward.
Swift SVN r30547
detailed analysis of callees, which give us overload sets in more cases,
producing notes more consistently, and producing much better diagnostics
for the curried cases in test/Constraints/diagnostics.swift.
This also allows us to eliminate getCalleeName, which simplifies things
in CSDiags.
Swift SVN r30491
with no returns *must* be (), add a defaulting constraint
so that it will be inferred as () in the absence of
other possibilities.
The chief benefit here is that it allows better QoI when
the user simply hasn't yet written the return statement.
Doing this does regress a corner case where an attempt
to recover from an uncalled function leads to the
type-checker inferring a result for a closure that
doesn't make any sense at all.
Swift SVN r30476
rationalizing how it handles members and curried functions, also paving
the way for future improvements. This implements the infrastructure but
keeps the functionality the same (the only functionality change is that
it works a bit better with vardecls of function type).
Swift SVN r30464
fixing:
<rdar://problem/20789423> Unclear diagnostic for multi-statement closure with no return type
<rdar://problem/21829141> BOGUS: unexpected trailing closure
<rdar://problem/21784170> Incongruous `unexpected trailing closure` error in `init` function which is cast and called without trailing closure.
Swift SVN r30443
