Support reporting of all compilation problems #2297
Conversation
In it's incremental nature, Zinc does only report problems for re-compiled files, which leads to situations, where you only see a glimpse of the overall compiler warnings. With this change, I keep a record of all reported problems, so they can be later re-shown to the user. The cache is dropping all recorded problems for files, which were recompiled.
|
The output in the first draft isn't correct yet. Also, I think we probably can also access complete problems via the internal compiler analysis, which need to be handled in the worker classpath though. I think I will change the design again. |
This reverts commit c6bca2d.
|
Yeah, |
We now use the Zinc compile analysis to recover older problems. Added a new `zincReportOldProblems` target to `JavaModule`.
lefou
changed the title
|
I changed the design and it seems to work reasonable now. Not sure about the name and the default value of configuration target |
| @@ -198,7 +198,8 @@ trait SemanticDbJavaModule extends CoursierModule { hostModule: JavaModule => | |||
| scalacOptions = scalacOptions, | |||
| compilerClasspath = m.scalaCompilerClasspath(), | |||
| scalacPluginClasspath = semanticDbPluginClasspath(), | |||
| reporter = T.reporter.apply(hashCode) | |||
| reporter = T.reporter.apply(hashCode), | |||
| reportOldProblems = false | |||
There was a problem hiding this comment.
My initial though was, that semanticdb data is used via Metals, and I think BSP clients are persisting problems anyway. Problems are send as events and not as a result of a compilation, so the client need to manage them anyway.
But OTOH, when semanticdb data is needed for other use, e.g. scalafix, warnings might be still of interest. WDYT?
There was a problem hiding this comment.
I don't know if Metals can correctly handle duplicated problems.
Maybe @tgodzik can answer this?
About Scalafix, having the warnings reported again would be good.
But this decision can also be taken in a second moment. We can merge this as false and then experiment in a second PR to see the implications for BSP.
There was a problem hiding this comment.
We will show all the diagnostics that we are sent until we get reset in PublishDiagnosticsParams , since we don't know if problems were solved until we are told so explicitely.
There was a problem hiding this comment.
@tgodzik Thanks Tomasz! That means, in case of incremental compilation, diagnostics where until now either incomplete (if there was a reset) or may even contain outdated or duplicate problems (if there was no reset). I think, always respecting the setting of zincReportOldProblems is probably the cleanest option.
|
This PR is now complete. I updated the description. |
In it's incremental nature, Zinc does only report problems for re-compiled files,
which leads to situations, where you only see a glimpse of the overall compiler warnings.
Now, we use the Zinc internal analysis to recover all found problems. We also record all already shown problems and simply log the not shown but still valid problems after the compilation finished.
This behavior can be configured by the new target
JavaModule.zincReportCachedProblems: T[Boolean]. It defaults tofalseto keep backward-compatible output.