-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
Rather than append the "Proto" suffix to all imported Objective-C
protocols, which can be confusing, whitelist those protocols that we
do have to rename. Only NSObject falls into this category so far.
Fixes <rdar://problem/15741699>.
Swift SVN r11856
This allows us to enable a verifier that ensures that protocol
conformances account for all requirements in the corresponding
protocol.
Swift SVN r11813
More specifically, instance methods on root objects are also class methods,
because the metatype for that class will inherit from the root class.
(That is, NSObject's metatype extends NSObject.)
This is necessary to allow calling, say, -respondsToSelector: on a class.
Unfortunately, it also brings in every other method on NSObject, including
"informal protocol" category methods like -awakeFromNib. We should probably
disprefer these in code completion, especially if they're declared in another
module, but it is perfectly legal to call these methods on Class objects in
Objective-C.
<rdar://problem/13371711>
Swift SVN r11614
and check for CF_ENUM/CF_OPTIONS, which NS_ENUM/NS_OPTIONS expand to.
This:
- Simplifies code
- Handles CF_ENUM/CF_OPTIONS enums
- Handles correctly an NS_ENUM/NS_OPTIONS enum that was itself expanded from another macro.
Swift SVN r11542
We'll need to perform name lookup based on the file-level
DeclContext*, so the module no longer suffices. No functionality
change here yet.
Swift SVN r11523
(various) FunctionType::get's, ArrayType::get,
ArraySliceType::get, OptionalType::get, and a few
other places.
There is more to be done here, but this is all I plan to do
for now.
Swift SVN r11497
This is a structural baby step toward lazily filling in protocol
conformances. We always build a ProtocolConformance, then mark it
either "complete" (when it's well-formed) or "invalid" (when it's
ill-formed). At present, the only benefit to this is that it slows
diagnostic cascades from invalid conformances.
Swift SVN r11492
typealias MyInt: ForwardIndex = Int
There is no real reason to allow this; it's just a static_assert that Int
conforms to ForwardIndex, which would be better spelled some other way.
This only applies to concrete typealiases, i.e. those that simply alias an
underlying type. Associated types can still have both inheritance clauses
and a (default) underlying type.
Swift SVN r11481
Until we can actually do the implementation work necessary to make 'if optionSetValue.Option {}' work, this is a reasonable affordance to allow the C 'if optionSetValue & .Option {}' pattern to work and bring us to parity with ObjC.
Swift SVN r11412
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
are not settable (like get-only ones). Set the 'isLet' bit in various
places, but not the particularly interesting or useful places yet.
Swift SVN r11121
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
Part of the FileUnit restructuring. A serialized module is now represented as
a TranslationUnit containing a single SerializedASTFile.
As part of this change, the FileUnit interface has been made virtual, rather
than switching on the Kind in every accessor. We think the operations
performed on files are sufficiently high-level that this shouldn't affect us.
A nice side effect of all this is that we now properly model the visibility
of modules imported into source files. Previously, we would always consider
the top-level imports of all files within a target, whether re-exported or
not.
We may still end up wanting to distinguish properties of a complete Swift
module file from a partial AST file, but we can do that within
SerializedModuleLoader.
Swift SVN r10832
Some work needs to be done on static member lookup and bitwise operations, but what's implemented now isn't a regression from what we have (except for an unfortunate case in Foundation.swift where we need to fully qualify a constant in a single-element NS_OPTIONS).
Swift SVN r10471
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
A problem with name lookup from Clang module contexts <rdar://problem/15410928> means I have to disable a ~= overload in the ObjectiveC overlay. Other than that, NS_ENUM import should be ready to go.
Swift SVN r10018
Only import NS_ENUM constants into Swift enum cases as part of the enum itself, not if the original C constant name is referenced by itself through the Clang module.
Swift SVN r10015
Swift enums don't yet support aliasing of enum cases, so if we see multiple constants in an NS_ENUM with the same underlying value, drop all but the first. Hopefully the first one is the "proper" name for the constant.
Swift SVN r10008
