CGFloat is 32-bit on 32-bit architectures and 64-bit on 64-bit
architectures for historical reasons. Rather than having it alias
either Float (32-bit) or Double (64-bit), introduce a distinct struct
type for CGFloat. CGFloat provides a complete set of comparisons and
arithmetic operators (including tgmath functions), initializers allows
explicit conversion between it an Int, UInt, Float, and Double, as
well as conforming to all of the protocols that Float/Double do.
This formulation of CGFloat makes use of CGFloat
architecture-independent, although it still requires a number of casts.
Fixes <rdar://problem/17224725>
Swift SVN r19689
Previously, bridged value types and their corresponding Objective-C
classes allow inter-conversion via a number of user-defined conversion
functions in the Foundation module. Instead, make this a general
feature of the type checker so we can reason about it more
directly. Fixes <rdar://problem/16956098> and
<rdar://problem/17134986>, and eliminates 11 (half) of the
__conversion functions from the standard library and overlays.
A few notes:
- The XCTest changes are because a String can no longer directly
conform to CVarArg: this is a Good Thing (TM), because it should be
ambiguous: did you mean to pass it as an NSString or a C string?
- The Objective-C representations for the bridged collections are
hard-coded in the type checker. This is unfortunate and can be
remedied by adding another associated type to the
_BridgedToObjectiveC protocol.
Swift SVN r19618
- Change the parser to accept "objc" without an @ sign as a contextual
keyword, including the dance to handle the general parenthesized case.
- Update all comments to refer to "objc" instead of "@objc".
- Update all diagnostics accordingly.
- Update all tests that fail due to the diagnostics change.
- Switch the stdlib to use the new syntax.
This does not switch all tests to use the new syntax, nor does it warn about
the old syntax yet. That will be forthcoming. Also, this needs a bit of
refactoring, which will be coming up.
Swift SVN r19555
There is some follow-up work remaining:
- test/stdlib/UnicodeTrie test kills the type checker without manual type annotations. <rdar://problem/17539704>
- test/Sema/availability test raises a type error on 'a: String == nil', which we want, but probably not as a side effect of string-to-pointer conversions. I'll fix this next.
Swift SVN r19477
As before, there may be more things marked @public than we actually want
public. Judicious use of the frontend option -disable-access-control may
help reduce the public surface area of the stdlib.
Swift SVN r19353
We haven't been advertising this syntax much, and it's closure form
was completely broken anyway, so don't jump through hoops to provide
great Fix-Its here.
Swift SVN r19277
Better to describe how the protocol can be used than how it can't. Also include a mention of Self type requirements as a source of non-existentiability.
Swift SVN r19207
don't call into CoreFoundation to perform UTF-8 transcoding. CoreFoundation
can replace ill-formed sequences with a single byte, which is not good enough
to implement U+FFFD insertion. Instead, use the same transcoding routine as
for contiguous buffer.
Pulled out the transcoding routine into a generic function that should be
specialized and simplified for the case when input is UnsafeArray; we should
not be losing efficiency here.
Fixes <rdar://problem/17297055> [unicode] println crashes when given string
with unpaired surrogate
Swift SVN r19157
Keep calm: remember that the standard library has many more public exports
than the average target, and that this contains ALL of them at once.
I also deliberately tried to tag nearly every top-level decl, even if that
was just to explicitly mark things @internal, to make sure I didn't miss
something.
This does export more than we might want to, mostly for protocol conformance
reasons, along with our simple-but-limiting typealias rule. I tried to also
mark things private where possible, but it's really going to be up to the
standard library owners to get this right. This is also only validated
against top-level access control; I haven't fully tested against member-level
access control yet, and none of our semantic restrictions are in place.
Along the way I also noticed bits of stdlib cruft; to keep this patch
understandable, I didn't change any of them.
Swift SVN r19145
Now that we use bridgeFromObjectiveCConditional to perform conditional
bridging, make bridgeFromObjectiveC handle forced bridging. For the
latter, deferred checking is acceptable.
Almost all of <rdar://problem/17319154>.
Swift SVN r19046
This entry point is used in conditional downcasts (as?) to attempt to
bridge from an Objective-C class down to a specific native type (e.g.,
array, dictionary), bridging all elements eagerly so that it can
produce nil if the bridging would fail.
This is the scaffolding for <rdar://problem/17319154>, and makes the
example there work, but there is much more cleanup and optimization to
do.
Swift SVN r18999
This is all goodness, and eliminates a major source of implicit conversions.
One thing this regresses on though, is that we now reject "x == nil" where
x is an option type and the element of the optional is not Equtatable. If
this is important, there are ways to enable this, but directly testing it as
a logic value is more straight-forward.
This does not include support for pattern matching against nil, that will be
a follow on patch.
Swift SVN r18918
This is our public API for how quicklooks work in the debugger, and the plan is to have this same API work in playgrounds as well
Fixes rdar://17023157
Swift SVN r18609
There's a bit of a reshuffle of the ExplicitCastExpr subclasses:
- The existing ConditionalCheckedCastExpr expression node now represents
"as?".
- A new ForcedCheckedCastExpr node represents "as" when it is a
downcast.
- CoerceExpr represents "as" when it is a coercion.
- A new UnresolvedCheckedCastExpr node describes "as" before it has
been type-checked down to ForcedCheckedCastExpr or CoerceExpr. This
wasn't a strictly necessary change, but it helps us detangle what's
going on.
There are a few new diagnostics to help users avoid getting bitten by
as/as? mistakes:
- Custom errors when a forced downcast (as) is used as the operand
of postfix '!' or '?', with Fix-Its to remove the '!' or make the
downcast conditional (with as?), respectively.
- A warning when a forced downcast is injected into an optional,
with a suggestion to use a conditional downcast.
- A new error when the postfix '!' is used for a contextual
downcast, with a Fix-It to replace it with "as T" with the
contextual type T.
Lots of test updates, none of which felt like regressions. The new
tests are in test/expr/cast/optionals.swift.
Addresses <rdar://problem/17000058>
Swift SVN r18556
Many changes in how we're presenting the NSString APIs on String, most
notably that we now traffic in String.Index and Range<String.Index>
rather than Int and NSRange. Also we present NSString initializers that
can fail only as factory functions, and factory functions that can't
fail only as init functions.
About 25% of the API changes here have been reviewd by the Foundation
guys, and testing is, as it has always been, admittedly spotty. Dmitri
is going to be writing some more comprehensive tests.
Swift SVN r18553
Dictionary's isBridgedToObjectiveC() was overly restrictive. This went
unnoticed because the tests were using internal Dictionary APIs to construct
the desired state, instead of going thourgh casts.
rdar://16973429
Swift SVN r18454
We were using the bridged non-verbatim path
(_arrayBridgeFromObjectiveC) for bridged-verbatim types. While that
path can do the right thing (and does when the standard library's
internal checking is turned off), it's unnecessarily inefficient.
Swift SVN r18418
This makes fun bridging like
var obj: AnyObject! = [3.14159, 2.71828, 0] as Double[]
if let intArr = obj as Int[] {
println("Array of doubles as ints is \(intArr)")
}
"work", given that NSNumber is the common class type through which we
are bridging.
Swift SVN r18398
Unfortunately, we can't add an implicit conversion from
String to CFString, or anything analogous like string
literal support, without introducing ambiguities
when converting to AnyObject.
rdar://16271682
Swift SVN r18387
This entry point is used when T is bridged verbatim and U is bridged
non-verbatim. It attempts to bridge each T from Objective-C to a U,
and returns nil if any of the elements cannot be bridged back to a U.
For now, only _convertNSArrayToArray and Array.bridgeFromObjectiveC
depend on this. It will soon be used for checked casts from, e.g.,
AnyObject[] to String[].
This is part of <rdar://problem/16952771> and general array bridging.
Swift SVN r18369
