-
Notifications
You must be signed in to change notification settings - Fork 950
[BSP]Do not fire build/publishDiagnostics
if there are (and were) no problems
#6847
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
build/publishDiagnostics
if there are (and were) no problems build/publishDiagnostics
if there are (and were) no problems
e10c391
to
893cfbb
Compare
@@ -2310,10 +2310,11 @@ object Defaults extends BuildCommon { | |||
val ci = (compile / compileInputs).value | |||
val ping = earlyOutputPing.value | |||
val reporter = (compile / bspReporter).value | |||
val prevAnalysis = previousCompile.value.analysis.toOption.getOrElse(Analysis.empty) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm bit concerned about the compile performance degradation by depending on previousCompile
in compileIncrementalTask
🤔
Here's a rough observation from this improvement.
sbt 1.6.2
This build
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
@tanishiking I tried this with SBT 1.7.0-M2 today on a very minimal scala 3 project with Metals 0.11.5 in VSCode and SBT as BSP backend and it looks like once I introduce a compile error and then remove it again, Metals is no longer notified that the error is gone, i.e. it stays in the "problems" list and will not go away anymore. |
@asflierl That sounds important. Could you escalate it as a GitHub issue please? Thanks! |
@asflierl Thank you for reporting! |
I tried to fix this problem and I found root cause. Depending on previous compilation result isn't working because when project has some error, However, when there are some warnings in the project, |
Yes I think you are right @kpodsiad, the |
Thanks for clarification @adpi2!
I tried to search where compilation analysis is stored in case of successful compilations but I couldn't find it. Do you mind pointing it out?
I was thinking about that, for now even the simplest I did some estimation (gist here) and such map (either mutable.Map or ConcurrentHashMap) would have roughly 96MB, is this memory footprint acceptable? I also experimented with some variants:
Unless you have better idea I'll try with |
Here it is: sbt/main/src/main/scala/sbt/Defaults.scala Lines 2249 to 2261 in f816aed
Seems like a good approach to me. I guess it is better in term of performance to store the file with errors because we want the case with no errors to be as fast as possible. |
As a first step for fixing #6844, this PR suppress the sbt server from sending
build/publishDiagnostics
ifWhile
bloop
doesn't send notifications if problems are the same as the previous ones, I have a concern about comparing all the problems may slow down the server performance a bit (Is there a good way to profile build?)Therefore, this PR suppresses the diagnostics only when there are (and were) no problems, for the time being. (I believe this is still pretty effective for reducing the message load between BSP client-server, assuming most of the programs have no problems).
example
For example, when we edit a file in this repository, (after a full compilation, edit doesn't contain any problems) sbt BSP sends the following requests/notifications
sbt 1.6.2
this SNAPSHOT
Point is, there's no
publishDiagnostics
notifications anymore :)