The parameter names in C functions are not API in C and can easily be
inconsistent from one redeclaration to another. Therefore, those
parameter names are not considered API.
Swift SVN r15853
Import a selector into a Swift method name, performing splitting at
that point. Use the resulting method name to determine the argument
names of the parameters, rather than trying to chop up the selector
again. There's more refactoring to do here.
This fixes a longstanding bug where the first argument of an
Objective-C method got the internal parameter name when it should
have gotten no name at all.
Swift SVN r15850
Swift will use the basename + argument names formulation for
names. Update the DeclName interfaces, printing, and __FUNCTION__ to
use the method syntax.
We'll still need to rework the "x.foo:bar:wibble:" syntax; that will
come (significantly) later.
Swift SVN r15763
Language features like erasing concrete metatype
values are also left for the future. Still, baby steps.
The singleton ordinary metatype for existential types
is still potentially useful; we allow it to be written
as P.Protocol.
I've been somewhat cavalier in making code accept
AnyMetatypeType instead of a more specific type, and
it's likely that a number of these places can and
should be more restrictive.
When T is an existential type, parse T.Type as an
ExistentialMetatypeType instead of a MetatypeType.
An existential metatype is the formal type
\exists t:P . (t.Type)
whereas the ordinary metatype is the formal type
(\exists t:P . t).Type
which is singleton. Our inability to express that
difference was leading to an ever-increasing cascade
of hacks where information is shadily passed behind
the scenes in order to make various operations with
static members of protocols work correctly.
This patch takes the first step towards fixing that
by splitting out existential metatypes and giving
them a pointer representation. Eventually, we will
need them to be able to carry protocol witness tables
Swift SVN r15716
...so that the enumerators of this declaration:
typedef NS_OPTIONS(NSUInteger, NSKeyValueObservingOptions) {
NSKeyValueObservingOptionNew = 0x01,
NSKeyValueObservingOptionOld = 0x02,
NSKeyValueObservingOptionInitial NS_ENUM_AVAILABLE(10_5, 2_0) = 0x04,
NSKeyValueObservingOptionPrior NS_ENUM_AVAILABLE(10_5, 2_0) = 0x08
};
...come in as .New, .Old, .Initial, and .Prior. The code checks for plurals
of the form -s, -es, and -ies, which covers all of the NS_OPTIONS in our SDK.
<rdar://problem/16448966>
Swift SVN r15712
Otherwise we'd import NSNumberFormatterBehavior10_0 of
NSNumberFormatterBehavior as '10_0'. (Yes, you could escape it, but...)
<rdar://problem/16452174>
Swift SVN r15710
When we see pointer types in function or method parameters, import them as the bridged CMutablePointer/CConstPointer types instead of UnsafePointer, enabling the array and inout conversions with imported APIs.
Swift SVN r15705
For example:
func foo(a: id)
now gets a fixit to turn 'id' into 'AnyObject'.
This relies on the ClangImporter recording the translation as it
processes declarations whose types are remapped.
Swift SVN r15668
With this in place, remove the hacks that peeked at the imported Clang
node to determine the selector for a method. We're all
attribute-driven now. Part of <rdar://problem/16019773>.
Swift SVN r15663
Protocols can declare methods as being unavailable, as they do
in NSObjectProtocol (e.g., 'retain'). We both need to flag these
uses, but understand this for protocol conformance. For protocol
conformance, treat unavailable methods as if they were marked
optional. The compiler will not allow you to use these methods
anyway.
This finishes up support for:
<rdar://problem/16331335> Ban ObjC ARC entry points
Swift SVN r15644
This is a direct translation which happens when a Clang declaration
gets translated to a Swift declaration. This changed, coupled
with the current @availability checking (which is still limited)
now prohibits cases such as using 'NSDeallocateObject()' or
'- (BOOL) allowsWeakReference' from Swift.
Interestingly, it doesn't catch uses of -retain/-release yet, because
those methods are marked unavailable in the NSObject *protocol*.
While the attributes are being mapped over, the @availability
checking needs to be enhanced to replicate more of what Clang does
for this case.
Swift SVN r15643
Now that we represent the Objective-C runtime names of classes and
protocols in a uniform way, stop peeking into the Clang AST nodes to
get this information for imported classes and protocols. This is
better layering and helps test that new code path.
Swift SVN r15632
We can just get it from the instance type, if the instance type has been fully initialized, which is the case except during parsing of type decls when the decls' own types are being formed.
Swift SVN r15598
The frontend/driver flag is "-application-extension'. This
activates a language option which will be used for more restrictive
availability checking.
Operationally, this also passes...
- "-fapplication-extension" to the clang importer
- "-application_extension" to ld
Swift SVN r15543
@partial_interface is like @class, but it allows the user to write categories
or (eventually) subclasses in their Objective-C headers even though the
class will be implemented in Swift. The resolution rules are thus exactly the
same as for class.
I've included a template hack to allow you to keep building without switching
to the new internal Clang repo; in this case you will see one test failure.
<rdar://problem/16426884>
Swift SVN r15523
You can't actually call these initializers with an existential yet, but nor could you safely call the init methods anyway. At least you'll be able to conform to NSCoding with an initializer rather than an "init method". Fixes <rdar://problem/15595471>.
Swift SVN r15521
This significantly reduces the amount of overhead incurred when naively importing large external modules without referencing many of its members, which should directly improve response times in the playground. For example, the repro code attached to rdar://problem/16387393 imports Foundation but references none of its members, and with these changes its total compilation time is almost 2.5x faster.
Swift SVN r15479
