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.
This implements all stories from https://github.com/sbt/sbt/wiki/User-Stories%3A-Conflict-Warning.
When scalaVersion is no longer effective an eviction warning will display.
Scala version was updated by one of library dependencies:
* org.scala-lang:scala-library:2.10.2 -> 2.10.3
When there're suspected incompatibility in directly depended Java libraries,
eviction warnings will display.
There may be incompatibilities among your library dependencies.
Here are some of the libraries that were evicted:
* commons-io:commons-io:1.4 -> 2.4
When there's suspected incompatiblity in directly depended Scala libraries,
eviction warnings will display.
There may be incompatibilities among your library dependencies.
Here are some of the libraries that were evicted:
* com.typesafe.akka:akka-actor_2.10:2.1.4 -> 2.3.4
This also adds 'evicted' task, which displays more detailed eviction warnings.
Add scala 2.11 test/build verification.
* Add 2.11 build configuratoin to travis ci
* Create command which runs `safe` unit tests
* Create command to test the scala 2.11 build
* Update scalacheck to 1.11.4
* Update specs2 to 2.3.11
* Fix various 2.11/deprecation removals
and other changes.
Fix eval test failure in scala 2.11 with XML not existing.
1) non-default derived settings, if they produce anything, the settings
they produce must supersede previous assignents (in the settings seq)
to the same key.
2) even if a derived setting is scoped at a higher scope (e.g.
ThisBuild) the settings it produces are scoped at the intersection of
that (the defining) scope and the scope of the triggering dependency.
2 is particularly nice as it enables this behaviour:
derive(b in ThisBuild := a.value + 1)
a in project1 := 0
// a could be defined in all projects
==>
Now (b in project1).value == (a in project1).value + 1 == 1
and similarly in all other projects
all with a single derived setting
Antonio Cunei
eugene yokota
Grzegorz Kossakowski
Josh Suereth
David Pratt
Dan Sanduleac
Dan Sanduleac