* Make Range conditionally a Collection
* Convert ClosedRange to conditionally a collection
* De-gyb Range/ClosedRange, refactoring some methods.
* Remove use of Countable{Closed}Range from stdlib
* Remove Countable use from Foundation
* Fix test errors and warnings resulting from Range/CountableRange collapse
* fix prespecialize test for new mangling
* Update CoreAudio use of CountableRange
* Update SwiftSyntax use of CountableRange
* Restore ClosedRange.Index: Hashable conformance
* Move fixed typechecker slowness test for array-of-ranges from slow to fast, yay
* Apply Doug's patch to loosen test to just check for error
Consider different overload choices for the same location in evaluation
order, this makes overload resolution more predictable because it's going
to follow expression bottom-up, that prevents situations when some
expressions are considered ambigious because choices taken further up
equate the score, instead each level is given distinct weight
based on evaluation order.
Resolves: rdar://problem/31888810
In `FailureDiagnosis::visitSubscriptExpr` if there is only a single
candidate available, verify that the problem is actually related
to the contextual mismatch by type-checking whole subscript without
contextual info, if that returns a type - it's contextual, otherwise
diagnose as incorrect argument type problem.
Resolves: rdar://problem/31977679
* 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
