remove DottyIDE

[SethTisue]

as per @smarter's suggestion on #14542

I'm approaching this somewhat blindly, not sure what my chances of coming up with a finished PR would be. Regardless, I thought it would be good to get the ball rolling.

I have not dealt with these areas of the build before. So this will need review, certainly, and may need refinement. In particular, it wasn't clear to me how to handle DottyLanguageServer.scala, especially IDE_CONFIG_FILE — is all of the code in that file around drivers and configs still needed at all? 🤷

@tgodzik you're responsible for a number of the recent commits in the language-server directory, perhaps you could have a look?

[tgodzik]

Looks good! As for the DottyLanguageServer, most of that code was copied over to Metals, however it is still used in the tests. Some of those tests could probably be removed, but others I would rather keep as they test some of the interactive features.

One test we could for sure remove additionally is the worksheet tests, since they are no longer used and instead we use the Metals worksheets. For others we could probably simplify the language server code and move some handling of hovers/completions etc. to the tests themselves. That is a bit more work though.

[SethTisue]

Okay — rather than increase the ambition level here any further, I'd say those additional removals could be considered future work.

Not sure if anyone else should approve this PR or we can go ahead and merge it. @smarter you did the most work on DottyIDE, I think. Do you know of anything else you believe this PR really ought to remove?

[smarter]

LGTM. I think ideally the tests should ever be changed to only depend on dotty.tools.dotc.interactive or moved to Metals (and we should have Metals run in our community build to check them).

[ckipp01]

For others we could probably simplify the language server code and move some handling of hovers/completions etc. to the tests themselves

LGTM. I think ideally the tests should ever be changed to only depend on dotty.tools.dotc.interactive or moved to Metals (and we should have Metals run in our community build to check them).

One of the important test suites in here is the hover tests and this got me thinking a bit yesterday. We do quite a bit of stuff in Metals to improve the hover experience even though the base is from the dotty language server. Instead of ever trying to move that functionality to the tests, what if we just moved it to interactive? I think it'd be pretty cool to handle hovers like we do completions. Imagine having a def hover(pos: SourcePosition)(using Context): Option[Hover] or something like that which could be used in the metals hover provider, or any other tool that would want this type of functionality. Then we could have pretty robust tests in the compiler itself for this. @tgodzik or @smarter do you have any thoughts on this?

[smarter]

You have my blessings to tweak interactive in any way you deem convenient 😁

[tgodzik]

I think it would be great to move a bunch of stuff into interactive 👍