a flags field, add an instance address point field, and reserve
some additional space.
This change must be coordinated with a corresponding change
to ObjC runtime bits in libarclite; without this, dynamic
subclassing features like KVO will break.
The actual contents of the new fields can change without
bothering the ObjC runtime.
Swift SVN r20183
lldb needs this to be able to tell how many generic parameters are actually needed to instantiate a generic type. Fixes <rdar://problem/17425286>.
Swift SVN r19573
r210062 they can point at arbitrary ConstantExprs again, and as of
r210734 our use of this can actually pass the IR verifier again.
Patch by Justin Bogner.
Swift SVN r18834
Blocks need their own type metadata with value witnesses appropriate to the block representation. Fixes <rdar://problem/16918740> and <rdar://problem/16981126>.
Swift SVN r18508
At long last, our generic classes are legal ObjC citizens. Note that you'll need to be either on OSX 10.10, or on OSX 10.9 with a recent enough Xcode 6.0 to have a not-broken arclite (6A207 worksforme) and building against a OSX 10.10 SDK, for this to work going forward.
Swift SVN r17916
If we officially register our classes with the ObjC runtime, we can't get away with generic class instances sharing a runtime name or a metaclass anymore, so pack the metaclass and rodata templates into the generic metadata template and add codegen to the fill function to wire up the references at instantiation time. Since we don't have a runtime mangler yet, create a stupid unique name for classes by tacking on the pointer value.
Swift SVN r17882
This basically just means "it's a CF class" for now,
but you could imagine applying this to all sorts of
class-like types from peer runtimes that we can't
support all possible language features for.
There are quite a few language features that require
fairly deep object-model integration to implement,
like subclassing and adding polymorphic methods.
Some of those features, like final classes, are useful
to generally support as attributes, but most of
them aren't. At least in the short term, it makes
sense to have a big hammer we can hit things with.
Swift SVN r17428
I've put these fields on the class object for now, just
so we can at least theoretically update them. A superclass
that grew left rather than right could maybe even be made
to work with this schema, but probably not.
rdar://16705821
Swift SVN r16880
We really don't need to support individual objects
this large, much less more than 4 billion fields in
a single type.
Also rearrange the fields to bring the instance
size/alignment fields closer to the class header,
just for a minor locality win.
Swift SVN r16879
We can't know whether a mixed-heritage class has a non-pointer isa, so use object_getClass to get its isa pointer. Fixes <rdar://problem/16656489>.
Swift SVN r16549
Blocks need to be born on the stack, so we need a way to represent that on-stack storage. @block_storage T will represent the layout of a block that contains storage for a capture of type T.
Swift SVN r16355
We should never actually try to emit metadata for dependent types, lvalues, inouts, or SIL function types; these cases indicate upstream bugs in Sema or SILGen.
Swift SVN r16058
ObjC protocol descriptors are uniqued by the ObjC runtime and lazily emitted by Clang, so we shouldn't burn time eagerly emitting descriptors for every protocol in the universe. Addresses some of the performance issue in <rdar://problem/16520314>.
Swift SVN r15924
Create a global alias into the metadata of @objc-visible classes at their address point, which should make these classes visible for linking from ObjC, fixing <rdar://problem/14449644>.
Swift SVN r15921
Language features like erasing concrete metatype
values are also left for the future. Still, baby steps.
The singleton ordinary metatype for existential types
is still potentially useful; we allow it to be written
as P.Protocol.
I've been somewhat cavalier in making code accept
AnyMetatypeType instead of a more specific type, and
it's likely that a number of these places can and
should be more restrictive.
When T is an existential type, parse T.Type as an
ExistentialMetatypeType instead of a MetatypeType.
An existential metatype is the formal type
\exists t:P . (t.Type)
whereas the ordinary metatype is the formal type
(\exists t:P . t).Type
which is singleton. Our inability to express that
difference was leading to an ever-increasing cascade
of hacks where information is shadily passed behind
the scenes in order to make various operations with
static members of protocols work correctly.
This patch takes the first step towards fixing that
by splitting out existential metatypes and giving
them a pointer representation. Eventually, we will
need them to be able to carry protocol witness tables
Swift SVN r15716
Eventually, SILGen will need to do something like this, and it
should go in the sil_vtable, and we should base the IR vtable
on that information. For now, emitting multiple entries with
the same pointer in each is just bogus.
Swift SVN r15533
As part of the nominal type descriptor for a struct or class, build a function that lazily generates the vector of type metadata for the fields of the nominal type given an instantiation of the type's metadata. To cache this for nongeneric types, produce a global variable we can stash the result in, or for generic types, reserve some space in the metadata template so that generic metadata instantiation naturally provides a space for every instance of the type.
Reapplying now that the missing Float80 builtin metadata is available.
Swift SVN r15260
As part of the nominal type descriptor for a struct or class, build a function that lazily generates the vector of type metadata for the fields of the nominal type given an instantiation of the type's metadata. To cache this for nongeneric types, produce a global variable we can stash the result in, or for generic types, reserve some space in the metadata template so that generic metadata instantiation naturally provides a space for every instance of the type.
Swift SVN r15256
We need them for reflection, and we always emit them for structs, so for consistency, always emitting them for classes isn't the worst thing.
Swift SVN r15214
Building the field type vector is potentially expensive and the vector isn't needed unless we do reflectiony things to a type, so let's use a lazy accessor. Make room for it, but don't populate it yet, so we can deal with fallout from the metadata layout change.
Swift SVN r15194
accessors.
Optimize these accessors by making them check for
BoundGenericXType instead of BoundGenericType and dyn_cast'ing
the Decl. (The latter used to be necessary before we split
BoundGenericType.)
Swift SVN r15037
LLVM doesn't have interior symbols as a first-class concept, so generate module inline asm that defines the OBJC_CLASS symbol relative to the Swift metadata symbol. To prevent our system linkers from considering this symbol as the start of a new object and breaking apart class metadata objects, put the class metadata object into a no_dead_strip section.
This isn't quite enough to get the OBJC_CLASS symbol to be available--the symbol appears to show up in the .o as an undefined symbol and stripped out of the .dylib. John is investigating with the backend and linker teams as to why this is the case.
Swift SVN r14927
Inherited initializers are now functional: one can use an inherited
initializer to construct an object of a subclass type, and we properly
handle delegation to overridden complete object or subobject
initializers as appropriate. See the executable test.
This commit also contains various fixes for the IRGen side of vtable
emission and use. Proper IRGen tests still to come.
For now, we're still performing peer delegation from a subobject
initializer to another subobject initializer, hence the SILGen hack
for identifying when we're in a complete object vs. a subobject
initializer. We'll be banning delegation from subobject initializers,
so this hack---along with the peer_method instruction---will be going
away in the near future.
Swift SVN r14571
We should also remove it from IRGen's Explosion API; IRGen
should always use maximal explosion, and SILGen will tell us
whether or not we need to put that in memory somewhere.
But that can be a later commit.
Swift SVN r14242
Emit vtable entries for abstract initializers. When we're constructing
an object using an abstract initializer based on a metatype value that
is not statically derivable, use the vtable entry to call the
subclass's allocating constructor.
Most of the IRGen work here is hacking around the lossy SILDeclRef ->
(Code|Function)Ref -> SILDeclRef conversion. I'd feel bad about this
if John hadn't already agreed to clean this up at some point.
Swift SVN r14238
Make IRGen just a little bit dumber: rather than inferring whether we
need the Swift or Objective-C metatype based on the uses of that
metatype, produce the metadata in the representation requested by the
'metatype' or 'class_metatype' instruction. SILGen will eventually
need to get smarter about asking for the representation it wants.
Swift SVN r14117
