Add Run/Debug CodeLens Support

[plemarquand]

Adds a response to the textDocument/codeLens request that returns two code lenses on the @main attribute of an application.

The LSP documentation breaks out the code lens requests into a Code Lens Request and a
Code Lens Resolve Request, stating this is for performance reasons. However, there is no intensive work we need to do in order to resolve the commands for a CodeLens; we know them based on context at the time of discovery. For this reason we return resolved lenses with Commands for code lens requests.

A missing piece is only returning code lenses if the file resides in an executable product. To my knowledge Libraries and Plugins can't have an @main entrypoint and so it doesn't make sense to provide these code lenses in those contexts.

Some guidance is required on how to best determine if the textDocument in the request is within an executable product.

testCodeLensRequestWithInvalidProduct asserts that no lenses are returned with the @main attribute is on a file in a .executable, and is currently failing until this is addressed.

This will currently implement swiftlang/vscode-swift#525 with no changes on the VS Code side.

[plemarquand]

One thing worth thinking about is whether or not command resolution should/could happen in the editor. I don't really like that sourcekit-lsp would have the "run" and "debug" commands hard coded within it. The editor may have more context about what commands it can run on a @main annotation.

A better flow might be that the LSP responds with a CodeLens for a range/uri annotated what type of lens it is (using CodeLens.data?). The client can then resolve the CodeLens command.

A technical limitation of the spec here is that if the server responds with one CodeLens then resolution response produces only one corresponding CodeLens with a command. Turning that one CodeLens response in to two (run + debug) doesn't seem straightforward.

Also CodeLens.data is a property of CodeLens in sourcekit-lsp but data isn't in the LSP spec, which would make using it to determine what type of CodeLens we're resolving in the client non standard.

[ahoppen]

I still don’t quite understand how these kinds of code lenses are intended to work in LSP. My impression is that the workflow is as follows:

• Client sends textDocument/codeLens request
• User selects the code lense
• Optionally, the codeLens/resolve request is sent (I agree that in our case we don’t need to use resolve)
• The server sends a workspace/executeCommand request to execute the command returned by the code lens, which returns an LSPAny

And now I’m lost: Who is responsible for interpreting the LSPAny and how does that get negotiated? The only clear example I have found is that _ workspace/executeCommand_ sends workspace/applyEdit to the client to achieve an effect (and presumable the response to workspace/executeCommand is ignored).

The equivalent to workspace/applyEdit for running a binary would, in my opinion, be that SourceKit-LSP executes the binary and returns the output via window/logMessage but I don’t like that idea because (a) SourceKit-LSP might not even know how to build the product, eg. for compile_commands.json projects (b) it’s awfully subtle to find the output and (c) you can’t debug the executable.

Do you have examples of how other language servers implement that kind of debug code lens?

Without any outside research my proposal would be: The client announces the kinds of commands that it can handle natively (swift.run and swift.debug in our case) and we only return code lenses with these commands if the client can handle them natively. That way in other editors, we won’t get a workspace/executeCommand request for the swift.debug command, which we then can’t handle.

[ahoppen]

I think we’re still missing the following, right? Otherwise looks good.

The client announces the kinds of commands that it can handle natively (swift.run and swift.debug in our case) and we only return code lenses with these commands if the client can handle them natively.

[plemarquand]

@ahoppen I've updated the PR so that SourceKit-LSP accepts a new field in the client initializationOptions. It contains a dictionary where the key is the lens name recognized by SourceKit-LSP and the value is the command as recognized by the client.

I set it up this way so that the LSP doesn't make an assumption about the names of commands that the client can support, as they're not guaranteed to be named swift.run/swift.debug on the client side, though they are in VS Code. This may be overkill though, so I'm interested in your thoughts.

initializationOptions: {
    "textDocument/codeLens": {
        supportedCommands: {
            "swift.run": "clientCommandName_Run",
            "swift.debug": "clientCommandName_Debug",
        }
    }
}

[ahoppen]

@swift-ci Please test

[plemarquand]

@ahoppen apologies, only ran the linter on Sources not Tests.

[ahoppen]

@swift-ci Please test

[ahoppen]

@swift-ci Please test Windows

[ahoppen]

@swift-ci Please test

[ahoppen]

@swift-ci Please test Windows