You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This adds tests related to diagnostics in BSP integration tests, and
fixes or adjusts several things related to diagnostics in BSP.
In particular, this ensures that a `CompileProblemReporter` is always
passed around when running tasks for BSP. This ensures that users get
all diagnostics related to compilation happening in BSP requests, not
only diagnostics happening in the `buildTarget/compile` request. This
includes compilation of the build itself, that happens upfront right
after having started the BSP server. This allows users to get
diagnostics for errors that make the build not compile for example
(which can help address those errors).
This fixes things related to generated files. Some diagnostics
notifications were not sent for those, which was making diagnostics
stick around in VSCode, even when the errors were addressed. Line
adjustment was incorrect for `build.mill` files having no `package`
directive. This fixes that too.
There was also a hardcoded limit of maximum 10 errors being reported
(both in BSP and in the console). This removes this limit for BSP, where
a large amount of errors shouldn't be a problem, given they're reported
inline in sources.
Lastly, the "Don't send diagnostics twice" commit ensures we don't send
duplicate diagnostics via BSP. Ensuring a CompileProblemReporter is
passed around everywhere (see above) can sometimes trigger that (when
semanticdb generation is enabled, compilation happens twice: once for
classes, a second time for semanticdbs, which would report each
diagnostic twice).
0 commit comments