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
- GenProto.cpp for protocols and protocol conformances
- GenExistential.cpp for existential type layout and operations
- GenArchetype.cpp for archetype type layout and operations
Swift SVN r32493
NFC, but this set of access modes applies more generally to other kinds of metadata that may need to be guarded by accessors, such as witness tables.
Swift SVN r31838
By using relative references, either directly to symbols internal to the current TU, or to the GOT entry for external symbols, we avoid unnecessary runtime relocations, and we save space on 64-bit platforms, since a single image is still <2GB in size. For the 64-bit standard library, this trades 26KB of fake-const data in __DATA,__swift1_proto for 13KB of true-const data in __TEXT,__swift2_proto. Implements rdar://problem/22334380.
Swift SVN r31555
This is more resilient, since we want to be able to add more information behind the address point of type objects. The start of the metadata object is now an internal "full metadata" symbol.
Note that we can't do this for known opaque metadata from the C++ runtime, since clang doesn't have a good way to emit offset symbol aliases, so for non-nominal metadata objects we still emit an adjustment inline. We also aren't able to generate references to aliases within the same module due to an MC bug with alias refs on i386 and armv7 (rdar://problem/22450593).
Swift SVN r31523
This is more resilient, since we want to be able to add more information behind the address point of type objects, and also makes IR a lot less cluttered. The start of the metadata object is now an internal "full metadata" symbol.
Note that we can't do this for known opaque metadata from the C++ runtime, since clang doesn't have a good way to emit offset symbol aliases, so for non-nominal metadata objects we still emit an adjustment inline.
Swift SVN r31515
Generic subclasses of @objc classes are thus no longer @objc, but still
have implicitly @objc members.
Explicit @objc on generic classes or classes that inherit from @objc
classes is now forbidden with a diagnostic. Users need to know that
while they can override Objective-C methods and properties in such
a class, they cannot refer to the class by name from Objective-C code,
since it will not appear in the bridging header.
Fixes <rdar://problem/21342574>.
Swift SVN r30494
If we have an unowned/weak protocol type with witness tables, we can't use the prefab NativeObject/UnknownObject layouts. While we're here, fix up some tests for 32-bit portability too.
Swift SVN r30270
Full type metadata isn't necessary to calculate the runtime layout of a dependent struct or enum; we only need the non-function data from the value witness table (size, alignment, extra inhabitant count, and POD/BT/etc. flags). This can be generated more efficiently than the type metadata for many types--if we know a specific instantiation is fixed-layout, we can regenerate the layout information, or if we know the type has the same layout as another well-known type, we can get the layout from a common value witness table. This breaks a deadlock in most (but not all) cases where a value type is recursive using classes or fixed-layout indirected structs like UnsafePointer. rdar://problem/19898165
This time, factor out the ObjC-dependent parts of the tests so they only run with ObjC interop.
Swift SVN r30266
