* Split Java analyzing compile into its own class.
* MixedAnalyzingCompiler now only does the mixing
* Start moving methods around to more-final locations
* Static analyzingCompile method now constructs a MixedAnalyzingCOmpiler and delegates to incremental compile.
* Removed as many binary incompatibilities as I could find.
* Deprecating old APIs
* Attempt to construct new nomenclature that fits the design of Incremental API.
* Add as much documentation as I was comfortable writing (from my understanding of things).
Since `DependencyContext` is needed in the compiler interface
subproject, it has to be defined in this same subproject.
`DependencyContext` is needed in this subproject because the
`AnalysisCallback` interface uses it.
* Create a new sbt.compiler.javac package
* Create new interfaces to control running `javac` and `javadoc` whether forked or local.
* Ensure new interfaces make use of `xsbti.Reporter`.
* Create new method on `xsbti.compiler.JavaCompiler` which takes a `xsbti.Reporter`
* Create a new mechanism to parse (more accurately) Warnings + Errors, to distinguish the two.
* Ensure older xsbti.Compiler implementations still succeed via catcing NoSuchMethodError.
* Feed new toolchain through sbt.actions.Compiler API via dirty hackery until we can break things in sbt 1.0
* Added a set of unit tests for parsing errors from Javac/Javadoc
* Added a new integration test for hidden compilerReporter key, including testing threading of javac reports.
Fixes#875, Fixes#1542, Related #1178 could be looked into/cleaned up.
The optimization, and therefore the change in the behavior
of Relation, is now needed by the class Logic, and cannot
be reverted.
This patch (written by Josh) therefore changes the
implementation of setAll() so that _1s is no longer used.
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.
Josh Suereth
Jean-Rémi Desjardins
eugene yokota
Grzegorz Kossakowski
Martin Duhem
Brian Topping
Antonio Cunei