New command to resolve main class - used for run/debug code lenses in editors

[themkat]

General information

Currently, users are only able to run or debug code if they have made a launch.json file. What is missing is an easy button to just run or debug the code directly next to your main method. This PR implements part of that solution on the language server side. To make this solution as general as possible, the language server now has a new command to resolve the main class to run, range in the file (useful to make the run/debug code lenses), and project root (which is needed to run the code from the right place, especially in multi-module projects). These 3 properties are very general, and could in theory be used for other problems as well in the future.

Currently, top level main function resolving, as well as main methods inside companion objects are supported. The validations on the main methods are quite minimal at this moment. Maybe we should have more, but I'm unsure on how deep we should validate them. main method rules have been changes a bit in newer versions of Kotlin after all (e.g, not needing arguments).

Now you may wonder, how does this help to run the code? This info can easily be used to make code lenses in the editor, whether it be VS Code, Emacs or something else (PRs incoming for the first two as well!). If the debug adapter is used in those projects, we have all the information we need to actually run the code.

Part of the solution for #321

Q/A for the solution (not addressed above)

Question: Why not return the Run/Debug code lenses directly with debug commands in the Code Lens functionality in the language server? Why make them in the editor?
Answer: This could in theory be possible, but would make a tight coupling between the language server and the debug functionality. Not all consumers use the debug adapters (in Emacs, Kotlin debug is currently not supported, but will be once emacs-lsp/dap-mode#593 is merged). If an editor or consumer has chosen not to use the debug adapter (or use an editor where it is not yet supported), a run debug code lens popping up as a result from the language server would not make a lot of sense. It makes more sense to use the Code lens part of the language server for things that are not tightly dependent on other functionality (references, usages etc.)

Future work

• Resolve JUnit/Spek/other tests to be able to run those directly
• Additional validations of main functions?

Other info

VSCode PR fwcd/vscode-kotlin#92

[fwcd]

Thanks for looking into this, I hope to find some time to take a detailed look at it soon, but I like the idea already!

[fwcd]

Thanks a lot!