SwiftInterface textual interface generation fails

[adam-fowler]

I may be wrong here, but I assumed that #668 would generate a textual interface similar to Xcode when jumping to the definition for a file. It seems this is failing because the SymbolInfo request in SourceKitServer.definition is being returned with a symbol.kind set to nil and not .module. I replicated this by asking to jump to the definition of String in VS Code.

[ahoppen]

Tracked in Apple’s issue tracker as rdar://108891020

[adam-fowler]

So I had a look into this further and it is seems it is only meant to generate the SwiftInterface textual view if you ask for the definition of the module ie right click on import MyModule and get textual interface. It does not generate the view if you right click on a symbol from the module. @bwhiteley given you wrote the PR is this as expected?

[adam-fowler]

As an aside I am adding better handling of swiftinterface files in VS Code swiftlang/vscode-swift#538

[bwhiteley]

So I had a look into this further and it is seems it is only meant to generate the SwiftInterface textual view if you ask for the definition of the module ie right click on import MyModule and get textual interface. It does not generate the view if you right click on a symbol from the module. @bwhiteley given you wrote the PR is this as expected?

That is correct. Loading the .swiftinterface when clicking a symbol from the module would be a welcome next step.

[adam-fowler]

@ahoppen I've been looking into how this could be implemented. So far I have the textual interface being generated whenever a symbol returns a .swiftinterface file. Are there are helper functions to work out a position in this file for the symbol? Can I maybe get the generated files indexed?

You can see what I've done so far here /~https://github.com/adam-fowler/sourcekit-lsp/blob/e30bdaca320626105012bd710fac7caaabeb4aeb/Sources/SourceKitLSP/SourceKitServer.swift#L1308

[ahoppen]

I assume that you are also implementing something in SourceKitServer.definition, or at least that’s your starting point.

From there, you make a SymbolInfoRequest, which creates a cursorInfo request to sourcekitd. Can you show me the results of that request? You should be able to set the SOURCEKIT_LOGGING=3` environment variable. I think cursor info should also return the offset inside the generated interface.

[adam-fowler]

Yes the implementation is in SourceKitServer.definition. The SymbolInfoRequest doesn't return a location. It doesn't seem to be returned in the cursorInfo. Instead definition needs to get the location from the index, which just returns the first line of the swiftinterface file.

I did run with SOURCEKIT_LOGGING=3 and when you make a OpenInterfaceRequest it produces a ton of output making it quite hard to catch anything

[bnbarham]

Cursor info actually doesn't return any location in this case (though in the Clang-imported decl case it may return the location in the header). It includes its USR and the module name it's in. So you'll first need to run the open interface request to grab the generated interface and after that run source.request.editor.find_usr which takes the name of the interface (from the previous response) and the USR from the cursor info response.

As an aside I generally call "open interface" the "generated interface", which is separate to the .swiftinterface (that I call "textual interface"). The generated interface is not the same as a .swiftinterface. It excludes a bunch of details (eg. underscored attributes) and also adds synthesized extensions:

public protocol SomeProto {}
public extension SomeProto {
  func foo() {}
}
public struct SomeStruct: SomeProto {}

would generate an interface of:

...
public protocol SomeProto {
}
extension SomeProto {
    public func foo()
}
public struct SomeStruct : A.SomeProto {
    public func foo()
}

[adam-fowler]

#747