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 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,)”.
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")
Fixes#1524
* Track generated .class files from Eval
* While loading, join all classfiles throughout Load, lots of bookkeeping.
* When a given build URI is done loading, we can look at its
project/target/config-classes directory and clean out any extra items
that are lingering from previous build definitions.
* Add TODOs to handle the same thing in global directories. Right now,
given the shared nature of these projects, it's a bit too dangerous to
do so.
First of all, we revert changes to Eval made in
a9cdd96152. That was a work-around
for problem with broken positions set on some trees. The rest of
the commit describes a fix.
Scala compiler's Global has `currentRun` method which is supposed to
return an instance of Run currently in use. Sbt's Eval which wraps
Global would create an instance of Run but not register it in Global.
Similarly, Eval would create an instance of `CompilationUnit` but not
set it in Run.
This would result in some silent failures like assigning broken positions
to parsed trees even if parser *has* received an instance of compilation
unit. See https://issues.scala-lang.org/browse/SI-8794 for details.
We fix the issue by subclassing Global and making it possible to set
current Run instance externally. Then we use this capability to set a run
instance right before we call compiler phases. We also make sure that
current run has current compilation assigned to it.
Fixes#1181Fixes#1501Fixes#1523
Fixes#1455
* Add a mechanism to detect if a plugin clause includes/excludes
a particular plugin.
* Add a filter for our "enabling" clauses so that user-excluded
root plugins do not show up.
* Add a test to ensure this succeed.
Adds `lastestSnapshots` flag to `updateOptions`, which controls the behavior of the chained resolver. Up until 0.13.6, sbt was picking the first `-SNAPSHOT` revision it found along the chain. When is enabled (default: ), it will look into all resolvers on the chain, and compare them using the publish date.
The tradeoff is probably a longer resolution time if you have many remote repositories on the build or you live away from the severs. So here's how to disable it:
updateOptions := updateOptions.value.withLatestSnapshots(false)
Ivy by default uses latest-revision as the latest strategy. This strategy I don't think takes in account for the possibility that a changing revision may exist in multiple repositories/resolvers with having identical version number like 0.1.0-SNAPSHOT.
The implementation is a bit hacky, but I think it attacks the core of this problem.
* Create a project "common" which publishes a "bad" artifact.
* Resolve project "dependent" which resolves the "bad" artifact into the cache.
* Publish a new "common" snapshot to a diffferent repository (publishLocal)
* Attempt to build the new project, leading to issues.
Commit a1e26ca6 broke the `make-pom` & `pom-advanced` dependency-management
tests by replacing one reference to `IBiblioResolver.DEFAULT_M2_ROOT` in
`Resolver`, but not the other reference in `MakePom`:
https://travis-ci.org/sbt/sbt/jobs/31939788#L2517-L2519
...the secure url was no longer recognised as the default Maven Repository
root, so was erroneously exported.
Havoc Pennington
Grzegorz Kossakowski
Martin Duhem
Eugene Yokota
Ben McCann
Josh Suereth
Roberto Tyley