The launcher defines a top classloader that willbe used by all
`ScalaInstance`s. Previously, this top classloader had a parent that
contained the scala library 2.10, which prevented the correct
compilation of the compiler bridge for scala 2.11.
Also, we no longer need the scala-reflect JAR.
This commit introduces a new "static" launcher that does not use Ivy to
gather all the artifacts that it requires, but rather expect them to be
immediately available.
To be able to use sbt without Internet access, we add a new
`ComponentCompiler` that is able to retrieve the bridge sources from the
resources on classpath and compile it.
Provides a workaround flag `incOptions :=
incOptions.value.withIncludeSynthToNameHashing(true)` for name hashing
not including synthetic methods. This will not be enabled by default in
sbt 0.13. It can also enabled by passing `sbt.inc.include_synth=true`
to JVM.
Some scripted tests override the default local repository, which
produces errors with the compiler because sbt cannot find the sources
for the compiler interface.
This fix proposes to publish the compiler interface sources to an
alternate local repository before running the scripted tests. This
alternate repository is added to the scripted sbt's configuration, so
that sbt is finally able to find the compiler interface sources.
Consider a configuration where we have two projects, A and B.
A has a library dependency on "a" % "b" % "1.0.0" % "compile->runtime"
and "a" % "b" % "1.0.0" % "compile->runtime2"
B depends on project A, and has a library dependency on
"a" % "b" % "1.0.1" % "compile->runtime".
Note that project B depends on a more recent version of "a" % "b" than
project A, and that it depends ONLY on it's "runtime" configuration.
However, when compiling project B, we expect to have on the classpath
project A, and "a" % "b" % "1.0.1" % "compile->runtime" AND
"a" % "b" % "1.0.1" % "compile->runtime2" because it is part of the
compile configuration of project A.
This commit changes the cached resolution engine so that it behaves like
that, by first resolving dependencies on other project and then ensuring
that the dependent project specifies dependencies on the same
configurations.
Mark test dependency-management/cached-resolution-configurations as
passing.
The reason for instability is a bit tricky so let's unpack what the
previous code checking if there's self type declared was doing. It would
check if `thisSym` of a class is equal to a symbol representing the class.
If that's true, we know that there's no self type. If it's false, then
`thisSym` represents either a self type or a self variable. The second
(type test) was supposed to check whether the type of `thisSym` is
different from a type of the class. However, it would always yield false
because TypeRef of `thisSym` was compared to ClassInfoType of a class.
So if you had a self variable the logic would see a self type (and that's
what API representation would give you).
Now the tricky bit: `thisSym` is not pickled when it's representing just
a self variable because self variable doesn't affect other classes
referring to a class. If you looked at a type after unpickling, the
symbol equality test would yield true and we would not see self type when
just a self variable was declared.
The fix is to check equality of type refs on both side of the type equality
check. This makes the pending test passing.
Also, I added another test that checks if self types are represented in
various combinations of declaring a self variable or/and self type.
Fixes#2504.
Add a pending test that shows a problem with instability of representing
self variables. This test covers the bug described in #2504.
In order to test API representation of a class declared either in source
file or unpickled from a class file, ScalaCompilerForUnitTesting has been
extended to extract APIs from multiple compiler instances sharing a
classpath.
This commit enables control of whether a compiler instance should be reused
between compiling groups of Scala source files. Check comments in the code
for why this can be useful to control.
When concatenating the artifacts coming from two modules, we sometimes
attempted to create a default artifact from the organization and name of
the module.
However, this may fail because a module a % b "1.0" may not have an
artifact named "b.jar" (see sbt/sbt#2431).
Fixessbt/sbt#2431.
sbt's shell provided completion only for keys that were relative to a
defined project, but didn't provide completion for keys that belong to
the build definition only.
This commit fixes this issue by defining a new kind of `Parser` (from
which completions are generated) which runs its input simultaneously on
distinct parsers. We now define a parser for project-level keys and
another parser for build-level keys. These two parsers are eventually
combined, and we get the completions of both parsers.
Fixessbt/sbt#2460
Fixes#2464 and Fixes#2465
appResolvers is a set of resolvers specified in the launcher
configuration.
This list fluctuates depending on the version of sbt, and sbt 0.13.10
meant to stabilize it by weeding out JCenter even when it includes it,
which failed when I applied the filter on the wrong list. This should
correct it.
For example, when the `--sourcepath` option is provided
and the refchecks phase compiles an annotation found
on a referenced symbol from the sourcepath.
`compileLate` assumes that all non-sentinel compiler
phases can be down cast to `GlobalPhase`.
This commit changes the two phases in SBT to extend
this instead of `Phase`. This has the knock on benefit
of simplifying the phases by letting the `GlobalPhase.run`
iterator over the list of compilation units and feed them
to us one by one.
I checked that the test case failed before making each
change.
Martin Duhem
eugene yokota
Dale Wijnand
Grzegorz Kossakowski
Jason Zaugg