Provide Data Types in Document Outline; Provide Code Documentation in CompletionItem

[LebJe]

Provide Data Types in Document Outline

Before:

After:

Problems

• SourceKit doesn’t provide the typename field for variables with inferred types, like let a = “string”, it's only provided for let a: String = "string". Function parameters always have a type, but they also are ignored by SourceKit. Is there a way to tell SourceKit to use the inferred types?

Provide Code Documentation in CompletionItem

Before:

After:

Problems/Questions

• Is it possible to retrieve the full documentation (perhaps doc_full_as_xml) for completion suggestions, not just doc_brief?
• SourceKit removes markdown in doc_brief.

[DavidGoldman]

@swift-ci please test

[DavidGoldman]

@swift-ci Please test

[benlangmuir]

Thanks!

SourceKit doesn’t provide the typename field for variables with inferred types, like let a = “string”, it's only provided for let a: String = "string". Function parameters always have a type, but they also are ignored by SourceKit. Is there a way to tell SourceKit to use the inferred types?

This is by design. The request that's being used here is purely syntactic. To get the types you need to go through type-checking, which is much more expensive. The way this request gets used, we want to always have a fast answer.

To get inferred types, we could use the same underlying data as the experimental "inlay type hints" feature (see #408). But we would want to avoid blocking on this information in the document outline. That would be a big increase in scope for the document outline.

Is it possible to retrieve the full documentation (perhaps doc_full_as_xml) for completion suggestions, not just doc_brief?

Not currently. To do this we would want to request it lazily per completion item that we need it for rather than copying the full documentation for every completion from sourcekitd, which might be 100,000 items.

SourceKit removes markdown in doc_brief.

Correct. The brief documentation provided by completion is plain text. We are also working around the lack of direct markdown in the hover request by reversing from CommentXML. In both cases, the real solution would be to add a way for sourcekitd to provide the raw documentation markdown.

[benlangmuir]

@swift-ci please test

[LebJe]

@benlangmuir, I'm currently experimenting with using completionItem/resolve to retrieve documentation for a CompletionItem currently selected in an editor.

Unfortunately, I haven't been able to find much documentation that describes the requests that can be sent to SourceKit.
Would you happen to know of a way to get information about a symbol returned by codecomplete?

This is by design. The request that's being used here is purely syntactic. To get the types you need to go through type-checking, which is much more expensive.

Since most of the items in the outline probably would not have a type, would you prefer if this feature was removed?

[benlangmuir]

Since most of the items in the outline probably would not have a type, would you prefer if this feature was removed?

I'm fine with it as-is. If we find it is confusing in practice we can always reconsider in the future.

Would you happen to know of a way to get information about a symbol returned by codecomplete?

We're not really setup for this right now. I think it's something we could look at in the future.

I'm currently experimenting with using completionItem/resolve to retrieve documentation for a CompletionItem currently selected in an editor.

Note: you can implement this request as an optimization over the current behaviour to avoid serializing all the documentation strings for all the results that are returned eagerly.