[Serialization] Store whether an override depends on its base for ABI

[jrose-apple]

In some circumstances, a Swift declaration in module A will depend on another declaration (usually from Objective-C) that can't be loaded, for whatever reason. If the Swift declaration is overriding the missing declaration, this can present a problem, because the way methods are dispatched in Swift can depend on knowing the original class was that introduced the method. However, if the compiler can prove that the override can still be safely invoked/used in all cases, it doesn't need to worry about the overridden declaration being missing.

This is especially relevant for property accessors, because there's currently no logic to recover from a property being successfully deserialized and then finding out that an accessor couldn't be.

The decision of whether or not an override can be safely invoked without knowledge of the base method is something to be cautious about—a mistaken analysis would effectively be a miscompile. So up until now, this was limited to one case: when a method is known to be @objc dynamic, i.e. always dispatched through objc_msgSend. (Even this may become questionable if we have first-class method references, like we do for key paths.) This worked particularly well because the compiler infers dynamic for any overload of an imported Objective-C method or accessor, in case it imports differently in a different -swift-version and a client ends up subclassing it.

However...that inference does not apply if the class is final, because then there are no subclasses to worry about.

This commit changes the test to be more careful: if the missing declaration was @objc dynamic, we know that it can't affect ABI, because either the override is properly @objc dynamic as well, or the override has introduced its own calling ABI (in practice, a direct call for final methods) that doesn't depend on the superclass. Again, this isn't 100% correct in the presence of first-class methods, but it does fix the issue in practice where a property accessor in a parent class goes missing. And since Objective-C allows adding property setters separately from the original property declaration, that's something that can happen even under normal circumstances. Sadly.

This approach could probably be extended to constructors as well. I'm a little more cautious about throwing vars and subscripts into the mix because of the presence of key paths, which do allow identity-based comparison of overrides and bases.

rdar://problem/56388950

[jrose-apple]

@swift-ci Please test

[jrose-apple]

@swift-ci Please test source compatibility

[varungandhi-apple]

Don't have time to review this right away but there's a typo in the commit message:

on knowing the original class was that introduced the method.

---

Again, this isn't 100% correct in the presence of first-class methods, but it does fix the issue in practice where a property accessor in a parent class goes missing

My understanding around keypaths is a bit fuzzy, but doesn't the fact that you can use keypaths to access properties (correct?), and that properties can be overriden mean that you kinda' have first-class methods for some limited types (T) -> Void and () -> T?

And since Objective-C allows adding property setters separately from the original property declaration

screaming

[jckarter]

Makes sense to me.

[jrose-apple]

My understanding around keypaths is a bit fuzzy, but doesn't the fact that you can use keypaths to access properties (correct?), and that properties can be overriden mean that you kinda' have first-class methods for some limited types (T) -> Void and () -> T?

That's sorta the point: I'm nervous about applying the same logic to VarDecls because they can be referenced in ways that require an additional symbol at runtime besides their accessors.

[jrose-apple]

Fixed commit message typo.

@swift-ci Please smoke test

[jrose-apple]

@swift-ci Please smoke test

[jrose-apple]

@swift-ci Please smoke test Linux

[jckarter]

That's sorta the point: I'm nervous about applying the same logic to VarDecls because they can be referenced in ways that require an additional symbol at runtime besides their accessors.

Well, the goal of the key path property descriptor is to abstract the details of the property implementation from other modules. The only thing that should affect the descriptor's ABI is the type of the property.

[jrose-apple]

Well, the goal of the key path property descriptor is to abstract the details of the property implementation from other modules. The only thing that should affect the descriptor's ABI is the type of the property.

Ah, do \Sub.foo and \Base.foo have different symbols? That would make me feel better about a future expansion to VarDecl as well.