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
Instead, just import them as a pair of methods. This is obviously suboptimal,
but better than the alternative in which you can see the property, but
attempting to use the accessor with the customized name results in a crash
at runtime.
Swift SVN r12755
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
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
Clang's LookupVisibleDecls is implemented by iterating over the map of lookups,
which clearly isn't deterministic. This *shouldn't* be a problem, but it
seems our importer has non-determinism based on the order it sees decls.
For now, at least, let's make this deterministic up front so that we don't get
weird results from :print_module.
See <rdar://problem/15785883> and <rdar://problem/15799697>.
Swift SVN r12309
-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
Although Cocoa.framework re-exports AppKit, Foundation, and CoreData, an
arbitrary library does not re-export most of its imports. Normally this
would be fine, but the Clang importer can pull in types too eagerly and
then generate thunks and wrappers for things we don't care about. At least
for now, return to the behavior of autolinking /anything/ that gets visibly
imported.
<rdar://problem/15705923>
Swift SVN r11844
This allows us to enable a verifier that ensures that protocol
conformances account for all requirements in the corresponding
protocol.
Swift SVN r11813
with qualifiers on it, we have two distinct types:
- LValueType(T) aka @lvalue T, which is used for mutable values on the LHS of an
assignment in the typechecker.
- InOutType(T) aka @inout T, which is used for @inout arguments, and the implicit
@inout self argument of mutable methods on value types. This type is also used
at the SIL level for address types.
While I detangled a number of cases that were checking for LValueType (without checking
qualifiers) and only meant @inout or @lvalue, there is more to be done here. Notably,
getRValueType() still strips @inout, which is totally and unbearably wrong.
Swift SVN r11727
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
