This commit covers only the AST-building side of indexed
subscripting, mapping objectAtIndexedSubscript: and
setObject:atIndexedSubscript: to Swift 'subscript' declarations. IR
generation and support for keyed subscripting to follow.
Swift SVN r3377
Only create constructors for class 'new' methods (not instance methods
like
newScriptingObjectOfClass:forValueForKey:withContentsValue:properties:),
and only do so when the class type inherits from NSObject. The latter
occurs because we don't have a notion of a 'top' for Objective-C
classes, and is a temporary measure.
Swift SVN r3374
Note that the constructors we emit don't function yet, since they rely
on the not-yet-implemented class message sends to Objective-C
methods.
Swift SVN r3370
This implementation is very lame, because we don't currently have a
way to detect (in Sema or SIL) where 'this' gets uniquely assigned,
and turn that assignment into initialization.
Also, I'm starting to hate the name 'allocating' constructor, because
it's the opposite of the Itanium C++'s notion of the allocating
constructor. Will think up a better name.
Swift SVN r3347
With this change, I'm able to import Cocoa (using my hacked OSX 10.9 SDK,
naturally) into Swift and poke at various classes and methods with
-parse. Runtime tests still fail, however.
Swift SVN r3274
This is mostly a hack to work around differences between how Swift and
Clang name lookup into modules works. However, it allows us to load
multiple Clang modules into Swift without causing spurious
ambiguities. The generation-based versioning isn't stricly necessary,
since module imports are resolved up front. However, we may eventually
want to speculatively load modules as part of name binding or type
checking, in which case we'd rather not have stale caches. And it
costs us very little.
Swift SVN r3269
Objective-C's 'id' is a very odd type, because it effectively acts as
both a "top" and a "bottom" for the lattice of Objective-C types,
where "top" is a type everything is a subtype of an "bottom" is a type
everything is a supertype of. We almost surely don't want the "bottom"
behavior in Swift, but we also don't have a suitable notion of "top"
yet. protocol<> is closest, but that's too general because it also
allows value types. NSObject is the closest thing we have, for now, so
we use it.
Swift SVN r3260
Tweak the import of Objective-C methods to build the proper FuncExpr
and tag the FuncDecl as an Objective-C method, along with a few other
tweaks, so calls to the imported Objective-C methods go through
objc_msgSend().
At this moment, this is aborting in the Objective-C runtime due to an
unrecognized selector. The issue does not appear related to the
importer.
Swift SVN r3255
There is no protection whatsoever if the Clang-to-Swift type
conversion produces something that Swift doesn't lower in an
ABI-compatible way. That will be dealt with later.
Swift SVN r3249
This functionality will come back when we get support for "thin"
function pointers in Swift, that don't capture anything from their
environment.
Swift SVN r3248
Note that we have to be very careful not to introduce ambiguities
between the name of the getter and the name of the property, so we do
the following:
- "Informal" properties (where there is no @property) are not
mapped to Swift variables. The methods are just methods.
- An @property suppresses name lookup's ability to find
the getters and setters of that property, so having a "foo" property
eliminates the "foo" and "setFoo" methods.
- If an @property is added in a subclass, such that its getter or
setter come from a superclass, than that property cannot be mapped
to a Swift variable. Hopefully, this is rare.
As part of this, I had to make sure that Objective-C method overrides
were recorded as overrides in the Swift AST. The same will need to
happen for properties at some point.
Swift SVN r3245
Note that we probably also want to do this if we're in a type context
and we found non-type declarations, so that "stat" referenced in a
value context finds the function, but in a type context finds the
type.
Swift SVN r3222
This importer handles all of the Clang structural types, e.g., builtin
types (int, float, void), function types, block pointer types, and
C pointer types. It does not yet handle nominal types such as enums,
structs, or Objective-C classes, and there are some questions about
(e.g.) array types.
Swift SVN r3212
From a user's perspective, one imports Clang modules using the normal
Swift syntax for module imports, e.g.,
import Cocoa
However, to enable importing Clang modules, one needs to point Swift
at a particular SDK with the -sdk= argument, e.g.,
swift -sdk=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9M.sdk
and, of course, that SDK needs to provide support for modules.
There are a number of moving parts here. The major pieces are:
CMake support for linking Clang into Swift: CMake users will now need
to set the SWIFT_PATH_TO_CLANG_SOURCE and SWIFT_PATH_TO_CLANG_BUILD
to the locations of the Clang source tree (which defaults to
tools/clang under your LLVM source tree) and the Clang build tree.
Makefile support for linking Clang into Swift: Makefile users will
need to have Clang located in tools/clang and Swift located in
tools/swift, and builds should just work.
Module loader abstraction: similar to Clang's module loader,
a module loader is responsible for resolving a module name to an
actual module, loading that module in the process. It will also be
responsible for performing name lookup into that module.
Clang importer: the only implementation of the module loader
abstraction, the importer creates a Clang compiler instance capable of
building and loading Clang modules. The approach we take here is to
parse a dummy .m file in Objective-C ARC mode with modules enabled,
but never tear down that compilation unit. Then, when we get a request
to import a Clang module, we turn that into a module-load request to
Clang's module loader, which will build an appropriate module
on-the-fly or used a cached module file.
Note that name lookup into Clang modules is not yet
implemented. That's the next major step.
Swift SVN r3199
