ClassLayoutBuilder computes a bunch of stuff in addition to the
StructLayout, which is then stashed in ClassTypeInfo. Extract this
into a new ClassLayout type. It probably should not exist at all,
if we only generalized StructLayout a bit.
of associated types in protocol witness tables.
We use the global access functions when the result isn't
dependent, and a simple accessor when the result can be cheaply
recovered from the conforming metadata. Otherwise, we add a
cache slot to a private section of the witness table, forcing
an instantiation per conformance. Like generic type metadata,
concrete instantiations of generic conformances are memoized.
There's a fair amount of code in this patch that can't be
dynamically tested at the moment because of the widespread
reliance on recursive expansion of archetypes / dependent
types. That's something we're now theoretically in a position
to change, and as we do so, we'll test more of this code.
Now, such classes will emit a metadata pattern and use the
generic metadata instantiation logic.
This was all wired up to handle the case of no generic
parameters previously, to support resilient struct layout
in the runtime.
The swift_initializeSuperclass() entry point still exists,
providing a fast path for when there's no field layout to
do, which is currently always true if we have a concrete
class.
This entry point no longer needs the global lock, since
now we get a per-class lock from the metadata cache.
Also, previously we would call the superclass accessor
function on every access of class metadata for a concrete
subclass of a generic class. Now that we re-use the
existing metadata cache logic, this extra call only occurs
during initialization.
Both swift_initializeSuperclass() and
swift_initClassMetadata_UniversalStrategy() used to take
the superclass as a parameter, but this isn't really
necessary, since it was loaded out of the class metadata
immediately prior to the call by the caller. Removing
this parameter makes the ABI a little simpler.
Once class layout supports resilient types, we will also
use swift_initClassMetadata_UniversalStrategy() to lay
out classes with resilient types as fields.
Singleton metadata caches will still allocate a copy of
the template, which is a slight performance regression
from the previous implementation of concrete subclasses
of generic classes. This will be optimized soon.
Right now, the template can always be modified in place;
in the future, it will be possible to modify in place as
long as the superclass is fixed-layout; a resilient superclass
might add or remove fields, thus we cannot leave room for
it in the metadata of the subclass, and will need to grow
the metadata and slide field offsets at runtime using a
new entry point.
Also, the representation of the cache itself could be
optimized to handle the singleton case, since all we
really need here is a lock without any kind of mapping
table.
Move the following from IRGen to runtime:
- Copying generic parameters from superclass to subclass
- Copying field offsets from superclass to subclass
- Initializing the Objective-C runtime name of the subclass
This eliminates some duplication between the generic subclass and
concrete subclass of a generic class cases.
Also this should reduce generated code size and have no impact on
performance (the instantiation logic only runs once per substituted
type).
class B<T> : NSFoo {}
class A : B<Int> {}
IRGen computes the ivar layout starting from offset zero, since
the size of the 'NSFoo' is unknown and we rely on the Objective-C
runtime to slide the ivar offsets.
The instantiated metadata for B<Int> would contain a field offset
vector with the correct offsets, because of how
swift_initClassMetadata_UniversalStrategy() works.
However, A's metadata is emitted statically, and this includes a
copy of the field offset vector from the superclass. A's metadata
was initialized by swift_initializeSuperclass(), which did not
copy the field offset vector over from A<Int>. And since the
Objective-C runtime only slides the immediate ivars of a class,
the field offsets corresponding to A<Int>'s fields in B's type
metadata were never slid, resulting in problems when an instance
of B was passed to a function operating on an A<T> generically.
Fixes <rdar://problem/23200051>.
If an enum is fixed-layout in our resilience domain but not
universally fixed-layout, other resilience domains will use
runtime functions to project and inject payloads.
These expect to find the payload size in the metadata, so
emit it if the enum is not universally fixed-layout.
Note that we do know the payload size, so it is constant
for us; there's no runtime call required to initialize
the metadata.
We've already got -enable-resilience and @_fixed_layout to compare
IRGen differences when lowering super_method instructions, so nuke
the -force-resilient-super-dispatch testing flag. While
we're at it, consolidate the super tests a bit.
We only need to indirectly load the superclass's metadata when the
superclass is resilient. For example, we may be calling a super method
inside an extension of a class we don't own. Otherwise, we can
immediately load the statically known superclass.
Adds a testing flag to force resilient super dispatch, since the
IRGen module resilience checks aren't fully implemented yet.
SIL -> IR tests added.
rdar://problem/22749732
Also fixes rdar://problem/23884670
Decrease the size of nominal type descriptors and make them true-const by relative-addressing the other metadata they need to reference, which should all be included in the same image as the descriptor itself. Relative-referencing string constants exposes a bug in the Apple linker, which crashes when resolving relative relocations to coalesceable symbols (rdar://problem/22674524); work around this for now by revoking the `unnamed_addr`-ness of string constants that we take relative references to. (I haven't tested whether GNU ld or gold also have this problem on Linux; it may be possible to conditionalize the workaround to only apply to Darwin targets for now.)
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
Reuses the enum metadata layout and builder because most of the logic is
also required for Optional (generic arg and payload). We may want to
optimize this at some point (Optional doesn't have a Parent), but I
don't see much opportunity.
Note that with this approach there will be no change in metadata layout.
Changing the kind still breaks the ABI of course.
Also leaves the MirrorData summary string as "(Enum Value)". We should
consider changing it.
After talking with @jckarter and @slavapestov we decided that getting
the superclass at runtime for super_method lookup was the right approach
if its based in the static base class and the lookup doesn't start with
the instance pointer.
NFC for current IRGen - SILGen doesn't lead to here yet.
rdar://problem/22749732
Following the self instance pointer to its class metadata isn't sound
for chained super calls since it means the same metadata is pulled,
resulting infinite recursion.
NFC for actual IRGen. SILGen isn't using super_method for native
dispatch yet.
rdar://problem/22749732
This is the first part of making class method dispatch resilient.
If we have the following class hierarchy:
// Module A
class Parent {
func foo() {}
}
class Child : Parent {}
// Module B
class Grandchild : Child {
override func foo() {
super.foo()
}
}
dispatch to `Parent.foo` will be static via a `function_ref`, so if
someone adds a `foo()` to `Child` later on, `Grandchild` won't know
about it without recompiling.
Stage in the IRGen portion of dynamic dispatch when calling methods on
`super`:
- Don't assert in IRGen if we see a native super_method instruction.
- Perform virtual lookup on superclass's metadata. If we see a
`super_method` instruction for a native class:
- Get the address of the superclass's metadata at offset 1
- Load the superclass's metadata
- Perform virtual lookup on this metadata instead
TODO: SILGen super_method instructions for native classes.
TODO: Devirtualize back down to static dispatch with a reslience lookup
mechanism.
rdar://problem/22749732
This reverts commit d326c8e5f7.
We believe the failure now may be in the setup of the test harness.
Re-applying this change, since the tests passed in our other
configurations.
Let's say that A and B defined in modules X and Y respectively.
This patch adds support for these two cases:
1) Fixed-layout struct A contains resilient struct B
2) Resilient struct A contains resilient struct B
In both cases:
a) Metadata access requires an accessor call
b) Fields of A do not have constant offsets, instead the offsets
must be loaded from type metadata
A future patch will switch over to initializing the template in-place,
instead of heap-allocating a copy.
The predicate for evaluating if a nominal type has constant metadata was
repeated in a few places, factor it out. Also, the generic signature was
passed down to GenericMetadataBuilderBase, but its not actually used there,
so remove it.
If a struct has fixed layout but contains fields which are opaque,
or if the struct itself is opaque, use a metadata accessor function
instead of loading the metadata directly.
Let's say that A and B are two structs defined in the same module,
and B has a fixed size. This patch adds support for these two cases:
1) Fixed-layout struct A contains resilient struct B
2) Resilient struct A contains resilient struct B
In case 1),
a) Inside X: A is fixed-size and has constant metadata
i) Direct metadata access can be performed on A and B
ii) Direct field access can be performed on A and B
d) Outside X: B has an opaque layout
i) Metadata accessor must be called for A and B
ii) Fields of A do not have constant offsets, instead the offsets
must be loaded from type metadata
Case 2) is the same as above except ii) does not apply, since fields
of resilient structs are manipulated via accessors.
Eventually, we will use metadata accessor functions for all public
struct and enum types.
The swift_unknown* entry points are not available on the Linux port.
Previously we would still attempt to use them in a couple of cases:
1) Foreign classes
2) Existentials and archetypes
3) Optionals of boxed existentials
Note that this patch changes IRGen to never emit the
swift_errorRelease/Retain entry points on Linux. We would like to
use them in the future if we ever adopt a tagged-pointer representation
for small errors. In this case, they can be brought back, and the
TypeInfo for optionals will need to be generalized to propagate the
reference counting of the payload type, instead of defaulting to
unknown if the payload type is not natively reference counted.
A similar change will need to be made to support blocks, if we ever
want to use the blocks runtime on Linux.
Fixes <rdar://problem/23335318>, <rdar://problem/23335537>,
<rdar://problem/23335453>.
This avoids us using reserved identifiers as the enum case names of all
our underscored protocols like _ObjectiveCBridgeable. I used the
convention PROTOCOL_WITH_NAME to mirror how the known identifiers work.
Swift SVN r32924
prologue is handled in the line table.
We now mark the first instruction after the stack setup as end_prologue and
any further initilizations (which may include function calls to metadata
accessors) with line 0 which lldb will skip. This allows swiftc to emit
debug info for compiler-generated functions such as metadata accessors.
Mixing debug and non-debug functions is not very well supported by LLVM
and the resulting line table makes it impossible for LLDB to determine
where a function with debug info ends and a nondebug function starts.
rdar://problem/23042642
Swift SVN r32816
