Incremental compiler didn't have any explicit logic to handle
cancelled compilation so it would go into inconsistent state.
Specifically, what would happen is that it would treat cancelled
compilation as a compilation that finished normally and try to
produce a new Analysis object out of partial information collected
in AnalysisCallback. The most obvious outcome would be that the
new Analysis would contain latest hashes for source files. The
next time incremental compiler was asked to recompile the same files
that it didn't recompile due to cancelled compilation it would think
they were already successfully compiled and would do nothing.
We fix that problem by following the same logic that handles compilation
errors, cleans up partial results (produced class files) and makes sure
that no Analysis is created out of broken state.
We do that by introducing a new exception `CompileCancelled`
and throwing it at the same spot as an exception signalizing compilation
errors is being thrown. We also modify `IncrementalCompile` to
catch that exception and gracefully return as there was no compilation
invoked.
NOTE: In case there were compilation errors reported _before_
compilation cancellations was requested we'll still report them
using an old mechanism so partial errors are not lost in case
of cancelled compilation.
Specifically, when the Scala version for sbt is the same as that for the project being built,
the jars in UpdateReport should be the same as those in ScalaProvider. This is because the
loader will come from the ScalaProvider, which uses jars in the boot directory instead of the
cache. The first part of the fix for #661 checks that loaded classes come from the classpath
and so they need to line up.
Introduce a way to configure incremental compiler itself instead
of underlying Java/Scala compiler.
Specific list of changes in this commit:
* Add a method to `xsbti.compile.Setup` that returns incremental
compiler options as a `java.util.Map<String, String>`. We considered
statis interface instead of a `Map` but based on mailing
list feedback we decided that it's not the best way to go because
static interface is hard to evolve it by adding new options.
* Since passing `java.util.Map<String, String>` not very convenient
we convert it immediately to `sbt.inc.IncOptions`
* Add options argument to various methods/classes that implement
incremental compilation so in the end options reach
`sbt.inc.IncOptions` object
* Add `incOptions` task that allows users to configure incremental
compiler options in their build files. Default implementation of
that tasks returns just `IncOptions.DEFAULT`
* Both system property `xsbt.inc.debug` and `IncOptions.relationsDebug`
trigger debugging of relations now. In the near future, we should
deprecate use of `xsbt.inc.debug`.
- Read macro modifier from method definition.
- Always recompile downstream files after a file containing macro defs is recompiled.
- Source is extended with a hasMacro attribute. Mark suggests that this might be better
tracked in Relations, but I'm not sure how to make that change.
the custom scalac Reporter now delegates to an instance of
an sbt interface called xsbti.Reporter
handling compilation logging is now mainly done on the sbt-side of the
compiler interface
the xsbti.Reporter interface provides access to richer information
about errors and warnings, including source file, line, and offset
xsbti.Reporter can be implemented by users to get access to
detailed information without needing to parse the logging output
the CompileFailed exception that is thrown when compilation fails now
includes an array of the problems, providing detailed
error and warning information that can, for example, be consumed
by doing a mapFailure on 'compile' and using 'Compile.allProblems'
support lazy arguments in data type generator
SafeLazy implementation that explicitly clears the reference to the thunk
in API representation, drop synthetic modifier and merge deferred into abstract
handle cyclic structures in API generation, display, comparison, persistence
gzip compile cache file
bump to 2.8.1.RC3, project definition cleanup
fix main method detection to check for the right name
properly view inherited definitions
exclude constructors of ancestors
updated compile tests for new minimal AnalysisCallback
moved discovery to discovery/ subproject and updated for new approach
fixed discovery to only find public methods when searching for annotated definitions
extracting inherited definitions unimplemented in api/, so some discovery tests fail
moved discovery classes from sbt.inc package to sbt.compile
Reduce AnalysisCallback interface:
remove discovery
simplify dependency notification methods
Use map of classpath entry to Analysis for locating
source API for external dependencies
Handle classpath changes by locating class
on classpath and either locating Analysis/Source
as above or comparing Stamp. This requires storing
the class name of a binary dependency now.
Make this process aware of full classpath, including
boot classpath
* Fixes to API extraction and equality checking
* Reworked tracking
* New compile infrastructure based on API changes
* Example application for testing
Grzegorz Kossakowski
Mark Harrah
Paolo G. Giarrusso
Eugene Vigdorchik
Jason Zaugg