Revert public fragile hack #2857
Conversation
|
@swift-ci Please test |
1 similar comment
|
@swift-ci Please test |
|
@eeckstein This is the revert that should fix the stdlib size regression in 3.0 |
|
Thanks! |
…nitializers If the base class is in a different module and defines an internal initializer, or it is in a different file and defines a private initializer, the subclass cannot access this initializer. Fix this by insisting on synthesizing initializers even if they override an internal or private initializer in the base class. In this case, synthesize them as a stub instead of a chaining initializer. They cannot be called, and they cannot reference the superclass initializer, so a stub is appropriate here. Also in SILGen, emit vtable entries for stub initializers unless they are overriding an Objective-C initializer.
…ity" This reverts commit 8e43990. See the discussion here for details: <swiftlang@6723560>
…ialize-all is on" This reverts commit 9a7a517. See the discussion here for details: <swiftlang@6723560>
slavapestov
force-pushed
the
revert-public-fragile-hack
branch
from
e42e287 to
6b92d95
Compare
|
@swift-ci Please test |
|
@jrose-apple Do you mind looking this over whenever you have a spare minute? (It's not for 3.0) |
|
@swift-ci Please test |
|
Hm. I really don't like the existence of the stub constructors. Can't we just take non-required constructors out of the vtable? |
|
Well, we have to emit something in place of the vtable entry. |
|
@swift-ci Please test |
|
I don't understand why there's a vtable entry at all. If it's not a |
|
Ah, good point. I need to see what IRGen does here (SIL's sil_vtable is actually a superset of what actually gets emitted in IRGen, which does its own walk of decls/methods). I have another patch that adds better tests in this area, I'll dig into the vtable code then too. |
No description provided.