In some cases, expanded macros report that their original tree and
its expansion are the same, thus creating a cyclic chain. This chain
may then produce a SOE during dependencies or used names extraction.
This kind of problem was already reported in sbt/sbt#1237 and
sbt/sbt#1408. Unfortunately, the fix that was applied to the
dependencies extraction part was not sufficient.
Mark test 'source-dependencies/macro' as passing
Fixes#1544
The issue is that when you manually set a ScalaInstance, i.e. not one from Ivy, the
classpath which is returned for any given configuration ONLY uses Ivy. This means that
the legitimate Scala JAR files that need to be on the classpath are missing from the list.
For some reason, the way we instantiate tests uses an unfiltered classloader against the
ScalaInstance, *BUT* the thread-context-classloader DOES use a filtered instance by
classpath. This add the hook into the TestFramework runner creation so that
the classpath accurately reflects the jars needed.
cc @rkuhn
Fixes#1568.
This is the fallout of attempting not to leak config-file classes. Since
we DO NOT have valid incremental compiler for config-classes, we've instituted
workaround to ensure that regular incremental compilation *AND* our own
sbt loader do not hose each other. A full solution will eventually be
to find a way for .sbt files to participate in regular compilation of a
project.
For now, we fix the tracking of generated.class files throughout an sbt
"loadProjects" call, and then clean any .class files that were not
generated for a full reload. This commit just fixes
a minor tracking issue.
Fixes#1565
* Create two chains if we have inter-project resolver
- One which ensures inter-project deps are always taken
- One which will look in all "other" repositories for
dependencies and will use the "most up-to-date" -SNAPSHOT
strategy.
* No additional tests, as this would simple break every
multi-project test if it were wrong.
There is sometimes the need to use a test version of Scala that is
intended to be binary compatible with a standard release version.
At this time, due to the particular logic implemented within sbt,
a non-numeric suffix will never have the same binaryScalaVersion
of a release version ending in ".0", like for instance "2.11.0".
This commit allows developers to use as suffix any string that
begins with "-bin", for instance "2.11.0-bin-compat-test-1".
Such a suffix will have a binaryScalaVersion of "2.11", being
therefore considered binary compatible with release versions.
Travis CI stopped allowing long file names on its file system. We need
to explicitly set lower limit on file name length using
`-Xmax-classfile-name` Scala compiler option. We set the limit to 240
characters.
Fixes#1553
Name hashing is now turned on by default, so I’m changing the value for
inc.Relations.empty, so inc.Analysis.empty functions as expected when
it’s joined with name hashing analyses.
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.
Grzegorz Kossakowski
eugene yokota
Josh Suereth
Martin Duhem
Daniel Peebles
Antonio Cunei
James Ward
Josh Kalderimis