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
Direct access to ivars is very rare in our frameworks, and they can conflict
with property names (which we should prefer). On top of that, we weren't
even emitting the right code to access them correctly.
<rdar://problem/15818047>
Swift SVN r12604
with two kinds, and some more specific predicates that clients can use.
The notion of 'computed or not' isn't specific enough for how properties
are accessed. We already have problems with ObjC properties that are
stored but usually accessed through getters and setters, and a bool here
isn't helping matters.
NFC.
Swift SVN r12593
-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
