The somewhat harder one is when the superclass is generic in
some way.
The much harder one (given the current representation) is when
the superclass is generic and *expressed in terms of the current
class's own generic arguments*.
Swift SVN r3477
The IR generation for this conversion is different from
derived-to-base conversions, because converting from an archetype to
its superclass type means projecting the buffer and then performing
the conversion.
Swift SVN r3462
Notably, there is still no support for +1 return values,
so we'll leak when doing alloc/init and so on; but this gets
the fundamentals in place. A lot of the extra stuff in here
is dealing with mapping between metatypes and class objects.
Swift SVN r3425
The interesting thing here is that we need runtime support in
order to generate references to metatypes for classes, mostly
because normal ObjC classes don't have all the information we want
in a metatype (which for now just means the VWT pointer).
We'll need to be able to reverse this mapping when finding a
class pointer to hand off to, say, an Objective-C class method,
of course.
Swift SVN r3424
Currently only used for parsing. The immediate intent of these attributes is
to have them behave like [objc] for the purpose of emitting method
implementations; however, they are semantically distinct and should only be
used to expose outlets and actions to Interface Builder.
Swift SVN r3416
When generating IR for the JIT, use sel_registerName() to unique the
selector references we generate. Static code doesn't need this
pessimization. Fixes <rdar://problem/12764732>.
Swift SVN r3403
An Objective-C subscript setter has a type of the form
(this) -> (value, index) -> ()
while a Swift subscript setter has a type of the form
(this) -> (index) (value) -> ()
Introduce a Swift "thunk" with the latter signature that simply calls
the underlying Objective-C method, and make sure that thunk gets
type-checked and IR-generated appropriately.
Swift SVN r3382
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
The principal difficulty here is that we need accessing the
value witness table for a type to be an efficient operation,
but there (obviously) isn't a VWT field for ObjC classes.
Placing this field after the metatype would tend to bloat
metatypes by quite a bit. Placing it before is best, but
it introduces an unfortunate difference between the address
point of a metatype and the address of the global symbol.
That, however, can be fixed with appropriate linker support.
Still, for now this is rather unfortunately over-subtle.
Swift SVN r3307
First, keep track of each of the selectors we emit and dump them into the
llvm.used global so that they don't get thrown away by the
optimizer. Second, emit Objective-C module-level named metadata so
that the linker knows it needs to unique selectors. Otherwise,
uniquing doesn't happen when Swift code is compiled into a separate
dylib.
Swift SVN r3287
Objective-C methods imported from Clang can be part of extensions,
which weren't covered by the existing logic. Note that we currently
ban [objc] methods in extensions written in Swift, a restriction we
may want to revisit.
Swift SVN r3284
This introduces support for the syntax
Derived(baseObj)
to downcast from a class type to one of its subclasses. This still
needs more language design and implementation work, including:
- This overloads the X(y) syntax again, which already means either
"coerce y to type X, performing implicit conversions if necessary"
or "construct a value of type X from y". It's no actually ambiguous,
because the first case won't apply for downcasts and the second case
is limited to value types, but it makes me wonder whether we want a
different syntax for the first case.
- We need this to be a checked cast, but don't have the runtime
infrastructure to do so yet. I've left this as a FIXME.
However, the Objective-C importer is fairly useless because everything
that creates an object returns an "id", "id" maps to "NSObject", and
then the type system doesn't let you get from NSObject back to the
type you care about. So, this lets you explicitly do the cast.
Swift SVN r3279
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
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
the metadata kind.
I don't think this is actually a particularly useful thing
to track, especially since a non-generic type can be
generically parented or have a generic superclass or two.
Swift SVN r3182
non-trivial representation.
This is because subtyping extends infinitely meta-wards
in the metatype hierarchy: the one thing you can do
with a metatype of a metatype is pull the instance
metatype out, but that instance type is still a subtype
of the instance type of the metatype of the base metatype,
so... just trust me on this.
Swift SVN r3178
