We currently mangle private declarations exactly like public declarations,
which means that private entities with the same name and same type will
have the same symbol even if defined in separate files.
This commit introduces a new mangling production, private-decl-name, which
includes a discriminator string to identify the file a decl came from.
Actually producing a unique string has not yet been implemented, nor
serialization, nor lookup using such a discriminator.
Part of rdar://problem/17632175.
Swift SVN r21598
Introduce an attribute that describes when a given CF type is
toll-free-bridged to an Objective-C class, and which class that
is. Use that information in the type checker to provide the CF <->
Objective-C toll-free-bridged conversions directly, rather than using
the user-defined conversion machinery.
Swift SVN r21376
Depending on visitation order, we would occasionally leave the factory
method available if we had completely imported the initializer
first. Fixes <rdar://problem/17261609>.
Swift SVN r21361
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
Without this, we try to bring these in as CF types, and then ARC tries to
manage them, and the program crashes.
<rdar://problem/17211521>
Swift SVN r21081
This handles things like NSSwapHostLongLongToBig and MKMapRectMake that
are static inline functions that themselves call other static inline
functions.
<rdar://problem/17227237>
Swift SVN r21080
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
This completes <rdar://problem/17024498>, except that we don't yet do
anything with 'deprecated' or 'obsoleted'. The former is covered by
<rdar://problem/17406050>, and I filed <rdar://problem/17873422> for the
latter.
Swift SVN r20845
Nearly all of them come from some annotation written explicitly in the
Objective-C header, and all of them should be shown in the generated
interface for an imported module.
Part of <rdar://problem/17024498>
Swift SVN r20841
Previously, we only retained the module in which a normal protocol
conformance occurred, which meant we either had to go searching for
the appropriate extension (yuck) or do without that information. This
is part of the separating-extension-archetypes work.
Swift SVN r20793
The eventual goal for extensions of generic types is to require them
to specify their generic parameters, e.g.,
extension Array<T> { ... }
rather than today's
extension Array { ... }
Start parsing (optional) generic parameters here, and update the
representation of ExtensionDecl to accomodate this new grammar
production. Aside from the parser changes, there's no intended
functionality change here.
Swift SVN r20682
This adds generic parameters and generic signatures to extension
declarations. The actual generic parameters just mirror what is
available on the extended type; however, it is filled in via extension
validation, which is handled lazily.
This is a NFC step toward decoupling the archetypes of extensions from
the archetypes of the extended types <rdar://problem/16974298>.
Swift SVN r20675
...rather than distinct classes. This is a bit more complicated than just
making a second typealias because we still want to strip off the "Ref".
<rdar://problem/17686069>
Swift SVN r20652
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
This replaces my egregious -initWithCoder:-specific hack with a more
reasonable general solution.
Replace my initWithCoder: hack with a proper
Swift SVN r20562
to emit fixit's when we rename something, e.g.:
t.swift:6:9: error: 'float' has been renamed to Float
var y : float
^~~~~
Float
Adopt this in the stdlib.
Swift SVN r20549
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
...and 'assign' and 'unsafe_unretained' as 'unowned(unsafe)', if the
property is a class type.
This isn't important for the compiler, but it is documentation for users
when they look at the generated interface for an Objective-C module.
Note that this actually produces a decl users can't yet write:
unowned(unsafe) var foo: UIView!
That's <rdar://problem/17277899> unowned pointers can't be optional.
<rdar://problem/17245555>
Swift SVN r20433
Initializers for non-final classes will soon need to be 'required' to
conform to an initializer requirement in a protocol, so start
marking imported initializers from Objective-C protocols as
'required'. This is part of <rdar://problem/17408284> and
<rdar://problem/17415607>.
Swift SVN r20428
If an enum has a name but isn't declared with NS_ENUM or NS_OPTIONS, we
don't know how it's intended to be used, so we import it as a struct with
each enumerator as a value. The raw value of the enum used to be accessible
as the 'value' field, but that was mistakenly marked Private in the Great
Access Control Update.
We could consider making plain enums RawRepresentable (and just convert
to and from their raw type without checking anything), but that's something
to do later.
<rdar://problem/17753237>
Swift SVN r20355
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
it indirectly through another pointer from Decl, just embed DeclAttributes
directly into Decl and get rid of the "getMutableAttrs" nonsense.
Swift SVN r20216
Mechanically add "Type" to the end of any protocol names that don't end
in "Type," "ible," or "able." Also, drop "Type" from the end of any
associated type names, except for those of the *LiteralConvertible
protocols.
There are obvious improvements to make in some of these names, which can
be handled with separate commits.
Fixes <rdar://problem/17165920> Protocols `Integer` etc should get
uglier names.
Swift SVN r19883
SIL SROA needs to know when a struct's visible fields actually completely make up the struct value, which becomes an issue if we start importing structs with yet-unrepresentable unions and bitfields. Track this in the ClangImporter, and add an 'aggregateHasUnreferenceableStorage' predicate to SILType to make it easy for passes to query. Part of <rdar://problem/17555966>.
Swift SVN r19720
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
