This reflects the fact that the attribute's only for compiler-internal use, and isn't really equivalent to C's asm attribute, since it doesn't change the calling convention to be C-compatible.
Revert "For unsafeReferenceCast rely on static verifier checks."
This reverts commit r32796.
This reverts commit r32795.
They very likely broke a buildbot.
Swift SVN r32813
unsafeBitCast should only be used when we actually need to lie to the type system (as opposed to just having an unchecked downcast).
Theses are the places where unsafeReferenceCast makes sense:
(In general it makes sense whenever the source & dest are class or class existential types)
- ArrayBuffer.getElement.
The deferred downcast case cannot be benchmarked. It is never on the critical path.
The ObjC array case cannot conceivably matter either, however, it is touched by
DollarChain, JSONHelperDeserialize, and StrSplitter.
These benchmarks do not regress at -O.
- arrayForceCast
No regressions at -O based on microbenchmarks.
None of these remaining cases affect PerfTestSuite at -O:
- General ObjC bridging
- Set/Dictionary bridging
- String bridging
- AutoreleasingUnsafeMutablePointer
These are confirmed speedups but I did not investigate the cause:
|.Chars...................|.32.1%.|
|.Sim2DArray..............|.15.4%.|
|.Calculator..............|.13.0%.|
|.RecursiveOwnedParameter.|..7.9%.|
Swift SVN r32796
Instead of Optional entries use a third bitmap array to mark whether an entry is
valid. This representation saves space (because individual entries don't have a
alignment padding slack) and simplifies ARC's job leading to better performance.
Speedup measured (before/after) at -O:
DictionaryHashableClass`````````3.1
DollarFilter````````````````````1.3
DollarMap```````````````````````1.3
DollarReduce````````````````````1.4
JSONHelperDeserialize```````````1.4
NSDictionaryImplicitConversion``1.4
NSXMLParser`````````````````````1.3
Speedup measured (before/after) at -Onone:
DictOfArraysToArrayOfDicts``````1.3
Dictionary``````````````````````3.5
Dictionary2`````````````````````3.2
Dictionary3`````````````````````3.2
DictionaryHashableClass`````````1.9
DictionaryHashableStruct````````2.4
DictionaryRemove````````````````3.3
DictionarySwap``````````````````2.5
DollarFilter````````````````````1.2
DollarMap```````````````````````1.2
DollarReduce````````````````````1.3
Forest``````````````````````````1.8
Histogram```````````````````````1.6
JSONHelperDeserialize```````````1.6
NSDictionaryImplicitConversion``1.3
Prims```````````````````````````2.9
RGBHistogram````````````````````1.4
rdar://22173734
Swift SVN r32244
Keeping this method in the swift dylib saves a few kilobytes for each
specialization of dictionary. This function is not on the critical
performance path and we don't gain much from pulling it and specializing
it in user code.
Swift SVN r31507
There's still work left to do. In terms of next steps, there's still rdar://problem/22126141, which covers removing the 'workaround' overloads for print (that prevent bogus overload resolution failures), as well as providing a decent diagnostic when users invoke print with 'appendNewline'.
Swift SVN r30976
...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
For Dictionary, that's a (KeyType, ValueType) pair. For Set, that's just
the set element type. This is more consistent with the removeAtIndex on
RangeReplaceableCollectionType (which Dictionary and Set don't conform to).
rdar://problem/20299881
Swift SVN r30696
These types are leftovers from the early pre-1.0 times when Int and UInt
were always 64-bit on all platforms. They serve no useful purpose
today. Int and UInt are defined to be word-sized and should be used
instead.
rdar://18693488
Swift SVN r30564
This is a travesty that makes it hard to reason about tuple vs. scalar
types. It's only use in our own code involved dealing with the
difference in element types between Set and Dictionary in
gyb-generated code. Ewww. Fixes rdar://problem/17963034.
Swift SVN r30074
This API was added by mistake, and the type alias should have been
called ``Generator``. In fact, a nested type alias is already inferred
to satisfy the associated type ``Generator`` in Set's ``SequenceType``
conformance.
rdar://20171363
Swift SVN r29796
This reverts commit r28892, r28894, and r28895.
They broke validation tests; JoeG is going to look at what's needed to
make them work again.
Swift SVN r28897
This has passed review, or at least satisfied Tony Parker, provided we
do something to hide SetAlgebraDispatchType. I think I can eliminate it
in an imminent commit.
Swift SVN r28892
