Resilient classes are not fully implemented yet, and can cause
crashes at runtime; add a flag disabling them until the code is
done, to unblock standard library testing with resilience
enabled.
initialization in-place on demand. Initialize parent metadata
references correctly on struct and enum metadata.
Also includes several minor improvements related to relative
pointers that I was using before deciding to simply switch the
parent reference to an absolute reference to get better access
patterns.
Includes a fix since the earlier commit to make enum metadata
writable if they have an unfilled payload size. This didn't show
up on Darwin because "constant" is currently unenforced there in
global data containing relocations.
This patch requires an associated LLDB change which is being
submitted in parallel.
initialization in-place on demand. Initialize parent metadata
references correctly on struct and enum metadata.
Also includes several minor improvements related to relative
pointers that I was using before deciding to simply switch the
parent reference to an absolute reference to get better access
patterns.
"minimal" is defined as the set of requirements that would be
passed to a function with the type's generic signature that
takes the thick metadata of the parent type as its only argument.
Now that all the machinery is in place, the ClassMetadataBuilder
can (more accurately) query the ClassLayout instead of trying to
re-derive whether the field offset vector is dependent, etc.
Apart from performing dynamic layout for resiliently-sized fields
in concrete classes, this also lets us *skip* dynamic layout
if we have a generic class without any dependent fields.
I haven't tested subclassing with resilient field layout yet, but
getting that working is the next step and should not be too much
work.
Also, swift_initClassMetadata_UniversalStrategy() only stores
the computed field offsets in the field offset globals when the
Objective-C runtime is available, because it gets the offset
pointers from the Objective-C class rodata. On Linux, we will
need to emit code to copy from the field offset vector into
field offset globals in IRGen. This is pretty easy, but I'll do
it in a follow-up patch so for now the new execution test is
XFAIL'd on Linux.
Subclasses of imported Objective-C classes have an unknown size, but
the start of the class's fields in the field offset vector is fixed,
since the field offset vector only contains offsets of Swift stored
properties. So we can always access fields with NonConstantDirect
(for concrete) or ConstantIndirect (for generic types).
On the other hand, generic subclasses of resilient classes must use
the most general NonConstantIndirect access pattern, because we can
add new fields resiliently.
Also, assume NSObject won't change size or grow any new instance
variables, allowing us to use the ConstantDirect access pattern.
getOverriddenVTableEntry only goes one level up in the class hierarchy,
but getConstantOverrideInfo requires that the next level up not itself be an
override.
A little bit of refactoring:
SILDeclRef::getOverriddenVTableEntry()
-> SILDeclRef::getNextOverriddenVTableEntry()
static findOverriddenFunction()
-> SILDeclRef::getBaseOverriddenVTableEntry()
rdar://problem/22749732
Core Data synthesizes Key-Value-Coding-compliant accessors for @NSManaged
properties, but Swift won't allow them to be called without predeclaring
them.
In practice, '@NSManaged' on a method is the same as 'dynamic', except
you /can't/ provide a body and overriding it won't work. This is not the
long-term model we want (see rdar://problem/20829214), but it fixes a
short-term issue with an unfortunate workaround (go through
mutableOrderedSetValueForKey(_:) and similar methods).
rdar://problem/17583057
Swift SVN r30523
correct preconditions for ObjC layout, and write the
computed offsets back to global ivar offset variables
when present.
Swift will use the global variables for accesses to
ivars when it can show that their offsets are
non-dependent.
Fixes a major problem with generic subclasses of ObjC
classes whose dynamic layout does not match the layout
in their @interface.
rdar://19583881
Swift SVN r25536
IRGen miscalculated that the allocating constructor for a required init that overrides a non-required init introduces a new vtable entry; the non-required super allocator is statically dispatched. Fix this and head off further divergences by reusing the logic in the new SILDeclRef::getOverriddenVTableEntry method. Fixes rdar://problem/19514920.
Swift SVN r25068
Stub initializers don't get serialized, so this fixes a vtable layout inconsistency when a method of a subclass of a subclass of NSObject is accessed. Fixes rdar://problem/18498385.
Swift SVN r22480
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
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 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
This switches property/subscript dispatch to use virtual dispatch instead of static
dispatch. This currently only works for computed properties (and subscripts of
course), not stored ones yet.
Long story short, this:
class Base {
subscript() -> Int {
return 42
}
}
class Derived : Base {
@override
subscript() -> Int {
return 9
}
}
var a : Base = Derived()
print(a[])
now prints 9 instead of 42.
Swift SVN r15142
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
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
with two kinds, and some more specific predicates that clients can use.
The notion of 'computed or not' isn't specific enough for how properties
are accessed. We already have problems with ObjC properties that are
stored but usually accessed through getters and setters, and a bool here
isn't helping matters.
NFC.
Swift SVN r12593
Build a nominal type descriptor when we emit the metadata or generic metadata pattern for a nominal type, and put a reference into the formerly null slot in the struct or enum metadata. We need to make a place for them in class metadata; that'll come next.
Swift SVN r9492
In the fill function for a generic subclass metadata pattern, arrange to memcpy the field offset vectors from all of the ancestor classes into the newly-instantiated class metadata, before laying out the subclass's own fields.
Swift SVN r9299
In particular, when a nongeneric class inherits a fragile generic class, we need to populate the field offsets for the instantiated base class because we can't rely on the runtime to populate it for us.
Swift SVN r9258
