This pull request broke the following tests on several build configurations
(eg --preset=buildbot,tools=RA,stdlib=DA)
1_stdlib/Reflection.swift
1_stdlib/ReflectionHashing.swift
1_stdlib/UnsafePointer.swift.gyb
This reverts commit c223a3bf06, reversing
changes made to 5c2bb09b09.
Changes:
- Reverted commit reverting original SR-88 commit
- Removed mirror children helper collections and related code
- Rewrote some tests to keep them working properly
- Wrote two more tests for the three pointer APIs to ensure no crashes if created using a value > Int64.max
This reverts commit 8917eb0e5a.
Jira: SR-88
Changes:
- Removed stdlib type conformances to _Reflectable
- Conformed stdlib types to CustomReflectable, CustomPlaygroundQuickLookable
- Rewrote dump() function to not use _reflect()
- CGRect, CGPoint, CGSize now conform to CustomDebugStringConvertible
- Rewrote unit tests for compatibility with new API
...replacing it with the new, after passing API review!
* The lazy free function has become a property.
* Before we could extend protocols, we lacked a means for value types to
share implementations, and each new lazy algorithm had to be added to
each of up to four types: LazySequence, LazyForwardCollection,
LazyBidirectionalCollection, and LazyRandomAccessCollection. These
generic adapters hid the usual algorithms by defining their own
versions that returned new lazy generic adapters. Now users can extend
just one of two protocols to do the same thing: LazySequenceType or
LazyCollectionType.
* To avoid making the code duplication worse than it already was, the
generic adapters mentioned above were used to add the lazy generic
algorithms around simpler adapters such as MapSequence that just
provided the basic requirements of SequenceType by applying a
transformation to some base sequence, resulting in deeply nested
generic types as shown here. Now, MapSequence is an instance of
LazySequenceType (and is renamed LazyMapSequence), and thus transmits
laziness to its algorithms automatically.
* Documentation comments have been rewritten.
* The .array property was retired
* various renamings
* A bunch of Gyb files were retired.
Swift SVN r30902
An index of a FlattenCollection is composed of two: an index to the
current chunk and an index within that chunk. So you take the
startIndex, and advance it to the second chunk; call the result idx1.
You take startIndex again, and advance it the same number of steps; call
the result idx2:
let idx1 = flatMapCollection.startIndex.advancedBy(10)
let idx2 = flatMapCollection.startIndex.advancedBy(10)
idx1 and idx2 have to compare equal according to collection and index
axioms. But this can't be cheaply implemented. Every index contains an
index into the inner collection. So indices into two collections with
the same elements have to compare equal even though the collections
don't have any common history, they were merely created using the same
sequence of steps.
What currently happens is that you get random results depending on the
underlying collection kind.
rdar://21989896
Swift SVN r30617
They pass various operations through to the base
collection (e.g. LazyMapCollection's .count) and thereby avoid taking
the potentially-slower path through the default implementation.
Swift SVN r30554
ExtensibleCollectionType's operations can all be represented by the
primitive range replacement operation, so fold it into
RangeReplaceableCollectionType.
In addition, provide default implementations of
RangeReplaceableCollectionType's methods.
- New tests added for combinations of (static, generic) calls and
(default, custom) implementations.
- Mark free Swift functions as unavailable with a message to direct the
developer to the protocol methods.
- Mark ExtensibleCollectionType as available with a message added to
direct the developer to the right protocol.
rdar://problem/18220295
Swift SVN r29857
Members of protocols found via unqualified name lookup are mapped to
their corresponding witnesses, as we do for qualified name
lookup. This is the bulk of the compiler changes for
rdar://problem/20509152. Performing this mapping for unqualified name
lookup of types will follow.
Swift SVN r28333
The targeted functions all take over a second to type-check with my debug
compiler (found using -debug-time-function-bodies). The top two---the two
replaceRange implementations---took about a minute each; this change
knocks them down to 30-40s.
All of this is just breaking expressions apart, and the expressions aren't
even that complicated. I'm concerned that we have a serious performance
regression around the use of lazy(), and I've filed rdar://problem/20875936
so we can look into it. The test change is particularly concerning; there's
a ridiculous difference between 'lazy(...).reverse()' and
'lazy(...).reverse().reverse()'.
No intended functionality change.
Swift SVN r28325
The rule changes are as follows:
* All functions (introduced with the 'func' keyword) have argument
labels for arguments beyond the first, by default. Methods are no
longer special in this regard.
* The presence of a default argument no longer implies an argument
label.
The actual changes to the parser and printer are fairly simple; the
rest of the noise is updating the standard library, overlays, tests,
etc.
With the standard library, this change is intended to be API neutral:
I've added/removed #'s and _'s as appropriate to keep the user
interface the same. If we want to separately consider using argument
labels for more free functions now that the defaults in the language
have shifted, we can tackle that separately.
Fixes rdar://problem/17218256.
Swift SVN r27704
"similar", avoiding false positive "not exhaustive" diagnostics on switches
like:
switch ... {
case let x?: break
case .None: break
}
Also, start using x? patterns in the stdlib more (review appreciated!), which
is what shook this issue out.
Swift SVN r26004
The standard library has grown significantly, and we need a new
directory structure that clearly reflects the role of the APIs, and
allows future growth.
See stdlib/{public,internal,private}/README.txt for more information.
Swift SVN r25876
