In 2.11, the implicit version is named `$conforms` so as to avoid
accidental shadowing by user code, which renders methods using
views and subtype bounds inexplicable unusable.
But, SBT intentionally needs to hide it to make the implicits
in this file line up.
This commit opts-in the the required identifiers from Predef,
rather than opting out of conforms. This makes the same code
source compatible with 2.10 and 2.11.
We now have `global.Range`, so our wildcard import of `global._`
shadows `scala.Range`.
This commit fully qualifies that type so as to be compatible with
Scala 2.10 and 2.11.
* Alter the TaskProgress listener key to be `State => TaskProgress` so it
can be instantiated from the current server/sbt state.
* Expose the xsbti.Reporter interface for compilation through to sbt builds.
This feature is not activated by default. To enable it set `testForkedParallel` to `true`.
The test-agent then executes the tests in a thread pool.
For now it has a fixed size set to the number of available processors.
The concurrent restrictions configuration should be used.
If an exception is thrown when accepting a connection from a forked test
agent, currently I'm seeing that all that happens is SBT hangs with no
output. Thread dumps show that the main process is waiting for the
agent to return, while the agent is waiting for the server to send it
something.
This change logs the exception, so that at least the error can be
googled. It also cleans up the server socket.
This protects against deadlocks between the writing and reading end,
since the ObjectOutputStream constructor writes a header, but does not
flush, and the ObjectInputStream constructor reads the header, and
blocks until it's read.
The serialized structures there aren't part of an Analysis,
so they aren't interned.
TODO: Refactor InternedAnalysisFormats so that this is more
straightforward and less error-prone. This commit is
a first-pass fix of the broken test.
-Changed usages and implementations of interfaces in org.scalatools.testing._ to use/implement interfaces/classes in sbt.testing._ instead.
-Added sbt.testing to interfaceFilter in TestFramework.createTestLoader method to enable loading of classes in sbt.testing package.
-Added FrameworkWrapper.java to wrap old framework implementations.
-Added code in ForkMain.java to serialize Selectors.
Introduce a way to configure incremental compiler itself instead
of underlying Java/Scala compiler.
Specific list of changes in this commit:
* Add a method to `xsbti.compile.Setup` that returns incremental
compiler options as a `java.util.Map<String, String>`. We considered
statis interface instead of a `Map` but based on mailing
list feedback we decided that it's not the best way to go because
static interface is hard to evolve it by adding new options.
* Since passing `java.util.Map<String, String>` not very convenient
we convert it immediately to `sbt.inc.IncOptions`
* Add options argument to various methods/classes that implement
incremental compilation so in the end options reach
`sbt.inc.IncOptions` object
* Add `incOptions` task that allows users to configure incremental
compiler options in their build files. Default implementation of
that tasks returns just `IncOptions.DEFAULT`
* Both system property `xsbt.inc.debug` and `IncOptions.relationsDebug`
trigger debugging of relations now. In the near future, we should
deprecate use of `xsbt.inc.debug`.
Some methods take a lot of arguments and I'm about to add one more
which will make them too long for easy reading.
This change is changes code formatting only. That's done on purpose
to make it easier to review other changes.
Let's consider compile/inc/src/main/scala/sbt/CompileSetup.scala.
There are multiple Output types, and according to Eclipse importing
xsbti.compile.Output within the package sbt does not work because the
import is shadowed by sbt.Output.
However, compilation proceeds just fine within SBT. Reproducing the
example however gives the same warning, if the files are in the same
project. The problem here is probably that the shadowing Output
is declared in the same package but in another project, and that seems
to give different results in Eclipse and SBT, but relying on
that looks fragile.
Reading the spec is inconclusive since it doesn't match with Scalac's
behavior — see
https://groups.google.com/d/topic/scala-internals/-Rquc2HBYLk/discussion .
ForkTests has the same behavior as CompileSetup.
Jason Zaugg
Josh Suereth
Bruno Bieth
Mark Harrah
James Roper
Benjy
Eugene Yokota
cheeseng
Grzegorz Kossakowski
Paolo G. Giarrusso