by the LLVM IR optimizer. Tuple metadata refs are now largely
readnone, function metadata refs are already readnone. There may be some
left that are not, but they can be handled later.
Swift SVN r5071
that handle the 2/3 element cases specially. These are not actually
optimized at the moment (they just call into swift_getTupleTypeMetadata)
but this could be done at some point.
This is a win for a couple reasons: this reduces the amount of code generated
inline and it allows swift_getTupleTypeMetadata2/3 to be marked readnone,
enabling CSE. As a driveby, optimize metadata refs of zero element tuples
to directly use _TMdT_, eliminating a branch from swift_getTupleTypeMetadata.
Swift SVN r5070
Represent protocol 'P.metatype' types using the type metadata of the contained metatype. Emit 'typeof' value witnesses for protocol types that project the existential container buffer and then call the 'typeof' witness for the contained value. Implement the SIL protocol_metatype instruction the same way.
You can't quite call static methods on protocols yet because protocol_method doesn't know how to look up static methods from an existential metatype yet.
This breaks references to protocol names—they will try to create an existential metatype that refers to the metadata of the protocol type itself, rather than to the metadata of a conforming type. <rdar://problem/13438779> would fix them.
Swift SVN r5033
John talked me out of this. We still want to cache metadata at the BB level, because even with SIL GVN, there are potentially redundant metadata bits at a level SIL doesn't know about.
Swift SVN r5030
handling non-fixed layouts.
This uncovered a bug where we weren't rounding up the header
size to the element alignment when allocating an array of archetypes.
Writing up a detailed test case for *that* revealed that we were
never initializing the length field of heap arrays. Fixing that
caused a bunch of tests to crash trying to release stuff. So...
I've left this in a workaround state right now because I have to
catch a plane.
Swift SVN r4804
Emit ObjC stubs and categories for methods defined in extensions of ObjC-compatible classes. This makes extensions of ObjC classes available to ObjC in statically compiled code. For immediate-mode code we'll still need to dynamically register extension methods using the ObjC runtime.
Swift SVN r4149
As Doug points out, we won't regress here. All Objective-C runtimes we care
about are correctly ignoring this bit.
<rdar://problem/13065246>
Swift SVN r4052
Push LLVM attribute generation from expandAbstractCC into getFunctionSignature and CallEmission so that they can generate sret and/or byval attributes per-argument according to the calling convention. Copy our bogus rule for emitting sret returns (more than three elements in the explosion) and reuse it to pass large struct values as byvals rather than as explosions. This should be good enough to get both 'NSRect' and
'NSRange', 'NSSize' etc. to pass correctly to ObjC methods. Next step is to set the AbstractCC correctly for imported func decls so that standalone C functions follow the same bogus rule.
Swift SVN r3993
While we don't have a model for overriding methods in Swift extensions yet,
overriding category methods is exactly like overriding any other Objective-C
method, and we shouldn't disallow it.
Swift SVN r3985
ObjC methods always need to be invoked through objc_msgSend, so they shouldn't have vtable slots, and Swift subclasses that override ObjC methods should always insert override slots into their vtables.
Swift SVN r3889
ObviouslUilabilityMacros.h is not the way to go when we're building against
10.9 SDKs on 10.8 systems. Since this is a temporary hack anyway, just make
it based on the the host syatem ake configuration time, and disable the
failing tests on 10.9.
Swift SVN r3851
The libobjc in current builds can't handle it. <rdar://problem/13046897>
We are going to want this bit set, though, so this hack should be
removed once a new libobjc is available. <rdar://problem/13065246>
Swift SVN r3839
and non-deallocating destructors and allocating/non-allocating
constructors.
Non-deallocating destructors might not play well with ObjC
classes; we might have to limit them to pure-swift hierarchies.
No functionality change except that I decided to not force
destructors to have internal linkage unconditionally.
Swift SVN r3814
The ObjC ABI requires these class fields to be initialized by
resolving symbols from the runtime. So this is a historical
requirement. Note that there is a desire to optimize this
even for ObjC, because in a project with many classes, these
can actually end up representing a significant fraction of
the external non-lazy relocations in the linked image. But
for now we follow the spec, as we must.
The ObjC ABI requires these to be taken from the runtime,
although there is an effort to make them not require external
relocations like this, since in large projects it can actually
add up to a large percentage of the non-lazy external relocs.
3,6d
2i
Swift SVN r3804
Archetypes and projected existentials have the type %swift.opaque* and not i8*, so I need a corresponding SIL type to be able to model the ProjectExistential operation. We might also end up needing the builtin type for other low-level things down the line.
Swift SVN r3793
The test changes are that we're setting a class body on
some types that we weren't before. For some of these,
this is okay; for others, it's more questionable, but
ultimately not *harmful*.
Swift SVN r3746
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
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
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
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
