Most of this is in updating the standard library, SDK overlays, and
piles of test cases to use the new names. No surprises here, although
this shows us some potential heuristic tweaks.
There is one substantive compiler change that needs to be factored out
involving synthesizing calls to copyWithZone()/copy(zone:). Aside from
that, there are four failing tests:
Swift :: ClangModules/objc_parse.swift
Swift :: Interpreter/SDK/Foundation_test.swift
Swift :: Interpreter/SDK/archiving_generic_swift_class.swift
Swift :: Interpreter/SDK/objc_currying.swift
due to two independent remaining compiler bugs:
* We're not getting partial ordering between NSCoder's
encode(AnyObject, forKey: String) and NSKeyedArchiver's version of
that method, and
* Dynamic lookup (into AnyObject) doesn't know how to find the new
names. We need the Swift name lookup tables enabled to address this.
These APIs are from the Swift 1.2 => Swift 2.0 transition, and are not
relevant anymore.
Removing them reduces the surface area of the library that needs to be
reviewed.
Adding a conformance to Foundation doesn't work because NSString can
be used without loading Foundation. debugDescription is one example of
this.
The only value we derive from the _CocoaStringType is its name, which
makes some APIs more readable. Adding a type safe wrapper around it
serves no purpose since we're almost always immediately casting back
and forth from an 'id'. This was previously done with unsafeBitCast,
which should be avoided unless we really need to reinterpret a bit
pattern.
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.
Swift was failing to autolink frameworks in the new text-based SDKs.
Clang r253060 fixes the underlying issue, so we can go back to relying
on autolinking for these.
This reverts the following commits (newest to oldest):
f65884159092a37ea9d54e52ef22
rdar://problem/23511008
All refutable patterns and function parameters marked with 'var'
is now an error.
- Using explicit 'let' keyword on function parameters causes a warning.
- Don't suggest making function parameters mutable
- Remove uses in the standard library
- Update tests
rdar://problem/23378003
This is an optional feature that is off by default, and is enabled by
passing -- -build-swift-dispatch-overlay=1 to utils/build-script.
The libdispatch build I was testing with was old and is missing some
symbols, so perhaps some of the stuff can move out of #if protection
later.
There isn't much here yet, and no tests either.
At some point I want to propose a revised model for exports, but for now
just mark that support for '@exported' is still experimental and subject
to change. (Thanks, Max.)
