The syntax being reverted added busywork and noise to the common case
where you want to say "I have the right address, but the wrong type,"
without adding any real safety.
Also it eliminated the ability to write UnsafePointer<T>(otherPointer),
without adding ".self" to T. Overall, it was not a win.
This reverts commits r21324 and r21342
Swift SVN r21424
Depending on visitation order, we would occasionally leave the factory
method available if we had completely imported the initializer
first. Fixes <rdar://problem/17261609>.
Swift SVN r21361
Previously, it was possible to write Unsafe[Mutable]Pointer(x) and have
Swift deduce the pointee type based on context. Since reinterpreting
memory is a fundamentally type-unsafe operation, it's better to be
explicit about conversions from Unsafe[Mutable]Pointer<T> to
Unsafe[Mutable]Pointer<U>. This change is consistent with the move from
reinterpretCast(x) to unsafeBitCast(x, T.self).
Also, we've encoded the operations of explicitly adding or removing
mutability as properties, so that adding mutability can be separated
from wild reinterpretCast'ing, a much more severe form of unsafety.
Swift SVN r21324
This allows UnicodeScalars to be constructed from an integer, rather
then from a string. Not only this avoids an unnecessary memory
allocation (!) when creating a UnicodeScalar, this also allows the
compiler to statically check that the string contains a single scalar
value (in the same way the compiler checks that Character contains only
a single extended grapheme cluster).
rdar://17966622
Swift SVN r21198
Now that CGFloat is its own distinct type, it's useful to have Double
initializers to go along with the Int initializers we added a while
back <rdar://problem/17224725>.
Swift SVN r21156
The determination of “favored” constraints for binary expressions was comparing the second argument to the first parameter to decide if the constraint is favored. Coupled with implicit bridging conversions through NSNumber, this meant that “1.0/10” would become Int when Foundation was imported, and hilarity ensued.
Fix the heuristic for favored constraints, tidy up this code a bit, and add ==(NSString, NSString) to cope with the ambiguity this creates.
Swift SVN r21154
Instead of trying to bridge NSDictionary to [String:String], XCTest needs to
just request the objects from the NSDictionary as String.
Also, move the unwrapping of the optional from the might-throw block such that
it only happens when the block hasn't thrown. Unwrapping the optional if the
block has thrown would crash, because the optional would still be unset.
Addresses <rdar://problem/17952584>.
Swift SVN r21119
Also, move the ObjectiveC overlay into its own directory, so that we can
use the directory name as an indicator of what overlays exist.
This is in preparation for DevPubs providing the contents of the apinotes/
directory. The downside here is that adding new apinotes files doesn't
automatically trigger a rebuild; I intend to mitigate that somewhat by at
least triggering one when the revision number of the DevPubs repo changes.
Swift SVN r21078
stringByAddingPercentEncodingWithAllowedCharacters() and
stringByAddingPercentEscapesUsingEncoding() to String?, and add API notes for
NSString to the same effect
Swift SVN r21007
_preconditionFailure()s. Some of these checks are clearly redundant (for
example, the check of array subscript), but since we have no tests for
these traps (and reflection is not fast in general), I prefer to keep this
transformation as straightforward as possible.
Swift SVN r20971
The _forceBridgeFromObjectiveC and _conditionallyBridgeFromObjectiveC
requirements of the _ObjectiveCBridgeable protocol previously returned
Self and Self?, respectively, where 'Self' is the value type that is
bridged. This use of returns is fairly hostile to the idea of calling
the witnesses for these requirements from the C++ part of the runtime,
leading to "interesting" tricks with OpaqueExistentialContainer that
made it hard to use these witnesses within the dynamic casting
infrastructure.
Replace the returns with inout Self? parameters, which are far easier
to deal with in the C++ part of the runtime. Despite the churn because
we're changing the _ObjectiveCBridgeable protocol, this is NFC.
Swift SVN r20934
The SPI that XCTest exposes to the overlay has Objective-C semantics,
while anything exposed to Swift code via @asmname needs Swift semantics.
Add a bridge to the overlay that handles this adaptation.
Addresses <rdar://problem/17408423>.
Swift SVN r20932
Rather than use a header file and -import-objc-header, use @asmname and
@objc_block to tell the overlay about the Objective-C function used to
capture exceptions.
Further addresses <rdar://problem/16453199>.
Swift SVN r20929
Since Swift itself has no exception support, use an Objective-C helper function
to evaluate a block and return an NSDictionary indicating whether an exception
was thrown out of that block (and if so, which exception).
Addresses <rdar://problem/16453199>.
Swift SVN r20880
Now that CGFloat is a peer of Float and Double, we need to add appropriate handling
to it for XCTAssertEqualWithAccuracy.
Addresses <rdar://problem/17762421>.
Swift SVN r20800
When NSArrays are bridged into Array<T>, they weren't being .copy()'d.
As a result, changes to an NSMutableArray (cast to NSArray), could cause
"unrelated" Swift Arrays to mutate. Found by inspection while
bottlenecking unsafeBitCast's in Array implementation, which also
happens in this commit.
Swift SVN r20678
Squash _[Conditionally]BridgedToObjectiveC into one protocol. This
change results in simpler bridging code with fewer dynamic protocol
conformance checks, and solves the nasty naming/semantics problem that
resulted from having _ConditionallyBridgedToObjectiveC refining
_BridgedToObjectiveC.
Also, rename things so they're more symmetrical and less confusing.
Swift SVN r20664
To limit user confusion when using conditional expressions of type Bool?, we've decided to remove the BooleanType (aka "LogicValue") conformance from optional types. (If users would like to use an expression of type Bool? as a conditional, they'll need to check against nil.)
Note: This change effectively regresses the "case is" pattern over types, since it currently demands a BooleanType conformance. I've filed rdar://problem/17791533 to track reinstating it if necessary.
Swift SVN r20637
When a non-final class satisfies a method requirement that returns
Self, it must do so with a method that also returns (dynamic)
Self. This ensures conformance will be inheritable, closing off an
awful type-safety hole <rdar://problem/16880016>. Other
non-contravariant uses of Self in the signatures of requirements cause
the protocol to be unusable by non-final classes.
I had to leave a tiny little gaping hole for the ~> operator, whose
removal is covered by <rdar://problem/17828741>. We can possibly put
this on firm footing with clever handling of generic witnesses, but
it's not important right now.
Swift SVN r20626
