Also cleaned up unnecessary body.isNonNull() check here. The code just
above already constructs a synthetic empty brace stmt for the body if
it didn’t have a real one.
This makes diagnoseGeneralConversionFailure more conservative: it
now never diagnoses a failed conversion when it involves a type that
has unresolved type in it. These types could not be resolved, so it
is better to let ambiguity resolution handle the problem.
On "[] as Set", we would previously get:
error: 'Set<_>' is not convertible to 'Set<Element>'
now we get:
error: generic parameter 'Element' could not be inferred
This adds some heuristics so we can emit a fixit to remove extraneous
whitespace after a . and diagnose the case where a member just hasn't
been written yet better. This also improves handling of tok::unknown
throughout the parser a bit.
This is a re-commit of ff4ea54 with an update for a SourceKit test.
This adds some heuristics so we can emit a fixit to remove extraneous
whitespace after a . and diagnose the case where a member just hasn't
been written yet better. This also improves handling of tok::unknown
throughout the parser a bit.
1. Array type parsing for postfix array types Int[]. We now handle this
in the parser, but remove the AST representation of this old form. We
also stop making vague promises about the future by saying that "fixed
size arrays aren't supported... yet". Removal of this fixes a compiler
crasher too.
2. Remove the special case support for migrating @autoclosure from types
to parameters, which was Swift 1.0/1.1 syntax. The world has moved or
we don't care anymore.
3. Remove upgrade support for # arguments (nee "backtick" arguments), which
was a Swift 1.x'ism abolished in an effort to simplify method naming
rules.
NFC on valid code.
Generally speaking, it's necessary to typecheck all parts of a
statement regardless of whether earlier parts failed to typecheck. For
example, even if the condition of an if-statement fails to typecheck, we
should still check its branches. This way all expressions in the AST are
processed (i.e. SequenceExprs translated to trees) and we get more
diagnostics.
The big thing left to fix is for-each statement checking. If there are
any type errors in the pattern or sequence of a for-each statement, the
body doesn't get type-checked.
<rdar://problem/23684220>
Warns of deprecation, checks all the appropriate bits to see if we can
do an automatic fix, and generates fix-its if that is valid.
Also adds a note if the loop looks like it ought to be a simple
for-each, but really isn’t because the loop var is modified inside the
loop.
This stops emitting unhelpful diagnostics about “<<error type>>” (as in
SR-176) while still complaining about the switch itself and any other
errors in case bodies.
This patch improves error recovery for malformed operator declarations,
previously we'd stop parsing the operator decl and try to parse the
body as an expression, hilarity (and a pile of horrible errors) would
ensue.
and probably others.
When we're type-checking a failed ApplyExpr that has an overload set that
prevents getting a specific type to feed into the initial typechecking of
the argument list, ranking can often narrow down the list of candidates
further, to the point where there is only one candidate left or where all
candidates agree that one argument is wrong.
In this case, re-type-check the subexpr with the expected type. In the case of
rdar://problem/22243469 we now produce:
t.swift:6:11: error: invalid conversion from throwing function of type '() throws -> ()' to non-throwing function type '() -> Void'
process {
^
instead of:
t.swift:6:3: error: cannot invoke 'process' with an argument list of type '(() throws -> ())'
process {
^
t.swift:6:3: note: overloads for 'process' exist with these partially matching parameter lists: (UInt, fn: () -> Void)
process {
^
Which is a heck of a lot less specific. Similarly, in the testcase from rdar://23550816, instead
of producing:
takeTwoFuncsWithDefaults { $0 + 1 }
error: cannot invoke 'takeTwoFuncsWithDefaults' with an argument list of type '((Int -> Int)?)'
note: expected an argument list of type '(f1: (Int -> Int)?, f2: (String -> String)?)'
we now produce:
error: cannot convert value of type '_ -> Int' to expected argument type '(String -> String)?'
which is a lot closer to what we want to complain about.
When passing a contextual type to a call, if we have a scalar element
initializing a varargs parameter list, we need to use the varargs element type
contextually. Fixing this improves some confusing diagnostics.
Make the following patterns illegal:
if var x = ... {
...
}
guard var x = ... else {
...
}
while var x = ... {
...
}
And provide a replacement fixit 'var' -> 'let'.
rdar://problem/23172698
Swift SVN r32855
call expression onto a callee when it was a binary expression. Doing this
requires improving the diagnostics for when the contextual result type is
incompatible with all candidates, but that is general goodness all around.
This fixes:
<rdar://problem/22333090> QoI: Propagate contextual information in a call to operands
and improves a number of diagnostics where the problem is that an operator
is used in a context that expects a type that it cannot produce.
Swift SVN r31891
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
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
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
