We started tracking statistics for these in r16529, but because we've
"always" done this for initializers, it's trivial to just implement
the splitting. As with initializers, we synthesize a named argument of
type '()' to capture the part of the first selector piece that follows
the class name.
Swift SVN r16530
For example, in an Objective-C class like this:
@interface NSFoo
+(instancetype)fooForReading;
@end
We don't import that class method as an initializer yet.
Swift SVN r16529
mystical workaround that hits our dogfooders.
Address this by adding '-fmodules-validate-system-headers' to the clang importer, which rebuilds the clang modules if system headers change.
By my unscientific testing I didn't see significant difference for compile time on the template Cocoa project beyond noise level, and it shouldn't
be significant on the project level because clang module importing happens on per-swift-target basis, not per-swift-file.
Swift SVN r16482
When an Objective-C class method follows the naming convention of a
factory method, i.e., its starting words match the ending words of the
class name, import it as a convenience initializer when it also:
- Returns instancetype (i.e., dynamic Self in Swift parlance)
- Has no NSError** parameters, which indicate the potential for failures
This is under a new flag (-enable-objc-factory-method-constructors)
because it is not generally functional. However, this is a step toward
<rdar://problem/16509024>.
Swift SVN r16479
This makes a number of changes to the selector-splitting
heuristics. Specifically:
- Eliminate last-word splitting, and with it the notion of
multi-words. We only split at prepositions now.
- Introduce the notion of "linking verbs" such as "will" or
"should"; when these show up, we refuse to split a selector, which
helps with delegates.
- Eliminate the special case for "get" and "set". It wasn't
helping.
Swift SVN r16265
In Objective-C, any method with no arguments can be used with dot syntax, as
can any method that takes one argument whose name starts with "set". This
commit adds a frontend-only flag -enable-objc-implicit-properties to look for
"setter-like" methods that match up with "getter-like" methods to import them
as Swift properties. By default, such methods are just considered unrelated
methods.
Part of <rdar://problem/16215476>
Swift SVN r16025
Seed the whitelist with the designated initializers for NSObject,
NSDocument, and UIDocument. We'll grow this list over time.
Fixes <rdar://problem/16521299>.
Swift SVN r16013
Regardless of the heuristic we choose when importing Objective-C
selectors into Swift method names, there will be poor cases. Allow us
to bake specific mappings into the compiler so we can address those
cases without having to modify the Objective-C headers.
Part of <rdar://problem/16341485>.
Swift SVN r15984
This makes sure that Clang uses the mangled class names for
Swift-defined classes. Should be last compiler-side piece of
<rdar://problem/15506580>.
Swift SVN r15977
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
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
When we see an unresolved @class in a Clang module, we check the class name
against the classes in the Swift module with the same name.
This unfortunately necessitates putting a reference to the active type checker
into the ClangImporter, because the class in the current Swift module hasn't
been type-checked yet. This is now being used everywhere we do a lookup.
<rdar://problem/16295994>
Swift SVN r15355
