This is a backport of sbt/zinc#95
The previous approach to value class API (introduced by #2261 and
refined by #2413 and #2414) was to store both unerased and
erased signatures so that changes to value classes forced
recompilations.
This is no longer necessary thanks to #2523: if a class type is
used, then it becomes a dependency of the current class and its name is
part of the used names of the current class. Since the name hash of a
class changes if it stops or start extending AnyVal, this is enough to
force recompilation of anything that uses a value class type. If the
underlying type of a value class change, its name hash doesn't change,
but the name hash of `<init>` changes and since every class uses the name
`<init>`, we don't need to do anything special to trigger recompilations
either.
This is a backport of https://github.com/sbt/zinc/pull/87
When `B2.scala` replaces `B.scala` in the new test
`types-in-used-names-a`, the name hash of `listb` does not change because
the signature of `C.listb` is still `List[B]`, however users of
`C.listb` have to be recompiled since the subtyping relationships of its
type have changed.
This commit does this by extending the definition of "used names" to
also include the names of the types of trees, even if these types
do not appear in the source like `List[B]` in `D.scala` (since `B` has
been invalidated, this will force the recompilation of `D.scala`).
This commit does not fix every issue with used types as illustrated by
the pending test `types-in-used-names-b`, `B.scala` is not recompiled
because it uses the type `T` whose hash has not changed, but `T` is
bounded by `S` and `S` has changed, so it should be recompiled.
This should be fixable by including the type bounds underlying a
`TypeRef` in `symbolsInType`.
The test `as-seen-from-a` that did not work before shows that we may not
have to worry about tracking prefixes in `ExtractAPI` anymore, see the
discussion in sbt/zinc#87 for more information.
traverse(tree: Tree) used to call super.traverse(tree) at the end.
sbt/sbt@0f616294c4 brought the traversing
call to inside of the pattern matching.
For the case of MacroExpansionOf(original), it amounts to not traveling
the macro-expanded code. See
sbt/src/sbt-test/source-dependencies/macro-nonarg-dep for the repro.
Unlike other scripted macro tests, the call site of this macro is
`Provider.tree(0)`, which does not introduce internal member reference.
Instead the macro itself calls `Bar.bar(0)`. Due to #2560, the expanded
tree is not traversed, and thus the reference to `Bar` is not caught
during incremental compilation.
Fixes#2546. Ref #958
scripted compiler-project/error-in-invalidated has been failing
frequently on Travis CI. It seems like incremental compiler is not
catching the change in source occasionally for `changes/A2.scala`.
It turns out that we can leverage the`FakeResolver` that has been
implemented to use with the static launcher, and resolve a "fake
compiler bridge" using it, rather than copying it from the resources.
This also has the advantage of not requiring to change the build
definition.
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.
ddworak
eugene yokota
Guillaume Martres
Martin Duhem
Dale Wijnand
Grzegorz Kossakowski