Arrays of non-verbatim-bridged types (such as Int, and today's String)
are converted to Objective-C lazily, with the objects created due to
element conversion being autoreleased when necessary.
Fixes <rdar://problem/17360154>
Note: test/SIL/Parser/array_roundtrip.swift was XFAIL'd;
see <rdar://problem/17758203>
Swift SVN r20293
Giving the invocation target proxy a type will be bogus when we turn on 'dynamic'. This breaks the NSUndoManager tests because we still can't work with lvalues through AnyObject. <rdar://problem/17755906>
Swift SVN r20283
+= only extends arrays with another sequence of the same element type.
Fixes <rdar://problem/17151420> The use of the overloaded += operator in
Swift is inconsistent and confusing with Arrays.
Note that this commits generated 3 new radars against the type checker:
<rdar://problem/17751308>
<rdar://problem/17750582>
<rdar://problem/17751359>
Swift SVN r20274
This effectively reverts all but the NSRange part of r20241, because
it's better to have consistent behavior across the platforms than have
this feature on just one platform.
Swift SVN r20252
Primarily, this means becoming resilient to Builtin.strideof(x) == 0.
Pretty much the only way to get pointers and arrays to make sense is to
treat zero-sized elements as having a stride of 1, so we do that in our
wrapper for Builtin.strideof. Other points include precondition checks
for radixes in number formatting.
Fixes <rdar://problem/17097768>
Swift SVN r20242
NSRange, NSPoint, NSSize, and NSRect. This time, using Jordan's
suggestion for iOS portability.
Fixes <rdar://problem/16973060>
Conflicts:
stdlib/objc/Foundation/CMakeLists.txt
stdlib/objc/Foundation/Foundation.swift
Swift SVN r20241
Even if the user supplies an ordering predicate that isn't a strict-weak
ordering, algorithms should not index beyond their bounds. Otherwise, a
use of withUnsafeMutableStorage for optimization purposes could easily
do an unsafe memory access.
This commit comments and tests our algorithms that require strict weak
orderings, and fixes safety problems in partition(). Most benchmarks
are unaffected, but the rewrite of partition produces a 27% speedup in
the Phonebook benchmark at -O3 and a 22% speedup at -Ofast.
Also, at -Ofast, QuickSort lost 6% and RC4 gained 6%. These benchmarks
were not noticeably affected at -O3
====================`PrecommitBench_O3`====================
````benchmark`,`baserun0`,`baserun1`,`baserun2`,``optrun0`,``optrun1`,``optrun2`,``delta`,`speedup`
````Phonebook`,``1608.00`,``1676.00`,``1651.00`,``1265.00`,``1278.00`,``1281.00`,`343.00`,```27.1%`
````QuickSort`,```430.00`,```448.00`,```429.00`,```428.00`,```431.00`,```428.00`,```1.00`,````0.2%`
``````````RC4`,```925.00`,```924.00`,```922.00`,```916.00`,```919.00`,```917.00`,```6.00`,````0.7%`
====================`PrecommitBench_Ofast`====================
````benchmark`,`baserun0`,`baserun1`,`baserun2`,``optrun0`,``optrun1`,``optrun2`,``delta`,`speedup`
````Phonebook`,``1521.00`,``1546.00`,``1591.00`,``1252.00`,``1255.00`,``1256.00`,`269.00`,```21.5%`
````QuickSort`,```478.00`,```477.00`,```476.00`,```506.00`,```510.00`,```513.00`,``30.00`,```-5.9%`
``````````RC4`,``1033.00`,``1874.00`,``1030.00`,```974.00`,```982.00`,```975.00`,``56.00`,````5.7%`
Swift SVN r20202
We've decided resilience is wrong for Swift given current constraints;
see rdar://problem/11940897 for more detail.
This reverts commit r20052
Swift SVN r20127
It wasn't properly handling the cases where the bound was in the
opposite direction from the amount, when advancing random access
indices.
Swift SVN r20123
This will allow more error checking, resilient slicing, and occasionally
other useful capabilities.
Step 1 of <rdar://problem/11940897>
Swift SVN r20036
This addresses or improves several existing TC perf bugs (rdar://problem/15933674, rdar://problem/17110608, rdar://problem/17240816, rdar://problem/17244974), and seems to speed up our unit test runs by ~5%. (On my MacBook Pro, total average execution time is reduced from 557.28s to 531.89s.)
Swift SVN r19939
modifiers and with the func implementations of the operators. This resolves the rest of:
<rdar://problem/17527000> change operator declarations from "operator prefix" to "prefix operator" & make operator a keyword
Swift SVN r19931
eliminating the @'s from them when used on func's. This is progress towards
<rdar://problem/17527000> change operator declarations from "operator prefix" to "prefix operator" & make operator a keyword
This also consolidates rejection of custom operator definitions into one
place and makes it consistent, and adds postfix "?" to the list of rejected
operators.
This also changes the demangler to demangle weak/inout/postfix and related things
without the @.
Swift SVN r19929
When the Index type of a Range is Comparable, we can reject invalid
ranges at their formation.
It might be worth injecting some checkability concept into ForwardIndex
so that even in generic contexts where Comparability is unknown, we can
do this same check in the Range constructor.
Also, remove pattern matching support for Ranges of RandomAccessIndex,
as that is covered by Interval.
Fixes <rdar://problem/16254937> (#Seed 4: Ranges with negative strides
are broken) to the extent possible (it's still possible to form an
invalid Range of indices that are not Comparable)
Fixes <rdar://problem/17164391> (Swift: Using ranges in for in for
counting down, causes the loop to go inifinely)
Fixes <rdar://problem/17580871> (Swift: Closed range with negative
endpoint excludes that endpoint)
Swift SVN r19903
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
This only tackles the protocol case (<rdar://problem/17510790>); it
does not yet generalize to an arbitrary "class" requirement on either
existentials or generics.
Swift SVN r19896
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
native Dictionary storage and adopt it if KeyType and ValueType match
exactly
This was the last missing piece to allow Dictionary to round-trip
thorough objc entrypoints of Swift methods in O(1).
Fixes rdar://17556319, partially fixes rdar://17010353
Swift SVN r19873
types to NSDictionary, perform bridging operation in O(1), and defer
bridging of the contents until the NSDictionary is accessed
There is no cache for bridged keys and values; the Swift NSDictionary
will return values with different pointer values when a given key is
repeatedly accessed.
Part of rdar://17556319
Does not fix the O(N) performance of objc thunks, because Dictionary is
not recognizing its own native storage when bridging from Objective-C.
This tracked by rdar://17010353
Swift SVN r19853
1) Add an ObjCObject disposition that tells us this Mirror is reflecting upon an ObjC-imported type
2) Change the default summary of _ClassMirror and _StructMirror to be the mangled typename, with no children count
Swift SVN r19817
ArrayBuffer
ArrayBufferType
ContiguousArrayBuffer
ContiguousArrayStorage
IndirectArrayBuffer
SliceBuffer
Unfortunately, can not remove 'public' from them since they are used by
Foundation overlay in bridging code.
Swift SVN r19810
