[ModuleInterface] Allow conformances to be missing value witnesses #18932
Conversation
It's not clear whether we'll actually need this feature in the long run, but we certainly need it now because non-@usableFromInline members can (currently) satisfy public requirements when a @usableFromInline internal type conforms to a public protocol. In these cases, we'll treat the witnesses as present but opaque, and clients will perform dynamic dispatch when using them even when a generic function gets specialized. With this, we're able to generate a textual interface for the standard library, compile it back to a swiftmodule, and use it to build a Hello World program!
|
@swift-ci Please test |
| // FIXME: ...but we should do something better about types. | ||
| if (conformance && !conformance->isInvalid()) { | ||
| if (auto *SF = DC->getParentSourceFile()) { | ||
| if (SF->Kind == SourceFileKind::Interface) { |
There was a problem hiding this comment.
I’ve noticed your patches often switch over the kind or check for an interface file - maybe a convenience predicate would be handy?
There was a problem hiding this comment.
Doug mentioned this too in #18778, but I'm not sure the rules are consistent enough to be worth it. Sometimes the special case is just for interface files; sometimes it's interfaces or SIL; sometimes it's interface, SIL, or library (i.e. not script mode).
| @@ -1060,6 +1060,23 @@ bool WitnessChecker::findBestWitness( | |||
| } | |||
|
|
|||
| if (numViable == 0) { | |||
| // Assume any missing value witnesses for a conformance in a textual | |||
| // interface can be treated as opaque. | |||
| // FIXME: ...but we should do something better about types. | |||
There was a problem hiding this comment.
If we don’t expect to generate textual interfaces for Swift 4 modules, we can make it an error in Swift 5 mode.
There was a problem hiding this comment.
We may still want to to help with incremental builds, but yes.
|
Great to hear the stdlib round-trips now! How big is the file? You’re not printing bodies of inlinable functions yet either are you? |
|
Yeah, that's completely without inlinable functions. The textual file is 652KB / 12028 lines; the reconstituted binary is 4.3MB (compared to the original Swift.swiftmodule at 20MB). I'm a little curious what's taking so much space now. |
|
As for private members of structs, at least for resilient libraries we have a restriction that all types involved must be public or |
|
@jrose-apple I wasn't aware we were planning on enforcing that restriction. If we do though, it would mean that @fixedContents has a semantic effect on the language even with resilience off. Also I was under the impression we wanted to be able to generate textual interfaces for non-resilient libraries too, but maybe not. |
That's only if we force the restriction when resilience is off.
I think we do too (third-party binary frameworks), but it's definitely trickier, because we have to support non-resilient layout for everything while not adding any extra language restrictions. (Or we have to add those restrictions.) |
It's not clear whether we'll actually need this feature in the long run, but we certainly need it now because non-
@usableFromInlinemembers can (currently) satisfy public requirements when a@usableFromInlineinternal type conforms to a public protocol. In these cases, we'll treat the witnesses as present but opaque, and clients will perform dynamic dispatch when using them even when a generic function gets specialized.With this, we're able to generate a textual interface for the standard library, compile it back to a swiftmodule, and use it to build a Hello World program!