When determining whether a given normal protocol conformance is “retroactive”,
consider an overlay module to be equivalent to its underlying Clang module.
Therefore, don’t classify conformances within the overlay as “retroactive”,
simplifying some common manglings (e.g., NSObject’s Hashable conformance is
no longer considered retroactive) and better capturing the intent.
change includes both the necessary protocol updates and the deprecation
warnings
suitable for migration. A future patch will remove the renamings and
make this
a hard error.
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.
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.)
Per discussion, there are certain times where our APIs really want you to use
the performSelector family of methods (e.g. when the framework hands you a selector
and expects you to call it upon completion).
Although the methods still aren't type-safe, we are at least making the result
Unmanaged so that you're forced to think about whether it's +1 or +0 before you
use it, and so that the compiler doesn't accidentally try to retain a non-object
pointer.
This commit also removes the blocks on the makeObjectsPerformSelector... methods,
but Foundation plans to add NS_SWIFT_UNAVAILABLE there (see rdar://problem/21150180).
rdar://problem/21150277
Swift SVN r30044
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
In most cases this means adding @public to things that get serialized;
in a few cases it means using a modern public stdlib API instead of
a legacy thing I was trying to keep @internal.
Swift SVN r19350
Also, don't allow file-relative imports (i.e. don't consider a /source file's/
location as an include path). Both of these should be requested by the user,
at least at this point.
Swift SVN r13249
