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
We needed some patching up to convert negative enum constants into proper negative IntegerLiteralExprs in the imported Swift AST, to handle the obnoxious INT_MIN edge case, and to handle "negative" values of unsigned enums.
Swift SVN r10005
Clean up ListMaker and get it compiling again. Delete all of the
stubbed-out table view delegate methods now that they're optional,
fixing the crash when dragging items <rdar://problem/14582991>.
Swift SVN r9995
Swift enum cases are already namespaced to their type, but Cocoa NS_ENUM constants are manually namespaced with a common prefix, so if we imported them as-is, we'd end up with expressions like 'NSStringSearchOptions.NSStringSearchCaseSensitive'. To make this a bit nicer, look for a common prefix of camel-case words among all of the constants in the enum, and remove that prefix from the enum case names in the Swift interface.
In the case of a single enum case, we have no basis for determining a prefix, so do nothing. This case doesn't come up in the frameworks (that I can see).
Swift SVN r9993
Previously, the Parser and BranchStmt typedef-ed ExprStmtOrDecl as a pointer union. Using typedef made the objects compatible, but did not allow us to extend the type with helper methods, such as getSourceRange(), which is something you can get on all of the AST objects. This patch introduces ASTNode that subclasses from PointerUnion and is used by both parser and BranchStmt.
Swift SVN r9971
When we see an enum declaration in the Clang importer, look at its source location to see if it was produced as part of an NS_ENUM macro expansion. If so, take the 'Enum' route through the Clang importer and import it as a Swift enum. This will break things until we have end-to-end support for Clang-imported enums, so hide it behind an -import-ns-enum switch for now.
Swift SVN r9951
Whatever kind of Swift decl we cons up for a Clang enum, add it to the externals list so we can pick it up and emit Swift metadata for it in IRGen. Fixes <rdar://problem/15242452>.
Swift SVN r9801
