At some point the watchOnTermination callback stopped working. I'm not
exactly sure how or why that happened but it is fairly straightforward
to restore. The one tricky thing was that the callback has the signature
(Watch.Action, _, _, _) => State, which requires propagating the action
to the failWatch command. The easiest way to do this was to add a
mutable field to the ContinuousState. This is rather ugly and reflects
some poor design choices but a more comprehensive refactor is out of
the scope of this fix.
This commit adds a scripted test that ensures that the callback is
invoked both in the successful and unsuccessful watch cases. In each
case the callback deletes a file and we ensure that the file is indeed
absent after the watch exits.
This PR makes changes to the existing `xsbti.Problem` to account for an
optional diagnostic code that the compiler can return for a given
diagnostic and also related information.
Given a piece of code like:
```scala
try {}
```
You'll receive the following:
```
-- [E002] Syntax Warning: /Users/ckipp/Documents/scala-workspace/dotty-error-index/examples/002_EmptyCatchAndFinallyBlockID.scala:3:2
3 | try {}
| ^^^^^^
| A try without catch or finally is equivalent to putting
| its body in a block; no exceptions are handled.
```
The `E002` here is the actual code. Right now there would be no
description.
Some diagnostics have multiple positions that they need to represent.
You can see an example of this
[here](lampepfl/dotty#14002) in Dotty with the
use of inlining. Instead of needing to rely on including all of that
information in the diagnostic message it can now be extracted out into
a `DiagnosticRelatedInformation`.
These changes reference the conversation in #6868
Problem
-------
In some situations like Dotty Community Build, sbt version is
mechanically upgraded on an old commit without humans checking the log.
For reasons we're not completely sure (likely change in ClassLoader
structure) sbt 1.6.x started to fail to load test frameworks during
tests, but since the failure of the test framework loading doesn't fail
the task, this silently succeeded the builds.
Solution
--------
On MatchError and NoClassDefFound Error, rethrow the exception.
Note that ClassNotFoundException is considered ok since we have
predefined test frameworks listed in sbt, which often are not included
in the users' classpath.
Before, the BSP config .bsp/sbt.json generated by `sbt bspConfig`
contained a command line which required the sbt binary in the PATH.
This fix changes the nature of the -Dsbt.script option. It was
an argument of the main class xsbt.boot.Boot, it's now a system
property and thus it's used to launch the sbt server.
Fixes https://github.com/sbt/sbt/issues/6760