Extend the contract for enumerateRequirements() a bit to preserve
archetype-to-archetype same-type constraints. Use that extra
information in the debug dump. NFC elsewhere.
Swift SVN r23008
This pushes some of the extra same-type requirements introduced in r22649 into the generic signature. Doesn’t really have an effect outside of extending generic signatures slightly.
Swift SVN r22680
When we have two protocol conformance requirements for the same type
T, and each of those protocols has an associated type with a given
(shared) name N, infer a same-type requirement between the two. Only
really enabled for testing now; it doesn't feed into general type
checking yet.
Swift SVN r22649
Whenever we add a requirement, we now know
(1) Why we added the requirement, e.g., whether it was explicitly written, inferred from a signature, or introduced by an outer scope.
(2) Where in the source code that requirement originated.
Also add a debugging flag for dumping the archetype builder information, so we can write tests against it.
This is effectively NFC, but it's infrastructure to help a number of requirements-related tasks.
Swift SVN r22638
When a specialization of a generic type occurs within the signature of
a generic function, it implies that the generic arguments meet the
requirements of the generic type. For example, in
func printHashes<K, V>(dict : Dictionary<K, V>) {
for (k, v) in dict {
print("\(k.hashValue())\n")
}
}
the presence of Dictionary<K, V> in the signature implies that K and V
meet the requirements on Dictionary's generic parameters, i.e., that K
is Hashable. Thus, infer that K is Hashable in printHashes().
Fixes the easy part of <rdar://problem/14691708>. Same-type and
superclass requirements are more interesting.
<rdar://problem/14691708>
Swift SVN r7574
