Add a default implementation for CollectionTypes where their SubSequence
== Self. That is, mainly, Slice and ArraySlice. This changes the slice's
view of, but not modifying or copying, the underlying collection.
rdar://problem/20302034
Swift SVN r30496
The lazy components, in particular generators and indices, need to offer
access to their base values so they can be mapped back into the
underlying sequences and collections. Along the way, give some love to:
* documentation comments
* argument labels for predicates
* not storing unneeded properties
* public constructors where appropriate
Swift SVN r30460
- De-underscore the API that takes an equatable separator, add doc
comment, and add a test for it.
- Add a test for the negative maxSplit case.
- Add lifetime tracker for isSeparator closure in the semantic test.
Swift SVN r30413
If the start of the ring buffer is aligned at the left, just wrap the
whole thing directly in an AnySequence and return it. Otherwise, return
a lazy concatenation of the the two slices of the ring buffer. This
prevents a forced full copy of the result.
rdar://problem/21885925
Swift SVN r30374
rdar://problem/21663830
Add the following new requirements to SequenceType with default implementations:
- dropFirst(n)
- dropLast(n)
- prefix(n)
- suffix(n)
- split(n)
In addition, provide specialized default implementations of these for CollectionTypes with forward, bidirectional, and random-access Index types where possible.
Add the following new requirements to CollectionType with default implementations:
- prefixThrough(n)
- prefixUpTo(n)
- suffixFrom(n)
- split() // isSeparator closure
Add the following convenience APIs:
- dropFirst() -> calls dropFirst(1)
- dropLast() -> calls dropLast(1)
Add a tentative underscored API:
- split() // takes Equatable separator.
Some APIs have undefined behavior when creating slices where the endpoints go beyond the bounds of the underlying collection. This will be fixed later by trapping creation of slices with invalid indices (rdar://problem/21822657).
Swift SVN r30371
We used to be only propagating laziness through reverse collections when
the base collection was a LazyCollection<T>, rather than all
LazyCollectionType's. Also updated the flatten tests to check for the
same issue.
Swift SVN r30367
There is no reason for the compiler to be synthesizing a body of
_domain when it can be implemented in a protocol extension. As part of
this, fix a recent regression in the computed domain: it was using
string interpolation, which means that the recent changes not to print
qualified names affected the domain of the generated NSErrors. Oops.
Swift SVN r30343
This is a low-level API that bypasses the usual type checks. To avoid
misuse, we add a dynamic type check that kicks in when stdlib asserts
are enabled.
Swift SVN r30311
This patch implements the pre-specialization for the most popular generic types from the standard library. If there are invocations of generic functions from the standard library in the user-code and the compiler can find the specialized, optimized versions of these functions, then calls of generic functions are simply replaced by the calls of the specialized functions.
This feature is supposed to be used with -Onone to produce much faster (e.g. 5x-10x faster) executables in debug builds without impacting the compile time. In fact, the compile-time is even improved, because IRGen has less work to do. The feature can be considered a light-weight version of the -Odebug, because pre-specialization is limited in scope, but does not have a potentially negative compile-time impact compared to -Odebug. It is planned to enable it by default in the future.
This feature is disabled by default for the time being. It can be enabled by using a hidden flag: -Xllvm -use-prespecialized.
The implementation consists of two logical steps:
- When the standard library is being built, we force a creation of specializations for the most popular generic types from the stdlib, e.g. Arrays of integer and floating point types, Range<Int>, etc. The list of specializations is not fixed and can be easily altered by editing the Prespecialized.swift file, which is responsible for forcing the specialization of generic types (this is simple solution for now, until we have a proper annotation to indicate which specializations of a given generic type or function we want to generate by means of the pre-specialization). These specializations are then optimized and preserved in the stdlib dylib and in the Swift SIL module. The size increase of the stdlib due to creation of pre-specializations is currently about 3%-7%.
- When a user-code is being compiled with -Onone, the compiler would run a generic specializer over the user-code. If there are calls of generic functions from the standard library, the specializer would check if there is an existing specialization matching these invocations. If such a specialization is found, the original call is replaced by the call of this more efficient specialized version.
Swift SVN r30309
