sbt, the interactive build tool
Go to file
Antonio Cunei e0dd2e6a4c This commit reverts part of 322f6de655
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.
2014-09-11 02:04:17 +02:00
cache Scalariforming test code 2014-05-07 11:52:23 -04:00
interface Add hashing of public names defined in a source file. 2013-12-04 01:34:18 +01:00
util This commit reverts part of 322f6de655 2014-09-11 02:04:17 +02:00
LICENSE Update CONTRIBUTING.md 2014-04-14 12:16:06 -04:00
NOTICE Update CONTRIBUTING.md 2014-04-14 12:16:06 -04:00