-
Notifications
You must be signed in to change notification settings - Fork 318
Fetch full documentation in code completion #2207
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from 3 commits
24de753
283e08c
fce98d5
ae3f00e
2b40e78
db44320
3c66365
4df7ea1
ed77735
4f8d69e
d3ed8b1
9d56a93
2f77852
c0b4ca2
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -574,13 +574,23 @@ class CodeCompletionSession { | |
fileContents: nil | ||
) | ||
} | ||
if let docString: String = documentationResponse?[sourcekitd.keys.docBrief] { | ||
|
||
if let response = documentationResponse, | ||
let docString = documentationString(from: response, sourcekitd: sourcekitd) { | ||
item.documentation = .markupContent(MarkupContent(kind: .markdown, value: docString)) | ||
} | ||
} | ||
return item | ||
} | ||
|
||
private static func documentationString(from response: SKDResponseDictionary, sourcekitd: SourceKitD) -> String? { | ||
if let docFullAsXML: String = response[sourcekitd.keys.docFullAsXML] { | ||
return try? xmlDocumentationToMarkdown(docFullAsXML) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Sorry, I should have noticed this before: We generally prefer to use There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Done ✅ |
||
} | ||
|
||
return response[sourcekitd.keys.docBrief] | ||
} | ||
|
||
private func computeCompletionTextEdit( | ||
completionPos: Position, | ||
requestPosition: Position, | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -241,6 +241,17 @@ struct ExtendedCompletionInfo { | |
return result | ||
} | ||
|
||
var fullDocumentation: String? { | ||
var result: String? = nil | ||
session.sourcekitd.ideApi.completion_item_get_doc_full_copy(session.response, rawItem) { | ||
if let cstr = $0 { | ||
result = String(cString: cstr) | ||
free(cstr) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Do we need to free the pointer here? I would assume that the memory is still owned by sourcedkitd since it only yields the pointer to us in a closure and is thus still responsible for its lifetime. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. sourcekitd doesn't keep full documentation comments in-memory, it prints them in a temporary buffer and passes a copy through There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. If we pass ownership to the client, I think There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I just modified Can you please recheck? |
||
} | ||
} | ||
return result | ||
} | ||
|
||
var associatedUSRs: [String] { | ||
var result: [String] = [] | ||
session.sourcekitd.ideApi.completion_item_get_associated_usrs(session.response, rawItem) { ptr, len in | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -262,10 +262,17 @@ actor CompletionProvider { | |
func handleCompletionDocumentation(_ request: SKDRequestDictionaryReader) throws -> SKDResponseDictionaryBuilder { | ||
let info = try handleExtendedCompletionRequest(request) | ||
|
||
return request.sourcekitd.responseDictionary([ | ||
request.sourcekitd.keys.docBrief: info.briefDocumentation, | ||
request.sourcekitd.keys.associatedUSRs: info.associatedUSRs as [SKDResponseValue]?, | ||
var response = request.sourcekitd.responseDictionary([ | ||
request.sourcekitd.keys.associatedUSRs: info.associatedUSRs as [SKDResponseValue]? | ||
]) | ||
|
||
if let fullDocumentation = info.fullDocumentation { | ||
response.set(request.sourcekitd.keys.docFullAsXML, to: fullDocumentation) | ||
} else { | ||
response.set(request.sourcekitd.keys.docBrief, to: info.briefDocumentation) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Open question: Does it make sense to also return the brief documentation in addition to the full documentation? Eg. an editor might want to display a brief documentation of the symbol by default and then expand that to full documentation once the user performs an action. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Do you have a specific flow in mind? AFAIK this doesn't happen in code completion since documentation is only shown when the completion item is selected in the completions list. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. For example, you could think about a UI where the brief documentation is displayed in the completion list (similar to how Xcode shows documentation) and only showing the full documentation when the user requests it. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I assume the plugin is used in SourceKit-LSP only, no? If so, then we don't have to return the brief documentation now as we don't need it. We can always add it later if we found a use case for it. If not, it'd probably make sense to return both yes, especially if it's used by Xcode which already has this use case. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The plugin can potentially be used by any SourceKit client yes, so I think we should return both by default. We can always add options to the request for cases where the client only wants the brief or full doc There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Now it makes sense, thanks for the clarification @ahoppen and @hamishknight 🙏🏼 I've changed the request to return both now. |
||
} | ||
|
||
return response | ||
} | ||
|
||
func handleCompletionDiagnostic(_ dict: SKDRequestDictionaryReader) throws -> SKDResponseDictionaryBuilder { | ||
|
Uh oh!
There was an error while loading. Please reload this page.