Rearrange diagnoseGeneralConversionFailure to diagnose structural problems
even if we have some UnresolvedTypes floating around, then reject constraint
failures with UnresolvedTypes in them even harder. This keeps us giving
good errors about failures where we have a structural problem (with buried
irrelevant details) while not complaining about cases that are actually
ambiguous.
The end result of this is that we produce a lot better error messages in the
case of failed archetype inference. This also highlights the poor job we do
handling multi-stmt closureexprs...
On something like this:
let x = .Tomato(cloud: .None)
we previously emitted a "type of expression is ambiguous without more context" error
while pointing to .None. With a previous fix, we now produce the same error pointing
to the .Tomato. With this fix, we now produce:
error: reference to member 'Tomato' cannot be resolved without a contextual type
to really drive the problem home.
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
a constraint system in "allowFreeTypeVariables" mode. Previously, we
only allowed a few specific constraints, now we allow any relational and
member constraints. The later one is a big deal because it means that we
can allow ".Foo" expressions as ambiguous solutions, which CSDiags can
handle well.
This unblocks solving 23942743 and enables some minor improvements across
the board, including diagnosing things like this better:
Optional(.none) // now: generic parameter 'T' could not be inferred
That said, it also just permutes some non-awesome diagnostics.
This reverts commit 420bedaae1 because it
appears to have unintentionally made some previously accepted code
involving casts of variadic parameters to closures no longer compile.
that it is specific to ClosureExprs. Also, consolidate some logic
in CSDiags into the now shared coerceParameterListToType, which
makes a bit more sense and simplifies things a lot. NFC.
There are still unanswered questions. It isn't clear to me why
we support API names on closures, when we don't implement proper
semantic analysis for them. This seems like an accidentally supported
feature that should be removed.
Parameters (to methods, initializers, accessors, subscripts, etc) have always been represented
as Pattern's (of a particular sort), stemming from an early design direction that was abandoned.
Being built on top of patterns leads to patterns being overly complicated (e.g. tuple patterns
have to have varargs and default parameters) and make working on parameter lists complicated
and error prone. This might have been ok in 2015, but there is no way we can live like this in
2016.
Instead of using Patterns, carve out a new ParameterList and Parameter type to represent all the
parameter specific stuff. This simplifies many things and allows a lot of simplifications.
Unfortunately, I wasn't able to do this very incrementally, so this is a huge patch. The good
news is that it erases a ton of code, and the technical debt that went with it. Ignoring test
suite changes, we have:
77 files changed, 2359 insertions(+), 3221 deletions(-)
This patch also makes a bunch of wierd things dead, but I'll sweep those out in follow-on
patches.
Fixes <rdar://problem/22846558> No code completions in Foo( when Foo has error type
Fixes <rdar://problem/24026538> Slight regression in generated header, which I filed to go with 3a23d75.
Fixes an overloading bug involving default arguments and curried functions (see the diff to
Constraints/diagnostics.swift, which we now correctly accept).
Fixes cases where problems with parameters would get emitted multiple times, e.g. in the
test/Parse/subscripting.swift testcase.
The source range for ParamDecl now includes its type, which permutes some of the IDE / SourceModel tests
(for the better, I think).
Eliminates the bogus "type annotation missing in pattern" error message when a type isn't
specified for a parameter (see test/decl/func/functions.swift).
This now consistently parenthesizes argument lists in function types, which leads to many diffs in the
SILGen tests among others.
This does break the "sibling indentation" test in SourceKit/CodeFormat/indent-sibling.swift, and
I haven't been able to figure it out. Given that this is experimental functionality anyway,
I'm just XFAILing the test for now. i'll look at it separately from this mongo diff.
This adds special tuned diagnostics to handle the case when someone attempts to index
a string with an integer value, which is pretty common to do for people new to Swift.o
That said, this only handles one special case, if there are other cases that are
common, I'd love to hear about them. Subscripts are already handled with a different
approach, I'm not sure which is better, but I added a testcase for both of them.
If you use a color literal without first having imported AppKit or
UIKit, the diagnostic is poor. Instead, recommend importing one of those
two modules as appropriate.
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.
