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
(to make it compatible with OSStatus) rdar://17285288
This line, and those below, will be ignored--
M stdlib/objc/Foundation/Foundation.swift
Swift SVN r20278
+= 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
The only interesting bit is that for stdlib/objc to build reliably, its
.o files all need to depend on the generated swiftmodule files for any
of its library dependencies. It looks like cmake treats
target_link_libraries as only implying a dependency between the
resulting libraries, and not the objects. For now, I've achieved this
by making the objects depend on the whole target (which includes
linking), but only the swiftmodule is actually necessary.
Swift SVN r20240
There's no meaningful way in which these methods are public, since they
can't be accessed through any value of the type
<rdar://problem/17647878>
Swift SVN r20224
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
Add a set of _preconditionOptionalHasValue intrinsics that merely test that an optional has a case. Emit an lvalue ForceValueExpr as a physical lvalue, first asserting the precondition then projecting out the Some payload.
Swift SVN r20188
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
.apinotes files provide API annotations alongside the Swift overlays
for Objective-C modules, and will be handled by the Clang
importer. Start generating these files from the current in-compiler
source (KnownObjCMethods.def).
The eventual goal is to switch from KnownObjCMethods.def to the
currently-being-defined textual format for API notes, and to replace
the silly swift-ide-test invocations with a Swift driver mode.
Swift SVN r20085
This will allow more error checking, resilient slicing, and occasionally
other useful capabilities.
Step 1 of <rdar://problem/11940897>
Swift SVN r20036
Marking these generic functions as transparent results in our not
emitting diagnostics for unreachable code if these functions are the
only code in a block and inlining generic code is enabled (due to
<rdar://problem/17687851>).
I don't believe other diagnostics benefit in any way from having these
marked as @transparent, and removing @transparent actually improved
Ackerman at -O3 by 15%.
Swift SVN r19996
Now that Swift has an access control model, we need to apply it to the XCTest overlay.
This is handy in that it lets us hide some implementation details of the overlay.
Addresses <rdar://problem/17653535>.
Swift SVN r19989
