Previously, we would import the init method as a FuncDecl, which
wasn't actually supposed to be used by anything, and then created a
separate ConstructorDecl via importSpecialMember(). That's insane:
just have VisitObjCMethodDecl() produce a ConstructorDecl directly
when given an init method. Should be NFC.
Swift SVN r16313
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
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
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
The frontend option -split-objc-selectors splits the first part of an
Objective-C selector into both a function name and the first parameter
name at the last preposition. For example, this Objective-C method:
- (NSString *)stringByPaddingToLength:(NSUInteger)newLength withString:(NSString *)padString startingAtIndex:(NSUInteger)padIndex
is imported as
func stringByPadding toLength(newLength: Int) withString(padString: String) startingAtIndex(padIndex: Int) -> String
Swift SVN r15156
This is the same as the previous commit, but for protocols. To do this I
had to modify the ObjC printer to include a SWIFT_PROTOCOL annotation like
the SWIFT_CLASS annotation already in use. This is probably a good thing
anyway.
Second half of <rdar://problem/16296027>
Swift SVN r14985
The standard library likes to have default definitions for associated types,
which is good. Often the /choice/ of default type, however, is a type that
(indirectly) conforms to the very protocol containing the associated type.
Rather than try to make sure everything is present all at once, just delay
the deserialization of the default definition until it's actually requested.
This does swell the size of AssociatedTypeDecl by two words. I've filed
<rdar://problem/16266669> to remind myself to try to reduce this.
Part of <rdar://problem/16257259>
Swift SVN r14809
In these cases, disable the standard system include paths so we don't
accidentally pick up headers in /.
This is going to be used by the runtime team for low-level interfaces with
C and Objective-C in the standard library.
Swift SVN r14789
This reverts part of r14563, which swapped out the mirroring of
Objective-C initializers into subclasses. We still need to do this
when a subclass does not declare it's designated initializers. At
least the mirroring code is more robust, and marks declarations as
implicit so they won't show up when printed.
Swift SVN r14633
Make Objective-C initializers inherited according to the inheritance
rules we've specified. Prevent the Clang importer from manually
copying all of the initializers from every superclass into each
class.
This eliminates a ton of extra allocating constructors generated when
importing Objective-C init methods. Now we only generate allocating
constructors for the init methods that are actually declared.
Note that initializer inheritance only actually works for
Objective-C-defined classes. More to come.
Swift SVN r14563
There are two parts to this:
- Import protocol properties as properties, instead of as a pair of methods.
- Fix IRGen to handle property accesses in @objc protocols.
<rdar://problem/12993073>
Swift SVN r14438
This is hidden behind the frontend flag -enable-objc-optional. Use -Xfrontend
when invoking the Swift driver.
Part of <rdar://problem/15189135>
Swift SVN r14332
We will still import these as just 'Int', 'UInt', etc., but we still want to
allow users to write some of these types themselves. We now have an enum field
in MappedTypes.def to control this.
Fix-up for r14069 and <rdar://problem/16067854>
Swift SVN r14105
...rather than Int.
This handles the case where there are existing 32-bit enum constants with
the bit set, which isn't that uncommon for NS_OPTIONS declarations.
Part of <rdar://problem/15368372>, but should also fix the main issue in
<rdar://problem/15236662>.
Swift SVN r14090
This is more in line with all other modules currently on our system.
If/when we get our final name for the language, we're at least now set
up to rename the library without /too/ much trouble. (This is mostly just
a lot of searching for "import swift", "swift.", "'swift'", and '"swift"'.
The compiler itself is pretty much just using STDLIB_NAME consistently now,
per r13758.)
<rdar://problem/15972383>
Swift SVN r14001
This is necessary on 32-bit arm, where va_list's canonical type is void*.
Without a typedef-based mapping the importer would drop declarations used
by the NSStringAPI bridge because they appear to have void* parameters.
This mapping does not work on x86_64. SwiftTypeConverter::VisitTypedefType()
never sees va_list on that architecture only, perhaps due to that
architecture's unusual definition of __builtin_va_list. The default mapping
to COpaquePointer plus the conversion CVaListPointer=>COpaquePointer
is still in place for that architecture.
Swift SVN r12853
This still isn't /that/ lazy because a lot of things can force member
deserialization (such as the type-checker generating a DestructorDecl for
every imported class), and we don't do this in a member-granular way just
yet. I don't see any change in testing time, for example.
But besides just being a good thing in general, this perturbs the order
of imported decls enough to fix <rdar://problem/15799697>: we can now
reliably see that there is a -URL:something: function on NSObject that
blocks any properties named 'URL' from being imported as properties.
(Which we don't actually want; see <rdar://problem/15456130>.)
Swift SVN r12685
Hardcoding a path to a particular SDK is definitely the wrong thing to do.
Let's see how far we can get without setting a default SDK.
See discussion in <rdar://problem/14395800>
Swift SVN r12414
This can happen when importing a decl causes a new Swift module to be loaded
(because it uses one of our bridged types), which then brings in a new Clang
module. In this case we have no choice but to throw out the existing cache
and start over. We do keep a map of everything we've imported already, though,
so at least we don't have to do that part again.
This appears to make r12309 unnecessary for correctness, but it probably still
makes performance more consistent.
<rdar://problem/15785883>
Swift SVN r12336
-respondsToSelector: is declared on the NSObject protocol, which is adopted
by the NSObject root class. The NSObject metaclass also extends NSObject,
so it also needs a respondsToSelector:. This effectively becomes a
+respondsToSelector: method on NSObject-the-class.
Change importMirroredProtocolMembers to actually do this, just like
importObjCMembers was changed in r11614 for instance methods declared
directly within the class.
Finishes <rdar://problem/13371711>.
Swift SVN r11881
Not only this creates less ASTs, but this makes the resulting AST correct (it
is invalid to have a struct and a typealias with the same name). But the
primary motivation is AST pretty-printing: we don't want to print those extra
useless typealiases.
Swift SVN r11289
Now that everything is done in terms of FileUnits, we don't need LoadedModule
anymore, and now that FileUnits just use virtual dispatch, we don't need to
indirect through ModuleLoader to distinguish them.
This doesn't quite simplify as much as it could, because the next change is
going to combine TranslationUnit and Module.
Swift SVN r10836
Part of the FileUnit restructuring. A Clang module (whether from a framework
or a simple collection of headers) is now imported as a TranslationUnit
containing a single ClangModuleUnit.
One wrinkle in all this is that Swift very much wants to do searches on a
per-module basis, but Clang can only do lookups across the entire
TranslationUnit. Unless and until we get a better way to deal with this,
we're stuck with an inefficiency here. Previously, we used to hack around
this by ignoring the "per-module" bit and only performing one lookup into
all Clang modules, but that's not actually correct with respect to visibility.
Now, we're just taking the filtering hit for looking up a particular name,
and caching the results when we look up everything (for code completion).
This isn't ideal, but it doesn't seem to be costing too much in performance,
at least not right now, and it means we can get visibility correct.
In the future, it might make sense to include a ClangModuleUnit alongside a
SerializedASTFile for adapter modules, rather than having two separate
modules with the same name. I haven't really thought through this yet, though.
Swift SVN r10834
Apply the same prefix-chopping logic as for NS_ENUM to produce static property names to put inside the Swift type we create. For now, continue importing NS_OPTIONS as structs with a single integer field; in the short term it's easy to put a C-like interface over them this way.
Swift SVN r10434
