ArrayList::add is not thread safe. I ran into cases where async tests
using utests would fail even when all of the individual tests passed.
This was because multiple threads called back into the handle method of
the handler instance variable, which just delegated to eventList::add.
When this happened, one of the events would get added to the list as a
null reference, which would manifest as an NPE upstream on the master
process. After this change, my tests stopped failing.
Sometimes when utest runs async tests (i.e. tests that return a future)
the test suite will fail even when none of the individual tests do. This
is due to a data race in sbt. Most, but not all, of the time, this test
will induce that race.
Fixes https://github.com/sbt/sbt/issues/3405
Ref https://github.com/scala/scala-xml/issues/195
sbt's `run` is emulated using a classloader trick that includes ScalaInstance as the parent classloader under the classpath. The problem is the ScalaInstance classloader currently contains both compiler, library, and their transitive JARs:
```scala
res0: Array[java.io.File] = Array(scala-library.jar, scala-compiler.jar, jline.jar, scala-reflect.jar, scala-xml_2.12.jar)
```
This could have been causing various issues, but most recently it showed up as wrong version of scala-xml getting prioritized over what's passed by the user.
1. new field loaderLibraryOnly is added to xsbti.ScalaInstance.
2. it is initialized to the library loader if the launcher creates it, otherwise create layered loader here.
This aims to isolate the library loader, and retain the perf.
I noticed that my custom WatchService was never cleaned up by sbt and
realized that after every build we were making a new WatchService. At
the same time, we were reusing the WatchState from the previous run,
which was using the original WatchService. This was particularly
problematic because it prevented us from registering any paths with the
new watch service. This may have prevented some of the file updates
from being seen by the watch service. Moreover, because we lost the
reference to the original WatchService, there was no way to clean it up,
which was a resource leak.
May be related to #3775, #3695
The following commit adds the test case used to report #3143 in a big
projects with lots of cross versions and modules. The execution of the
test is instant!
Ethan Atkins
Dale Wijnand
Dale Wijnand
Eugene Yokota
Naohisa Murakami
tmiyamon
Hiroshi Ito
TATSUNO Yasuhiro
jvican