If the mismatched argument is on an archetype param, check to see
whether the argument conforms to all of the protocols on the archetype,
using a specific does-not-conform diagnosis if one or more protocols
fail.
Also added another closeness class
`CC_GenericNonsubstitutableMismatch`, which happens when more than one
argument is a mismatch, but all the failing arguments are of the same
type and mismatch only because of substitutability. This closeness is
farther away than normal `CC_ArgumentMismatch` so that if we note
expected matches, we’ll prefer non-generic matches. But if this is the
result, we can still produce the specific conforms-to-protocol
diagnosis (since, in a sense, it’s only one type of argument that is
wrong even though it is multiple arguments).
When one spells a compound declaration name in the source (e.g.,
insertSubview(_:aboveSubview:), keep track of the locations of the
base name, parentheses, and argument labels.
The problem was that an associated type was always resolved with the nearest protocol `Self` as a reference, but in the case of nested protocols the associated type might be from the enclosing protocol leading to a crash.
We now enumerate in a bottom-up way through the contexts until we have found the correct protocol which provides us with the `Self` reference to resolve the associated type.
which was reported here: https://twitter.com/jadengeller/status/619989059046240256
The underlying problem here is that the user was defining an associated
type named "Type", and then trying to refer to it with stuff.Type. The
problem is that stuff.Type is a reserved way to refer to the metatype.
Solve this sort of confusion by banning type members named Type (and
Protocol, while we're here) since forming a reference to them won't
work. This produces a note that indicates that a backtick'd version
of the identifier will work, since "stuff.`Type`" will correctly form
the reference to it.
This only bans type members named Type or Protocol, but we could consider
banning all ValueDecls from being named Type or Protocol. Module
qualification isn't widely used though, and metatypes of modules don't
really make sense at the moment.
- Improve the specific cases of nil and empty collection literals.
- Improve cases of contextual member lookup where the result type of the looked up member disagrees with context.
- Add some fixme's to the testsuite for cases of this diagnostic that should be diagnosed in other ways.
This standardizes processing of callees in invalid applyexprs, eliminating
bogus diagnostics like:
t.swift:6:2: error: cannot invoke closure of type '() -> _' with an argument list of type '()'
we now properly diagnose the example in closure/closures.swift as ambiguous,
but don't do a particularly good job of saying why. That is to follow.
In the case of an invalid override of an init, mark the override invalid, not the
init. This way, code that uses the init can be parsed and analyzed correctly and
bogus downstream errors are reduced.
Before:
t.swift:2:12: error: initializer does not override a designated initializer from its superclass
override init() {}
~~~~~~~~ ^
t.swift:5:1: error: cannot invoke initializer for type 'C' with no arguments
C()
^
t.swift:6:1: error: 'B' cannot be constructed because it has no accessible initializers
B()
^
After:
t.swift:2:12: error: initializer does not override a designated initializer from its superclass
override init() {}
~~~~~~~~ ^
This crash was a bug in computeTupleShuffle handling conversions to
a parameter list with a varargs argument in the middle of the list.
In this case, it is coming from the parameter list for Swift.print.
In these cases, we should just go ahead and remove the redundant constraints:
- They don't help us derive a solution for the system
- Not doing so might leave "dangling" constraints that will make the system unsolvable
There are two problems here, first we were diagnosing type member
constraints with the "function 'foo' was used as a property" error,
which doesn't make sense.
Second, we were diagnosing member constraints as lookup failures when
the constraint was actually referring to an archetype in its anchor
expression that wasn't resolved. Address this by simply ignoring the
constraint and letting ambiguity resolution handle it.
Before:
t.swift:5:9: error: function 'foo' was used as a property; add () to call it
After:
t.swift:5:9: error: generic parameter 'T' could not be inferred
let a = foo()
t.swift:4:6: note: in call to function 'foo'
func foo<T: IntegerType>() -> T.Type { return T.self }
Thanks to Jordan for noticing this!
Note that the typecheck perf for these kinds of expressions still isn't fantastic, but at least they're now computationally feasible. I have further improvements planned for this area which should bring performance in line with expectations.
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.
