Producing single argument mismatches involving generics causes some
gross looking error messages if the generic mismatches get put into the
same closeness bucket as non-generic mismatches.
E.g. `var v71 = true + 1.0` used to produce `error: cannot convert
value of type 'Bool' to expected argument type 'Double’`, but would now
end up with `binary operator '+' cannot be applied to operands of type
'Bool' and 'Double’` `overloads for '+' exist with these partially
matching parameter lists: (Double, Double), (T, T.Stride), (T.Stride,
T)`.
Resolve this by adding CC_OneGenericArgumentNearMismatch and
CC_OneGenericArgumentMismatch, that are similar but ever so slightly
not as close as a mismatch involving non-generic functions. This gets
back the original error message in cases like the above, because there
is only one declaration of `+` which partially matches and is
non-generic, and the generic partial matches are now farther away.
But now single arg mismatches and nearness work for single-archetype
generic functions, as in the additions to the SR-69 test at the end of
deduction.swift.
In the specific case of sr-69, and in a bunch of other code where
errors arise involving generic function application, better type
constraint failure diagnoses are being masked by the overly
conservative implementation in evaluateCloseness(). If the actual arg
types didn’t exactly match the parameter types, we’d always diagnose a
non-specific arguments-don’t-match error instead of allowing discovery
of better errors from the constraint system.
This commit adds more cases where evaluateCloseness will return
CC_ExactMatch, specifically in application of functions with one or
more arguments of a single archetype, like `func min<T: Comparable>(T,
T) -> T`. It verifies that the actual argument type
isSubstitutableFor() the archetype, and that all such arguments are of
the same type. Anything more complicated than that still has the
previous behavior of not matching at all.
I think the final answer here ought to be to make a constraint system
with type variables for any archetypes, add appropriate constraints to
the actual args and then see if the system can solve all the argument
constraints at once. That’s because the next most complicated set of
things to handle in the stdlib are things like `func -<T:
Strideable>(lhs: T, rhs: T.Stride)` where generic argument types depend
on each other. I tried attacking that, but it was too big of a bite for
me to manage all at once. But there are FIXME’s here to try that again
at some point.
New tests for SR-69 are at the end of deduction.swift, and the rest of
the test changes are generally improved deduced diagnoses. I think the
changed diagnoses in materializable_restrictions.swift is the only one
which is worse instead of better, and that’s just because the previous
general message mentioned `inout` basically accidentally. Opportunity
for further improvement (a new diagnosis maybe) there.
Validation tests run and passed.
information about where the archetype was defined. Before:
t.swift:6:17: error: generic parameter 'T' could not be inferred
var a : Int = A.foo()
^
After:
t.swift:6:17: error: generic parameter 'T' could not be inferred
var a : Int = A.foo()
^
t.swift:2:8: note: 'T' declared as parameter to type 'A'
struct A<T> {
^
When a contextual conversion has a matching type, don't diagnose it as a
conversion error, the problem is due to something else (in this case, an
unresolved archetype somewhere else in the expression).
Before:
t.swift:6:17: error: cannot convert value of type 'Int' to specified type 'Int'
After:
t.swift:6:17: error: generic parameter 'T' could not be inferred
This should still be a bit better to provide information about where the T
archetype came from, but at least now it isn't completely wrong diagnostic.
UnresolvedConstructorExpr is not providing any value here; it's
essentially just UnresolvedDotExpr where the name refers to an
initializer, so use that instead. NFC
Basic implementatation of SE-0021, naming functions with argument
labels. Handle parsing of compound function names in various
unqualified-identifier productions, updating the AST representation of
various expressions from Identifiers to DeclNames. The result doesn't
capture all of the source locations we want; more on that later.
As part of this, remove the parsing code for the "selector-style"
method names, since we now have a replacement. The feature was never
publicized and doesn't make sense in Swift, so zap it outright.
This reverts commit 5ce503c886 because it
breaks the stdlib build with:
Assertion failed: (!isPolymorphic() && "no args for polymorphic substitution"), function substGenericArgs
for initializer lookup, allowing it to produce more specific diagnostics
when referring to a private initializer that the compiler can see.
In addition to improving diagnostics, this allows us to eliminate the
NoPublicInitializers failure kind.
It is a common point of confusion that property initializers cannot access self, so
produce a tailored diagnostic for it.
Also, when building implicit TypeExprs for the self type, properly mark them implicit.
When member lookup completely fails and when CSDiags is the one performing
the lookup, reissue another lookup that ignores access control. This allows
it to find inaccessible members and diagnose them as such, instead of pretending
we have no idea what the user wants. We now produce an error message like this:
main.swift:1:6: error: 'foo' is inaccessible due to 'private' protection level
C().foo()
^
test.swift:1:35: note: 'foo' declared here
internal class C { private func foo() {} }
^
instead of:
main.swift:1:2: error: value of type 'C' has no member 'foo'
C().foo()
^~~ ~~~
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.
