[SymbolGraph] add sourceOrigin field for symbols implementing remote protocol requirements #37351
Conversation
…rements rdar://77626724
|
@swift-ci Please smoke test |
|
@swift-ci Please build toolchain macOS platform |
|
macOS Toolchain Install command |
| func otherFunc() | ||
|
|
||
| func bonusFunc() | ||
| } |
There was a problem hiding this comment.
Should we also test public default implementations of the protocol or is that not relevant?
e.g.,
public extension P {
/// This one also has docs!
func someFunc()
}and assert that "This one also has docs!" doesn't get inherited. I'm not sure about this one because I think the extension someFunc() gets a separate USR than S's someFunc().
There was a problem hiding this comment.
Default implementations coming from an extension are tested as part of the existing inherited docs test, though not for protocols in a different module... 🤔
But i'm not sure i understand the situation you're asking about. Can you write an extension like that without an implementation? What happens with someFunc in that situation?
There was a problem hiding this comment.
Sorry, I meant
public extension P {
/// This one also has docs!
func someFunc() {}
}
There was a problem hiding this comment.
Ah, that makes more sense. I've added a couple more situations to the test.
|
@swift-ci Please smoke test |
Resolves rdar://77626724
Currently, the symbol graph has no way to relate symbols that implement protocol requirements from another module to that remote protocol. This causes situations where "inherited docs" appear on these locally-defined symbols.
This PR adds a
sourceOriginfield to these symbols, relating them to their upstream protocol.