Clarify what `source-dependencies/import` really tests by renaming
it to `source-dependencies/import-package` which better describes
the scope of that test.
Also, introduce analogous `source-dependencies/import-class` test which
tests dependency tracking on imported classes.
The reason why we should distinguish between imported packages and classes
is that incremental compiler doesn't track packages as products of source
files as it does for classes. Therefore, problem with imported classes
is much more tractable than with imported packages.
Added a test-case for an edge case where an introduction of private member
(var in this case) should trigger recompilation of all classes that
inherit from a trait where the member is declared.
The reason is that current encoding of traits make it impossible for them
to declare fields directly so fields are being introduced in classes
inheriting from those traits. Check the test case for details.
This is a pending test case for sbt/sbt#686 which tests if dependencies
are track properly when it comes to implicit scope.
This test is marked as pending because sbt does not track
dependencies correctly in this case.
The `final` modifier is not essential in `source-dependencies/export-jars`
and removing it eliminates the danger of running into Scala's bug SI-7173
where typer inlines constants and does not record any information about
dependency. In case we want to switch to dependency tracking based on
trees we would run into this problem in this test-case.
Testing for that scenario has been moved to separate test case
`source-dependencies/constants`.
Git blaming reveals the intent of sleeping after file modification
that was described in 02f666ec0e commit.
Let's put it straight into source code.
Also, added a new lines before each sleep command to better signal
the pause.
Switched to current version of Scala that sbt itself uses in
`source-dependencies/macro` test. Since sbt is on Scala 2.10 now
we can do that.
Adjusted test-case to current API for macros.
It is no longer necessary for it to be loaded in a stable class loader
and line reading in the launcher does not require anything more advanced
than java.io.Console.readLine(String).
Scala versions 2.8 and later use the version that goes through JAnsi
and for that it is sufficient to have JNA in a stable loader.
Ideally, we wouldn't need to construct the classpath ourselves and instead
reuse the classpath construction code from a compiler (scalac or javac).
However, we need to ensure that we only call the compiler when needed.
Because we need to construct the classpath even when compilation might
not happen, we have to duplicate classpath construction.
This reverts commit 9dd5f076ea which was a revert
itself so we are back to the state before those two reverts.
The problem that caused revert that happened in 9dd5f076ea
has been fixed in 88061dd262.
In `ClassToAPI` both `Private` and `Protected` vals had forward
reference to `Unqualified` so they would get `null` as a result.
Fixed that by rearranging the order of vals being declared.
This fixes a problem described in 9dd5f076ea.
Specifically, when the Scala version for sbt is the same as that for the project being built,
the jars in UpdateReport should be the same as those in ScalaProvider. This is because the
loader will come from the ScalaProvider, which uses jars in the boot directory instead of the
cache. The first part of the fix for #661 checks that loaded classes come from the classpath
and so they need to line up.
It is now used for consoleProject, run, and test. This loader verifies
that all classes loaded through it came from a particular classpath or
from the "root" loader. Root loader here is the launcher loader so that
those classes with native bindings come from that shared loader.
Grzegorz Kossakowski
Mark Harrah
Brendan W. McAdams
Juan Manuel Caicedo Carvajal
Alex Dupre