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
instead of treating it as an erroneous subexpr. This was causing <<error type>> to pop
out in diagnostics, and had a hackaround that dissolves now from CSDiags.
Swift SVN r30442
we can start taking advantage of ambiguously typed subexpressions in CSDiags. We
start by validating the callee function of ApplyExprs, which substantially improves
our abilities to generate precise diagnostics about malformed calls.
This is the minimal introduction of this concept to CSDiags, a lot of refactoring
is yet to come, however, this is enough to resolve:
<rdar://problem/21080030> Bad diagnostic for invalid method call in boolean expression
<rdar://problem/21784170> Incongruous `unexpected trailing closure` error in `init` function which is cast and called without trailing closure.
one of the testcases from:
<rdar://problem/20789423> Unclear diagnostic for multi-statement closure with no return type
and a bunch of other places where we got weird "unexpected trailing closure"
diagnostics that made no sense. As usual, it is two steps forward and one step back,
as this exposed some other weird latent issues like:
<rdar://problem/21900971> QoI: Bogus conversion error in generics case
Swift SVN r30429
return statements, or a return statement with no operand.
Also, fix a special-case diagnostic about converting a return
expression to (1) only apply to converting the actual return
expression, not an arbitrary sub-expression, and (2) use the
actual operand and return types, not the drilled-down types
that caused the failure.
Swift SVN r30420
which allows solving of a constraint system to succeed without emitting
errors in the face of ambiguous solutions. This is important for CSDiag
because it is in the business of trying to solve subexpressions of a global
expression - and it wants to know the difference between a subexpression
that is inherently impossible to solve, vs one that is simply ambiguous
because its context has been removed.
Use this in CSDiag's typeCheckChildIndependently() to provide it an
extra flag that enables this behavior. This is currently unused, so NFC
with this patch.
Swift SVN r30402
DiscardAssignmentExpr's, because they require context to typecheck anyway
and doing so triggers bogus errors about _ needing to be on the LHS of an
assignment. There is a correct way to fix this, but layers of issues need
to be peeled off before that can happen.
This fixes <rdar://problem/21883806> Bogus "'_' can only appear in a pattern or on the left side of an assignment" is back
but the new diagnostic that is revealed now that this bogus one is removed is
also really bad.
Swift SVN r30369
to avoid having to use CS->TC.diagnose everywhere.
Also, change SubscriptExpr diagnostics to put the caret on the [ of the subscript
instead of at the start of the base expression. For example, instead of:
error: cannot subscript a value of type '[Int]?'
return foo.array[0]
^~~~~~~~~
emit:
error: cannot subscript a value of type '[Int]?'
return foo.array[0]
~~~~~~~~~^
Swift SVN r30318
value, and use that to rank a problem as very specific. This required indicating a difference
between singular argument mismatch vs self mismatch and single-argument mismatch (which is very
specific) as being different from the argument list in general mismatching (which matters to
differentiate argument lists that contain a single argument).
These extra mechanics combine to fix <rdar://problem/21362748> [WWDC Lab] QoI: cannot subscript a value of type '[Int]?' with an index of type 'Int'
Swift SVN r30305
To support this, make 'try' and 'try!' no longer IdentityExprs
and give them a common base class to simplify the sorts of
analyses and transformations that do want to treat them
as identity-like.
Note that getSPE() still looks through normal 'try', since
the overwhelming proportion of clients will consider it
semantically equivalent to the undecorated expression.
Change getValueProvidingExpr() to look through try!, since
it's allowed to return something with slightly different
semantics, and use it in the unused-result diagnostic.
Fixes a large number of bugs, mostly uncaught, with SILGen
peepholes that use getSPE() and therefore were accidentally
looking through try!. <rdar://21515402>
Swift SVN r30224
into trouble when we dive into a subexpr of a ClosureExpr, because that subexpr
may refer to type variables on the closureexpr's parameters.
Check for this case, and refuse to dive into the subexpr in this case. It would
be great to rewrite the closure parameter types to Type() or ErrorType or something
so that we can proceed even in this case, but this causes us to fail to catch
nested constraint checking failures.
This was figured out while working on other things, but fixes a validation test.
Swift SVN r30135
avoid emitting this diagnostics. They are always irritating to it because they
are duplicative with whatever the actual type constraint problem is. It also
interferes with there recursive structure of the problem.
Disabling them also allows us to shorten the black list of expr nodes that cannot
be handled in typeCheckIndependentSubExpression.
Swift SVN r30122
and getTypeOfExpressionWithoutApplying and change typeCheckExpression
to take it as a single-entry OptionSet, in prep for getting other
options. NFC.
Swift SVN r30121
1) Teach resolveImmutableBase about SubscriptExprs that have
resolved the decl that they are referring to. This fixes case where we'd
generate an imprecise diagnostic because we weren't able to find the
result in the ResolvedOverloadSet list (which is because CSApply rewrite
it to a different expr node and the locator can't find it).
2) Change FailureDiagnosis::typeCheckIndependentSubExpression to have a
blacklist of expressions that aren't recursed into, along with rationale
for each node kind, instead of a short white list. This produces more
predictable results, e.g. producing the right diagnostic in
ClangModules/objc_parse.swift
Swift SVN r30118
- Remove all uses of CleanupIllFormedExpressionRAII from this file, which are now
unnecessary since this is handled at a higher level.
- Stop splatting ErrorType in the diagnostics stuff. This was formerly needed to
indicate that a diagnostic is emitted, but is now handled other ways. Removing
this enables the type checker to produce other follow on warnings in some cases
(e.g. var should be marked let).
- Remove an arbitrary limitation on unop and binops that didn't print an overload
candidate set with one entry, leading to better consistency in diagnostics, now
that all the pieces are in place to make this not be super annoying.
Swift SVN r30084
RebindSelfInConstructorExpr, which gets issues related to
self.init and super.init onto the CallExpr best path, instead
of in the generic overload constraint failure morass.
Swift SVN r30067
argument list for a CallExpr instead of matching a gang of typevartypes against them.
This allows us to produce better matches in some cases.
Swift SVN r30065
disjunction candidate set for a constraint that fails to match, not just
a single Bind within it. This eliminates the arbitrary nature of picking
one match, allowing us to diagnose the entire candidate set.
This exposed that we were trying to do argument matching of 'self' against
the partially curried arguments. Adjust the hack we have for that a bit to
make things work, but there are bigger problems for argument matching that
will need to be addressed.
Swift SVN r30064
facilities used by operators etc. This required a bunch of changes to make
the diagnostics changes strictly an improvement:
- Teach the new path about calls to TypeExprs.
- Teach evaluateCloseness some simple things about varargs.
- Make the generic diagnosis logic produce a better error when there is
exactly one match.
Overall, the resultant diagnostics are a step forward: we now produce candidate
set notes more uniformly, and the messages about some existing ones are
more specific. This is just another stepping stone towards progress though.
Swift SVN r30057
Now for:
let req = NSURLRequest(URL: NSURL(string: "<some url>")!)?
instead of producing:
test.swift:2:58: error: could not find an overload for 'init' that accepts the supplied
we produce the correct diagnostic, with a fixit:
error: cannot use optional chaining on non-optional value of type 'NSURLRequest'
let req = NSURLRequest(URL: NSURL(string: "<some url>")!)?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^
This also consolidates some existing diagnostics to improve their wording.
Swift SVN r30049
satisfying the request of <rdar://problem/20409366> Diagnostics for init calls should print the class name
I'm keeping that radar open though, because the case in it should get better still.
Swift SVN r30029
Completely revamp getTypeOfIndependentSubExpression, to return the subexpression produced by
type checking instead of just a type. This is important for cases when type checking changes
the root of the AST (e.g. resolving an unresolved_dot_expr) and allows us to eliminate grungy
and unsafe recovery code that was in place to work around this. The last point makes the
examples in Constraints/lvalues.swift better (giving a somewhat generic error instead of an
specific-but-incorrect error that 'z' is immutable),
but more importantly, it fixes a class of crashers like:
<rdar://problem/21369926> Malformed Swift Enums crash playground service
where we'd end up with a LiteralExpr typed as Int instead of a Builtin integer type of some sort.
Swift SVN r30028
... by reimplementing the DiscardAssignmentExpr checker in MiscDiagnostics
instead of being in CSApply (which gets run on partial expression ASTs).
Also, when type checking and salvaging an expression fails, do not generate
structural diagnostics in addition to the type checker diagnostics, they are
just noise.
Swift SVN r29937
- Fix a diagnostic to not include redundant ''s around a type name.
- Rework CleanupIllFormedExpression to be simpler and to not
unconditionally destroy data when it doesn't. This makes a code
completion test a bit more precise.
- Completely revamp getTypeOfIndependentSubExpression, to return the
subexpression produced by type checking instead of just a type. This
is important for cases when type checking changes the root of the AST
(e.g. resolving an unresolved_dot_expr) and allows us to eliminate
grungy and unsafe recovery code that was in place to work around this.
The last point makes the examples in Constraints/lvalues.swift better (giving
a somewhat generic error instead of an specific-but-incorrect error that 'z'
is immutable), but more importantly, it fixes a class of crashers like
<rdar://problem/21369926> Malformed Swift Enums crash playground service
where we'd end up with a LiteralExpr typed as Int instead of a Builtin integer
type of some sort.
Swift SVN r29932
and change it to get the source before the destination. This is the right thing to
do and also conveniently works around a bogus:
'_' can only appear in a pattern or on the left side of an assignment
diagnostic.
This needs to be fixed in a more systematic way to cover other cases, but this change
is the right thing to do independently of that.
Swift SVN r29929
when we're diagnosing a value member constraint but have resolved the base, then the
member must not exist. Diagnose this with a specific message.
Swift SVN r29908
value member constraints do.
This fixes:
<rdar://problem/21662365> QoI: diagnostic for for-each over an optional sequence isn't great
before we'd produce:
t.swift:3:10: error: '[Int]?' does not have a member named 'Generator'
for x in array {
^
now we produce:
t.swift:3:10: error: value of optional type '[Int]?' not unwrapped; did you mean to use '!' or '?'?
for x in array {
^
Swift SVN r29902
- Remove a weird special case for literals from TypeChecker::typeCheckCondition.
- Enhance FailureDiagnosis::getTypeOfIndependentSubExpression to know about situations
where recursive type checks fail (in some nested situation) but still produce a type
for the top level of the expr tree.
- Remove dead code from CSApply now that you can't branch on Builtin.Int1.
The first & second combine to slightly improve one case I've been looking at in
test/expr/expressions.swift.
Swift SVN r29860
expressions. Broadening from callexpr to apply expr (picking up operators) improves
several diagnostics in the testsuite, and is important to avoid regressions from an
upcoming patch.
Swift SVN r29821
- Enhance subscript diagnostics to chase into the constraint system to find
overload candidates that failed to match so we can rank and diagnose
subscript ambiguities using the same mechanics we have for operators.
- Implement a copy of suggestPotentialOverloads based on the new mechanics
for overload set resolution. This allows us to diagnose these in a more
detailed way, but for now we're keeping it as similar to the old system as
possible. The old version to be removed once the last client moves off it.
- Add a bunch of testcases to decl/subscript/subscripting.swift where we are
doing unfortunate things still.
Swift SVN r29810
