I assumed 1.1+ should be treated as 1.+, but it seems like Ivy treats
it more as “any version that starts with 1.1” including 1.10.
Josh’s original implementation approximates this by making ranges for
multiple digits, 1.1~1.2, 1.10~1.20, etc.
I assumed 1.1+ should be treated as 1.+, but it seems like Ivy treats
it more as “any version that starts with 1.1” including 1.10.
Josh’s original implementation approximates this by making ranges for
multiple digits, 1.1~1.2, 1.10~1.20, etc.
This commit changes the default value of `IncOptions.nameHashing` to be
set to true. It means, the improved incremental compilation algorithm
known as "name hashing" will be enabled by default.
In order to disable it, users should add this to their sbt configuration:
incOptions := incOptions.value.withNameHashing(false)
Number of tests has been cleaned up as part of this change. All tests
that were marked as name hashing specific are removed. The list includes:
* constants-name-hashing
* import-class-name-hashing
* java-static-name-hashing
* macro-name-hashing
* struct-name-hashing
We'll keep just regular version of those tests. The tests will just
exercise the default algorithm: name hashing. This is the first step
towards phasing out of the old incremental compilation algorithm.
Apart from that, a few tests changed its status due to enabling name
hashing algorithm.
The `constants` test has been marked pending due to issue described in
#1543.
The `import-class` test has been marked as passing because name hashing
tracks dependencies introduced by import statements correctly, now.
The `macro` test has been marked as pending due to issue described in
#1544.
The `struct` test has been marked as pending due to issue described in
#1545.
The `java-static` has been slightly modified to exercise just static field
and not run into the same issue as with `constants` test.
There are no other known issues related to name hashing so we conclude
that name hashing is ready to be shipped to all sbt, Scala IDE and zinc
users.
In Scala 2.10.4, this macro can produce a stack overflow :
def foo(a: Any): Any = macro impl
def impl(c: Context)(a: c.Expr[Any]): c.Expr[Any] = a
Here, an application such as `foo(someVal)` will produce the expansion
`someVal`. As expected, `someVal` has `original` tree `foo(someVal)`,
but if we inspect this tree, we will find that `someVal` has an
original tree, but it shouldn't.
Moreover, in Scala 2.11, some macros have their own application as
`original` trees.
See sbt/sbt#1237 for a description of these problems.
This commit fixes these two problems.
Fixessbt/sbt#1237
This test shows that macros that simply return their argument produce
a stack overflow during extraction of used names.
Consider a macro `foo(c: Context)(a: c.Expr[Any]) = a`. An
application of this macro such as `foo(someVal)` will lead to the
expansion `someVal`. sbt will extract the `original` tree from it,
and find `foo(someVal)`, and recurse infinitely on `someVal`.
#1525 removes unused *.class files created by the metabuid.
The implementation currently prints out a long list of *.class files
it’s about to remove. Unless something bad happens, this information is
not very useful to the user, so I suggest we don’t display it.
scala-library is currently treated as just one of the library modules.
This means that it’s at the mercy of eviction if some other library
uses newer version of scala-library.
This commit displays a instruction on how to force scalaVersion if
warnScalaVersionEviction flag is true on EvictionWarningOptions.
scala-library is currently treated as just one of the library modules.
This means that it’s at the mercy of eviction if some other library
uses newer version of scala-library.
This commit displays a instruction on how to force scalaVersion if
warnScalaVersionEviction flag is true on EvictionWarningOptions.
Scala instance is added to the Ivy graph via autoLibraryDependency.
For metabuilds, scala-library is scoped under “provided” configuration,
which does not seem to evict modules on “compiled” configuration.
This commit turns overrideScalaVersion flag to true for the metabuilds,
so override rules are added for the following modules:
- scala-library
- scala-compiler
- scala-reflect
Scala instance is added to the Ivy graph via autoLibraryDependency.
For metabuilds, scala-library is scoped under “provided” configuration,
which does not seem to evict modules on “compiled” configuration.
This commit turns overrideScalaVersion flag to true for the metabuilds,
so override rules are added for the following modules:
- scala-library
- scala-compiler
- scala-reflect
Ivy and pom uses slightly different notation for version range and
dynamic revision.
This change fixes the dynamic revisions involving “+”.
First, when a revision like “1.1+” is found, it will now be treated as
“1.+”.
Next, when it finds a revision like “1+” is found, it will be treated
as “+”.
The conversion of “+” is hardcoded to be “[0,)”.
Ivy and pom uses slightly different notation for version range and
dynamic revision.
This change fixes the dynamic revisions involving “+”.
First, when a revision like “1.1+” is found, it will now be treated as
“1.+”.
Next, when it finds a revision like “1+” is found, it will be treated
as “+”.
The conversion of “+” is hardcoded to be “[0,)”.
We forward errors from the spawned server to stderr, so we are
already using stderr and this should save someone some pain
vs. just swallowing the fail.
The defaults here are copied from Activator which
in turn are probably copied from somewhere else.
They are of course basically arbitrary, but the
JVM's defaults if we don't set memory options
are insufficient to run most apps.
If the user sets any memory options in the configuration,
we completely leave them alone and don't set any of
our own. So it's always possible to override.
Ivy gives an array that contains null for caller configurations.
sbinary barfs when it sees null. Curiously two of the sbt plugins that
hit this bug happens to be from Typesafe:
addSbtPlugin("com.typesafe.play" % "sbt-plugin" % "2.3.2")
addSbtPlugin("com.typesafe.sbt" % "sbt-native-packager" % "0.7.3")
Ivy gives an array that contains null for caller configurations.
sbinary barfs when it sees null. Curiously two of the sbt plugins that
hit this bug happens to be from Typesafe:
addSbtPlugin("com.typesafe.play" % "sbt-plugin" % "2.3.2")
addSbtPlugin("com.typesafe.sbt" % "sbt-native-packager" % "0.7.3")
Eugene Yokota
Josh Kalderimis
Grzegorz Kossakowski
Havoc Pennington
Martin Duhem
Ben McCann