* One-sided ranges and RangeExpression
* Remove redundant ClosedRange methods from String
* Fix up brittle tests
* Account for Substring update
* XFAIL range diagnostics on Linux
The code here is unprincipled, and mixes archetypes from
multiple sources:
1) The callee's generic environment
2) The caller's generic environment
3) Any random archetypes appearing in the original types of
typealiases, which could come from any generic environment
Initially, an UncurriedCandidate's type starts out as #1,
and then we sometimes set it to type #2 if the candidate is
a method on a base class.
We get #3 by virtue of walking the original types of
SubstitutedTypes created as part of dependent member type
substitution.
However, it turns out the real reason the SubstitutedType
walk existed was so that #2 archetypes that appear in the
UncurriedCandidate's type map to themselves. This doesn't
require looking at the original type of a SubstitutedType
at all; instead we just walk the UncurriedCandidate's type
normally, collecting archetypes.
If we do this, the code doesn't (erroneously) pick up random
archetypes from typealiases, and this changes the output in
the RangeDiagnostics test. While we can debate if the new
diagnostics are better or worse (I think it's either a wash,
or slightly better) the reason they changed is because more
in-depth diagnostic code is now executing, without breaking
things randomly as before. I suspect this is a good thing.
This decreases total testing time by over a minute on my old Mac Pro.
It probably has much less effect on systems with fewer cores, but shouldn't
be any worse there.
Swift SVN r22745
When computing the set of potential bindings for a type variable with
a literal constraint, we suggest the default literal type as a
fallback. Suppress this suggestion in the cases where another
constraint provides a type that already has some kind of contextual
type information (that does conform to the protocol), making the
default literal type more of a fallback. When type-checking the given
declaration:
var dict: NSDictionary = [
"status": 200,
"people": [ [ "id": 255,
"name": [ "first": "John", "last": "Appleseed" ] ] ] ]
it reduces the number of solution states explored by 2/3, the number
of attempted type variable bindings by 3/4, and the number of
disjunctions explored by 1/3. This optimization is useful in general,
and lets type annotations guide the type checker to a much greater
extent. It also helps with rdar://problem/18269449.
Swift SVN r21878
This allows 0.0..<10.3 and 0.1...4.4 to work properly in pattern
matching.
Fixes <rdar://problem/12016900> (#Seed 4: add a "contains" method to the
range types) by making "contains" available on Interval
Addresses <rdar://problem/16254937> (#Seed 4: Ranges with negative
strides are broken) by making the formation of an invalid Interval a
runtime error.
Fixes <rdar://problem/16304317> (Range<T> has limited awesomeness: it is
restricted to types that conform to ForwardIndex)
Fixes <rdar://problem/16736924> (#Seed 4: Enable range inclusion pattern
matching for all types that conform to Equatable and Comparable)
Addresses <rdar://problem/16846325> (#Seed 4: Introduce index range) by
distinguishing Range (which operates on indices) from Interval
Fixes <rdar://problem/17051263> (Pattern-matching a Double range with an
infinite endpoint triggers an assertion failure)
Fixes <rdar://problem/17051271> (#Seed 4: Pattern-matching Double ranges
excludes fractional values)
Addresses <rdar://problem/17171420> (Separate types for closed and
half-open ranges)
Swift SVN r19900
Mechanically add "Type" to the end of any protocol names that don't end
in "Type," "ible," or "able." Also, drop "Type" from the end of any
associated type names, except for those of the *LiteralConvertible
protocols.
There are obvious improvements to make in some of these names, which can
be handled with separate commits.
Fixes <rdar://problem/17165920> Protocols `Integer` etc should get
uglier names.
Swift SVN r19883
Sliceable is a totally non-critical protocol and Range slicing wasn't
even being tested. Along with r19771, fixes <rdar://problem/16363898>
Swift SVN r19775
This horrible hack prevents the user from indexing Range<I>, for all
integer types I, outside of a generic context. This seems to be the
best we can do to prevent confusion given the current language.
Addresses <rdar://problem/16363898>
Unfortunately, I can't make this work for slicing ranges yet.
Swift SVN r19771
