After the recent improvements to the ARC optimizer these should not longer be
necessary and I did not measure negative performance impact from removing them.
rdar://24011261
In swift 1.2, `Slice` has been renamed `ArraySlice`.
In swift 2.0, type parameter name of `Array` is changed from `T` to `Element`.
Therefore, modified the names which appear in code comments and a document.
In swift 2.0, type parameter name of `Set` is changed from `T` to `Element`.
Therefore, modified the names which appear in code comments and a document.
This function was named exactly backwards (it incremented only when
*not* signed). Investigating this naming error revealed that the call
site was also unclear: `incIfSigned` was called from a block where
`signed` was known to be False). So, I inlined the logic in the one
place where it was actually used, and removed the function.
Overriding `AnySequence.dropFirst` and `AnySequence.prefix` to delegate
these operations to an underlying sequence, thus simplifying default
implementations in `Sequence`.
The default initializer for a float types initializes the value to `0`
by calling a “builtin” function to convert an integer with value `0`
into an “FPIEEE” float with value `0`. The integer value is signed, but
the code was calling a function that expected an unsigned integer.
If this semantic tag is applied to a function, then we know that:
- The function does not touch any reference counted objects.
- After the function is executed, all reference counted objects are leaked
(most likely in preparation for program termination).
This allows one, when performing ARC code motion, to ignore blocks that contain
an apply to this function as long as the block does not have any other side
effect having instructions.
I have wanted to do this for a while but was stymied by lacking the ability to
apply multiple @_semantics attributes. This is now committed to trunk so I added
this attribute instead of pattern matching against fatalError (since there could
be other functions with this property).
rdar://19592537
Many lazy collections don't offer O(1) performance for `startIndex`,
`first`, or any method that depends on `startIndex`.
`LazyFilterCollection` already had a note to this effect (which I
tweaked a bit), but `FlattenCollection` didn't.
Related to SR-425.
For lazy collections, `isEmpty` and `startIndex` may be O(N) operations.
The old implementation ended up being potentially O(2N) instead of O(1).
In particular, accessing `col.lazy.filter(pred).first` would evaluate
the predicate on elements twice, once to determine the result of
`isEmpty` and once to determine `startIndex`.
We can define the operations for N+1-tuples in terms of the ones for N-tuples, which reduces an x86-64 stdlib by about 4KB:
-rwxr-xr-x 1 jgroff staff 5172856 Dec 30 10:54 lib/swift/macosx/libswiftCore.before.dylib
-rwxr-xr-x 1 jgroff staff 5168752 Dec 30 11:59 lib/swift/macosx/libswiftCore.after.dylib
The optimizer should still be able to inline all the calls together in release builds.
Implement == and != for tuples up to arity 6 where each component type
is Equatable.
Implement <, <=, >, and >= for tuples up to arity 6 where each component
type is Comparable.
