The implementation of Relation should in theory make no difference
whether an element is unmapped, or whether it is mapped to an empty
set. One of the changes in 322f6de655
introduced an optimization to the '+' operation on Relations that,
in theory, should have made no difference to the semantic.
The result of that optimization is that some mappings of the form
"elem -> Set()" are no longer inserted in the forwardMap of the
Relation.
Unfortunately, the change resulted in the breakage of #1430,
causing "set every" to behave incorrectly. There must be, somewhere
in the code, a test on the presence of a key rather than an access
via <relation>.get(), or some other access that bypasses the
supposed semantic equivalence described above. I spent several
hours trying to track down exactly the offending test, without
success.
By undoing the relevant change in 322f6de655, "set every"
works again. That however offers no guarantee that everything else
will keep working correctly; the underlying quirk in the code that
depends on this supposedly inessential detail is also still
lurking in the code, which is less than ideal.
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.
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.
Antonio Cunei
Josh Suereth
eugene yokota
Daniel Peebles
James Ward
Grzegorz Kossakowski
Josh Kalderimis
Havoc Pennington