`@differentiable` attribute on protocol requirements and non-final class
members now produces derivative function entries in witness tables and vtables.
This enables `witness_method` and `class_method` differentiation.
Existing type-checking rules:
- Witness declarations of `@differentiable` protocol requirements must have a
`@differentiable` attribute with the same configuration (or a configuration
with superset parameter indices).
- Witness table derivative function entries are SILGen'd for `@differentiable`
witness declarations.
- Class vtable derivative function entries are SILGen'd for non-final
`@differentiable` class members.
- These derivative entries can be overridden or inherited, just like other
vtable entries.
Resolves TF-1212.
If an override B.f() is more visible than a base method A.f(), it is
possible that an override C.f() of B.f() cannot see the original method
A.f().
In this case, we would encounter linker errors if we referenced the
method descriptor or method dispatch thunk for A.f().
Make this work by treating B.f() as the least derived method in this
case, and ensuring that the vtable thunk for B.f() dispatches through
the vtable again.
Fixes <rdar://problem/48330571>, <https://bugs.swift.org/browse/SR-10648>.
They should never be dynamically dispatched (unless `required`), so this entry should never be used.
We were accidentally dynamically dispatching to them in convenience-to-convenience `self.init`
delegations; fix that.
Some changes I was working on uncovered a latent bug where we would
emit a class_method instruction to call an allocating initializer
that did not have a vtable entry.
Previously this wasn't caught because the only example of this in
our test suite was in test/SILGen/objc_bridging_any.swift, which
did not test with IRGen; if it did, an IRGen crash would have been
observed.
Factor out some code duplication to prevent this from happening
again, and add a SILGen test that we emit a vtable entry in this
case, and that the test case passes IRGen also.
This lets us serialize that decision, which means we can conceivably
/change/ the decision in later versions of the compiler without
breaking existing code. More immediately, it's groundwork that will
eventually allow us to drop decls from the AST without affecting
vtable layout.
This isn't actually a great answer; what we really want is for SIL
vtables to be serialized consistently and treated as the point of
truth. But that would be more change than we're comfortable taking in
the Swift 4 timeframe.
First part of rdar://problem/31878396.
This replaces SILDeclRef::getBaseOverriddenVTableEntry(). It lives
in the TypeConverter because it needs to use type lowering information
to determine if the method requires a new vtable entry or not.
In the old vtable emission code, IRGen would skip addressors,
but they had entries in the SILVTable. This is still correct
behavior, so skip addressors explicitly in SILVTableVisitor.
We never call addressors dynamically, only inside a getter,
setter or materializeForSet. When a property with addressors
is overridden we provide new getters and setters (which may
or may not statically dispatch to a peer addressor).
This is a CRTP utility to walk the members of a class and
produce vtable entries. It will be used to clean up some
code duplication between SILGen and IRGen, and to provide
missing functionality for multiple vtable entries per
method.
