This time, the issue is that TypeNullifier skips bodies of
multi-statement closures. However, ExprRewriter will type
happily pass them on to typeCheckClosureBody(). This could
trigger assertions. Fix this by skipping type checking of
multi-statement closures when diagnosing.
There seems to be a minor QoI regression in some test cases
that already looked pretty dodgy and/or had FIXMEs. However
I think its worth fixing a crash.
mode (take 2)
Allow untyped placeholder to take arbitrary type, but default to Void.
Add _undefined<T>() function, which is like fatalError() but has
arbitrary return type. In playground mode, merely warn about outstanding
placeholders instead of erroring out, and transform placeholders into
calls to _undefined(). This way, code with outstanding placeholders will
only crash when it attempts to evaluate such placeholders.
When generating constraints for an iterated sequence of type T, emit
T convertible to $T1
$T1 conforms to SequenceType
instead of
T convertible to SequenceType
This ensures that an untyped placeholder in for-each sequence position
doesn't get inferred to have type SequenceType. (The conversion is still
necessary because the sequence may have IUO type.) The new constraint
system precipitates changes in CSSimplify and CSDiag, and ends up fixing
18741539 along the way.
(NOTE: There is a small regression in diagnosis of issues like the
following:
class C {}
class D: C {}
func f(a: [C]!) { for _: D in a {} }
It complains that [C]! doesn't conform to SequenceType when it should be
complaining that C is not convertible to D.)
<rdar://problem/21167372>
(Originally Swift SVN r31481)
It is a somewhat common case where folks are accidentally referring to an
instance member with the Type as the base. This forms a curried member,
which then produced head scratching error messages downstream.
Now that the prep work has gone in, the first part of this is now
straight-forward to fix: simply check for this case and diagnose it
with a custom error, which makes it more clear what the mistake was.
The other half of this problem (tracked by 22108559) affects cases where
the method you're calling takes a single argument. This isn't fixed
yet, but I'm adding a testcase for it anyway.
the code to be actually readable since it unnests it greatly), and call it
both before and after argument type validation. This allows us to capture
many more structural errors than before, leading to much better diagnostics
in a lot of cases. This also fixes the specific regressions introduced by
96a1e96.
overloaded argument list mismatches. We printed them in simple cases
due to "Failure" detecting them in trivial situations. Instead of
doing that, let CSDiags do it, which allows us to pick things out of
overload sets and handle the more complex cases well.
This is a progression across the board except for a couple of cases
where we now produce "cannot convert value of type 'whatever' to
expected argument type '(arglist)'", this is a known issue that I'll
fix in a subsequent commit.
This teaches SubscriptExpr diagnostics to substitute the base type of a
subscript expr through the generic argument types, resolving achetypes in
common situations to concrete types. We previously complained:
error: cannot subscript a value of type '[String : AnyObject]' with an index of type 'String'
which is completely wrong, we now produce the correct error:
error: cannot assign value of type 'AnyObject?' to type 'String?'
Previously we erroneously complained:
error: cannot invoke 'contains' with an argument list of type '(String)'
now we correctly complain:
error: unexpected non-void return value in void function
This enhances CSDiags to use "getTypeOfMember" when analyzing method
candidates that are applied to a known base type. Using it allows us to
substitute information about the base, resolving archetypes that exist in
subsequent argument positions. In the testcase, this means that we use
information about Set<String> to know that the argument to "contains" is a
String.
This allows us to generate much better diagnostics in some cases, and works
around some limitations in the existing stuff for handling unresolved
archetypes. One unfortunate change is the notes in Misc/misc_diagnostics.swift.
Because we don't track argument lists very well, we are flattening an argument
list that is actually ((Int,Int)) into (Int, Int) so we get a bogus looking
diagnostic. This was possible before this patch though, it is just one
more case that triggers the issue.
When inferring a contextual type for the input expression to an assignment,
use getRValueType() to strip lvalues from tuple types in recursive positions,
this allows us to produce a sensible diagnostic of:
error: binary operator '%' cannot be applied to two 'T' operands
instead of:
error: cannot assign value of type 'T' to type '@lvalue _'
because we don't have a weird lvalue type in the way.
The original issue has long since been fixed, but we were now producing:
error: cannot subscript a value of type 'UnsafePointer<Int8>'
which is pretty obviously wrong. The problem is that when ranking subscript
decl candidates, CSDiags was using TC.isConvertibleTo to evaluate whether the
actual base type is compatible with the base type of a subscript decl. This
was failing when the base was generic, because the logic isn't opening
archetypes. Instead of incorrectly deciding that they are incompatible, just
decide we don't know if an archetype is present. This allows us to generate
good errors in situation like this.
A crash in CSDiag that happened when we were unconditionally looking at the
getter of a subscript. This failed on UnsafeMutablePointer because it only
has addressors, not getter/setters.
This improves the error message when attempting an array to UnsafeMutablePointer
conversion but where the element type of the array is incorrect or where the array itself
is immutable.
As a bonus fix, this dramatically improves the diagnostic when you pass "&array" to
a function that takes an UnsafePointer. We decided to not require & in this case, so
we can just provide a nice fixit to rip it off when this common error happens.
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.
A literal in a sub-expression of the right-most expression in a sequence
could accidentally still have an error-type when going through CSApply.
rdar://problem/23488528
This also rearranges the logic for diagnosing faulty ApplyExprs to group the logic
for a single candidate together in one place. Nothing really earth shattering here,
just yak shaving.
code had the effect of squishing the note that printed the overload candidate
set for the operators in question. While these are not generally helpful given
how many overloads we have of (e.g.) the + operator, it doesn't do us any good
to have special cases like this, because methods can have tons of overloads as
well.
notion of a "near miss" for an argument type mismatch. This allows us to prune
the candidate set down in some cases. For example, in the testcase in
rdar://22243469 we are able to go from:
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), (UInt)
down to:
t.swift:6:3: note: expected an argument list of type '(UInt, () -> Void)'
This paves the way for producing a better error in cases like this, but there are
other bits of weirdness that need to be untangled first.
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.
That way, re-typechecking doesn't complain about the lvalue access kind
bit already having been set.
<rdar://problem/23185177> Compiler crashes in Assertion failed: ((AllowOverwrite || !E->hasLValueAccessKind()) && "l-value access kind has already been set"), function visit
Swift SVN r32854
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
of providing contextual diagnostics (e.g. producing the warning in
Constraints/dynamic_lookup.swift). This drops a specific diagnostic about
force casting the result of as! which was added in the Swift 1.2 timeframe
to explain the change in cast semantics. Now that as! has been around for
a long time, it is more confusing than helpful.
Swift SVN r31887
which is a case where the only problem lurking in the constraint system is a disjunction
between two impossible to solve conversion constraints. Arbitrarily pick the first one
so that we complain about *something*, instead of just calling the reference to path
ambiguous.
Swift SVN r31886
Otherwise, we'll hit an assertion failure (or produce the wrong message)
when a property has an addressor instead of a getter and setter.
rdar://problem/22363304
Swift SVN r31865
