[Swift Export] KT-87947: Enable inheritance from abstract bases. - #7113
[Swift Export] KT-87947: Enable inheritance from abstract bases.#7113glukianets wants to merge 1 commit into
Conversation
Expose abstract base class constructors in swift. Ignore calls to abstract class constructors in FIR for exported bridges KT-86403: allocate kotlin counterpart objects for swift inheritance with the right TypeInfo from the start.
Code Owners
PR commands for maintainers
|
| return expression | ||
| } | ||
|
|
||
| return IrDelegatingConstructorCallImpl( |
There was a problem hiding this comment.
I feel like there should be tests for this PR?
There was a problem hiding this comment.
Sorry, I'm not really familiar with this codebase. Do I understand correctly, that we have moved this lovering to the first phase of the compiler? Does that mean, that for an abstract class to work in swift export - it declaration should be compiled to klib with a certain compiler?
If so - that would render all our 3rd party libraries that relies on abstract classes unusable with swift export, until theirs kills are republished with 2.5.0 compiler. Correct?
There was a problem hiding this comment.
Yes to all.
The specific reason for this is that we have partial linkage check that locates every call to an abstract class constructor and replaces it with an error-node. This check was particularly hard to isolate and disable specifically for swift export. So instead I use an early phase to re-write our super calls to IrDelegatingConstructorCall - which PL accepts fine.
There was a problem hiding this comment.
Is it possible to provide a human readable explanation as a reason to a failed build, when this is the case? Should we do that?
| // Leave the second argument of [initInstance] as is. | ||
| super.visitConstructorCall(constructorCall) | ||
| // Leave the second argument of [initInstance] as is, but coerce its arguments. | ||
| super.visitFunctionAccess(constructorCall) |
There was a problem hiding this comment.
Shouldn't we preserve visitConstructorCall for the IrConstructorCall?
| @@ -91,12 +90,7 @@ public class SirVisibilityCheckerImpl( | |||
| } else return@withSessions exported | |||
| } | |||
| is KaConstructorSymbol -> { | |||
| if ((ktSymbol.containingSymbol as? KaClassSymbol)?.modality?.isAbstract() != false) { | |||
There was a problem hiding this comment.
I bet that now you can instantiate a swift inheritor of a sealed base class, like so
// kt
sealed class A
class B: A()
// swift
class C: A {}
let c: A = C()
2 participants
Expose abstract base class constructors in swift.
Ignore calls to abstract class constructors in FIR for exported bridges
KT-86403: allocate kotlin counterpart objects for swift inheritance with the right TypeInfo from the start.