Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Unify build tool integrations with Metals #942
Add an additional mechanism to save information about the SemanticDB plugin version for Metals. That information is then used to add scala options to compiler instances for the SemanticDB plugin.
@jvican Is this what you meant? I still need figure out some tests and a way to simulate failing fatal warnings, although the current solution works the same as the one in this PR.
After talking with @jvican I think what we should do is:
We would need to add an additional parameter with SemanticDB version to all integrations (we don't have that while running
Just a question to @jvican : is there a reason that we don't use Scala 2.12 in all of the integrations? At least in Gradle and Maven I don't see any reason to do that. And Metals doesn't work with 2.10 modules :P
I've given this a lot more thought and I think this PR is on the right track. Implementing specific semanticdb support in every build as I proposed in our call @tgodzik has the advantage that everything that requires downloading is done by the build tool but two big disadvantages:
By centralizing the download and setup in the server, we have two key advantages:
Therefore, we only need to tweak how this PR is implemented internally, I'll leave few code comments after this long comment.
The intent of this piece of code was good but after thinking about it and trying it out locally I've realized this is too verbose of a message and this information should be shown in the Metals doctor instead. Some of this code will be added back in a next commit in a different place without the `displayWarningToUser`, which IMO should only be used when the semanticdb plugin could **not** be resolved for a version we know it's compatible for. This is truly an scenario that is unlikely to happen and where good communication with users is key.
- Use new coursier API at the request of Alex, simplifies error handling - Add documentation to `enableMetalsSettings` and `detectWorkspaceDirectory`. - Cache `latest.release` resolution so that we only resolve the plugin once in the whole server session, otherwise there's too much overhead of resolving a `latest.release` artifact per project. - Refine the logic transforming the project so that we unconditionally apply range positions and we only emit warnings to users when a resolution error that we didn't expect happens.
This big commit rethinks how build load works to make it incremental. It adds more tests and documentation to the appropiate internal APIs to make this area easier to browse in the future. The previous logic was working perfectly fine but could incur some performance overhead because every time there was a change in the server the build load process would restart and that implies also resolving semanticdb plugins for all scala versions in a project. That is not a big problem because most of the times they are cached but the overhead of that operation is nevertheless too expensive, so the incremental build load process mitigates that.
The semantics to retry adding the semanticdb plugin to a project depend uniquely on whether the project has semanticdb disabled and whether the `newSettings` passed by the client are not empty. Whether there is a change in the settings or not should not affect these semantics.
Because `writeToFile` returned `Either`, there were places in our tests where we were completely swallowing any exception that could be happening when writing the workspace settings file. Now we will throw the exception instead. In the case of the internal build logic, we do swallow any exception thrown by this logic intentionally.
The workspace already implies that it's the root directory and we already use `Dir` as the suffix of many fields in the configuration, so this is a more idiomatic choice.
@tgodzik I've just pushed several changes that IMO make this PR already ready to be merged, it's your time now to review! I've left a few comments/explanations on the most important parts of the changes and the commit messages are also meant to be descriptive. Please let me know what you think about the changes