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
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
...or at least the same machinery as #line. We add a (referential) mirror
of the Clang buffer to Swift's source manager, then remap that particular
line to whatever Clang currently thinks is the presumed location for that
line. (This means we respect Clang line directives too.)
This also modifies Swift's source manager to be more forgiving about adding
the same virtual file range twice; it will tell you when you try to do it.
<rdar://problem/16596800>
Swift SVN r20572
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
We choose not to model "OptionalTypeAdjustment(1, OTK_Optional)" in yaml, so update the known methods to use what we can model.
Introduce the absence of nullability info and use it to set NullabilityAudited and NumAdjustedNullable. (Maybe, after the .def file is gone and we have more testing, we could change the KnownObjCMethod API to better reflect the yaml format..)
Swift SVN r20367
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
Specifically, handle them by also importing the top-level module. This is
unfortunate, but at least lets people /access/ things in explicit submodules,
even if it doesn't let them limit their import to a specific submodule.
(swift) import OpenGL.GL3
(swift) glGetString
// r0 : (GLenum) -> ConstUnsafePointer<GLubyte> = (Function)
(swift) OpenGL.glGetString
// r1 : (GLenum) -> ConstUnsafePointer<GLubyte> = (Function)
One unfortunate side effect of having a single Clang ASTContext is that if
one Swift module imports a Clang submodule, every Swift module can now see
it. That means /mixing/ incompatible submodules, such as OpenGL.GL and
OpenGL.GL3, still won't work. Filed <rdar://problem/17756745> for that.
<rdar://problem/13140302>
Swift SVN r20288
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
Make the "merging class-wide information into method information"
operation part of ObjCMethodInfo. It doesn't belong in the Clang
importer.
Swift SVN r20171
Now that bridging headers from ASTs are always present and bridging headers
from the command line are checked in advance, we no longer need to worry
about the Clang instance failing to find the bridging header. That's good,
because this wasn't implemented correctly anyway: if a bridging header
imported a module, we could get an error.
Swift SVN r20129
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
