When we print the ObjectiveC module, we really shouldn't see extensions that
come from Foundation. Admittedly, we don't see them correctly in Foundation
either, but that's a separate issue.
There is one slightly unsafe hack here: we still import NSString as String,
by name alone, even when Foundation isn't present. This is because NSString
shows up in the ObjectiveC module, but we want people to be using String
when interacting with NSObject in real life.
Swift SVN r21857
This can be used by SourceKit's interface printer to display modules with
forward declarations of classes in dependent modules, e.g. ObjectiveC
forward-declaring Foundation's NSString for use in NSObject. We can consider
doing something similar for C tag types (structs and enums).
Part of rdar://problem/18273845
Swift SVN r21828
This is a hack that allows us to support accessibility APIs in Swift.
It addresses radar://17509751.
A class might conform to both NSAccessibility (containing accessibility
properties) and individual accessibility protocols (containing
accessibility methods with the same names as the properties). This should
not compile (but currently happens to compile). To avoid the problem down
the road, we import setters and getters instead of the accessibility
properties from NSAccessibility.
Swift SVN r21757
In this mode, use nullability information on the result type of the
initializer or factory method to determine failability of the
initializer. This is behind the flag
-enable-objc-failable-initializers until we have the SILGen support in
place.
Swift SVN r21341
i.e. don't look for attributes on an @class somewhere.
Also do this for tag decls, whose attributes propagate forwards until there's
a definition.
<rdar://problem/17986861>
Swift SVN r21223
This is a step towards making the framework easier to use in Swift; in the
actual headers, these are typed as "CFTypeRef" or "const CFTypeRef", which
is not considered Hashable (and thus cannot be put in a dictionary).
Unfortunately, CFStringRef is also not hashable, so we're not there yet,
but at least this allows a freer conversion to NSString.
Part of <rdar://problem/17162475>
Swift SVN r20931
Previously, we were just storing setter accessibility via the accessibility
level on the setter function. However, some Stored properties never actually
have a setter synthesized, which led to the compiler dropping the setter
accessibility at serialization time. Rather than try to hack up something
clever, just store the setter accessibility explicitly in every
AbstractStorageDecl. (We still only serialize it for VarDecls, because
settable SubscriptDecls always have setter functions.)
<rdar://problem/17816530>
Swift SVN r20598
If importing a Clang module fails, we should report that at the location of
the import statement. This doesn't do that fully because it isn't transitive
(if Swift module Foo imports Swift module Bar, which fails to import Clang
module Baz, we don't get an error in user source), but it's a step forward
for the simple cases.
Swift SVN r20575
This replaces my egregious -initWithCoder:-specific hack with a more
reasonable general solution.
Replace my initWithCoder: hack with a proper
Swift SVN r20562
This allows us to express required initializers in the API notes. Use
it to smooth over NSString differences in the various SDKs even more.
Swift SVN r20511
To do this, we keep track of decls with superfluous typedefs (rather than
just the typedefs), and check for that. Tag decls without typedefs are
printed with the tag.
<rdar://problem/17569385>
Swift SVN r20221
We do this so that the swiftmodule file contains all info necessary to
reconstruct the AST for debugging purposes. If the swiftmodule file is copied
into a dSYM bundle, it can (in theory) be used to debug a built app months
later. The header is processed with -frewrite-includes so that it includes
any non-modular content; the user will not have to recreate their project
structure and header maps to reload the AST.
There is some extra complexity here: a target with a bridging header
(such as a unit test target) may depend on another target with a bridging
header (such as an app target). This is a rare case, but one we'd like to
still keep working. However, if both bridging headers import some common.h,
we have a problem, because -frewrite-includes will lose the once-ness
of #import. Therefore, we /also/ store the path, size, and mtime of a
bridging header in the swiftmodule, and prefer to use a regular parse from
the original file if it can be located and hasn't been changed.
<rdar://problem/17688408>
Swift SVN r20128
We're not using this for anything, yet, so there aren't any checked-in
tests. Also note that I'm using ".apinotesc" for the binary form of
API notes.
Swift SVN r20096
CGFloat is 32-bit on 32-bit architectures and 64-bit on 64-bit
architectures for historical reasons. Rather than having it alias
either Float (32-bit) or Double (64-bit), introduce a distinct struct
type for CGFloat. CGFloat provides a complete set of comparisons and
arithmetic operators (including tgmath functions), initializers allows
explicit conversion between it an Int, UInt, Float, and Double, as
well as conforming to all of the protocols that Float/Double do.
This formulation of CGFloat makes use of CGFloat
architecture-independent, although it still requires a number of casts.
Fixes <rdar://problem/17224725>
Swift SVN r19689
No validation is done yet on whether the user-specified access control makes
sense in context, but all ValueDecls should at least /have/ accessibility now.
/Still/ no tests yet. They will be much easier to write once we're actually
enforcing access control and/or printing access control.
Swift SVN r19143
Add the ability to store optionality of the ObjC method parameters and return
type in a sidecar. This hardcoded info is then used to import Objective C
object pointer types as either optional or none, instead of implicitly
unwrapped optionals.
The feature is enabled with -import-with-tighter-objc-types=true.
Swift SVN r19048
.../if/ the protocol and the class are from the same top-level Clang module.
If not, the protocol is /not/ renamed, and users will have to disambiguate
with module qualification.
This kills our hardcoded "RenamedProtocols" list; it turns out this pattern
is more common than we thought /and/ leads to cross-referencing issues.
<rdar://problem/16206627>
Swift SVN r18809
instead of importing them as _Nil (which will be going away when nil becomes an expr).
You now get an error saying:
error: 'NULL' is unavailable: use 'nil' instead of this imported macro
This is pretty cool all around, except for the GCD macros that need to be fixed, I'll
handle that as a follow-up.
Swift SVN r18747
Use this for -class and +class, to make them less ad hoc. More to follow.
As part of this, actually mark imported unavailable declarations in a
protocol as "optional", because nobody should have to implement an
unavailable declaration.
Swift SVN r18262
attributes and create implicit conversions for them.
Also, when generating Clang modules for import, set the
appropriate macro to make CoreFoundation actually apply
those attributes to its typedefs.
Also, give shared linkage to imported class method
definitions.
The net effect is that CFString now automatically
converts to NSString and vice-versa.
Depends on Clang r208756 in order to preserve attributes
applied to tag types in multiple typedef declarations.
Swift SVN r18069
Attribute validation is not naturally idempotent, and we shouldn’t need to make it so. Rather, we should only do the validation once. This fixes an immediate issue with @NSManaged in multi-file situations (<rdar://problem/16879162>) and avoids some redundant work.
Longer term, we have a ton of redundant visitation that needs to be addressed <rdar://problem/16905199>.
Swift SVN r18039
Previously, the getter and setter for a property could disagree on what the
"type of the property" was: Unmanaged<CFType> vs. CFType, or COpaquePointer
vs. CMutableVoidPointer. Now, we treat property accessors as distinct from
normal methods when importing their parameter and result types, and have
those types follow the same rules as they would for the property itself.
This will need a bit of cleanup work once we're importing implicit properties
everywhere, but this handles the crashes and unfortunate limitations we were
seeing for WWDC.
<rdar://problem/16544938>
Swift SVN r17987
corresponding getter method is audited.
There are a host of other potential consistency problems
here, but this should fix a particular egregious one
that was preventing use of NSColor's CGColor property.
rdar://16846555
Swift SVN r17667
- the type of a const global variable
- the type of a parameter, always
- the return type of a function that has been audited
or has an explicit retained/not-retained attribute
- the return type of an ObjC method that has an explicit
retain/not-retained/inner-pointer attribute
Additionally, choose the correct conventions for all
these cases during SIL type lowering.
All this importing logic is still only enabled under
-Xfrontend -import-cf-types.
Swift SVN r17543
