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
In particular, fix a bug where DREs that refer to types were
always given trivial reps because we were trying to emit the
metatype's metatype. This in turn exposes a number of bugs,
including a typechecker bug (where GetMetatypeExpr bases
weren't converted to r-values) and a bug where MREs that
refer to types were always assumed to produce trivial reps.
Swift SVN r3095
Introduce a '.metatype' form in the syntax and do some basic
type-checking that I probably haven't done right. Change
IR-generation for that and GetMetatypeExpr to use code that
actually honors the dynamic type of an expression.
Swift SVN r3053
to avoid some obvious redundancies. This also gives us a
more general framework with which to exploit other ways
in which metadata is known.
Swift SVN r3047
dispatch. Currently there is no possibility of override.
This was really not as difficult as I managed to make it
the first time through.
Swift SVN r2960
of a class is part of the class members section and is not
global to the entire class metadata. This is crucial for
correct operation of functions expecting a base-class
metadata object.
That gives us the correct foundation to implement an
optimization under which generic arguments that can be
inferred from the 'this' pointer need not actually be
separately passed. This has the important result of
making all class member functions with the same signature
up to abstraction actually have the same physical
signature.
Swift SVN r2936
towards optimizing generic calls to derive things from the
'this' pointer, which is actually crucial for virtual
dispatch (to get all methods to agree about how the
implicit arguments are passed). Fix a number of assorted
bugs in metadata emission. Lots of assorted enhancements.
This was proving surprisingly difficult to actually tease
apart into smaller patches.
Swift SVN r2927
uncurrying level, which is something I find myself passing around
quite a bit. Make sure that it can propagate getter/setter
references in the same way.
Swift SVN r2902
the metadata objects for classes. This is currently only
done for methods defined in the main class body, and it's
(naturally) totally fragile, and it's screwed up in a
couple known ways w.r.t. generic classes: there's no
thunking when the overrider differs by abstraction from
the overridden method, and methods on classes currently
expect to get all the type arguments passed directly
and thus will disagree in signature from members of
non-generic classes. Also, of course, we're not using
any of this in the call infrastructure. But it's progress.
Swift SVN r2901
